Sitemap Could Not Be Read or Couldn't Fetch: Fixes

Search Console reports two different sitemap failures. "Couldn't fetch" means Google did not retrieve the file: the URL is wrong, blocked, returning an error, or Google has not tried yet. "Sitemap could not be read" (shown as "Has errors" in the table) means Google got the file but could not make sense of it: HTML where XML was expected, broken XML, a bad compressed file, stray bytes before the first tag, or a file over the limits. The fix starts with working out which of the two you have, and the sections below take each one in turn.

Two messages, two different problems

Message	What happened	Where to look
Couldn't fetch	Google's request for the file failed or has not happened yet	Reachability: URL, DNS, status code, robots.txt, firewall
Sitemap could not be read (status "Has errors")	Google received a response and could not parse it	Content: format, encoding, XML validity, compression, size
Success, but errors or warnings listed	Google parsed the file and found problems with some entries	Individual URLs: wrong host, blocked URLs, invalid dates

Open Indexing > Sitemaps, click the row, and Search Console shows the detail: the message, when the file was last read, and for parse errors the line and the specific complaint.

Couldn't fetch: causes and checks

Start with the clock. A sitemap submitted an hour ago that says "Couldn't fetch" is usually just waiting for Google's first attempt. Give it a day. If it still says so after that, one of these is in the way.

Typo or wrong path. Search Console submits exactly what you typed. sitemap.xml versus sitemap_index.xml, a trailing space, a wrong folder. Open the exact URL from the Sitemaps table in a browser.

Wrong property. A URL prefix property for https://www.yoursite.com/ cannot fetch a sitemap at https://yoursite.com/sitemap.xml. Submit it under the matching property, or use a Domain property.

