Why this is the worst sitemap failure
Every other sitemap problem announces itself. A 404 shows up in Search Console. A malformed XML file throws a parse error. A missing file is obvious the moment you look.
This one hides. The URL returns 200, so uptime monitoring is happy. Open it in a browser and you see a page rather than an error, so a casual check passes. Search Console may simply report that it could not read the sitemap, which is easy to dismiss as a temporary glitch.
Meanwhile every crawler that fetches it receives a document with no URLs in it. The sitemap has been doing nothing since whenever it broke.
We found three instances of this on a single competitor's site while testing our own checker, which is a fair indication of how common and how invisible it is.
What causes it
Almost always a routing or configuration change that nobody connected to the sitemap.
| Cause | What you see | Typical trigger |
|---|---|---|
| Catch-all route serving the app shell | Your homepage or a blank page | Moving to a single-page app or a new framework |
| Custom 404 returning 200 | A styled not-found page | A theme or plugin that renders errors as normal pages |
| Plugin deactivated | A 404 page rendered by the CMS | Removing or replacing an SEO plugin |
| Redirect to a human-readable page | An HTML sitemap for visitors | A well-meaning redirect from XML to the visitor sitemap |
| Server error page | A host's default error page | Misconfiguration after a migration |
How to confirm it in ten seconds
Do not judge it by eye in a browser, because a browser will render whatever it is given and some browsers style XML in a way that looks like a page.
View source instead. A valid sitemap starts with an XML declaration and contains either a urlset or a sitemapindex element. If you see a doctype and html tags, that is your answer.
Or run the URL through our sitemap checker, which reports exactly this case as "not valid sitemap XML" and distinguishes it from a 404.
Fixing it
The fix depends on the cause, but the order of investigation is the same in every case.
First, confirm what is actually serving that path. If a framework catch-all is answering, you need an explicit route for the sitemap ahead of the catch-all. If a plugin was producing it, reinstall or re-enable the plugin and check the path it uses, which may have changed.
Second, once it is serving XML again, resubmit it in Search Console rather than waiting. That both requests a fresh fetch and confirms the file now parses.
Third, and this is the part that prevents a repeat: add the sitemap URL to whatever uptime or monitoring you already run, and check the response body rather than only the status code. A check that only looks at 200 will pass on a broken sitemap forever.
Common questions
How do I know if my sitemap is returning HTML?+
View source rather than trusting how it renders. Valid sitemap XML begins with an XML declaration and contains a urlset or sitemapindex element. A doctype and html tags mean it is HTML. Our sitemap checker reports this case explicitly.
Why does it still load fine in my browser?+
Because the server is returning HTTP 200 with a real document, just the wrong kind. Browsers render whatever they receive, and uptime monitoring that only checks the status code will report it as healthy.
Will Search Console tell me?+
It usually reports that the sitemap could not be read or could not be fetched, which is easy to mistake for a temporary problem. It rarely says plainly that the content was HTML.
How long could this have been broken?+
Potentially years. Because nothing errors and nothing alerts, this typically dates back to whichever migration, plugin change or framework switch introduced it.
Sources