Search Console Says “Couldn’t Fetch” Your Sitemap: What Each Error Means

You submitted your sitemap, waited, and Search Console is showing a red Couldn’t fetch next to it. No explanation, no detail, and a sitemap that loads perfectly when you open it in a browser.

That last part is the frustrating bit, and it is also the clue. Google is not using your browser. It is fetching as Googlebot, from outside your network, with no cookies and no session — and in that situation several very ordinary things look like failures.

What each Search Console message actually means

The messages are terse and several of them sound alike. They are not.

That last row matters more than people expect. A sitemap is a suggestion, not an instruction. “Success” means Google read your list. It has never meant Google agreed to index everything on it.

Working through "Couldn’t fetch"

1. Check the exact URL you submitted

Search Console is unforgiving about this. https://example.com/sitemap.xml and https://www.example.com/sitemap.xml are different properties, and submitting one to the other produces a fetch failure. So does a stray space, or a capital letter in a path that is case sensitive.

Open the exact URL from the Search Console row in a private window. Not from memory — copy it from the field.

2. Check it returns 200, not a redirect

If /sitemap.xml redirects to /sitemap_index.xml, or from http to https, or from non-www to www, Google may report a fetch failure rather than following it. Submit the final URL — the one that answers directly with a 200.

3. Check robots.txt is not blocking it

A Disallow rule that happens to cover your sitemap path will stop Googlebot reading it, and nothing in Search Console says so plainly. While you are there, confirm your robots.txt names the sitemap:

Sitemap: https://example.com/sitemap.xml

Our Robots.txt Checker will tell you whether a given path is reachable by Googlebot.

4. Rule out the firewall or CDN

Security plugins, Cloudflare rules and host-level firewalls sometimes serve a challenge page to anything that does not look like a browser. You see the sitemap because you are a browser; Googlebot sees a block page. If everything else checks out, this is the most likely remaining cause, and your host can confirm it from the access logs.

5. Consider that it may have been temporary

If the server was briefly down or slow when Google tried, the error sticks in the interface until the next fetch. Resubmit and give it a day before troubleshooting further.

When the file is fetched but will not parse

“Sitemap could not be read” is a different animal. Google got the file; the contents are the problem.

• Invalid XML. An unescaped ampersand in a URL is the classic. In XML, & must be written &, and a single raw one invalidates the whole document.
• Wrong content type. The file should be served as application/xml or text/xml. Some servers send text/html, which confuses the parser.
• A BOM or blank line before the declaration. The <?xml declaration must be the very first thing in the file. Anything before it, including an invisible byte order mark, breaks parsing.
• Mixed domains. Every URL in a sitemap must be on the same host as the sitemap itself.
• Over the limits. A single sitemap may hold 50,000 URLs and must stay under 50 MB uncompressed. Past that, split it and use a sitemap index.

Where your sitemap lives, by platform

A surprising share of “couldn’t fetch” errors are simply the wrong address submitted. Different platforms put it in different places, and several generate more than one.

If you are not sure which applies, open yoursite.com/robots.txt — most platforms declare the sitemap there, and that line is the authoritative answer for your particular setup.

Sitemap index files

Once a site passes a few thousand URLs, the usual arrangement is an index file that lists other sitemaps rather than listing pages directly. Submit the index on its own; Google follows the children automatically, and submitting all of them separately clutters the report without helping.

The error that catches people here is a child sitemap listed in the index at a URL that no longer resolves — for example a product sitemap that is only generated when products exist. The index fetches fine, one of its children 404s, and the report shows a failure that looks unrelated to anything you changed.

Resubmitting, and how long to wait

Once you have fixed the cause, go to the Sitemaps report, delete the failing entry, and submit the URL again. Deleting first matters: Search Console sometimes keeps showing the old status against the old entry even after the underlying problem is gone, which sends people chasing a fault they already fixed.

Then wait. A fetch usually happens within a day or two, sometimes within hours, and the report updates when it does rather than in real time. Resubmitting repeatedly does not speed it up. If it still fails after two or three days with everything above checking out, the next place to look is your server access log for requests from Googlebot — that tells you whether the request is arriving at all, which separates a Google-side problem from a firewall silently refusing it.

What belongs in a sitemap, and what does not

Most sitemap problems that are not technical are editorial. A sitemap should list the canonical, indexable pages you actually want in search — nothing else.

Leave out: pages that redirect, pages that return 404, anything with a noindex tag, pages canonicalised to a different URL, tag and filter pages that generate near-duplicates, and anything behind a login. Including them does not get them indexed; it just makes Google trust the file less.

lastmod is worth getting right because Google does use it as a hint — but only if it is honest. Setting every page to today’s date on every build teaches Google to ignore the field entirely.

You can safely ignore priority and changefreq. Google has said for years that it does not use them.

Submitted successfully but pages still not indexed

This is the most common follow-up, and it is not a sitemap problem. A sitemap helps Google discover URLs. Whether it indexes them depends on whether the pages look worth indexing.

In the Pages report you will see two phrases a lot. Discovered — currently not indexed means Google knows the URL but has not got round to crawling it, which is normal on newer sites with little authority. Crawled — currently not indexed means it looked and decided not to keep it, which usually points at thin or near-duplicate content.

Neither is fixed by resubmitting the sitemap. The first needs internal links and patience; the second needs better pages. A full page audit will show you which of your pages look thin before Google does.

Do you even need a sitemap?

Worth asking, because a lot of effort goes into files that change very little.

Google has been explicit that a small, well-linked site does not strictly need one. If every page is reachable in a couple of clicks from your home page, the crawler will find everything with or without a sitemap. The cases where it genuinely helps are: a site larger than a few hundred pages, a new site with almost no inbound links, pages that are poorly linked internally, and sites with a lot of media or news content where freshness matters.

What a sitemap never does is improve rankings. It is a discovery aid, not a quality signal, and no amount of tuning priority values changes where a page sits in results. If your pages are discovered and indexed already, time spent perfecting the sitemap is time not spent on the thing that would move the needle.

The one argument for having one regardless of size is diagnostic. The Sitemaps report gives you a clean count of submitted versus indexed URLs, which is a genuinely useful health signal over time — a gap that widens month after month tells you something is wrong well before traffic drops.

A quick checklist

• Open the exact submitted URL in a private window. Does it return XML with a 200?
• Is it the same host and protocol as the Search Console property?
• Does robots.txt allow it, and does it name the sitemap?
• Is the content type XML rather than HTML?
• Any unescaped ampersands, or anything before the <?xml line?
• Under 50,000 URLs and 50 MB?
• Does it list only canonical, indexable pages?