Sitemap Could Not Be Read: Diagnose the Actual Response

“Sitemap could not be read” is a problem with the submitted sitemap request, not proof that every page on your site is missing from Google. Open the sitemap’s detail view, expand the reported error and check the exact URL Google attempted. Then inspect that URL’s HTTP response and actual body before regenerating the sitemap.

A file can have a .xml address and return a login screen. It can be valid XML today while Search Console still shows a failed request from yesterday. Those situations need different next steps.

Separate a fetch failure from a parsing failure

Google’s Sitemaps report documentation distinguishes the following outcomes:

Record the submitted address, property, error detail, Submitted date and Last read where present. Last read is not an indexing date for the pages in the file.

Keep three questions separate throughout the investigation:

1. Can the exact sitemap file be fetched?
2. Does its body contain a supported, readable sitemap?
3. Can Google crawl and index the individual pages it lists?

Fixing question one does not settle question three.

Step 1: verify the exact submitted address

Copy the URL from the report rather than typing the path you think the CMS uses. Check the protocol, host and path. http://, https://, www and non-www addresses are different requests.

Common sitemap locations include /sitemap.xml, /sitemap_index.xml and a platform’s own generated path. A sitemap index lists child sitemap files; it is not the same as a sitemap listing pages.

If a redesign retired the submitted path, find the current generated sitemap and submit its direct public URL. Google’s report identifies the exact submitted sitemap and says redirects are not followed for that address. Do not rely on the browser silently taking you from an old path to a working new one.

Our Sitemap Checker and Validator helps discover sitemap declarations in robots.txt and common paths. Read the URL it actually selected. Finding a different working sitemap on the same host does not establish that the particular file failing in Search Console works.

For a general explanation of sitemap types and discovery, read what a sitemap is.

Step 2: inspect a GET response and the body

Ask your developer to capture a normal GET request, including response headers and body. A HEAD request checks headers only and can behave differently on a misconfigured route.

For example, this command saves the first response without following redirects:

curl --silent --show-error \
  --dump-header sitemap-headers.txt \
  --output sitemap-body.xml \
  'https://example.com/sitemap.xml'

Replace the example with your submitted address. Inspect both saved files. The command’s output filename does not make the response XML.

A successful local request proves only that your request succeeded. It does not prove that Google received the same content from another network at a different time. Likewise, a public checker’s failure can come from a rule aimed at that checker.

Do not disable the whole firewall as a diagnostic shortcut. Preserve the failing URL, request time and response, then review the specific access rule. Google’s crawler verification guidance explains how to verify crawler identity; changing a user-agent string to “Googlebot” does not perform that verification.

Step 3: check the actual sitemap structure

For an XML sitemap, inspect the response body or use a full XML parser. A browser’s styled display can hide the underlying markup.

A minimal page sitemap looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/services/</loc>
  </url>
</urlset>

Check for HTML before the XML, plugin warnings inserted into the response, incomplete closing tags, unescaped special characters and invalid URL values. If the file is compressed, verify decompression before parsing the resulting XML.

Google’s sitemap construction guide covers supported formats, UTF-8 encoding, absolute URLs and size limits. A single sitemap may contain up to 50,000 URLs and be up to 50 MB uncompressed. Split larger sets into files referenced by a sitemap index.

Those are Google’s limits, not our tool’s scan limits. The Web Aloha checker uses a lightweight structure parser, a 5 MB uncompressed response cap and bounded processing. Its “Valid XML” result means it recognised the expected sitemap structure, not that it completed XML Schema validation.

Step 4: open child files individually

A working index can point to a broken child. Open each child referenced in the failed report and repeat the response and parsing checks.

This matters after catalogue changes: the main index may still return normally while a product sitemap throws a server error. Conversely, an old child may have been deliberately retired while its reference remains in the index.

The free checker samples at most the first five child files, retains a bounded URL list and stops within its time budget. It does not fetch every listed page. A clean sample cannot clear the remaining child files or establish page indexability. Its report can also be cached for up to ten minutes, so check the live file directly when verifying a fresh release.

Step 5: compare with Google’s current fetch

Paste the exact sitemap URL into Search Console’s URL Inspection, run Test live URL, and inspect the availability and fetch details. Google’s Sitemaps help recommends this to diagnose fetch failures.

For this task, you are checking whether the sitemap can be fetched, not asking Google to index the XML as a search result. If the live result and the older Sitemaps record disagree, compare their dates and preserve both observations.

If Google’s live fetch fails while your browser succeeds, inspect access logs and delivery rules with your developer or host. If Google can fetch it now but the report has not recorded a later attempt, an immediate rewrite may only obscure a resolved transient failure.

Worked example: a sitemap route returns the homepage

This example is illustrative, not a captured production incident.

Before a routing correction, a site returns:

GET /sitemap.xml
HTTP 200
Content-Type: text/html
Body: the normal homepage HTML

An owner sees a page load and assumes the address works. The response is successful HTTP, but it contains no sitemap. A catch-all website route handled a missing file.

After correcting the route, the same direct URL returns the intended XML sitemap. The developer verifies its body, confirms its child references where relevant and then resubmits it. Only a subsequent Google report can establish Google’s fetch outcome; only page-level inspection can establish the listed pages’ indexing states.

Finish with a focused acceptance check

Before resubmitting, confirm that the submitted URL directly serves the intended sitemap, its structure parses, required child files work and no access rule blocks the request. After a persistent failure is corrected, resubmit the sitemap and monitor the next recorded result. Google’s documentation says failed fetches are retried for a while, but persistent failures can stop those attempts.

If the sitemap reads successfully and the complaint is now “my page is not indexed,” move to the website visibility decision tree or the Search Console guide. Repeatedly submitting a readable sitemap does not diagnose a page-level noindex, canonical decision or content problem.

Google documentation and the checker’s limits reviewed on 28 October 2026.