“Couldn’t fetch” next to a sitemap in Search Console means one specific thing: Google could not retrieve the sitemap file itself. Not that it disliked the contents, not that the URLs inside have problems. The request for the file failed, so Google never saw a single URL you listed. That specificity is useful, because it shrinks the search space to the handful of things that can stop a fetch, and Google’s own help page lists them.
The status sits alongside two others in the Sitemaps report. Success means the file was fetched and read with no errors, and the URLs were queued for crawling. Has errors means Google got the file but choked on parts of it, and whatever parsed cleanly still went through. Couldn’t fetch is the only one of the three where nothing happened at all.
Why does Search Console say couldn’t fetch?
Google’s documentation gives five causes. This is the order I check them in, which is roughly the order of how often they turn out to be the answer on real sites:
The submitted URL is wrong. The file is not where the submission says it is, and Google gets a 404. This one is embarrassingly common on WordPress sites where the sitemap moved when an SEO plugin was installed, removed or replaced: the plugin’s sitemap_index.xml was submitted years ago, the plugin is gone, and core’s /wp-sitemap.xml lives at a different path. Open the exact submitted URL in your browser. If you do not see XML, neither does Google.
robots.txt blocks the sitemap. Google respects robots.txt when fetching sitemaps, so a disallow rule that matches the sitemap path stops the fetch cold. Check with the robots.txt report or by reading the file. The nastier cousin is a robots.txt that itself cannot be fetched reliably, which degrades all crawling, and I covered that failure separately in robots.txt unreachable.
The server failed on that request. Timeouts, 5xx errors, a firewall or bot-protection layer challenging Googlebot. These can be transient, and Google says so: it retries a few times before giving up on a sitemap. The catch is that your browser is the wrong test for this cause, because CDN and bot-protection rules treat browsers and crawlers differently. Test the sitemap URL with the URL Inspection live test, which fetches as Google actually fetches.
A manual action on the site. Sitemaps are not read while an unresolved manual action stands. Rare, but it is a two-second check in the manual actions report, and if it is the cause, the sitemap is the least of your problems.
Low crawl demand. The quiet fifth cause: Google fetches sitemaps on a schedule driven by how much it wants to crawl the site, so on a very low-demand site the fetch may simply not have happened yet. This is the one that explains “Couldn’t fetch” appearing seconds after submission and resolving itself by morning. Give a fresh submission a day before treating the status as real.
How do I test a sitemap the way Google fetches it?
My working sequence on any Couldn’t fetch, whether on my own property or a client audit:
- Open the exact submitted URL in a browser. Wrong path and dead files fall out here.
- Run the same URL through the URL Inspection live test. This catches everything the browser test cannot: robots.txt blocks, bot protection challenging Googlebot, server behavior that differs by user agent.
- Read robots.txt for any rule matching the sitemap path.
- Check the manual actions report.
- If all four are clean and the submission is fresh, wait a day, then resubmit.
Once it fetches, the file has to survive parsing too, and the ceilings are part of that: 50,000 URLs or 50 MB uncompressed per file before you must split it, which I covered in how many URLs can a sitemap have.
On this property the report has been Success on sitemap-index.xml since launch, and I keep it that way with a habit worth stealing: the sitemap URL is part of my routine checks, not something I look at only when a report goes red. A sitemap that quietly starts failing costs you discovery of new pages first, which is precisely the part you notice last, because Google does read lastmod from a well-behaved sitemap and new URLs enter the queue from it.
One permission note that catches people on new properties: submitting through the report requires owner permission on the property. If you only have full or restricted user access, the submit button is not for you, but listing the sitemap in robots.txt achieves the same discovery without any Search Console access at all.
And when the status does flip to Success, know what you have actually won. Success is a verdict on your XML rather than on your index, which is why a sitemap can be submitted and still not indexed with the report showing green the whole time.
Sources
- Google Search Console Help, Sitemaps report, status definitions, fetch error causes, retry behavior and the owner permission requirement, checked 30 August 2026
- Google Search Central, build and submit a sitemap, on size limits and the robots.txt sitemap line
- Google Search Console Help, URL Inspection tool, for the live test that fetches as Google