Sitemap Couldn’t Fetch, but It Opens in Your Browser
Diagnose sitemap fetch errors with a response worksheet, XML examples, last-fetch evidence, and a clear path for hosting support.
A sitemap opening in your browser proves that your browser obtained a response. It does not establish what Google received, whether that response is valid sitemap XML, or when Search Console last tried to fetch it. Diagnose those questions before replacing the file.
Start with the submitted URL
In the Sitemaps report, open the affected submission and record the exact URL, last read/fetch information and detailed error. Do not silently substitute a similar filename. A sitemap index and an individual child sitemap may have different outcomes.
Google's Sitemaps report guide describes checking error details and using URL Inspection's live test to investigate fetch failures. A sitemap submission is a discovery hint, not an indexing guarantee.
| Check | Record | Why it changes the diagnosis |
|---|---|---|
| Address | Scheme, host and full sitemap path | The submitted location may be wrong |
| Redirects | Initial status and final URL | A browser may hide a redirect to a login/error page |
| Body | XML root and a representative URL | A 200 response can contain HTML instead of XML |
| Access | Live-test fetch and robots result | Public browser access is only one observation |
| History | Error date and last deployment | A report may describe a previous response |
| Child files | Index entries and child responses | A valid index can reference failing files |
A misleading 200 response
These are constructed examples. Neither is a measurement of your site.
HTTP/2 200
content-type: text/html
<html><body>Please sign in to continue</body></html>
The browser displays a page successfully, but that body is not a sitemap. Compare it with a minimal intended sitemap body:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https://example.com/guide</loc></url>
</urlset>
Check the body as well as the extension and content type. If there are encoding/escaping problems, the sitemap generator can prepare XML from your intended URL list. It cannot prove that Google fetched the published file.
When to investigate the host
If the exact file is valid and publicly accessible, save the live test outcome. If it fails, provide your host with the affected URL, UTC timestamp, status/body sample and any matching access-log entry. Ask them to check access rules or upstream errors associated with that request rather than to disable security globally.
The local log analyzer can summarize supplied logs. A Googlebot-looking user agent is a claim, not authenticated identity; server verification is a separate step. No matching log row may also mean you have incomplete logs.
When the file changed recently
Use a sitemap comparison to compare saved before/after files. Unexpected URL removal is a different problem from failed fetching. A correct current file plus an older error can justify observing the next fetch, but there is no universal waiting period that proves everything is healthy.
If you have a sitemap index, work through sitemap index structure and test the affected children. If the live URL is blocked, review robots syntax.
A useful handoff note
Submitted sitemap URL:
Search Console error and last fetch date:
Live test date and result:
Browser/GET final URL and status:
Body root (urlset, sitemapindex, or something else):
Affected child sitemap, if any:
Recent publishing/access-rule change:
What has been ruled out:
Recheck the same URL after the fix. Save the new fetch result separately from any later page-indexing results; a successfully read sitemap does not mean every listed page will enter search.