Hi again! Sorry for the delay, and thank you for bringing this up for discussion. I enjoy pondering over why we did (or didn’t) do things, so I am sure we made the right choice or otherwise need to make amends. This suggestion is new to me, so let’s dive into the arguments.
The overhead added by the sitemap is little, and should not be notable at for small sites. The energy footprint of small sites compared to larger ones is also something to consider.
If we were to test the number of items that belong in the sitemap before we actually output a sitemap, that’d add a significant load to many sites.
Before considering this, we’d have to measure the actual economics of this feature. Since I practically perfected its load-sequence, I think I am safe to assume that testing whether this feature might be useful would consume more energy than it saves.
First, we’d have to test whether to load the sitemap on /robots.txt before adding a link. Second, we’d have to recount all posts during a post-save sequence. And most importantly, search engines will try the /sitemap.xml
without a prompt — them landing on a 404-page after WordPress tests whether the request is viable consumes more energy than loading TSF’s sitemap directly.
Adding a toggle to completely disable the sitemap entirely (without falling back to WordPress Core’s sitemap), adds more text and options for me to check and maintain, hence eating up my time and our user’s server resources.
With the toggle, I must also consider the user’s requirements and intent: Do they understand what a sitemap is for, and if so, have they considered all the pros and cons of disabling it? I think the pros are relatively insignificant compared to the cons. Explaining all this next to the options, and adding translations for several languages, is also a large task.
Lastly, not all sites have proper internal linking. A sitemap would save those sites from not being indexed at all, although relying on the sitemap is a bad practise.
I think I covered everything. Let me know what you think!