Blocked by robots.txt. A Disallow rule matching the sitemap path stops Googlebot fetching it. Test the sitemap URL in the robots.txt tester with Googlebot as the agent. Rules like Disallow: /*.xml$ written to hide feeds are the usual culprit.

403 from a firewall or CDN. Bot protection that challenges non-browser requests returns 403 or a challenge page to Googlebot. Your browser sees the file, Google does not. The HTTP headers checker fetches the URL from outside your network and shows the status code and headers; a 403 or a cf-mitigated style header points at the edge. Allow Googlebot by its published IP ranges.

404 or 410. The file is not there. A plugin was disabled, a static export did not include it, or the generator writes to a path the web server does not serve.

5xx or timeout. Dynamic sitemaps that query the database for every URL on each request can take longer than Google waits. Cache the output or generate the file on a schedule.

Redirect to another host or to HTTP. A sitemap that redirects, especially to a different host, to the http version or through a chain, is a frequent source of failed fetches and of URLs reported as not allowed. Serve the file directly at the submitted URL with a 200.

DNS or TLS problems. An expired certificate or a DNS record that resolves only from inside your network. Test from a machine outside your office or with a public checker.

A quick command that shows most of these at once:

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -D - -o /tmp/sitemap.out https://www.example.com/sitemap.xml | head -20
head -c 300 /tmp/sitemap.out

You want 200, a Content-Type of application/xml or text/xml, and a body that starts with <?xml or <urlset.

Sitemap could not be read: causes and messages

Google got a response. Now the content is the problem.

Search Console message	Cause	Fix
Your Sitemap appears to be an HTML page	The URL returns a web page, not XML	Find out why: 200 "not found" page, catch-all route, plugin off, redirect to home
Unsupported format	Not XML, RSS, Atom or a plain text URL list	Serve a real sitemap; JSON and CSV are not sitemaps
Parsing error	Invalid XML: an unescaped & in a URL, an unclosed tag, a stray character	Validate the XML and escape special characters
Incorrect namespace	Missing or wrong xmlns on <urlset> or <sitemapindex>	Use http://www.sitemaps.org/schemas/sitemap/0.9 exactly
Leading whitespace	Bytes before <?xml: a BOM, a blank line, PHP output before the header	Strip the BOM and anything printed before the declaration
Compression error	The file ends in .gz but is not gzip, or is compressed twice	Serve plain XML, or compress once and check with gunzip -t
Empty sitemap	No <url> entries	Check the generator; an empty filter or a failed query produces this
Sitemap file size error	Over 50 MB uncompressed	Split and use a sitemap index
Too many URLs in sitemap	Over 50,000 URLs	Split and use a sitemap index
Nested sitemap indexes	A sitemap index that points at another sitemap index	Indexes may only list sitemaps, not other indexes
Invalid URL or Incomplete URL	A <loc> that is relative, missing the protocol, or contains spaces	Use absolute, encoded URLs
URL not allowed	URLs on a different host or above the sitemap's own path	Match the host exactly and place the file at the root
Invalid date	A <lastmod> that is not W3C datetime	Use 2026-10-11 or 2026-10-11T09:30:00+00:00
HTTP error	The response to the sitemap request carried an error status	Same checks as Couldn't fetch

The HTML case deserves a closer look because it is the most common and the least obvious. Your browser opens /sitemap.xml and shows an XML tree, so the file "works". But the browser may be showing a cached copy, or your logged-in session may be served differently from an anonymous crawler, or the server returns HTML only to requests without a browser-like Accept header. The curl command above, with its head -c 300, shows what a crawler gets.

The leading whitespace case is nearly always PHP: a closing ?> followed by a newline in some included file, or a UTF-8 BOM saved by an editor. The XML declaration must be the first byte of the response.

A fix checklist

1. Open the sitemap URL from the Search Console table in a private browser window. Note what you see.
2. Fetch it with curl and inspect the status code, content type and first 300 bytes.
3. Run it through the sitemap validator, which parses the XML, checks the namespace, counts the URLs, flags relative or foreign-host locations and reports the size.
4. Test the URL in the robots.txt tester as Googlebot.
5. If the file is compressed, test it with gunzip -t sitemap.xml.gz.
6. If a sitemap index is involved, repeat steps 2 and 3 for each child file; a single broken child shows as an error on the index.
7. Fix what you found, confirm with curl again, then submit the same path again in Search Console.
8. Check the next day. The status should read Success with a discovered count that matches the number of <url> entries.

For dynamic sitemaps, add a step 0: look at the server logs for requests to the sitemap path with Googlebot's user agent and see what status code they got. That answers the fetch question directly.

When to just wait

Three situations where nothing is wrong:

• A new submission. Google's first fetch can take up to a day, and the row shows "Couldn't fetch" or no status until then.
• A new property. A site verified today has no crawl history. Google starts with robots.txt and the home page; the sitemap follows.
• A transient error. One 5xx during a deploy produces a failed fetch. Google retries on its own schedule; if the next read succeeds, the status updates and the old error disappears.

What to watch instead of the status alone is the Last read date in the table. If it keeps advancing, Google is reading the file; if it froze weeks ago, there is a real block.

After the fix

Once the status is Success, the discovered count should match your URL count. Then switch to Indexing > Pages and filter by the sitemap to see what happened to the URLs. A read sitemap does not mean indexed pages, only that Google now knows which URLs you want it to consider. How to submit it the first time, and what the robots.txt Sitemap: line adds, is covered in how to submit a sitemap to Google. The format itself, with the optional tags and the limits, is in the XML sitemap guide, and splitting a big site into an index is in sitemap index files for large sites.

One more way to get an early warning: any tool that reads your sitemap hits the same walls as Google. TurboIndex reads the sitemaps submitted in Search Console with its own crawler, TurboIndexBot, and a file it cannot fetch or parse shows up as a problem in the dashboard right away, rather than a day later in Search Console. The crawler's user agent and how to allow it through a firewall are on the TurboIndexBot page. If your sitemap is blocked for it, it is worth checking whether Googlebot is blocked by the same rule.