Fix WordPress XML Sitemap Returning 404 (Yoast/Rank Math)

Google Search Console shows a red "Couldn't fetch" next to your sitemap, or you click the sitemap link in your SEO plugin and get a plain 404 page instead of XML. It's one of those errors that doesn't break your site for visitors, so it sits unnoticed for weeks — until you realize new pages have stopped getting indexed. Here's how to actually track down why it's happening and fix it for good.

Symptom

You visit yourdomain.com/sitemap_index.xml (or /sitemap.xml) and instead of an XML file listing your pages, you get your theme's normal 404 page, a blank white screen, or a raw "File not found" from Apache/Nginx. Google Search Console's Sitemaps report shows a red status with "Couldn't fetch" or "Sitemap could not be read." Sometimes it works in a browser but Google still can't fetch it — that's usually a caching or firewall issue, covered below.

Cause

Sitemaps in WordPress aren't static files sitting in your document root (unless you've generated a physical one). They're generated on the fly by rewrite rules that intercept the request and hand it to PHP. When that chain breaks, you get a 404. The usual culprits, roughly in order of how often we see them:

• Permalinks are set to "Plain." Pretty sitemap URLs need pretty permalinks. If your site is using ?p=123 style links, the sitemap rewrite rule was never registered.
• Stale rewrite rules. WordPress caches its rewrite rules in the database. Installing or switching SEO plugins doesn't always trigger a fresh flush, so the old plugin's rules linger and the new plugin's sitemap route never gets registered.
• Two SEO plugins fighting over the same URL. Yoast, Rank Math, and All in One SEO all want to own /sitemap_index.xml. If more than one is active (even a leftover one you thought you deactivated), the requests collide and one wins unpredictably.
• A security plugin or firewall is blocking the request. Wordfence, All In One WP Security, or a server-level mod_security rule can flag .xml requests or bot-heavy traffic patterns and return a 403 that your theme renders as a generic error page.
• Page caching is serving a stale 404. If the sitemap 404'd once — say, during a plugin switch — and you're running full-page caching (LiteSpeed Cache, WP Super Cache, or a CDN edge cache), that 404 response can get cached and served to every visitor and bot afterward, even after the real fix is in place.
• robots.txt is disallowing the path. This won't cause the 404 itself, but it's often found alongside it: a leftover Disallow: /*.xml$ or Disallow: /sitemap* rule blocks Googlebot from ever reaching a perfectly working sitemap.
• Multisite subdirectory conflicts. On a WordPress multisite network using subdirectories, sub-sites can end up with sitemap requests routed to the wrong site's rewrite table.

Fix

Work through these in order — most sites are fixed by the first two steps.

1. Check your permalink structure

Go to Settings > Permalinks in wp-admin. If it's set to "Plain," switch to "Post name" (or any structure other than Plain), then hit Save Changes. Saving this screen is what actually flushes and rewrites the rules — just looking at it doesn't help.

2. Force a rewrite flush from the command line

If you have SSH/terminal" class="auto-link">WP-CLI access, this is faster and more reliable than clicking Save twice:

wp rewrite flush --hard

No WP-CLI? Go to Settings > Permalinks, switch to a different structure, save, switch back, save again.

3. Make sure only one SEO plugin is active

Go to Plugins and confirm you only have one of Yoast SEO, Rank Math, or All in One SEO active. If you migrated between them, fully deactivate and delete the old one — deactivated-but-installed is usually fine, but a half-migrated setup with leftover options tables can still cause route conflicts.

4. Test the URL directly, bypassing cache

Open the sitemap URL in an incognito window with a cache-busting query string:

https://yourdomain.com/sitemap_index.xml?nocache=1

If that loads correctly but the plain URL still 404s, you've confirmed it's a caching problem, not a WordPress routing problem. Purge your page cache plugin, then purge Cloudflare or any CDN cache in front of the site, then re-test the plain URL.

5. Check your security plugin and server firewall logs

In Wordfence, check Tools > Live Traffic or the firewall's blocking log for requests to /sitemap_index.xml around the time you tested. If cPanel-level ModSecurity is the culprit, check WHM > ModSecurity Audit Log or ask us to pull it — look for a rule ID tied to the request and whitelist that specific path rather than disabling ModSecurity entirely.

6. Confirm robots.txt isn't blocking it

Visit yourdomain.com/robots.txt and make sure there's no line like Disallow: /sitemap.xml or a wildcard rule catching .xml files. Most SEO plugins add a Sitemap: line automatically — if it's missing, add it manually:

Sitemap: https://yourdomain.com/sitemap_index.xml

7. Know which URL your plugin actually uses

Requesting the wrong path is a surprisingly common false alarm. Double check against this table before assuming something's broken:

8. Multisite? Check the site ID in the URL

On subdirectory multisite, each sub-site's sitemap should be under its own path, e.g. /site2/sitemap_index.xml. If Google is fetching the root domain's sitemap URL for a sub-site, update the sitemap submitted in Search Console to match the sub-site's actual path.

Prevention

A few habits keep this from coming back:

• Whenever you switch SEO plugins, immediately run wp rewrite flush --hard as part of the migration, not as an afterthought.
• After any plugin change that touches URLs, purge every layer of cache — page cache plugin, LiteSpeed/OPcache, and any CDN — in that order.
• Submit the exact sitemap URL in Google Search Console rather than letting Google guess it from robots.txt, and re-check the Sitemaps report a day after any plugin change.
• If you're on shared hosting with ModSecurity, ask your host to whitelist your sitemap path by rule ID rather than turning the firewall off for the whole account.

Frequently Asked Questions

Why does my sitemap work when I'm logged into WordPress but 404 for everyone else?

That's almost always a caching issue. Logged-in users typically bypass page cache, so you're seeing the live, correct version while anonymous visitors and bots get a stale cached 404. Purge your cache plugin and any CDN edge cache.

Can I just upload a static sitemap.xml file instead of relying on the dynamic one?

You can, but it defeats the point of using an SEO plugin's sitemap — it won't auto-update when you publish new content. If you go this route, make sure the static file doesn't conflict with the plugin's own rewrite rule, or you'll get inconsistent results depending on which one WordPress matches first.

I flushed rewrite rules and it still 404s. What now?

Check for a .htaccess file that's missing the WordPress rewrite block entirely, or one where the block has been manually edited and is out of date. Compare it against a fresh copy: WordPress regenerates the standard block automatically when you save Permalinks settings, provided the file is writable.

Does a broken sitemap actually hurt my SEO?

Indirectly, yes. Google can still crawl and index your site without a sitemap by following internal links, but a working sitemap speeds up discovery of new and updated pages significantly, especially on larger sites. A sitemap that's been broken for a while is also a signal worth investigating — it often means something else changed on the site around the same time.

My sitemap loads fine but Search Console still says it can't fetch it. Why?

Check that your robots.txt isn't blocking Googlebot specifically (a User-agent: * disallow will catch it too), and confirm the sitemap URL you submitted in Search Console exactly matches the live URL, including https:// and any trailing differences. A mismatched protocol or www/non-www version is a common cause.