WordPress Sitemap Returning 404? Causes and the Fix

Google Search Console is throwing "Couldn't fetch" on your sitemap, or you've typed yourdomain.com/sitemap_index.xml into a browser and gotten a flat 404. It's one of the more annoying WordPress issues because the site itself works fine - it's just this one XML file that won't load. Here's why it happens and how to fix each cause.

Symptom: What You're Actually Seeing

Usually it's one of these three:

• Search Console's Sitemaps report shows a red "Couldn't fetch" status next to a 404 code.
• Visiting the sitemap URL directly in a browser returns WordPress's standard 404 page (not a server error, not blank - a real themed 404).
• The sitemap loaded fine last month and just stopped working after a plugin update or a migration.

The fact that you get WordPress's own 404 page (rather than an Nginx/Apache-level error) is a clue: WordPress is answering the request, it just doesn't recognize the URL as a valid sitemap route anymore. That points to permalinks or plugin routing, not a server misconfiguration - though there are exceptions, covered below.

Cause 1: Permalinks Weren't Re-Saved After a Change

WordPress sitemaps (both the built-in /wp-sitemap.xml since WP 5.5, and the ones generated by SEO plugins) are registered as rewrite rules, not physical files. Rewrite rules are cached in the database and only regenerate when you visit Settings → Permalinks and click Save - or when certain plugin activation hooks fire.

If you recently:

• Changed the permalink structure
• Migrated the site (a database import doesn't always trigger a rewrite flush)
• Activated or deactivated an SEO plugin
• Restored from a backup

...the rewrite rule for the sitemap can go stale, and every sitemap URL 404s even though nothing else on the site is broken.

Fix: Go to Settings → Permalinks in wp-admin and click Save Changes without changing anything. This forces WordPress to rebuild the rewrite rules table. If you don't have admin access to click through the UI (e.g. you're doing this via WP-CLI on a migration script), run:

wp rewrite flush --hard

The --hard flag also rewrites the .htaccess file on Apache setups, which matters for the next cause.

Cause 2: Two SEO Plugins Both Claim the Sitemap

This is the most common one we see in support tickets. Yoast SEO, Rank Math, and All in One SEO all generate a sitemap at a similar URL (usually /sitemap_index.xml or /sitemap.xml), and each one registers its own rewrite rule for it on activation.

If a site had Yoast installed at some point, then someone switched to Rank Math without fully deactivating Yoast (or a staging clone still has both plugins in the database with one merely "inactive" but leftover options rows), the rewrite rules can conflict. Whichever plugin's hook runs last during the request wins - and sometimes neither wins cleanly, so you get a 404.

Fix:

1. Go to Plugins and confirm only one SEO plugin is active. Fully deactivate (not just disable a module in) any others.
2. Check each plugin's sitemap toggle is actually on - Rank Math: General Settings → Sitemap Settings; Yoast: SEO → Settings → Site features → XML sitemaps.
3. Flush permalinks again (Settings → Permalinks → Save) after deactivating the extra plugin.

Here's the default sitemap URL for the common ones, so you know what you should actually be hitting:

If you submitted /sitemap.xml to Search Console but you're actually running Yoast, that URL will 404 even though the real sitemap works fine at /sitemap_index.xml. Worth double-checking before you assume something's broken.

Cause 3: Caching Is Serving a Stale 404

If you fixed the permalink issue above and the sitemap still 404s, clear cache everywhere before troubleshooting further. A full-page cache (LiteSpeed Cache, WP Super Cache, or a CDN like Cloudflare) can cache the 404 response itself and keep serving it even after the underlying rewrite rule is fixed.

Fix, in order:

1. Purge the WordPress caching plugin's cache (usually a one-click "Purge All" button in its admin bar menu).
2. If you're on Cloudflare, go to Caching → Configuration → Purge Everything, or purge just the sitemap URL under Custom Purge.
3. If you're using LiteSpeed at the server level (not just the WP plugin), clear it from cPanel's LiteSpeed Cache Manager too - the plugin cache and the server-level cache are separate layers.

Test with a cache-busting query string to confirm: yourdomain.com/sitemap_index.xml?nocache=1. If that loads but the clean URL doesn't, it's cache, not the sitemap itself.

Cause 4: .htaccess Rewrite Rules Are Missing or Broken

On Apache/LiteSpeed hosting, WordPress relies on .htaccess to route pretty-permalink requests (including sitemaps) through index.php. If the file got overwritten during a migration, a security plugin rewrote it and broke the block, or file permissions locked WordPress out of editing it, the sitemap rewrite never reaches WordPress at all - and you'll usually get a server-level 404, not WordPress's themed one.

Fix: Check that your .htaccess has the standard WordPress block:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If it's missing, re-save permalinks (Cause 1) to regenerate it, or paste the block above manually via cPanel's File Manager if wp-admin is inaccessible. Also confirm the file is writable (644) and owned by your hosting user - a permissions issue silently blocks WordPress from rewriting it on future flushes.

Cause 5: robots.txt or a Security Rule Is Blocking It

Less common, but worth ruling out: if a custom robots.txt has a blanket Disallow: /*.xml$ rule, or a security plugin / ModSecurity rule is blocking requests containing "xml" in the path, Search Console will report the sitemap as blocked rather than technically 404 - but some setups return a 403 or 404 depending on how the block is implemented.

Fix: View yourdomain.com/robots.txt directly and make sure there's no rule disallowing the sitemap path. If you're on Getwebup hosting and suspect a ModSecurity rule is involved, check cPanel → Security → ModSecurity for a recent hit against the sitemap URL, and whitelist that specific rule ID rather than disabling ModSecurity site-wide.

Prevention

• Whenever you switch SEO plugins, fully deactivate and delete the old one - don't leave it dormant.
• After any migration or backup restore, flush permalinks as a standard step, not an afterthought.
• Submit the correct sitemap URL to Search Console for the plugin you're actually running, and re-check it after a plugin switch.
• If you use a CDN or full-page cache, exclude XML sitemap paths from long-TTL caching so a fix doesn't get masked by a stale cached 404.

Still 404ing?

If you've gone through all five causes and it's still broken, the fastest diagnostic is checking your server's raw access log for the actual request (cPanel → Metrics → Raw Access, or tail -f /var/log/apache2/access.log on a VPS) to see the real HTTP status code WordPress or the web server returned, rather than relying on what Search Console reports - Search Console's cache of the error can lag behind the actual current state by a day or more.