Sitemap Couldn't Fetch in Google Search Console: What It Means and What to Fix First
A "sitemap couldn't fetch" error in Google Search Console means Google tried to grab your sitemap and came back empty-handed. The status sits there in the Sitemaps report, sometimes for days, and every instinct says to resubmit immediately. That instinct is wrong more often than it's right.
Google will retry a failed sitemap fetch for a few days before giving up. So the worst thing you can do is mash the resubmit button before you've confirmed what actually broke. The fix order matters here, and so does knowing when to wait. Below is the full confirmation-first checklist: what Google means by this status, how to diagnose the real cause, how to fix it in the right sequence, and how to tell recovery is actually happening.
What GSC means by "couldn't fetch" (and "sitemap could not be read")
The Sitemaps report in Google Search Console shows the status of the last request for each sitemap you've submitted. "Couldn't fetch" means exactly what it says: Google attempted to retrieve the sitemap file and the request failed.
If you click into the sitemap's details page, you may see the wording "Sitemap could not be read." That's the same problem with a bit more context. The details page names the specific reason the fetch failed.
One detail operators miss: if Google successfully read your sitemap before, a later fetch failure doesn't make Google forget what it learned from the earlier reads. Google's Sitemaps report help says this directly.
Google also says it will retry a failed fetch for a few days, then stop trying. At that point, you need to fix the underlying problem and resubmit.
The report only shows sitemaps submitted through the Search Console interface or the API. Sitemaps discovered through your robots.txt file won't appear here.
If you're looking at the http:// property and your sitemap lives on https://, you won't see it. Same goes for www versus non-www mismatches.
One more thing that catches people: Google does not follow redirects on the submitted sitemap URL. If the URL you submitted redirects to another location, the report won't treat it as the sitemap you meant, even though a browser would land on a perfectly valid XML file.
Confirm the problem before you change anything
Don't start editing server configs based on a status message alone. Confirm what's actually happening first.
Click the sitemap URL in the Sitemaps report. The details page tells you why the fetch failed.
Use curl -I or a similar tool to request the exact URL you submitted. Check three things.
- The HTTP status code (you need a 200)
- The
Content-Typeheader (should beapplication/xmlortext/xml) - The final URL after any redirects (there shouldn't be any)
If you see a redirect, a missing page, or an HTML page where XML should be, you've found the problem.
Open your robots.txt and verify it doesn't disallow the sitemap path. Then check your CDN or WAF logs for Googlebot requests to that URL.
Bot-protection services sometimes challenge or block crawlers without returning a clean error code.
You can also run a URL Inspection live test on the sitemap URL directly in Search Console for another data point.
Common causes worth checking
These are the causes worth ruling out, roughly from quickest to check to slowest.
The sitemap URL returns a missing page or redirect. Someone changed the CMS, moved the sitemap path, or the plugin that generated it got deactivated.
A WAF or bot-protection rule blocks Googlebot. Challenge modes, firewall rules, or custom rate limits on a CDN can intercept the request before your server ever sees it.
robots.txt disallows the sitemap path. This happens most often with broad disallow rules that accidentally cover /sitemap.xml.
Wrong property or protocol mismatch. You submitted under the http:// property, but the sitemap is served over https://. Or you're looking at the www property while the sitemap lives on the bare domain.
The URL serves HTML instead of XML. Your server might return a custom error page or a login screen with a 200 status code. Google sees HTML where it expected a sitemap and can't read it.
Timeouts on large or dynamically generated sitemaps. Google Search Central limits a single sitemap to 50MB uncompressed or 50,000 URLs. Even under that limit, dynamically generated sitemaps that take too long to render can time out.
A freshly submitted sitemap that just hasn't been fetched yet. The status can briefly look like a failure before Google's first successful attempt. If you submitted it minutes ago, check back in a day before changing anything.
Fix-first order and what to correct
Order matters here because some fixes make others unnecessary. Work through this list top to bottom.
The sitemap must return a 200 status code with valid XML at the precise URL you submitted. No redirects, no HTML wrappers, no soft-404 pages pretending to be successful.
If the URL changed, you have two options. Either serve the sitemap at the old URL again, or remove the old submission and resubmit at the new URL. Don't rely on a redirect.
Since Google won't follow redirects on submitted sitemap URLs, a redirect is functionally the same as a missing file in this context. Remove the redirect and serve the file directly, or submit the destination URL instead.
If robots.txt disallows the sitemap path, remove that rule. If your WAF or CDN is challenging Googlebot, allow verified Googlebot requests (Google publishes its crawler IP ranges) or adjust the security rules.
Understanding how robots.txt blocking works at the page level helps here, though the sitemap-level behavior is different since Google can't even read the URL list.
Verify you're submitting the sitemap under the correct Search Console property. The protocol (http vs. https) and host (www vs. non-www) must match.
If your sitemap is large or dynamically generated, break it into smaller files and use a sitemap index file. This reduces generation time and file size, both of which contribute to timeout-related fetch failures.
Once you've applied the relevant fix, resubmit the sitemap once.
When not to keep resubmitting
Resubmitting a broken sitemap doesn't fix the sitemap. It just tells Google to try again and fail again.
If the underlying problem still exists, repeated submissions achieve nothing.
Google already retries for a few days on its own. Piling on manual resubmissions adds noise to your Sitemaps report without bringing you closer to resolution.
When operators see that their sitemap failed, the next impulse is to go into URL Inspection and hit "Request Indexing" for every URL in the sitemap. This doesn't address the problem. The sitemap is the delivery mechanism. Fix the mechanism first.
Request Indexing has a quota and is designed for individual URL-level issues. Using it as a substitute for a working sitemap is like hand-delivering mail because the mailbox fell over.
Put the mailbox back up.
How to measure sitemap couldn't fetch recovery in GSC
After you resubmit, here's what a real recovery looks like.
The Last read date should update to reflect a new, successful fetch. The status should change to "Success." The discovered URLs count should populate with the number of URLs in your sitemap.
If "Last read" doesn't update within a few days, the fetch is still failing. Go back to the confirmation step.
A successful sitemap fetch doesn't guarantee indexing of every URL. Watch the Page indexing report over the following weeks for changes in indexed URL counts.
We won't promise timing here. Google doesn't commit to crawl or index schedules, and neither should you when setting expectations internally.
How this differs from page-level statuses
The "sitemap couldn't fetch" status is a sitemap-level problem. Google never got to read your URL list.
Page-level statuses like "Blocked by robots.txt" or "Server error (5xx)" mean Google reached for the individual page and hit a specific issue there. A sitemap fetch failure is upstream. It stops Google from discovering URLs through that channel.
A server error (5xx) on a specific page means Google found the URL but the server choked when delivering content.
Similarly, a 404 error on a page means Google crawled that URL and found nothing there. With a sitemap fetch failure, Google may not even know those URLs exist yet (unless it found them through other discovery methods like internal links).
The sitemap is the table of contents. Page-level errors are problems with individual chapters. A broken table of contents doesn't delete the chapters, but it makes them harder to find.
Frequently asked questions
Should you submit your sitemap in robots.txt, in Search Console, or both?
Both is a reasonable default. A robots.txt reference helps discovery, while submitting in Search Console is what gets the sitemap into the Sitemaps report, where you can see fetch status and errors. Sitemaps found only through robots.txt don't show up in that report.
What is the easiest way to check that your sitemap XML is correctly formatted?
Run the sitemap through an XML validator to catch invalid characters or broken tags. You can also open the file in a browser and confirm it renders as XML and not as a styled HTML page.
Does your sitemap have to include every URL on your site?
No. A sitemap should focus on canonical, indexable URLs you actually want in search results. Leave out duplicates, parameter variants, and URLs blocked by noindex or robots rules.
How can you catch sitemap fetch failures before Search Console does?
Set up an uptime check that alerts on non-200 responses or an unexpected content type for your sitemap URL. Pair it with a periodic look at the Sitemaps report's Last read date.
Fix the fetch, then step back
A "couldn't fetch" sitemap status usually comes down to a fixable infrastructure problem: a wrong URL, a redirect, a firewall rule, or a property mismatch.
The fix is usually fast. The mistakes are acting before confirming, resubmitting before fixing, and over-monitoring before giving Google time to process the change.
Confirm the cause. Apply the specific fix. Resubmit once.
Then watch the Sitemaps report for a status change and the Page indexing report for downstream effects over the following weeks.
If you'd rather catch sitemap fetch failures and indexing drops before they snowball, ClickFlow helps you keep an eye on your GSC sitemap and Page indexing statuses so you can act on real signals instead of refreshing the Sitemaps report by hand.