Couldn’t fetch sitemap in Google Search Console
“Couldn’t fetch” is one of the shortest messages in Search Console and one of the least informative. It sits next to a sitemap you submitted and reports that Google asked your server for that file and did not get back anything it could use. There is no second line.
Most of the advice written about it is guesswork: rename the file, resubmit it, wait a fortnight. This page runs the other way round. Below are the causes in the order they are worth checking, each with the specific test that confirms or rules it out, ending in one live fetch that separates a broken file from a blocked crawler.
What “Couldn’t fetch” actually reports
Three columns in the Sitemaps report matter: the sitemap URL, its status, and the date Google last read it. The status is a statement about a single HTTP request. Google resolved your domain, sent a GET for that exact address, and either got no response, got an error code, or got a body it could not parse as a sitemap. That is the entire content of the message.
Two things follow from it. First, the URLs inside the file were never read, so the report is saying nothing at all about your pages: not that they are broken, not that they were rejected, not that they are missing. Second, the status you are looking at came from the last attempt, not from this moment. Read the Last read date beside it. A recent date means Google is retrying and still failing. An empty one means Google has never successfully read this file, which usually points at the submitted path rather than the server. An old date next to a status that only turned red recently tells you something changed on your end around then, and that is a useful place to start.
One exception before you start digging. A sitemap submitted a few minutes ago can show this status simply because the fetch has not been attempted yet. Give a brand-new submission a day before you treat it as a fault.
The causes, in the order worth checking
The list is ordered by how often each one turns out to be the answer and how cheap it is to eliminate. The first three cover most cases and take about five minutes between them.
- 01
The sitemap URL errors out or redirects
Request the exact address listed in the Sitemaps report, character for character. A 404 means the file is not where you told Google it is. A 500 usually means a generator crashed: on WordPress the sitemap is built at request time by a plugin, and on a large site that query can run past the PHP time limit and die halfway through. Redirects are not fatal by themselves, since Google follows them, but a chain that ends on an error page is, and so is an http:// entry submitted to a site that now forces HTTPS and www.
Confirm it Run the URL through the HTTP status checker. Anything other than a 200 on the first request is your answer. If it redirects, trace the hops with the redirect checker and submit the final address instead.
- 02
robots.txt blocks the sitemap path, or blocks Googlebot
Google will not fetch a file that robots.txt forbids, and the sitemap is not exempt from that. The rules responsible are rarely aimed at sitemaps: a Disallow: / left behind from staging, a broad block on the directory a plugin writes into, or a group targeting Googlebot that is stricter than the group targeting *. There is a second version of this one that catches people out. If robots.txt itself returns a 503, Google treats the entire host as disallowed until it can read the file again, and the sitemap fetch fails as collateral damage.
Confirm it Open the robots.txt tester, enter your domain, put the sitemap path in the path box and Googlebot in the user-agent box. A BLOCKED verdict ends the investigation. While you are there, check the status robots.txt itself returns.
- 03
The response is HTML, not XML
This is the cause that hides best, because the request succeeds. The server answers 200 and hands back a page: a themed “not found” template for a path that no longer generates anything, a login screen, a cookie consent interstitial, a bot-check page, a maintenance notice. In a browser it looks like a page loading. To a parser the body opens with <!DOCTYPE html> where <?xml or <urlset> belonged, and there is no sitemap anywhere in it. Single-page apps produce this constantly: soft 404s from a catch-all route return the app shell with a 200 for every unmatched path, sitemap paths included.
Confirm it Look at the first line of the response body rather than the status code. The sitemap checker states this case outright: no <loc> entries found, that page is not a sitemap. It is the same conclusion Google reached, in plainer words.
- 04
gzip served with headers that contradict the body
A compressed sitemap is legal and common. It breaks when the compression and the headers disagree. Two shapes come up. A .gz file served as text/xml with no Content-Encoding, so the client reads compressed bytes as text and fails on the first character. Or a file already gzipped on disk that the server compresses a second time in transport, so one round of decoding leaves the client holding binary. Neither is obvious from a browser, which will usually just download the file and let you assume it arrived intact.
Confirm it Run the sitemap URL through the header checker. For a .gz file expect application/gzip; for a plain file expect application/xml or text/xml, with Content-Encoding: gzip present only when the body was compressed for transport. Then fetch it again and confirm the body actually parses.
- 05
The submitted URL is not the real sitemap path
Search Console keeps whatever you typed, typos included, and retries it forever. The usual mismatches: /sitemap.xml submitted for a site that publishes /sitemap_index.xml (Yoast, Rank Math) or /wp-sitemap.xml(WordPress core), an entry added under the non-www property while the site serves www, or a path left over from a plugin that has since been switched off. An entry with an empty Last read column, one that has never worked at all, is very often this.
Confirm it Read the Sitemap: lines in your own robots.txt, which is the address your site publishes to every crawler. The robots.txt tester lists all of them. If that address differs from the one in Search Console, the Search Console entry is the wrong one.
- 06
A firewall, WAF or bot rule is blocking Googlebot
Here the file is genuinely fine and Google specifically is not getting it. Cloudflare’s Bot Fight Mode, an Under Attack challenge, a country block, a security plugin’s rate limiter, a rule that rejects any request whose user agent is not a browser. What comes back is a 403, a 503, or a JavaScript challenge page that then fails as cause three. Sitemap indexes trip rate limits especially well, because Google requests the index and then its children in quick succession from the same range, and somewhere around the twentieth request the throttle engages.
Confirm it This is the one no outside tool can see for you, so go to your own logs. Filter the access log, or your WAF’s event view (on Cloudflare, Security › Events), by the sitemap path and look for requests carrying a Googlebot user agent that were blocked or challenged. Confirm the request really was Google’s with a reverse DNS lookup on the IP: it should resolve to a name in googlebot.com or google.com that forward-resolves back to the same address.
- 07
The file is genuinely too large
One sitemap file may hold 50,000 URLs and 50MB uncompressed. Past either limit it is rejected rather than trimmed. Size is the one people cross without realising, because a sitemap carrying image or video extensions spends far more markup per URL than a plain list of addresses. There is a softer variant too: a sitemap generated on demand for a large catalog can take half a minute to build and run out Google’s patience long before it runs out of bytes.
Confirm it Check the byte size and count the <loc> entries. The sitemap checker reports how many it found, and for a sitemap index it lists each child with its own count, so an oversized child stands out immediately. Anything near either ceiling should be split across several files under one index.
Confirming it in one pass
Most of that list collapses into a single question: can anything other than Google fetch this file? Paste the sitemap address into the sitemap checker, which requests it over a real HTTP connection the way a crawler would, and read which of three things happens.
- It cannot download the file at all. The problem is the file or the access to it, not Google. You are in cause one, four or six, and the status code it reports narrows that down further.
- It downloads something and reports no <loc> entries. Cause three. The response is a page, not a sitemap, and HTML is exactly what you have been sending Google.
- It fetches cleanly and lists your URLs. The file exists, parses, and is retrievable by an ordinary HTTP client. The difference must be who is asking, so move to robots.txt and bot rules.
For that third outcome, run the domain through the robots.txt tester with the sitemap path in the path field and Googlebot as the user agent. A clean fetch paired with a BLOCKED verdict is a complete diagnosis, and you got there without opening a log file.
One honest limit on this. A checker makes its request from its own address with its own user agent, so a successful fetch proves the file exists and parses; it cannot prove that Googlebot is welcome. That is precisely why the second step exists, and why cause six ends in your server logs rather than in a tool.
The “it says couldn’t fetch but the file loads in my browser” case
This is the most commonly reported version of the problem and the one that attracts the most useless replies, because the observation looks like it contradicts the error. It does not. Your browser is not Googlebot, and the two of you get different responses more often than anyone expects.
You are logged in
A session cookie walks you past a login screen, a staging password or a maintenance-mode plugin that every anonymous request hits head-on.
Consent walls and interstitials
A cookie banner or age gate that only serves the wall when no consent cookie is present. Google never has one.
Geography
A region block, or a CDN rule that routes traffic from outside your country to a different origin or a challenge page.
User-agent branching
A rule at the edge or in the application that handles unknown agents differently: a challenge, a redirect to a browser-support page, or a stripped-down response.
Your own cache
The browser may be showing a copy saved before the file broke. Reload with the cache bypassed, or request it from another network.
The status code you never saw
A browser renders a 404 or a 503 page as happily as a 200. What looked like the sitemap loading may have been an error page loading.
The test that settles it takes two commands from a machine outside your own network. Request the file as a plain client, then request it again claiming to be Googlebot, and compare the status line and the first line of the body.
curl -sI https://example.com/sitemap.xml
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/sitemap.xmlDifferent answers mean a user-agent rule somewhere between the edge and your application. Identical answers, both healthy, while Google still reports a failure, points at the remaining two variables: the IP range the request came from, and robots.txt.
After you fix it
Resubmit once. If the URL itself was wrong, remove the bad row in the Sitemaps report and add the correct address. If the URL was right and the server was at fault, submit the same address again. Either way that queues one fetch, and then the useful thing to do is nothing.
The field to watch is Last read, not the status. When that date moves, Google has genuinely retried. It normally happens within a few days, occasionally within hours on a site that is crawled often, and nothing you do speeds it up. Resubmitting every morning does not stack fetches in a queue; it overwrites the same entry, and it costs you the one signal you had, which was whether the date moved on its own.
If a week goes by with no change to Last read while the file downloads cleanly from outside your network, stop treating it as a file problem. Go back to causes two and six, because something is answering Google differently from everyone else. And while you wait, the sitemap being unreadable is not holding your pages out of the index: read the guide on fixing 404 errors if the Pages report is what actually changed.
Frequently asked questions
- Why does Search Console say couldn't fetch sitemap?
- Because the request Google made for that file failed. Google sent an HTTP request to the exact URL listed in your Sitemaps report and either got no response at all, got an error status such as 403, 404 or 503, or got a body it could not parse as a sitemap. The one message covers all of those, which is why it tells you nothing on its own. The realistic causes, in order: the sitemap URL errors or redirects, robots.txt blocks the path or blocks Googlebot, the server returns an HTML page instead of XML, gzip is served with headers that contradict the body, the submitted path is not the real one, a firewall or bot rule is answering Google differently, or the file is past the 50,000 URL / 50MB limit.
- My sitemap opens fine in the browser — why can't Google fetch it?
- Your browser sends a different request than Googlebot does, and it often gets a different answer. You may be logged in and passing a login screen, staging password or maintenance-mode plugin that the crawler runs straight into. A consent banner or bot challenge may appear only when no cookie is present, which is every request Google makes. A CDN or firewall rule may treat non-browser user agents, or IP ranges outside your country, differently. Your browser may also be showing a cached copy from before the file broke, and it will render a 404 or 503 page as readily as a real sitemap, so a page appearing is not proof that the response was a 200 with XML in it. Request the URL from outside your network, once normally and once with a Googlebot user agent, and compare the two.
- How long does Google take to fetch a sitemap after resubmitting?
- Usually a few days. Sometimes within hours on a small site that is crawled often, and there is no way to make it faster. Watch the Last read date rather than the status, because that is the field that changes when a fetch actually happens. If the date has not moved after about a week and the file downloads cleanly from a client outside your network, the problem is access rather than the file itself: check robots.txt and any firewall or bot rules that could be answering Google's request differently from yours.
- Should I delete and resubmit my sitemap?
- Only if the URL you submitted is wrong. Deleting an entry removes the row from the report, not the sitemap from your site, and it does not reset anything on Google's side or trigger a faster crawl. If the address is correct and the failure was on your server, fix the server and submit the same address once. If the address was never right, such as a path from a plugin you no longer use or a non-www URL under a www property, remove that row and add the address your robots.txt actually publishes.
- Does 'couldn't fetch' mean my site won't be indexed?
- No. A sitemap helps Google discover URLs; it is not a requirement for indexing them. Pages already in the index stay there, and pages reachable from your navigation or from links on other sites can still be found and crawled normally. What an unfetchable sitemap costs you is the fastest discovery path for new and deep pages, plus one of the signals Google uses when deciding what to recrawl. It is worth fixing and it is not an emergency. If you want to know whether indexing actually changed, read the Pages report, not the Sitemaps report.
- Which sitemap URL should I submit?
- The one your own robots.txt names on its Sitemap: line, on the exact protocol and hostname of the Search Console property you are working in. On WordPress that is normally /wp-sitemap.xml with core sitemaps, or /sitemap_index.xml with Yoast or Rank Math. Shopify, Wix and Squarespace publish /sitemap.xml. Submit the index rather than the individual children when your site has one, since Google reads the children from it. If robots.txt names no sitemap at all, add the line: it is how every crawler other than Google finds the file.
Related tools
Sitemap Checker
Fetch the sitemap over a real request and test every URL inside it.
robots.txt Tester
Check whether Googlebot is allowed to fetch the sitemap path.
HTTP Status Checker
Read the live status code the sitemap URL returns.
HTTP Header Checker
Inspect Content-Type and Content-Encoding on the response.
Fetch your sitemap the way a crawler does
One request, one answer: the file downloads and parses, or it does not. Free, no signup.