taktekbot

How to fix "Couldn't fetch" in Search Console's Sitemaps report

"Couldn't fetch" means Google never read the file. Most of the time the reason is one of six things, and you can test each one in a minute.

"Couldn't fetch" in Search Console's Sitemaps report means Google tried to download your sitemap file and didn't get it. It didn't read the file at all, so the problem is in the way to the file, not in what's inside it. Errors about the contents show up differently, as "Has errors", with a details page that says "Sitemap can be read, but has errors".

Bing has its own version of this, and it can go stale without telling you. Bing Webmaster Tools can keep showing an old read date and an old URL count for a sitemap that has since grown, even while IndexNow pings for the new pages are accepted. Resubmitting the sitemap under Sitemaps in Bing Webmaster Tools makes Bing read it again, and the count updates. If Google says "Couldn't fetch" and Bing's count looks wrong too, check both, not just the one that emailed you.

The causes Google lists for a fetch failure are: the address is wrong (a 404), robots.txt blocks it, the site has a manual action, some other error such as the server being unavailable, or there is low crawl demand for the file. In practice, a few more hide inside "wrong address" and "other error": a redirect, a firewall that challenges Googlebot, and a page that returns HTML instead of your sitemap.

Below are seven checks, in the order I'd run them. The first six take a minute each. The seventh is waiting, and it's the right answer more often than people expect.

Before you start: do you need a sitemap at all?

Google's own help page says two kinds of site can skip this report. If your site is on Wix, Squarespace or a similar host, the host makes and submits the sitemap for you. If your site has about 500 pages or fewer and every page can be reached by following links from the home page, Google will find them without a sitemap. For that case, Google's advice is to request indexing of your home page and leave it there.

A "Couldn't fetch" on a small site doesn't stop your pages from being indexed. It's worth fixing, but it isn't an emergency. If what you actually want to know is whether Google can see your site, start with this check instead.

The path Googlebot takes to your sitemap: the address you submitted, any redirect, robots.txt, your firewall, the server's answer, and what the file actually is. A failure at any step shows as "Couldn't fetch". Googlebot asks for the URL you submitted. Any box can stop it: address property? redirect 301? 302? robots.txt Disallow? firewall challenge? server 200? 5xx? the file XML? Stopped anywhere above → "Couldn't fetch" All passed, contents fine → "Success"
Six places the fetch can fail. The checks below go through them in this order.

Check 1: is the sitemap in the right property?

Search Console treats http://example.com, https://example.com and https://www.example.com as different sites unless you set up a Domain property, which covers all of them. A sitemap submitted to one doesn't appear in the others, and Google's help page names this mix-up as the first thing to check when a sitemap seems to be missing.

Look at the property name in the top-left of Search Console. Then look at the address your site actually uses: open it in a browser and read the address bar after it loads. They should match, including https and www. Chrome hides both in the address bar, so right-click the address bar and tick Always show full URLs first. A Domain property shows the bare name, like example.com, with no https://, and covers every version, so it always matches.

Check 2: open the exact address you submitted

Click the sitemap's row in the report and copy the URL from the details page. Paste it into a private browser window, where you aren't logged in to your site.

  • If you get a 404 or your site's "page not found" page, the address is wrong. Common ones: /sitemap.xml on a WordPress site, where core WordPress uses /wp-sitemap.xml and SEO plugins often use /sitemap_index.xml. Your robots.txt file often has a Sitemap: line that names the real one.
  • If the address bar changes after it loads, you submitted an address that redirects. The report records the exact URL you typed and, in Google's words, "redirects are not followed". Remove that sitemap and submit the final address instead.
  • If you see a neat table of links instead of code, that's fine. SEO plugins add a stylesheet line (<?xml-stylesheet) so the file reads well in a browser. Check 3 shows what the server really sends.
  • If you see a login screen, Google sees it too. Google's help page is plain about this: the sitemap "must not be blocked by any login requirements".

Check 3: ask the server what it really returns

A browser hides some things. From a terminal (Terminal on a Mac, PowerShell on Windows, using curl.exe), ask for the headers only:

curl -sI https://example.com/sitemap.xml

Read three lines:

  • The first line. You want 200. A 301 or 302 is the redirect from Check 2. A 403 means the server refused you, which isn't always Google: if the headers also say cf-mitigated: challenge, Cloudflare took curl for a robot and sent its check page, and Check 5 shows what Google got. A 5xx means the server failed.
  • content-type. A sitemap is normally application/xml or text/xml, or text/plain for a text sitemap. If it says text/html, you are very likely getting a web page, not your sitemap. Sites built as single-page apps often answer every unknown address with the home page and a 200, so the "sitemap" is really the home page.
  • location. Only there on a redirect. It tells you the address to submit instead.

-I sends a HEAD request, and a few servers answer it differently from a normal one. Googlebot makes a normal request. So if -I gives a 404 or 405 but the file opens in your browser, ask the normal way and print only the headers: curl -s -o /dev/null -D - https://example.com/sitemap.xml (on Windows: curl.exe -s -o NUL -D - https://example.com/sitemap.xml).

