Sitemap couldn't fetch in Google Search Console: causes and fixes by status

When Google Search Console says your sitemap “couldn’t fetch”, Googlebot either tried to download the file and failed, or hasn’t fetched it yet. A one-minute live test with URL Inspection tells you which: if the test passes, the file is fine and you mostly wait; if it fails, the test shows you the block, the wrong URL or the server error to fix.

That split matters because the two cases need opposite responses. People who resubmit a working sitemap every day waste their time, and people who wait on a broken one wait forever. Google’s own Sitemaps report help page says that when a fetch fails, Google retries for a few days and then stops until you resubmit. Everything below is organized by what you see in the report, with the cause and the fix for each. The Google documentation quoted here was checked in November 2026.

Run this check before anything else

1. Open the exact sitemap URL in a private browser window. Copy it from the Sitemaps report, not from memory. You should see XML (a list of <url> and <loc> entries, or <sitemap> entries for an index), not your homepage, a login screen or a “page not found” page.
2. Check the status code. Run curl -I https://www.yoursite.com/sitemap.xml in a terminal, or use any free HTTP header checker. You want 200. A 301, 403, 404 or 5xx is your answer.
3. Run a live test in URL Inspection. Paste the full sitemap URL into the search bar at the top of Search Console and select Test live URL. Google’s help page says to confirm that Page fetch shows Successful before you submit a sitemap.
4. Read your robots.txt. Open yoursite.com/robots.txt and look for a Disallow rule that matches the sitemap path. Google lists “blocked by robots.txt” as the first fetch error to rule out.
5. Check the property. The sitemap must sit on the same protocol and hostname as the Search Console property you submitted it in (more on this below).

Step 3 decides which section of this guide you need. If the live test fetches the sitemap successfully, skip to the next section. If it fails, the error it shows points you to the section after that.

Symptom: “Couldn’t fetch”, but the live test passes

Cause: Google hasn’t spent the time on it yet. This is the most common case on new and small sites, and it isn’t a fault in your file. On Google’s Search Off the Record podcast, John Mueller explained that Google may label a sitemap “couldn’t fetch” when “we don’t have any time to crawl this sitemap file because we’re too busy with other things,” as Search Engine Journal reported on October 6, 2026. He added a second reason: Google may skip the file “because we got enough already,” and “the crawl demand is very often based on the perceived quality of a website.”

Google’s help page says the same thing in drier words. Under fetch errors it lists “low crawl demand” and notes that “other general errors,” such as a server being unavailable, can be transient.

Fix:

• Leave the submission in place for a week or two. Don’t delete and resubmit it every day.
• Add the sitemap to robots.txt with a line such as Sitemap: https://www.yoursite.com/sitemap.xml, which Google’s sitemap build guide supports. It gives Google a second way to find the file.
• Link your important pages from your navigation or from other pages. A sitemap helps discovery, but internal links are what Google follows on every crawl. Our internal linking tools guide covers how to find pages with no links pointing to them.
• If it still says “couldn’t fetch” after a couple of weeks while the live test passes, look at crawl demand rather than the file. Thin or duplicate pages are the usual reason Google wants less from a site.

What not to do: don’t take a lingering “couldn’t fetch” as proof your pages aren’t indexed. Check a few important URLs in URL Inspection. If they say “URL is on Google,” the sitemap status is cosmetic for now.

Symptom: “Couldn’t fetch” and the live test fails

Now there is a real fault, and the live test or your status code check usually names it.

Cause: you submitted the wrong URL. This is the one to check first, because it’s the easiest to miss. Typical mistakes are submitting a page (/sitemap or your homepage) instead of the XML file, or guessing a filename your site doesn’t use. WordPress’s built-in sitemap lives at /wp-sitemap.xml, but an SEO plugin usually replaces it with its own file at a different address. Shopify serves the sitemap at /sitemap.xml on your store’s domain, and so does Squarespace.

Fix: open the sitemap from your CMS or plugin settings (most have a “view sitemap” link), copy that exact URL, and submit it. Then remove the wrong entry from the report.

