asquaresolution.com/sitemap_index.xml returned HTTP 404 despite robots.txt correctly declaring the sitemap URL and Rank Math's XML sitemap being enabled in plugin settings. Root cause: WordPress rewrite rules cache was stale — the URL handler for the sitemap was no longer registered. Fix: flush and rebuild rewrite rules by saving Permalinks settings without any changes.
Resolution Steps
During the May 2026 WordPress SEO technical audit, a curl check of the sitemap URL confirmed:
curl -I "https://asquaresolution.com/sitemap_index.xml"
# HTTP/1.1 404 Not Found
The robots.txt file correctly declared:
Sitemap: https://asquaresolution.com/sitemap_index.xml
And Rank Math's plugin settings showed XML Sitemap as enabled. From WordPress's perspective, the sitemap should exist. But it didn't.
Google Search Console had been receiving the sitemap URL for weeks. The GSC sitemap report showed "Couldn't fetch" — Google's crawler was hitting the same 404.
WordPress uses a rewrite rules system to map pretty URLs to internal query parameters. The URL /sitemap_index.xml is not a physical file — it's a virtual URL that WordPress maps to Rank Math's sitemap generation handler via registered rewrite rules.
These rewrite rules are stored in the WordPress database option rewrite_rules. They are regenerated ("flushed") when:
flush_rewrite_rules()If the rewrite rules are flushed but not rebuilt (which can happen during certain plugin updates, core updates, or server-level PHP opcode cache clears), the sitemap_index.xml mapping disappears. WordPress then falls through to its default 404 handler.
The fix — saving Permalinks without changes — works because WordPress always regenerates and saves the full rewrite rules table on any Permalinks save. This is the documented WordPress method for forcing a rewrite flush.
Why not just deactivate/reactivate Rank Math? Plugin reactivation also triggers a rewrite flush and rebuild, but it's a heavier operation. Saving Permalinks is the minimal-impact approach.
Why not just call flush_rewrite_rules() via WP-CLI? That works too:
wp rewrite flush
But the WP Admin approach requires no server access and is appropriate in a managed hosting environment.
The sitemap 404 had been in place for an unknown duration before the audit. Google Search Console showed the sitemap in "Couldn't fetch" state. After fixing the 404 (saving Permalinks, confirming HTTP 200), the sitemap was re-submitted in GSC and the status changed to "Success" on the next crawl cycle.
Implication: During the 404 period, Googlebot's ability to discover new URLs on asquaresolution.com was reduced to following links from existing indexed pages and external backlinks. The sitemap XML — which provides explicit URL lists, change frequencies, and priority signals — was unavailable to the crawler for indexing decisions.
When a sitemap URL returns 404:
curl -I directly to the origin, bypass any Cloudflare or CDN layer with --connect-to if necessarywp rewrite list | grep sitemap — if no result, the rule is not registeredIn the asquaresolution.com case, step 2 confirmed the plugin was enabled, making stale rewrite rules the most likely cause — which was immediately confirmed after the Permalinks save.
wp rewrite flush to ensure rules are currentcurl -I domain.com/sitemap_index.xml as a quick automated checkFix Confidence
Recovery Complexity
Pattern Family
This failure belongs to a named recurring pattern. Other failures in this family share the same root cause structure — understanding the pattern prevents multiple failure types simultaneously.