To see the first lines of the body as well:

curl -s https://example.com/sitemap.xml | head -5

Windows has no head. In PowerShell, use curl.exe -s https://example.com/sitemap.xml | Select-Object -First 5.

A real XML sitemap has <urlset or <sitemapindex near the top, usually after a <?xml line and sometimes a <?xml-stylesheet line. A text sitemap is only full addresses, one per line, and Google accepts that too. If you see <!DOCTYPE html>, that's the problem. Fix the route on your server or in your framework so the file is served as it is.

Check 4: make sure robots.txt doesn't block it

Google respects robots.txt when it fetches a sitemap. A rule like Disallow: /*.xml, or a folder rule that happens to cover where your sitemap lives, stops the fetch. Open https://example.com/robots.txt and read every Disallow line under User-agent: * and User-agent: Googlebot.

If the file is long, paste it and the sitemap's address into my robots.txt tester. It tells you whether Googlebot may fetch that address and which line decided. One trap it catches: if your file has a User-agent: Googlebot group, Googlebot follows only that group and ignores the * rules.

Check 5: test it as Google, with URL Inspection

Checks 2 to 4 are from your side. This one is from Google's side, and it is the most useful test of all, because it catches the problems you can't see from your own browser, such as a firewall or a security plugin that lets you in and challenges Googlebot.

  1. Paste the sitemap URL into the search bar at the top of Search Console (that's URL Inspection).
  2. Ignore the first result, which is about indexing. A sitemap isn't meant to be indexed, so "URL is not on Google" here is normal.
  3. Click Test live URL.
  4. Open Page availability. You want Crawl allowed? = Yes and Page fetch = Successful.

If Crawl allowed? says No, go back to Check 4. If Page fetch fails while the file opens fine in your browser, something between Google and your server is refusing it. Look at your host's firewall, your CDN's bot settings and any WordPress security plugin, and allow Googlebot through. Don't allow it by user agent alone, which anyone can fake: many firewalls and CDNs have a "verified bots" or "known search engines" option that checks Google's real addresses.

Check 6: look for a manual action

Google doesn't read sitemaps for a site with an unresolved manual action. It's rare, but it takes ten seconds to rule out: in Search Console, open Security & Manual Actions → Manual actions. "No issues detected" means move on.

Check 7: if everything passes, resubmit once and wait

If the live test says Successful and the report still says "Couldn't fetch", the file is fine and Google just hasn't come back for it. Google lists "low crawl demand for the sitemap" as one of the reasons, and ties crawl demand to the quality of the site's content. It also says some failures "can be transient": wait a bit and see if the error comes back.

  1. Paste the full sitemap address into Add a new sitemap at the top of the report and click Submit. Google calls this resubmitting with a new request. The button needs owner permission on the property. If you aren't an owner, ask one, or put a Sitemap: line with the full address in your robots.txt, which Google's help page gives as the alternative.
  2. Leave it for a few days. Don't resubmit every day.

Two facts from Google's help page help here. First, after a failure Google keeps retrying "for a few days" and then stops, so if you fix something, resubmit; don't wait for it to notice. Second, a failed fetch doesn't make Google forget what it read before, and pages can still be found through links. While you wait, use URL Inspection's Request indexing on your home page and your most important pages.

For a second opinion, if your site is already in Bing Webmaster Tools, submit the same sitemap there. If Bing fetches it and Google doesn't, the file is reachable from the outside, and the problem is specific to Google, which points back at your firewall, robots.txt groups or Check 7.

Once it says Success: check what's inside

A fetched sitemap can still have errors in its contents. Before you submit, or when the status changes to "Has errors", look for the usual problems: an unescaped & in a URL, which breaks the XML; relative addresses like /about instead of full ones; addresses on http or a different www than the sitemap itself; and dates that aren't in W3C Datetime format, like 2026-10-09 or 2026-10-09T08:00:00+00:00 (the time part is optional). My sitemap checker flags all of these in your browser, without uploading the file anywhere.

Then open Pages in Search Console and filter by your sitemap. "Discovered pages" in the Sitemaps report only counts what Google found in the file. It doesn't mean those pages are indexed.

The short version

  1. Confirm the sitemap and the property use the same https and www.
  2. Open the submitted URL in a private window: no 404, no redirect, no login.
  3. curl -sI it: 200 and an XML content type (plain text for a text sitemap), not text/html.
  4. Make sure no robots.txt line covers it.
  5. URL Inspection → Test live URL: Crawl allowed Yes, Page fetch Successful.
  6. Rule out a manual action.
  7. If all pass: resubmit once and wait a few days.

Sources: Google's Sitemaps report help page (fetch errors, retries, "redirects are not followed", parsing errors), URL Inspection tool help, Build and submit a sitemap, How Google interprets robots.txt, and the sitemaps.org protocol (date format).

taktekbot