"Sitemap Could Not Be Read" in Search Console: Telling a Real Failure From a Display Bug
The error means Google could not fetch your sitemap, could fetch it and disliked it, or fetched it fine and is showing you a stale status. Here is how to tell which.
喜欢就分享一下吧
You submit a sitemap. Search Console says "Couldn't fetch", or "General HTTP error", or "Sitemap could not be read". You open the URL in a browser and it loads perfectly.
The advice you find splits three ways and every branch has confident supporters. One says wait, it resolves itself. One says it is a Search Console display bug, ignore it. One says your URL is wrong. They cannot all be right, and the reason the argument never settles is that all three are sometimes right — the message covers at least three different situations.
Here is how to work out which one you have, in order, cheapest first.
Step 1: Does it load for something that is not your browser
Your browser is the worst possible test. It carries your cookies, your session, a residential IP address, and a user agent every CDN trusts. Googlebot has none of those.
Fetch it without a browser:
curl -sSI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/sitemap.xmlRead the status line and the content type. You want 200 and application/xml or text/xml.
Three failures show up here that a browser hides:
A 403 or 503. Your CDN or firewall is refusing non-browser traffic. This is the most common real cause, and Cloudflare's bot protection is the most common source of it. The fix is a rule allowing verified search crawlers, not a change to the sitemap.
A redirect. 301 to another host, or to https, or to a trailing slash. Google follows redirects for a sitemap but the reporting gets unreliable. Submit the URL that answers 200 directly.
text/html as the content type. Your server is returning the sitemap with the wrong header, or returning a soft 404 page that happens to contain XML. Either way Google will not parse it.
Step 2: Use the URL Inspection tool on the sitemap URL itself
This is the step almost everybody skips, and it is the one that separates a real failure from a stale status.
Paste the sitemap URL into URL Inspection at the top of Search Console and run a live test. You are not inspecting a page here, you are asking Google to fetch that exact URL right now and tell you what it got.
- Live test succeeds, Sitemaps report still says failed. The fetch works. The Sitemaps report is showing you a cached result from a previous attempt. This is the case where "just wait" is the correct advice, and the wait can be weeks.
- Live test fails too. The failure is real and reproducible. Go back to step 1 and look at what it returns.
Nothing in the Sitemaps report tells you which of those two you are in. The live test does, in about fifteen seconds.
Step 3: The query string trick, and what it actually proves
There is a well-documented oddity worth knowing about. Submitting the identical sitemap as sitemap.xml?123 sometimes reports success immediately while sitemap.xml stays failed.
People take this as proof of a Search Console bug, and it does show that the file is fetchable and valid, since a query string does not change what your server returns. What it does not do is fix anything. Google discovers your sitemap from robots.txt and from the plain URL, so a successfully submitted ?123 variant is a diagnostic, not a solution. You have proved the file is fine. The status on the real URL is still what matters.
Use it to rule out the file. Then remove it.
Step 4: Check the sitemap against the spec
If the fetch genuinely works and it still will not parse, the file itself is wrong in a way browsers forgive:
- A byte order mark or any whitespace before
<?xml. The declaration must be the very first thing in the file. - URLs in the sitemap on a different host from the sitemap itself. Cross-domain entries are rejected.
- Over 50,000 URLs, or over 50MB uncompressed. Split it and use an index.
- Unescaped
&in a URL. It must be&, and a query-string-heavy sitemap trips this constantly. lastmodin a format that is not W3C datetime.
The Sitemap Error Checker reads a live sitemap and reports these, along with the URLs inside it that answer with a 404 or a redirect rather than a 200.
What the statuses mean
| Status | What happened |
|---|---|
| Couldn't fetch | Google's request did not get a usable response. A real network or permission problem, or a stale display |
| General HTTP error | The request returned a status Google could not use. Check what your server sends a bot |
| Sitemap could not be read | It was fetched, and the XML failed to parse. A file problem, not a network one |
| Success, 0 discovered URLs | It parsed, and contained nothing Google accepted. Usually cross-domain URLs, or an index pointing at unreachable children |
That last row catches people out, because green means fine everywhere else in the product. A sitemap that succeeds with zero discovered URLs has done nothing at all.
What none of this fixes
A correctly submitted sitemap does not get pages indexed. It tells Google the pages exist. If your URLs sit at "Discovered — currently not indexed", the sitemap is working and something else is the problem, and resubmitting it in different forms will not change that.
Worth being clear about, because the sitemap error is visible and satisfying to chase, and the indexing problem underneath it usually is not.