Cause: robots.txt blocks it. A broad rule such as Disallow: /wp- or Disallow: /*.xml can catch the sitemap by accident. Remember that Google caches robots.txt for up to 24 hours, so a fix may not show up straight away.

Fix: remove or narrow the rule, and check it in Search Console’s robots.txt report. If you’re also writing rules for AI bots, our robots.txt guide to AI crawlers shows how to target them without touching Googlebot.

Cause: the site is private or set to hide from search engines. Shopify says a sitemap can’t be read while the store is password protected. Squarespace says a private or password-protected site must be set to Public before the sitemap loads, and sitemaps aren’t available on trial sites. In WordPress, the “Discourage search engines from indexing this site” setting turns off the core sitemap altogether.

Fix: make the site public, or untick the WordPress setting under Settings, then Reading, then resubmit.

Cause: a firewall or security plugin returns 403 to Googlebot. Your browser sees the file, but Googlebot gets refused. The live test shows this even when your own check passes, which is exactly why step 3 matters.

Fix: allow verified Googlebot in your host’s firewall, CDN bot settings or security plugin, then rerun the live test. Don’t allow anything that merely calls itself Googlebot.

Cause: the file doesn’t exist (404) or the server errors (5xx). A 404 means the URL is wrong or the sitemap feature is off. A 5xx means your server failed when Google asked. Google calls server errors possibly transient, so one failed fetch on a cheap shared host may clear on its own. Repeated ones won’t. For 404s on normal pages rather than the sitemap, see how to fix 404 errors in Search Console.

Cause: a manual action. Google’s help page says sitemaps aren’t read while a manual action is unresolved. Check Security and manual actions, then Manual actions. This is rare, but it explains a sitemap that never fetches on an otherwise healthy site.

Symptom: “Has errors” or “Sitemap could not be read”

These two look alike but mean different things. Google’s help page explains that the details page shows Sitemap could not be read when the fetch failed, so treat it exactly like “couldn’t fetch” above. Has errors means Google got the file but couldn’t parse some of it. It still queues the URLs it could read, so a few errors won’t stop the rest of the site being found.

Open the sitemap’s details to see the error name and, for XML problems, the line number. The ones that turn up most on small business sites, with Google’s fix for each:

• URL not allowed or path mismatch. The sitemap lists URLs on a different protocol, hostname or www version than the sitemap itself, or above its folder. Google says to check that the URLs all begin with the same domain as your sitemap location. This often happens after a move to HTTPS or a domain change, when a static sitemap file still holds the old addresses.
• Invalid date. lastmod must use W3C Datetime format. The time is optional, but if you include one you need a time zone too, such as 2026-11-14T09:30:00-06:00.
• Invalid URL or parsing error. Spaces or unescaped characters in a URL, most often a bare & in a query string. Escape it as &.
• Unsupported format. A missing or wrong header or namespace, or curly quotes pasted in from a word processor. Google asks for straight quotes.
• Too many URLs or file size error. One sitemap can hold 50,000 URLs or 50MB uncompressed. Split it and submit a sitemap index instead. Few local businesses ever get close.
• Temporary error. Google says no action is usually needed. Resubmit only if it lasts several hours.

If your CMS or plugin generates the sitemap, fix the setting or the page causing the bad entry, not the XML by hand. A hand edit is overwritten the next time the file is rebuilt.

Symptom: the sitemap is missing or in the wrong property

Cause: property scope. Google says sitemaps appear only in the property they were submitted to, and that http, https, www and non-www count as separate sites. If you submitted to the old http:// property, the current https://www property will show nothing.

Cause: permissions. You need owner permission on the property to submit through the report. A full user without ownership can’t, so an agency or freelancer may see the sitemap missing for that reason alone. Our guide to adding a user to Search Console explains what each role can do. If you can’t get owner access, the robots.txt Sitemap: line still works.

Fix: add a Domain property if you can verify DNS, so every version of the site sits in one place, then submit there.

Symptom: “Success”, but the pages still aren’t indexed

A green status only means Google read the file and queued the URLs for crawling. It doesn’t promise to index them. If the report says Success and pages are still missing, the sitemap has done its job, and the reason sits on the pages themselves: noindex tags, canonicals pointing elsewhere, or content Google chose not to index. Our technical SEO issues guide works through those by symptom, and the technical SEO checklist covers what a clean sitemap should and shouldn’t list.

After the fix: resubmit once, then leave it

Once the live test passes, resubmit the sitemap in the report. Google’s help page says it retries a failed fetch for a few days and then stops, so a resubmission is what restarts it after a real fix. After that, Google rereads sitemaps it fetched successfully on its own schedule, separate from the rest of the site’s crawl.

Don’t use Remove sitemap as a reset button. Google says removing a sitemap only takes it out of the report. Google keeps the sitemap and the URLs it already knows. To stop Google crawling those URLs you need a robots.txt rule, a deleted file or a noindex header, not the report.

FAQ

Trust the live test over the status label

The Sitemaps report status lags behind reality and sometimes means “not yet” rather than “broken.” URL Inspection’s live test is the faster, more honest check. If it passes, link your pages well, list the sitemap in robots.txt and give Google time. If it fails, it tells you what to fix, and one resubmission afterward is all the report needs.

// written byLiam FraserSEO specialist with 3 years of experience. Liam writes about what works in local, technical and AI search.About SerpSurfers →