Modern WordPress can generate `/wp-sitemap.xml`. A 404 may be a rewrite failure; an empty or wrong-host sitemap may be a visibility or URL-setting problem. An SEO plugin may intentionally replace the core endpoint.
Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: check WordPress sitemap routing, rewrite rules, public visibility, canonical host, plugin ownership, and cache behavior before submitting it.
What the symptom narrows down
- Pretty-permalink rewrite rules do not reach WordPress.
- Search engine visibility, a filter, or an SEO plugin disables/replaces the core sitemap.
- Home/siteurl, migration data, or cache emits old-domain URLs.
The branches are ordered to protect the strongest evidence around this possibility: pretty-permalink rewrite rules do not reach WordPress. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Crawlability, indexability, and canonical selection are separate; a crawler may discover a URL it cannot fetch, fetch a URL marked noindex, or index a different canonical than the publisher prefers; test the live HTTP response and rendered document before interpreting a report label; in this guide, the practical goal is to check WordPress sitemap routing, rewrite rules, public visibility, canonical host, plugin ownership, and cache behavior before submitting it.
Evidence to collect before the fix
- Request
/wp-sitemap.xmlwithcurl -iand inspect status, Content-Type, body, and redirects. - Check whether an SEO plugin owns a different sitemap endpoint.
- Open child sitemaps and sample canonical URLs as a logged-out user.
- Compare WordPress URL settings and clear only the sitemap cache.
The sequence moves from observation toward intervention. Preserve the result of the final check—compare WordPress URL settings and clear only the sitemap cache—because it provides a useful comparison after the repair.
Worked diagnostic: evidence before action
Begin with the first plausible cause: pretty-permalink rewrite rules do not reach WordPress. Before changing state, write down what would confirm it and run the first read-only check: request /wp-sitemap.xml with curl -i and inspect status, Content-Type, body, and redirects.
If the result supports that cause, try one bounded repair on staging: repair rewrite routing or save Permalinks once. If evidence from “Request /wp-sitemap.xml with curl -i and inspect status, Content-Type, body, and redirects” points elsewhere, keep this layer unchanged and move to the next check. That small decision log is far easier to audit than several simultaneous edits.
Validate the sitemap response and sample URLs
Inspect the status, redirects, content type, and the first lines of XML before submitting the sitemap again.
curl -sS -D /tmp/sitemap.headers \
-o /tmp/sitemap.xml https://example.com/wp-sitemap.xml
sed -n '1,20p' /tmp/sitemap.headers
sed -n '1,20p' /tmp/sitemap.xmlInterpretation and safety: Remove the temporary files after review. Open several child-sitemap URLs and confirm that each listed page is canonical, public, and returns 200.
Apply fixes in the safest order
- Repair rewrite routing or save Permalinks once.
- Choose one sitemap provider and remove conflicting filters.
- Correct migrated URLs using serialized-data-aware tools, then regenerate.
Before applying “Repair rewrite routing or save Permalinks once,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can validate the XML and confirm only canonical, public URLs return 200; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Prove recovery
- Validate the XML and confirm only canonical, public URLs return 200.
- Submit the sitemap in Search Console and wait for a successful fetch status.
- Check the sitemap after future domain or permalink changes.
One successful refresh is not closure. Keep the incident open until you can also submit the sitemap in Search Console and wait for a successful fetch status, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
When escalating, include the exact canonical URL, response chain, robots rules result, meta and X-Robots-Tag values, canonical annotation, sitemap entry, and Search Console live-test date; search changes require recrawling; they are not instant configuration toggles; include the result of this first observation: request /wp-sitemap.xml with curl -i and inspect status, Content-Type, body, and redirects.
State what was tested, including the result of “Request `/wp-sitemap.xml` with `curl -i` and inspect status, Content-Type, body, and redirects,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Shortcuts that create a second incident
- A sitemap can help discovery but does not guarantee indexing.
- Do not list redirects, private pages, search results, or intentional 404s.
Operator record
Primary references
- Google sitemap guidance — official reference consulted for this guide.
- WordPress common errors — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Repair rewrite routing or save Permalinks once”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.