What “Sitemap couldn’t fetch” tells you

The top-level status describes retrieval of the sitemap file. A parsing error concerns the content of a retrieved file. A page-indexing exclusion concerns an individual page. Start with the layer that failed; changing page titles will not repair a missing sitemap endpoint.

Google’s sitemap overview explains the discovery role of a sitemap. It can help crawlers find URLs, but it does not guarantee crawling or indexing. This guide covers the file-delivery problem. For the wider system, use our technical SEO guide.

Record the failure before changing settings

1. Copy the exact submitted sitemap URL, including protocol, hostname and path.
2. Save the detailed error and the report’s last-read date, if present.
3. Record the first time you noticed the problem and relevant releases: plugin changes, redirects, hosting work or security rules.
4. Identify whether the failed address is a sitemap index or an individual child file.

Keep the screenshot and current file response together. The error report and your new test may describe different moments. If you need help navigating the interface, our Search Console guide explains the reports.

Google recommends live inspection of the submitted sitemap URL to investigate access. Use Page availability to check crawl access and fetching. Its URL Inspection documentation also explains the distinction between stored and live results.

Check the response and choose the matching fix

A browser view hides useful evidence: whether you followed a redirect, received a login page or saw a cached response. Save the actual GET response, including its body. A HEAD-only request does not retrieve that body.

curl --silent --show-error --max-time 30 \
  --dump-header sitemap-headers.txt \
  --output sitemap-body.xml \
  --write-out "HTTP %{http_code} | URL %{url_effective}\n" \
  "https://example.com/sitemap_index.xml"

Replace the example URL with the submitted address. This command writes two local evidence files and does not follow redirects. The curl manual documents the options. On Windows, use curl.exe where curl is an alias. Inspect the files before interpreting the result.

Scroll sideways to read the full table.

These observations narrow an investigation; they do not identify the responsible component by themselves. Google’s HTTP-status guidance explains crawler handling of response classes. For a persistent availability failure, continue with our 503 troubleshooting workflow.

The sitemap report documents that submitted sitemap redirects are not followed. A live URL Inspection test can follow redirects without showing the final URL. Inspect the first response separately; a successful live test can otherwise obscure the wrong submitted address. Our redirect guide covers implementation.

Check robots.txt and the matching Search Console property

Google respects robots.txt when fetching a sitemap. Check the live file on the submitted sitemap’s hostname and the rule applying to that exact path. In the sitemap’s Live URL Inspection result, expand Page availability and look for Crawl allowed? Yes and Page fetch: Successful. A robots block can coexist with a successful ordinary browser request.

The Sitemaps report documentation also lists unresolved manual actions and low crawl demand among possible fetch-error causes. Check the Manual actions report if the endpoint tests pass. Do not diagnose low crawl demand from a 200 response alone.

Confirm that you are reading the property that matches the submission. URL-prefix properties distinguish protocol and host variants; a sitemap in another property will not appear in the current report. Record the property alongside the submitted URL before changing the file.

WordPress and Next.js: check the actual generator

Yoast SEO

Find the sitemap through Yoast SEO → Settings → Site features → XML sitemaps → View the XML sitemap. Use the generated address rather than guessing a filename. Yoast documents this route and explains that its XML sitemap can carry an X-Robots-Tag: noindex, follow header. The file does not need to rank as a search result to be useful.

For an actual sitemap 404, Yoast’s troubleshooting steps include saving Settings → Permalinks without changing the structure, checking whether content exists for a child sitemap and investigating server rewrite rules. Save and retest after one change. If the endpoint still fails, give the host the exact response rather than repeatedly resaving settings.

Rank Math

For a sitemap 404, Rank Math also documents saving the existing permalink settings. For stale output, examine sitemap caching and conflicting files or plugins. Follow the relevant part of its sitemap troubleshooting documentation after identifying the symptom. Keep intentionally excluded pages excluded; making everything indexable is not a general sitemap repair.

A useful before-and-after record names the provider, the endpoint, the incorrect response, the configuration changed and the repeated test. It should be possible for another developer to understand why that particular change was made.

Next.js and other application routes

Next.js supports static app/sitemap.xml and generated app/sitemap.ts or app/sitemap.js conventions. Its sitemap documentation explains caching behavior and generation of multiple sitemaps. Check the deployed route, its data source and the output served in production. A development URL is insufficient evidence for the submitted production endpoint.

For any framework, check whether middleware, authentication or a fallback page intercepts the sitemap route. Compare the deployment that works with the one that fails, then verify the resulting response. A CMS setting cannot correct a failure introduced by a separate proxy.

Cloudflare: prove which layer blocked the request

A Cloudflare response header alone does not prove that Cloudflare generated a 403. A proxied origin can return the same status. Use the failed request’s timestamp, hostname, path and request identifier where available to correlate the edge event with origin logs.

Cloudflare’s Security Events documentation explains how to inspect mitigated requests. Find the matching action and rule. A matching block event supports an edge-rule diagnosis; an origin rejection requires investigation at the origin. Log availability and retention depend on the account and product.

