Why 4 sitemaps

Hello!

TSF’s sitemaps are dynamic and have unlimited sitemap endpoints, accessible from /sitemap.xml. You can add anything, like /sitemap.xmlanything. This is to support any random translation plugin because they add /es/ or ?lang=es to the sitemap. See https://tsf.fyi/kb/a/104#same-site-sitemaps.

This also accounts for the /sitemap_index.xml endpoint — a duplicate endpoint of /sitemap.xml. We had to add this because Yoast still spreads wrong information about NGINX configurations. See https://tsf.fyi/p/3251#features-sitemap.

All these sitemaps are identical (they run the same code for output and caching). If you have an active translation plugin, the sitemaps may differ depending on the language requested.

You only need to submit /sitemap.xml to Google and Bing if you do not have a translation plugin. If that endpoint redirects to /sitemap_index.xml, then you can submit that instead.

It’s best to submit a sitemap of each translation if you have a translation plugin.

Thank you @cybr. But I don’t use neither Yoast nor a translation plugin. So should these sitemaps still exist?

Hello!

When we register the sitemap endpoints, we are yet unaware if any (exotic) translation plugin is active, nor how they’re configured. The translation plugin changes the language based on the endpoint parameters, such as ?lang=es, at which point we can read the language registered and generate a different sitemap if needed.

As for the Yoast SEO endpoint, we added it not because of Yoast SEO’s plugin but because of their erroneous documentation. This documentation causes some bad hosts to only support Yoast SEO’s sitemap endpoint (by, for example, redirecting /sitemap.xml to /sitemap_index.xml). This can make our /sitemap.xml endpoint unavailable — hence, we also support the /sitemap_index.xml endpoint to display a sitemap. When we register the sitemap endpoints, we cannot tell how the site/host responds to them — so we register them all.

The registration of these endpoints does not affect the rest of the site, so removing them is unnecessary. Allowing users to toggle these alternative endpoints doesn’t help the user in any beneficial way (not even for performance); it’ll only confuse them. Hence, we do not provide an option.