Sitemap could not be read in Search Console: what each status means, and how to fix it

“Sitemap could not be read” means Google tried to download your sitemap file and failed. Search Console shows it as the status Couldn’t fetch in the Sitemaps report, and as “Sitemap could not be read” when you open the sitemap’s details. Sometimes it is a real fault: a robots.txt rule, a 404, a firewall, an HTML page where the XML should be. Sometimes the file is fine and Google simply has not used it yet. The first job is to tell which, and one test does that in a minute.

This guide quotes what each status means in Google’s words, gives the order to check things in, and lists every cause with its fix. To see what your sitemap URL actually answers, run it through the free sitemap validator: it reports the status code, the content type, whether the body is XML, and whether robots.txt blocks it for Googlebot.

Sources: Search Console’s Sitemaps report help^[1]; Google’s page on HTTP status codes^[3].

What each Search Console status means

The Sitemaps report shows the status of the last request for each sitemap you submitted, and Google defines each one^[1]:

Opening a sitemap shows one of two messages. “Sitemap could not be read” means “the fetch failed”, with the reason in a section you can expand. “Sitemap can be read, but has errors” lists parsing errors such as an invalid date or a wrong namespace^[1]. This guide is about the first. For the second, the sitemap format guide shows what valid XML looks like.

Two things in the report are easy to misread. It records “the exact URL specified when the sitemap was submitted. Redirects are not followed”^[1], so submit the final URL, not one that redirects to it. And Google remembers what it read before: “A later failure or success to read a sitemap will not cause Google to ‘forget’ the information from previous reads”^[1]. A sitemap that fails today has not undone last month’s successful read.

Step 1: is it a fault or a wait?

Google’s own debugging steps start in the URL Inspection tool. Paste the sitemap URL, run Live test, and expand Page availability. “Basically you want to see Crawl allowed? = ‘Yes’, Page fetch = ‘Successful’”^[1]. That gives you three branches:

• Crawl allowed? No. A robots.txt rule blocks the sitemap. “Google respects robots.txt when fetching sitemaps”^[1]. Fix the rule; see cause 1.
• Page fetch fails. The field names the problem: a 404, a server error, a redirect, or a site-wide issue such as “Robots.txt unreachable”, an invalid SSL certificate or “Hostload exceeded”^[2]. Work through causes 2 to 5.
• Both pass. Google can fetch the file now. Either the failure was transient, or Google has not wanted the sitemap. Wait before changing anything; see cause 7.

Step 2: see what Google gets

You can reproduce most of the live test from a terminal. These four checks show the status code, the content type, any redirect, the first bytes of the body and the robots.txt rules, with and without Googlebot’s user agent:

# 1. What does the sitemap URL answer? Status, content type, redirects.
curl -sI https://www.example.com/sitemap.xml

# 2. The same request with Googlebot's user agent. A different answer here
#    means something on your server or CDN treats crawlers differently.
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://www.example.com/sitemap.xml

# 3. Is the body XML? The first bytes should be <?xml or <urlset / <sitemapindex,
#    not <!DOCTYPE html>.
curl -s https://www.example.com/sitemap.xml | head -c 300

# 4. Does robots.txt answer, and does it block the sitemap path?
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/robots.txt
curl -s https://www.example.com/robots.txt | grep -i -E "^(user-agent|disallow|allow|sitemap)"

What a healthy answer looks like:

• A 200, directly. Not a 301 to another URL. Submit whatever URL finally answers 200.
• An XML body. The file starts with an XML declaration or a <urlset> or <sitemapindex> root. Neither Google’s sitemap guide nor the Search Console help names a required Content-Type header^[6][1]; what matters is that the body is a sitemap and not an HTML page.
• The same answer for both user agents. If the Googlebot request gets a 403, a challenge page or a different body, look at your firewall, CDN or bot settings.

The user-agent test has a limit: firewalls that check IP addresses will treat your curl differently from the real Googlebot either way. To check requests in your logs, Google says to run a reverse DNS lookup on the IP, confirm the name ends in googlebot.com, google.com or googleusercontent.com, then look the name up again and confirm it returns the same IP^[4]:

# Is a request in your logs really Googlebot? Reverse, then forward DNS.
host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Step 3: every cause, and its fix

Google lists the reasons a sitemap shows Couldn’t fetch^[1]. Here they are with the related problems the help page covers elsewhere, and one it does not, in the order worth checking.

