sitemap_index.xml not working in WordPress: how to fix it

Which sitemap address your site should have

Since WordPress 5.5, core generates a sitemap at /wp-sitemap.xml. SEO plugins that build their own sitemaps turn the core one off and use a different address. Asking for the wrong address is the most common reason a sitemap seems missing:

If you switch a plugin's sitemap off, its address stops working and the core sitemap usually returns. If you remove the plugin entirely, the same happens. Requests for /sitemap.xml are redirected to whichever index is active in many setups, so that address is a useful test but not a guarantee.

The index itself contains no pages. It lists child sitemaps, such as post-sitemap.xml and page-sitemap.xml in Yoast and Rank Math, or wp-sitemap-posts-post-1.xml in core. A working index with broken children is a separate problem worth checking too.

What each symptom usually means

Look at the page itself first. A WordPress-styled error page means WordPress received the request and decided nothing matched. A bare page with nginx at the bottom means WordPress never saw it, which points at the server configuration rather than any setting inside WordPress.

How to diagnose it

Request the index and look at the status line, content type and the very first bytes of the body:

curl -sI https://www.example.com/sitemap_index.xml
curl -s https://www.example.com/sitemap_index.xml | head -c 80 | od -c | head -n 3

A healthy response is 200 with a content type of text/xml or application/xml, and the body starts with <?xml. If od shows \n or a space first, a line break or space was printed before the declaration. If it shows 357 273 277, the octal form of a UTF-8 byte order mark, a PHP file was saved with a BOM.

Then test with caches out of the way. Add a throwaway query string, such as ?nocache=1, and compare. If the fresh request works and the plain one does not, a cache is serving a broken copy. Request one child sitemap too, because a broken child can fail on its own.

In a browser, view the source of the sitemap rather than the styled view. Yoast and Rank Math attach an XSL stylesheet that makes the sitemap look like a web page, which can hide what is really at the top of the file. If Search Console reports the sitemap as unreadable, see Sitemap could not be read for the checks Google applies.

Rewrite rules and nginx

Yoast and Rank Math sitemaps are not files on disk. They are built by WordPress when a request arrives, so the server has to pass the request to WordPress. On Apache, the standard WordPress block in .htaccess does that, and saving Settings, then Permalinks, rebuilds both WordPress's internal rules and that block when the file is writable.

nginx does not read .htaccess. The server block needs a try_files line that sends anything that is not a real file to index.php:

location / {
    try_files $uri $uri/ /index.php?$args;
}

With that in place, WordPress usually handles /sitemap_index.xml on its own. The trouble starts when another location block matches the address first. Many configurations include a block like this for static files:

location ~* \.(xml|txt|css|js|png|jpg|svg)$ {
    expires 30d;
    try_files $uri =404;
}

Because regex locations take priority over location /, any address ending in .xml is looked up on disk, not found, and answered with nginx's own 404. Either remove xml from that list, change =404 to /index.php?$args, or add the rewrite lines that Yoast and Rank Math both document for nginx above it:

rewrite ^/sitemap_index\.xml$ /index.php?sitemap=1 last;
rewrite ^/([^/]+?)-sitemap([0-9]+)?\.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;

Check the current wording in your plugin's documentation, since plugins occasionally change their query names. After any edit, run sudo nginx -t and then sudo systemctl reload nginx. On Plesk, add custom directives under Apache and nginx Settings for the domain rather than editing generated files, which are overwritten. For nginx redirects more generally, see fixing redirects in Plesk.

Finding stray output and cache problems

The XML declaration must be the first thing in the response. Chrome reports a violation as XML declaration allowed only at the start of the document, and Firefox as XML or text declaration not at start of entity. The usual source is a PHP file that ends with ?> followed by a blank line, or a file saved with a byte order mark. Every request then starts with that stray character, which is harmless in HTML and fatal in XML.

To find a BOM in theme and plugin files, run this from the WordPress root:

grep -rlI --include='*.php' $'^\xEF\xBB\xBF' wp-content/themes wp-content/plugins wp-config.php

For blank lines after a closing tag, open the files you or a developer edited recently, starting with the child theme's functions.php. Remove the closing ?> at the end of the file altogether; PHP does not need it, and leaving it out prevents the problem. If you cannot see the culprit, test by elimination with WP-CLI, which avoids clicking through the dashboard:

wp theme activate twentytwentyfive
wp plugin deactivate plugin-name

Reload the sitemap after each change, and switch everything back once you have found the file responsible.

Caching and minification

Page caching and HTML minification plugins sometimes store or rewrite the sitemap as if it were a page. Add sitemap and .xml to the cache exclusions, switch off minification for those addresses, then purge. Yoast and Rank Math also keep their own sitemap cache; turning the sitemap feature off, saving, turning it back on and saving again refreshes it. If a CDN cache rule caches everything, exclude sitemap addresses there too. The sitemap lastmod guide explains why a stale copy also misleads crawlers about what has changed.

A worked example

A WordPress site moves from shared Apache hosting to a VPS running nginx. The home page loads normally, so the move looks finished. A week later, Search Console reports the sitemap as unreadable. Opening /sitemap_index.xml shows a plain 404 page with nginx at the bottom.

The plain page shows WordPress never saw the request. The new server block, copied from a static site template, has no try_files line in location /, so only the home page, which nginx passes to index.php as the index file, ever reaches WordPress. Adding location / { try_files $uri $uri/ /index.php?$args; }, running nginx -t and reloading brings the sitemap back.

A check of other addresses shows posts, category archives and the feed had also been returning 404 since the move. Visitors mostly arrived on the home page, so nobody had noticed. The sitemap was the first thing reported, not the only thing broken.

The fix, step by step

Edge cases worth knowing

• Two sitemap generators. Yoast and Rank Math together, or an SEO plugin plus a dedicated sitemap plugin, fight over the same address. Keep one and turn the sitemap feature off in the others.
• Search engine visibility. If Discourage search engines is ticked under Settings, then Reading, the core sitemap is switched off. Untick it on a live site.
• Noindexed content. SEO plugins leave content set to noindex out of the sitemap. A post type or taxonomy marked as not shown in search results disappears from the index, which looks like a missing child sitemap.
• Large sites. Plugins split sitemaps into numbered children. If a child times out or runs out of memory, lower the number of entries per sitemap where the plugin allows it. See fixing sitemap size.
• Security rules. A firewall that challenges bots can block crawlers from the sitemap even when it loads for you.

Keeping it fixed

After any migration, plugin change or server change, open the sitemap index straight away with curl and check for a 200, an XML content type and a body that starts with the declaration. It is often the first thing to break and the last thing anyone checks. Keep one sitemap generator, list its address in robots.txt with a Sitemap: line, and look at the Sitemaps report in Search Console each month for its last read date and status. The sitemap declaration guide covers the robots.txt line, and robots.txt and sitemaps in WordPress covers the wider setup.