Sitemap can be read, but has errors: fix the file Google received
The fetch worked, so stop checking status codes. Validate the XML, URL format, encoding and size that Search Console read, then resubmit.
What this status actually means
“Sitemap can be read, but has errors” is different from a failed fetch. Google downloaded the file, so the server, DNS record, TLS certificate and CDN all worked. The problem is what the file contained or how it was parsed.
Open the sitemap row in Search Console and read the error details rather than editing the file blindly. The wording usually points at one of four layers: malformed XML, an unsupported format, URLs that cannot be indexed, or a file that exceeds a limit.
| Error detail | What to inspect | Typical fix |
|---|---|---|
| Invalid XML | Unescaped &, broken tags, wrong encoding | Escape entities and validate the document with an XML parser |
| Unsupported format | The URL returns HTML, a feed, or gzipped text Google cannot expand | Serve one of the supported sitemap formats |
| URL not allowed | URLs from another host, or malformed loc values | Use absolute URLs on the same site |
| Too large | More than 50,000 URLs or 50 MB uncompressed | Split into child sitemaps under an index |
Validate the XML before touching Search Console
Fetch the exact URL Google fetched and parse it as XML, not as text in a browser tab. A document can look fine while one unescaped ampersand breaks the whole file.
Look for the expected root element. A page sitemap starts with urlset; an index starts with sitemapindex. If the root is html, the sitemap route is serving the app shell instead of XML.
curl -sL https://example.com/sitemap.xml -o sitemap.xml
head -c 200 sitemap.xml
xmllint --noout sitemap.xmlCheck every loc, not just the first one
A single invalid entry can raise the warning. Sample the listed URLs and confirm each one is absolute, on the verified host, and returns a normal page rather than a redirect chain or a 404.
Remove URLs you do not want indexed: login and dashboard routes, parameter combinations, and pages that canonicalise somewhere else. A sitemap is a recommendation list, so include the version of each page you want Google to keep.
- Every loc uses the final HTTPS host.
- No localhost, staging, or preview domains.
- No session IDs or sort/filter parameters.
- No URLs that redirect to a different page.
- No URLs that return noindex.
Resubmit only after the file is fixed
Replace the deployed file, fetch it once yourself, and confirm the response is XML. Then resubmit the same URL in Search Console and wait for the next read. Resubmitting an unchanged file does not clear a parsing error.
If the warning persists after a successful fix, compare the last-read time with the deployment time. A CDN or build cache can keep serving the previous document for a while.
Frequently asked questions
Does a warning stop pages from being indexed? Not by itself. Google can still crawl and index listed URLs, but a broken file reduces discovery and hides the rest of the list.
Should I delete and resubmit the sitemap? Deleting is rarely necessary. Fix the file, fetch it, and resubmit the same URL; keep the history in one place.
The sitemap validates locally but not in Search Console. Compare the exact response Google receives, including redirects, content type, compression, and any CDN challenge.
Check the page, not just the sitemap
A readable sitemap still lists pages that may be noindexed or canonicalised elsewhere. Run the URL through a free audit before resubmitting.
Run a free audit