Google Search Console Couldn't Fetch Sitemap: How to Find the Cause

A Webflow site owner received an HTTP 200 response for sitemap.xml, yet still had trouble registering it in Google Search Console. The response identified the file as application/rss+xml, raising a question that the successful response code could not answer: what did Google receive, and could it read it?

When Google Search Console couldn't fetch sitemap content, its Sitemaps report has not successfully retrieved the submitted file for the request shown. The status alone does not prove an XML error or identify the cause. Check the exact URL and report details, then test access, redirects, and the returned content before resubmitting. These checks show when a short wait is reasonable and when investigation should start.

What “Google Search Console couldn't fetch sitemap” means

Google's Sitemaps report documentation distinguishes three outcomes. Success means Google fetched and read the sitemap. Couldn't fetch means Google could not retrieve it. Has errors means Google fetched the file but encountered problems reading some of its contents. Those are different starting points for troubleshooting.

Open the sitemap's detail page rather than relying on the status in the main table. Google distinguishes “Sitemap could not be read” from “Sitemap can be read, but has errors” and provides further error details there. A parsing error calls for inspecting the returned file; a failed fetch calls first for checking the address and access to it.

The status reflects the latest reported request, not a permanent judgment on every URL the site has submitted. Google says it retries a failed fetch for a few days before stopping if the sitemap remains unavailable or has critical errors. A newly submitted sitemap may therefore warrant a brief recheck. A status that persists for weeks or months warrants diagnosis, even when the XML is generated automatically.

Start with a quick check: wait or investigate?

Use the Sitemaps report to make the first decision. Record the submitted sitemap URL, its status, any detail-page error, and the Discovered pages count. Then open that exact URL in a private browser window. This is a quick public-access check, not proof that Googlebot receives the same response.

1. The submission is recent, the file opens publicly, and no specific error is shown: Allow time for another attempt, then recheck the report. Google's retry guidance supports waiting briefly, not waiting indefinitely.
2. The URL fails to open or returns a login page, 404, or server error: Investigate the endpoint immediately. A valid sitemap elsewhere on the site will not fix a broken submitted address.
3. The file opens but “Couldn't fetch” persists: Check Google's detail-page error, robots rules, security controls, redirects, and what the server actually returns to different requests.
4. The status is Success but Discovered pages is zero: Shift attention from fetching to the sitemap's contents and the type of sitemap submitted.

A count of zero alongside “Couldn't fetch” does not identify a second failure. Google defines Discovered pages as page URLs it parsed from the sitemap; if it has not retrieved and read the file, zero can follow from that first problem. Investigate the fetch before treating the count as evidence that every page is missing or excluded.

Verify the exact sitemap URL you submitted

Copy the URL from Search Console's Sitemaps report and compare it with the site's live sitemap. Check the protocol (https versus http), hostname (www versus non-www), path, spelling, and trailing path components. https://example.com/sitemap.xml and https://example.com/blog/sitemap.xml are different endpoints, even if both look plausible in a submission field.

Open the copied address and confirm it returns the intended sitemap—not a homepage, branded 404 page, security challenge, or unrelated feed. A sitemap index should point to child sitemaps; a standard XML sitemap should list page URLs. The filename alone cannot establish what the server delivered.

Also confirm that the Search Console property matches the site being inspected. Google notes that http/https and www/non-www properties can cause confusion when a sitemap is not visible where expected. If a platform publishes the sitemap at a different address than /sitemap.xml, submit the published address rather than guessing a conventional filename.

For a command-line check, request the submitted URL as a normal GET request:

curl -L -D headers.txt -o sitemap-response.xml 'https://example.com/sitemap.xml'

headers.txt records response headers and redirects; sitemap-response.xml holds the returned body. Inspect both. A successful-looking response code is less useful if the saved body is HTML instead of the expected sitemap.

Check whether Google can reach the sitemap

A sitemap that loads on an office laptop may still be unavailable to Googlebot. Google's fetch-error guidance names a robots.txt block, an incorrect URL, an unresolved manual action, and server unavailability among possible causes. Start with those checks before changing the XML.

Test public access and blocking rules

Request the sitemap without signing in. Check whether robots.txt blocks Google from fetching the sitemap URL, and review Search Console's Manual actions report if the sitemap detail page or site history points that way. If the server intermittently returns a 5xx error, investigate hosting and CDN logs around attempted fetches rather than judging availability from one successful visit.

Next, inspect firewall, bot-protection, and geographic rules. A site might serve the file to its owner while challenging or denying another visitor. Community troubleshooting has raised the possibility of restrictions affecting requests from the US, but a location test cannot establish what Googlebot receives. Review security-event and origin-server logs for the sitemap path, including blocks, challenges, and rate limits. Do not assume that a request succeeds merely because its user-agent string says Googlebot—that string can be copied.

Use Search Console for corroboration

The URL Inspection tool can test a representative *page URL* and show whether Google can access that page. It does not replace the Sitemaps report's error details or a server-log check for the sitemap file. If pages are accessible but the sitemap is not, focus on rules or responses specific to /sitemap.xml rather than changing site-wide crawl settings without evidence.

Look for redirects and sitemap format problems

