Google Search Console Couldn't Fetch Sitemap? Here's the Fix

By Toy Wen Da, Co-Founder · Updated 5 November 2026 · 6 min read · scored 93/100

"Couldn't fetch" usually means Google tried to retrieve your sitemap file at the moment it checked and failed. It doesn't mean the sitemap is broken. Open the sitemap URL in your browser to confirm it loads, then resubmit it in Search Console.

Key Takeaways

"Couldn't fetch" is a retrieval problem and not proof that your sitemap is invalid; many sitemaps showing this status load fine in a browser.
The most common causes are a domain mismatch (www vs. non-www, http vs. https), a blocked or slow server response, or Google holding a stale cached copy.
Resubmitting the same URL, sometimes twice in a row, clears the error for a lot of sites.
Some webmasters report that adding or removing a trailing slash in the submitted URL makes Google treat it as new, and that it works roughly half the time, so use it as a backup and don't count on it.
If every page indexes fine individually but the sitemap keeps failing, the problem is usually how the file is delivered, since your content is not the issue.

Before you touch Search Console, run the sitemap through a free Sitemap Checker (searchblueprint.io/free-tools/sitemap-viewer). It fetches the file the way Google does and flags a bad status code, a redirect or malformed XML in seconds, which gives you useful context before you start changing settings.

Person in winter gear using a laptop with a Google search on screen outdoors.

Why Google Search Console says it couldn't fetch your sitemap

Close-up of hands holding a tablet showing the Google search page.

Google's crawler requested the sitemap URL and got no response, a timeout, a redirect loop or an error code instead of a clean 200 status. The file can be perfectly fine and still trigger this: a slow server, a firewall rule or a one-off blip during Google's check is enough.

The usual suspects

The property you verified doesn't match the domain in the sitemap URL. One is https and the other http, or one has www and the other doesn't.
A caching plugin or CDN served Google a stale or broken copy instead of the live file.
The server returned a non-200 status code (404, 403 or a 5xx error) at the exact moment Google crawled it.
The sitemap references pages set to noindex, which can make some SEO plugins omit them and leave the file looking empty or malformed.

How to fix the "couldn't fetch" sitemap error, step by step

Person using a tablet with Google search open while having breakfast with toast and tea.

Open the sitemap directly in a private or incognito browser window. If you see a 404 or a blank page, the file itself is the problem and Search Console is fine.
Check that the property matches your sitemap's domain exactly. In Search Console, confirm the verified property uses the same protocol and subdomain as the URL you're submitting.
Clear any caching layer (plugin, host-level cache or CDN) and reload the sitemap to confirm it serves a fresh, current copy.
Go to Indexing > Sitemaps in the left-hand menu, enter the sitemap URL and click Submit.
Resubmit the same URL a second time without refreshing the page first. This alone resolves it for a meaningful share of cases.
If it still shows "Couldn't fetch" after a day, try submitting it with a trailing slash added or removed. Some webmasters have reported this works, but it isn't an official fix and it won't work for everyone.

If you haven't submitted a sitemap to this property before, walk through this guide on how to add a sitemap to Google Search Console to make sure the property and URL are set up correctly from the start.

Common causes and fixes at a glance

Cause	What You'll See	Fix	Typical Time to Resolve
Domain/property mismatch	Sitemap "Couldn't fetch" even though it loads fine in a browser	Verify the property that matches the sitemap's exact protocol and subdomain	Minutes once corrected
Stale cache served	File loads but shows outdated content or an error intermittently	Exclude the sitemap from caching, then purge cache	A few minutes to a day
Server returned an error code	Direct visit to the sitemap shows 404, 403, or 5xx	Fix hosting/permissions, confirm the sitemap feature is enabled	Varies by host
Google holding a cached failure	File now returns 200, but status hasn't updated	Resubmit, or resubmit with a trailing slash change	Up to a few days

According to Google's Search Console Help documentation, Google processes and re-checks sitemaps on its own schedule, so the status in Search Console doesn't always update immediately after you fix the underlying issue.

A smartphone displaying Google Search trends on a table at night.

When Search Console's own tools are enough and when they aren't

For a single page that won't index, or a one-off fetch failure right after you resubmit, Search Console's built-in tools (URL Inspection, the Sitemaps report and resubmission) are genuinely enough. They're free, they're Google's own data, and most single-URL problems resolve within the steps above.

They stop being enough when failures are site-wide or keep recurring. If the same sitemap keeps failing across multiple properties, if you manage sitemaps for dozens of client sites, or if you need to catch broken sitemap links before Google ever sees them, manual checking in Search Console doesn't scale. The same goes for related diagnostic work. Search Console lets you review backlinks pointing at your site, for example, and this walkthrough on checking spam backlinks using Google Search Console covers that without needing a paid tool. Search Console is the right first stop, but ongoing monitoring across many pages or sites is a different job.

Common mistakes to avoid

Submitting the sitemap under the wrong property (http instead of https, or missing the www) and assuming the file is broken.
Resubmitting constantly within minutes instead of giving Google time to re-crawl. It doesn't speed anything up.
Ignoring a genuine 404 or 403 on the sitemap because the error message points your attention at Search Console instead of the server.
Assuming "Couldn't fetch" means lost rankings. Individual pages can still index normally while the sitemap-level status shows an error.

FAQs

Does "couldn't fetch" mean my sitemap is broken?

Not necessarily. It usually means Google's crawler couldn't retrieve the file at the exact moment it checked. If the sitemap loads correctly in a browser and returns a 200 status, the file itself is working.

How long does it take for Google to fetch a sitemap after I fix it?

There's no fixed timeline. Google re-crawls sitemaps on its own schedule, and Search Console's status report doesn't always refresh right away, so it's common for the status to lag behind the actual fix by a day or more.

Do I need to resubmit my sitemap every time I publish new content?

No. Once Google has successfully fetched a sitemap, it re-crawls it periodically on its own. You only need to resubmit if the status shows an error or you've changed the sitemap's URL.

Why does the sitemap work in my browser but still show an error in Search Console?

This usually points to a domain/property mismatch, a caching layer serving Google a different version of the file, or Google still holding the result of an earlier failed attempt.

Can a noindex tag cause the "couldn't fetch" error?

Indirectly. If most of your content is set to noindex, some sitemap generators leave it out of the file entirely, which can make the sitemap look empty or trigger validation issues rather than a true fetch failure. According to Google Search Central's documentation on sitemaps, the file just needs to be reachable and correctly formatted, and what it contains is a separate issue from whether Google can retrieve it.

Resubmit the sitemap, then check back tomorrow

Confirm the sitemap loads with a clean status code, make sure the property matches your exact domain, resubmit it in Search Console and give Google a day before assuming anything is broken. If the Google Search Console couldn't fetch sitemap error keeps coming back across more than one site or property, talk to the team and get a sample report showing exactly what's happening with your indexing.

Sources

About the author

SearchBlueprint researched, wrote and scored this article with the content pipeline our customers run on their own sites. The score in the byline is what our content engine gave this page before it published. Nothing here is reviewed by hand, which is the point: it is the product's output, published where anyone can check it.