What is wp-sitemap.xml? It is the XML sitemap WordPress generates by itself, with no plugin involved, at /wp-sitemap.xml on every WordPress site running version 5.5 or later. Core sitemaps shipped in August 2020, and since then a stock WordPress install has told Google where its content lives out of the box.
That sounds like a solved problem, and mostly it is. The reason the file still turns up in my audits is that almost nobody runs stock WordPress. The moment an SEO plugin arrives, a second sitemap arrives with it, and the two start competing in ways Search Console reports very quietly.
What wp-sitemap.xml contains
The file at /wp-sitemap.xml is a sitemap index, not a list of pages. It points to child sitemaps, and WordPress builds one group of children per content type it exposes:
- Posts and pages, one sitemap per public post type, split into files of up to 2,000 URLs each.
- Taxonomies, categories and tags with published content in them.
- Users, meaning author archive pages, plus the homepage.
The limits come straight from the implementation: up to 50,000 sitemaps in the index and up to 2,000 URLs per sitemap, with the per-file number filterable through wp_sitemaps_max_urls. The sitemap protocol itself allows 50,000 URLs per file, so WordPress runs well under the ceiling on purpose, to keep generation cheap on shared hosting. I went through what the protocol permits in how many URLs can a sitemap have.
WordPress also adds the sitemap reference to your robots.txt automatically. If your robots.txt is the virtual one WordPress generates, you will find a Sitemap: line in it that you never wrote. I covered how that virtual file works in where is robots.txt in WordPress.
Why wp-sitemap.xml has no lastmod
Open any child sitemap and you will notice each entry is a bare <loc> tag. No <lastmod>, no <changefreq>, no <priority>. That is deliberate. The core developer note says the optional tags were left out because they are either ignored by search engines or hard to populate accurately, and a wrong lastmod is worse than none.
They have a point on two of the three: Google has said for years that it ignores changefreq and priority. But lastmod is the exception, because Google does use it when it has proven trustworthy, and it is the one signal that can get a changed page recrawled sooner. I went through the evidence in does Google use lastmod in sitemaps, and it is the main functional reason SEO plugin sitemaps are more useful than the core one: Yoast, Rank Math and the rest emit real lastmod dates from the database.
Should I disable wp-sitemap.xml?
If an SEO plugin generates a sitemap for you, yes, one of the two should go, and every major plugin handles this by disabling the core sitemap when its own is active. The failure mode I see in audits is the leftover: a Search Console property with both sitemap_index.xml from a plugin and wp-sitemap.xml submitted, where one of them now redirects or 404s because the plugin changed at some point and nobody revisited the Sitemaps report. Google copes, but your report fills with fetch errors that mean nothing, and real errors hide behind them.
For what it is worth, this site is not WordPress at all, and its server logs still record regular requests for /wp-sitemap.xml from crawlers and scanners probing for it. The path is so standard that bots check it on every site. On mine those requests get a 404, which is the correct answer for a site that has no WordPress in it.
Two more things turn the whole file off. The “Discourage search engines from indexing this site” checkbox disables core sitemaps along with everything else, which is one more way that setting quietly outlives a launch, something I covered in the discourage search engines setting. And a developer can return false from the wp_sitemaps_enabled filter.
How do I remove users from wp-sitemap.xml?
The users sitemap is the part most sites actually want gone, because author archives on a single-author blog are duplicate listings of the posts, and because it publishes every author slug. Core provides the wp_sitemaps_add_provider filter for exactly this: return false when the provider name is users and the child sitemap disappears. The same filter removes taxonomies, and wp_sitemaps_post_types trims post types. No plugin needed for any of it.
The check that matters afterwards is not the code, it is Search Console. Open the Sitemaps report, look at what is actually submitted for the property, fetch each submitted URL in a browser, and delete the entries that no longer return a sitemap. Five minutes, and the report goes back to meaning something.
One thing that quietly breaks the sitemap line in robots.txt is worth knowing about, because it has nothing to do with sitemap settings: creating a physical robots.txt file stops core generating the virtual one, and the Sitemap: line goes with it. The default robots.txt for WordPress covers that precedence.
Sources
- WordPress core, XML sitemaps in WordPress 5.5 developer note, on the index structure, providers, loc-only entries and filters, checked 30 August 2026
- Google Search Central, sitemaps overview, on what sitemaps do and the 50,000 URL protocol limit
- Google Search Central, build and submit a sitemap, on lastmod being used when consistently accurate and changefreq and priority being ignored