1. robots.txt blocks the sitemap

The most direct cause. Google says: “You must remove the rule that prevents Google from fetching your sitemap”^[1]. Look for a broad rule such as Disallow: /*.xml or a disallowed folder that contains the sitemap. A related failure is a robots.txt that cannot be reached at all: “Google won’t crawl a website if the robots.txt file is present but not reachable”^[2]. Test the path against your rules in the robots.txt tester.

2. The URL is wrong, or in the wrong property

“The URL provided for the sitemap is wrong (HTTP 404 error: sitemap not found at the address provided)”^[1]. Open it in a browser. Then check the property: a sitemap on https://www. listing URLs on the bare domain triggers the “Path mismatch” and “URL not allowed” errors, and the report only shows sitemaps in the current property^[1]. If you are unsure of the address, the guide to finding a sitemap lists every platform’s path.

3. A server or site-wide error

Google files these under “some other general error”, such as server unavailability, and adds that “some of these errors can be transient: wait a bit and see if Google continues to encounter this error in later crawl attempts”^[1]. The live test names the site-wide ones: DNS failures, connection errors, an invalid SSL certificate, an unreachable robots.txt, or “Hostload exceeded”, when your site “seems to be at maximum capacity for Google crawling”^[2]. A 5xx or 429 also makes Google’s crawlers “temporarily slow down with crawling”^[3]. A sitemap that is built on request from a slow database query can time out under load even when it opens in your browser.

4. A manual action

The cause no blog post on this error mentions: “Sitemaps are not read when a site has an unresolved manual action.” Check the Manual actions report, fix the issue, and resend the sitemap^[1].

5. A firewall, CDN or bot rule

Google’s Couldn’t fetch list does not name firewalls, so treat this one as our inference from what Google does document. Its AI features page does list “ensuring that crawling is allowed in robots.txt, and by any CDN or hosting infrastructure” among the basics^[5]. A bot-protection rule, rate limit or country block that answers Google’s crawler with a 403 or a challenge page is, to Google, a 4xx: it “doesn’t use the content from URLs that return 4xx status codes”^[3]. The sign is a curl request with Googlebot’s user agent that gets a different answer from a normal one, or blocked requests from verified Google IPs in your firewall log. The fix is to allow verified Google crawlers, by IP list or reverse DNS^[4], rather than by the user-agent string, which anyone can fake.

6. The URL does not serve a usable sitemap

Several problems sit on the boundary between “could not be read” and “has errors”. A URL that answers 200 with an HTML page, which is common after a site move or when a missing page returns the home page, is not a sitemap; Search Console reports a file it does not recognise as “Unsupported format”^[1]. A file larger than 50 MB uncompressed gets a file size error, and a damaged gzip a compression error^[1]. The protocol’s limits are 50,000 URLs and 50 MB per file^[7].

7. Google does not want it yet

The last reason on Google’s list explains most of the cases where everything checks out: “There is low crawl demand for the sitemap. The higher the quality of the site’s content, the higher the crawl demand.”^[1] John Mueller of Google said the same thing in February 2026, answering a site owner whose sitemap answered 200 and passed the live test but still showed Couldn’t fetch:

^[8] No header or rename changes that. What helps is what raises demand in general: pages worth indexing, and links to them from pages Google already crawls. Wix’s help page on the error makes the same point from the other side: it “is known to occur for sites hosted with any company” and “in most cases, it resolves itself within a couple of days or weeks”^[9].

Fixes by platform

Hosted platforms generate the sitemap for you, so the fix is usually a setting, not a file.

After the fix

Resubmit once. After a failed fetch, Google “will retry for a few days, and then stop” if the sitemap stays unavailable, so after a real fix “you should fix the problem and resubmit your sitemap”^[1]. For the separate “Temporary error”, Google says “you do not need to resubmit” unless it persists for several hours^[1]. Then watch the Last read column, which only appears when Google could fetch the file^[1]. Adding the sitemap to robots.txt as well costs nothing and lets every crawler find it^[6].

Once the file is read, the next question is what is in it. A sitemap that lists redirects, 404s or pages robots.txt blocks will show up in Search Console as “URLs not accessible” or “URLs not followed”^[1]. The redirect checker traces any listed URL that redirects.

Questions people ask

Sources