Changing a command-line request’s user-agent to Googlebot tests a header-dependent response. It does not turn the request into Googlebot. Google documents verification by IP ranges or reverse and forward DNS. Match the appropriate crawler or fetcher category; a user-triggered inspection and an automatic crawl need not encounter identical rules.

If a managed WAF rule is demonstrably responsible, Cloudflare documents conditional exceptions. Scope the correction to the relevant rule and legitimate request conditions. Managed-rule exceptions do not skip every security product. Re-run the original failing test and confirm the expected event afterward.

Do response headers prove what failed?

Inspect headers together with the response body. RFC 7303 registers both application/xml and text/xml. Seeing text/xml alone does not establish a defect. An HTML content type is a reason to inspect the bytes and route, rather than proof of a particular Google error.

Likewise, Cache-Control: private governs shared-cache storage; it does not, by itself, prove a login requirement. RFC 9111 defines that directive. Compare an unauthenticated GET, the actual body and matching request logs before changing authentication or cache policy.

Validate the XML and every referenced child sitemap

An XML parser can check well-formedness. It cannot, by itself, establish that a document is a useful sitemap. Check the root element, namespace, URL entries and the actual bytes returned.

• For an XML URL sitemap, inspect urlset in the sitemap namespace and its url/loc entries.
• For an XML sitemap index, inspect sitemapindex and test the child URLs referenced by sitemap/loc.
• Escape special characters inside XML values. In a URL query, an ampersand must be represented as & in the XML source.
• Use UTF-8 and correct malformed tags or encoding at the generator. Check compressed files with a compatible decompressor.

The Sitemaps protocol defines the XML structure and escaping. Google’s build-and-submit documentation sets a single sitemap limit of 50,000 URLs or 50 MB uncompressed. Larger inventories need multiple files. Include the intended canonical page URLs rather than redirect variants.

A working index is only the first test. If sitemap_index.xml loads but post-sitemap.xml returns an error, record the child failure separately. For a small index, inspect every child; for a large one, automate checks and document which failures were found.

Tested local example: three different responses with 200 OK

Scope: We ran eight controlled HTTP fixtures on a local loopback server on October 1, 2026. Each received a real curl GET, followed by a Python XML parse and a root-element check. This is a local demonstration of response diagnosis. It is not a client case study, a test of Google or a production CDN experiment.

Scroll sideways to read the full table.

<loc>https://example.com/service/?a=1&b=2</loc>

<loc>https://example.com/service/?a=1&amp;b=2</loc>

Both endpoints returned 200. Only the corrected fixture passed the XML parse and sitemap-root check. The parser recovered the intended URL value, including the query separator. The change repaired XML serialization; it did not create a new destination URL.

To reproduce the comparison on files you control, save each GET body and run the following Python check. This checks parsing and the XML sitemap root, not every protocol rule, URL’s availability or Google acceptance:

import xml.etree.ElementTree as ET

root = ET.parse("sitemap-body.xml").getroot()
allowed = {
    "{http://www.sitemaps.org/schemas/sitemap/0.9}urlset",
    "{http://www.sitemaps.org/schemas/sitemap/0.9}sitemapindex",
}
print("Sitemap root:", root.tag in allowed)

An HTML response requires correcting the route, authentication or response-producing layer. An XML-escaping failure requires correcting serialization. Their identical HTTP status should not lead to identical fixes.

Verify the correction in separate steps

1. Repeat the same GET. Preserve the response headers and body after the correction.
2. Repeat the XML and child-file checks applicable to your submission.
3. Run the relevant Google live inspection; record the result and test time.
4. Resubmit the corrected sitemap when appropriate. Record a subsequent read and status separately from the live test.
5. Inspect representative important page URLs to assess page indexing independently.

Google’s Sitemaps report shows the latest sitemap request and a last-read date when a fetch occurred. A subsequent read is stronger evidence than repeatedly reopening an old error. For a temporary processing error, Google says it can retry; follow the detailed error’s guidance rather than applying a fixed waiting period to every failure.

A passing live inspection does not guarantee page indexing. If important pages remain excluded after the file works, switch to our page-indexing diagnosis. If multiple public endpoints fail, use the broader crawl-error workflow.

What if every current test passes but the report still fails?

Keep the old report and current test times separate. A later successful request does not prove an earlier request succeeded. Preserve the first response, parsed body, child results and live-inspection result, then search available edge and origin logs around the failed read. Missing retained logs leave the original cause unconfirmed.

If no continuing defect is demonstrated, follow the detailed error’s retry guidance and record the next sitemap read. Escalate a persistent mismatch with the exact URL, property, timestamps and test evidence. Repeatedly renaming the file or changing unrelated plugin settings makes that comparison harder.

Prevent a repeat after the file works

Scroll sideways to read the full table.

Run the endpoint and structure checks after sitemap-generator, routing, hosting or security changes. Compare URL counts with a documented baseline; choose alert thresholds appropriate to normal publishing and deletions. Do not invent a universal percentage. Monitor the important page URLs separately from the sitemap file.

Give your developer a verifiable repair ticket

Scroll sideways to read the full table.

A ticket saying “fix Search Console” cannot be accepted objectively. A ticket documenting a particular route and showing the corrected response can. Keep the old evidence so a later recurrence can be compared with the same failure.

Frequently asked questions