Search Console troubleshooting

Google Search Console couldn’t fetch your sitemap

The “Couldn’t fetch” status means Google did not successfully retrieve the submitted sitemap in its last reported attempt. Work from the exact submitted URL and its live HTTP response before changing sitemap entries.

Confirm the exact URL and property

Copy the sitemap URL from the Search Console details page rather than typing it again. Check the scheme, hostname, port, path, filename, and capitalization. A sitemap at https://www.example.com/sitemap.xml is a different URL from http://example.com/sitemap.xml. Search Console properties also distinguish combinations such as HTTP/HTTPS and www/non-www when URL-prefix properties are used.

Open the URL in a private browser window and request it from a command-line HTTP client if available. A browser can follow redirects and display a branded error page in ways that conceal the original response. Record the first status, redirect chain, final URL, response content type, and body.

Read the HTTP response before the XML

A healthy public sitemap normally returns HTTP 200 without login, cookies, JavaScript, a challenge page, or a form. Common retrieval failures include:

• 404 or 410: the submitted path does not exist, the generator is disabled, or a deployment omitted the file.
• 401 or 403: authentication, a firewall, bot protection, or an access rule blocks the request.
• 429: rate limiting treats crawler requests too aggressively.
• 5xx: the origin, serverless function, CMS, or upstream dependency failed while generating the sitemap.
• Redirect problems: a loop, excessive chain, cross-host redirect, or redirect to a login/home page prevents retrieval of the XML.
• HTTP 200 with HTML: a soft error page or application fallback responds successfully at a missing sitemap path.

Inspect requests in origin and edge logs around Google's reported fetch time. A successful request from your own IP does not establish that a crawler received the same treatment.

Review robots and edge security rules

Google's Search Console documentation lists robots.txt blocking as a cause of sitemap fetch failures. Check every applicable Disallow rule, including wildcard patterns that unintentionally match the sitemap path. A Sitemap: line helps discovery but does not override a blocking rule.

CDN bot products, web application firewall rules, country restrictions, ASN filters, browser-integrity checks, and managed challenges can also treat crawler traffic differently. Use narrowly scoped exceptions for the public sitemap path when a rule is responsible. Avoid disabling broad security controls without evidence from logs.

Check TLS, DNS, and response consistency

Confirm the hostname resolves publicly, its TLS certificate covers the submitted host, and both IPv4 and IPv6 endpoints behave consistently. Intermittent origin timeouts can produce a successful manual test and a failed crawler attempt minutes apart. Test the URL several times and review server health around the recorded failure.

For dynamically generated sitemaps, keep generation fast and independent of fragile downstream services. Pre-generating a static XML response is often easier to serve reliably than rebuilding a large inventory during every crawler request.

Account for framework and hosting fallbacks

Single-page applications and static hosts often route unknown paths to index.html. The sitemap URL then returns HTTP 200 while its body contains the website shell. Serverless routes can fail similarly when a production environment variable, database connection, or route export is missing. Confirm that the sitemap path is emitted as a real static asset or handled by a dedicated route before the catch-all fallback.

Check deployment manifests and immutable deployment URLs when the platform provides them. If an immutable build serves the right XML while the production hostname serves an older response, the alias, cache, or promotion step needs attention. Purge only the affected sitemap cache after deployment rather than clearing unrelated site content.

When Search Console says the sitemap could not be read

Search Console distinguishes retrieval from processing. A file may be fetched and then produce XML or sitemap-protocol errors. Download the exact live body and validate that copy. Look for HTML injected by an edge service, truncated output, invalid UTF-8, unescaped ampersands, broken closing tags, a missing sitemap namespace, or a response that exceeds protocol limits.

If CorrectSitemap reports a clean result, continue with the delivery checks above. Its clean result covers the supplied document within a 5 MiB analysis ceiling; it does not reproduce Google's network request or certify search-engine acceptance.

Resubmit after the live fix

1. Verify the exact public URL returns the intended XML with HTTP 200.
2. Confirm robots and edge rules allow the sitemap request.
3. Validate the downloaded response body.
4. Use URL Inspection's live test where Search Console makes it available and review page availability.
5. Resubmit the corrected sitemap in the Sitemaps report.
6. Allow time for another fetch; the displayed status may not update immediately.

Google states that it retries failed sitemap fetches for a period, then stops after continuing failures. Once the underlying cause is fixed, a fresh submission gives the corrected endpoint a clear new attempt.

Interpret delayed status carefully

The report describes Google's last sitemap request, so a recently repaired endpoint and a stale failure can coexist. Preserve evidence from the current response and server logs while waiting for the next attempt. Repeatedly changing the sitemap URL or adding disposable query parameters makes the submission history harder to understand and can leave several equivalent entries in the report.

“Success” means Google fetched and read the sitemap. It does not promise that every discovered page will be crawled or indexed. Use the Page indexing report and URL Inspection for page-level outcomes after retrieval succeeds.

Primary reference

Google's Search Console Sitemaps report documentation describes “Couldn’t fetch,” retrieval causes, report scope, live URL inspection, and resubmission behavior.