Follow the submitted URL's redirect chain and inspect its final response. An HTTP-to-HTTPS or non-www-to-www redirect may be ordinary, but a chain ending in a 404, login screen, security challenge, or unrelated document gives Google the wrong destination. If the site has a stable final sitemap URL, submitting that address removes an avoidable redirect from the path being tested.

Check the bytes, not just the filename

Open the saved response from the curl test. For a standard XML sitemap, expect a well-formed document with a sitemap root such as <urlset> or <sitemapindex>, not HTML that happens to be served from a .xml URL. An XML parser can catch malformed markup:

xmllint --noout sitemap-response.xml

Passing that check confirms XML syntax, not that every listed URL is useful or that Google could fetch the file. If Search Console says it *can* read the sitemap but reports errors, use those specific errors to guide the next correction.

Worked example: HTTP 200 with an RSS content-type

In the Webflow sitemap report, a request to sitemap.xml returned HTTP/2 200 with content-type: application/rss+xml; charset=utf-8; the headers also showed a Cloudflare cache hit. That response proves the reporter's request reached a server and received a body. It does not prove Googlebot received the same response, and the header alone does not establish a format failure: RSS feeds can be submitted as sitemaps.

The next checks separate delivery from format rather than treating the header as a verdict:

For this case, save the response body, identify whether it starts with <rss>, <urlset>, or something else, and compare that result with the sitemap detail-page error. If the body is well-formed but the reported response still appears wrong, provide the URL, headers, and body to the platform or CDN. A filename change would not resolve a blocked crawler or an incorrect response.

What to do when GSC shows zero discovered pages

Search Console's Discovered pages figure counts page URLs parsed from a sitemap, including URLs in child sitemaps when the submitted file is an index. It is not a count of indexed pages. Google says that discovery through a sitemap does not guarantee a URL will be crawled or indexed.

Work through the count in order:

• Couldn't fetch plus zero: Resolve the fetch problem first; Google may have had no file from which to parse URLs.
• Success plus zero: Confirm the submitted file or its child sitemaps contain page URLs rather than an empty sitemap, an unrelated feed, or only references that fail to load.
• Discovered pages above zero but little search visibility: Inspect representative page URLs and use Search Console's Page indexing report to investigate indexing separately.

For a lean publishing team, this distinction matters. Publishing an article to the site's own URL does not make a sitemap submission an indexing command. A reliable workflow keeps the published destination, sitemap entries, and Search Console observations aligned. For broader publishing checks, see the guide to source-backed AI-generated content SEO.

Resubmit carefully—and know when to escalate

Fix the observed problem before trying another submission. Correct a mistyped URL, remove a sitemap-specific block, repair a failing redirect, or replace malformed output as appropriate. Retest the final address publicly and confirm its response body contains the intended sitemap. Then submit the corrected URL through Sitemaps in Search Console and watch its status and discovered-page count.

Google says it retries failed fetches for a few days but may eventually stop; after a persistent failure is fixed, a new submission prompts another request. If the sitemap was already read successfully and only routine content changed, Google also says it periodically recrawls it, so repeated submissions are generally unnecessary.

Removal is optional housekeeping, not a repair mechanism. In the sitemap's detail page, use the more options menu and Remove sitemap if an obsolete submission needs to leave the report; then submit the correct URL. Google notes that removing a sitemap from the report does not make it forget the sitemap or URLs already found there. Similarly, changing sitemap.xml to a new filename is a community-suggested retry tactic, not evidence that the underlying access problem is solved.

If the same error persists after the final URL works, escalate with specifics: the Search Console detail-page message, submitted and final URLs, response headers and body, redirect chain, and relevant server or CDN events. Platform support can act on that evidence more readily than on the status alone. Teams balancing these technical checks with regular publishing can also compare manual SEO and content automation workflows.

FAQ

Does a sitemap fetch error mean my pages are not indexed?

No. The Sitemaps report describes Google's attempt to retrieve a submitted file, not the indexing status of every page on the site. Google says removing a sitemap from the report does not erase URLs it already knows. Check specific pages with URL Inspection, and use the Page indexing report to assess indexing rather than inferring it from one sitemap status.

How can I tell whether Googlebot, rather than my browser, was blocked?

Compare the sitemap error in Search Console with server and CDN security logs for that exact path. Look for denied requests, challenges, rate limits, and differing responses around Google's attempted fetches. A successful browser request or a curl command using a Googlebot user-agent cannot prove that Google's verified crawler was allowed through.

Can a Blogger or other platform-generated sitemap show “Couldn't fetch”?

Yes. Automatically generated XML does not prevent a wrong submitted path, access rule, redirect failure, or temporary server problem. For a Blogger or other hosted site, locate the sitemap URL the platform publishes, open it without signing in, and compare it with the address in Search Console. If the URLs match but delivery fails, take the response and report details to platform support.

Is a temporary processing error the same as an XML sitemap error?

No. A temporary fetch or processing problem concerns Google's ability to retrieve or handle the request; a parsing error concerns content Google fetched and attempted to read. Search Console's sitemap detail page is the place to distinguish them. Recheck a recent transient error, but investigate a recurring one instead of assuming more time will repair an invalid response.

For teams that also need a publishing workflow, Seovyn syncs a site's sitemap weekly to link to existing pages, including pages published by Seovyn. That sync helps connect published content; it does not diagnose or repair a Search Console fetch error. Start free.