Skip to content

SEO indexing diagnostics

How to diagnose “Couldn't fetch” for a Search Console sitemap

Opening sitemap.xml in a browser proves that one browser request received a response. Search Console reports what Google could retrieve at a different time and under different conditions. Collect evidence before changing XML, submitting repeatedly or publishing more articles.

Updated

1. Record the exact error and submission target

Record the Search Console property, submitted URL, status, last-read time and detailed error. A generic fetch failure does not establish an XML parsing error or prove that Google is blocked.

Check that you submitted within the correct verified property and did not accidentally use a staging host, wrong protocol or mismatched path. Reading the account report requires the appropriate Search Console access; a public URL check cannot replace it.

Google: Manage sitemaps with the Sitemaps report

2. Inspect the response rather than browser appearance

Check the final status and complete body. A login screen, challenge or generic homepage returning 200 is still not a sitemap. Look for redirect chains, intermittent timeouts, 403, 429 and 5xx responses, keeping timestamps for comparison with logs.

A tree view versus plain-looking text in a browser does not establish whether Google can process the XML. Check the declaration, root element, sitemap namespace and actual URLs instead of deleting correct entries to change the display.

  • Public requests receive XML rather than an HTML error page.
  • Entries use absolute URLs and properly escaped characters.
  • Each loc identifies a real public canonical page intended for indexing.
  • Modification dates represent actual content changes rather than deployment time.

Google: Build and submit a sitemap

3. Compare firewall and server logs

If normal access works while the report continues to fail, inspect CDN, firewall and server logs around the failure time. Look for challenges, access restrictions and temporary service problems. Browser and crawler requests can experience different conditions; narrow the fix using evidence.

Changing a User-Agent does not establish that a request is Googlebot or fully reproduce Google's access conditions. Do not allow access to sensitive endpoints based on a request header. Keep the investigation scoped to public content and the sitemap.

Google: Manage sitemaps with the Sitemaps report

4. Check real pages after sitemap processing succeeds

A sitemap provides discovery hints, not an instruction to index every entry. Inspect a representative article and its translated version with URL Inspection. Separate indexed information from the live test, checking responses, robots, noindex directives, canonical URLs and accessible content.

A passing live test describes current accessibility under the test conditions; it does not confirm indexing. If Google selects another canonical, identifies duplication or reports another exclusion reason, investigate that specific explanation.

Google: URL Inspection tool

5. Confirm the fix through reports

After correcting a verified issue, resubmit the sitemap in the matching property and watch the read record. Request recrawling for a small number of important pages where appropriate. Record fix and submission times without describing a submission confirmation as indexing.

Ordinary articles are not eligible for the Indexing API intended for specific page types. Repeated submissions do not guarantee faster inclusion. Improve internal links and content while waiting, without repeatedly changing URLs or canonicals without a reason.

Google: Ask Google to recrawl your URLs

6. Keep a reusable diagnostic record

Illustrative case: a sitemap submission fails while a normal request returns 200. Inspecting the body reveals an HTML challenge. The fix in this hypothetical example concerns public XML access, not article titles. This is a diagnostic demonstration, not a confirmed explanation of an incident on this site.

For each incident, preserve the URL, report time, status, response content type, actual body type, relevant logs, corrective action and follow-up result. Report that Google has read the sitemap only when its read record and successful status confirm it. Check page indexing separately.

Frequently asked questions

Does opening the sitemap in a browser prove Google can read it?

No. It proves that browser request worked. Google's request may encounter a challenge, rate limit or service failure at another time. Confirm the cause through detailed reports or logs.

Does a successfully read sitemap mean every article is indexed?

No. Reading, discovery, crawling and indexing are separate states. Use page-indexing reports and URL Inspection to confirm individual page status.

Put this guide to work for your business

Once indexing conditions are checked, need a clearer path from reading to enquiry? Discuss page creation, lead forms and conversion events with the LanderGrow team.

Contact your customer success manager

References

Keep reading

Contact your customer success manager

Contact your customer success manager

Add us on WhatsApp or Telegram to discuss your account setup.

Can’t add us, or don’t use Telegram or WhatsApp?

Prefer another way? Leave your contact details and we will reach you within 10 minutes.