Search Console Says Your Sitemap Has Errors? What Each Status Actually Means (and the Fix)

Search Console's Sitemaps report flagged your sitemap — but the status alone does not tell you what is broken. "Couldn't fetch" means Google never got the file. "Sitemap could not be read" means it got the file and could not parse it. And a sitemap that reads fine can still list URLs Google will never use. Each failure has a different fix, and fixing the wrong one wastes a resubmission cycle. Here is what each status actually means, in the order you should check them.

First, the distinction that saves the most time: a sitemap is a hint, not a command. Submitting one does not guarantee Google downloads it, crawls the URLs in it, or indexes any of them — Google's own build-and-submit documentation says so plainly. So a sitemap error is worth fixing, but a clean sitemap is not a promise of indexing. Keep that in mind before treating any single status as an emergency.

1. "Couldn't fetch": Google never got the file

Couldn't fetch is a retrieval failure, not a content failure. Googlebot asked for the sitemap URL and did not get a usable response. The usual causes, in the order to check them: the URL is wrong (a typo in the submitted path, or a sitemap that moved without updating the submission); the server returned an error (a 500, or a 404 because the file was deleted or never generated); the sitemap URL is blocked by robots.txt (yes, this happens — a broad Disallow that catches the sitemap path, or a staging robots.txt pushed to production); or the host itself was unreachable during the fetch attempt (DNS failure, server down, or a firewall blocking Googlebot). Fetch the exact submitted URL in your own browser first. If you get anything other than a 200 with the sitemap content, you have found it. If the browser fetch works but Google still reports Couldn't fetch, check the response from Google's side: a robots.txt block, a server that rate-limits or blocks crawler user agents, or a CDN rule that serves Googlebot an error page. One more trap: submitting a sitemap URL on a different host than the property it belongs to. A sitemap at example.com can only list example.com URLs, and a property for the www host does not automatically cover the apex host — the sitemaps protocol ties a sitemap's scope to where it lives, and Search Console enforces the same boundary. If the fetch keeps failing intermittently, look at server logs for Googlebot's requests around the reported fetch time; a pattern of 500s or timeouts under crawler load points at the server, not the file.

2. "Sitemap could not be read": the file arrived, but it does not parse

This is the XML failure. Google downloaded something at the sitemap URL and could not parse it as a sitemap. The most common causes: the file is not valid XML at all (an unclosed tag, a stray ampersand in a URL that was never entity-escaped to &, a PHP warning or HTML error page served with a .xml extension); the wrong namespace (the urlset element must declare the sitemaps namespace, or parsers reject the file); a gzip-compressed sitemap served without the right content encoding, or a .xml.gz file that is not actually gzipped; or a file that is not a sitemap format at all (an HTML error page, or a JSON feed submitted where an XML sitemap was expected). The fix is mechanical: run the file through an XML validator and fix the first error it reports, because XML parsers stop at the first problem — everything after it is unexamined, so one broken tag can hide the rest. Pay special attention to URLs containing & characters: every & in a URL must appear as & in the XML, and this is the single most common parse failure on hand-built or template-generated sitemaps. Also check encoding: the file must be UTF-8, and a file saved in another encoding with non-ASCII characters in URLs will fail in ways that look mysterious until you check the byte encoding. After fixing, do not just resubmit and wait — fetch the URL again and confirm it parses cleanly first, because resubmitting a still-broken file restarts the same waiting period for the same error.

3. Sitemap index errors: the index is fine, a child is not

A sitemap index is a file that lists other sitemaps instead of pages, used once a site outgrows a single file (over 50,000 URLs or 50MB uncompressed). When Search Console reports errors against an index, the index itself usually parsed fine — the failure is in one or more of its children. Open the index, take each child URL it lists, and fetch it individually. You will typically find one of three things: a child URL that 404s (the file was renamed, deleted, or never generated, while the index still references it); a child that fails to parse (same XML failures as section 2, now one level down); or a child that lists URLs outside the index's host scope. The fix belongs to the child, not the index — but remember to also fix the index if it references children that no longer exist, or the error will recur on the next read even after the child is repaired. One related mistake: submitting each child sitemap separately in addition to the index, then "fixing" only the separately-submitted copy. Google reads the file at the URL you submitted; if the index points at an old copy, editing the other copy changes nothing. Always fix the file at the exact URL the report names.

4. The sitemap reads fine, but Google discards half the URLs in it

This is the most misunderstood status, because nothing looks broken. The Sitemaps report shows a "Discovered URLs" count far below the number of URLs you submitted, with no error at all. Google read the file, then threw entries away — because a sitemap entry is only usable if the URL is crawlable, indexable, and canonical. The entries Google discards are almost always one of these: URLs that redirect (Google follows the redirect and indexes the destination, not the sitemap entry — and if the entry keeps pointing at the redirect, it keeps being discarded); URLs that return 404 or another error; URLs blocked by robots.txt (a sitemap can list a URL that robots.txt blocks, and our robots.txt and XML sitemaps guide explains why that combination quietly fails); URLs carrying a noindex tag or header; and URLs that are not the canonical version (a duplicate or parameter variant whose canonical points elsewhere). The fix is a sitemap audit, not a resubmission: crawl your own sitemap's URLs, drop every entry that does not return a 200, indexable, canonical page, and regenerate the file from your live URL list rather than patching it by hand. A sitemap that lists only real, current pages is worth more than a large sitemap padded with dead entries — Google uses the discovered count, not the submitted count, when deciding how much attention the file deserves.

5. Zero discovered URLs and no error at all

A sitemap that parses, returns no error, and still yields zero discovered URLs usually has a scope or content problem rather than a syntax problem. Check these in order: the file is empty or contains only a header (a generator that produced no entries, often because its URL source was empty or its query failed silently); the file lists URLs on a different host than the sitemap itself (cross-host entries are ignored — a sitemap at example.com cannot claim shop.example.com URLs unless cross-submission is properly set up and verified); the submitted URL is a sitemap index whose children are all empty or broken (the index reads fine, so no error is reported against it, while every child yields nothing); or the file is in a format Google read as something else (a text file of URLs submitted with an XML content type, or vice versa). The diagnostic is simple: open the submitted URL, count the entries yourself, and confirm at least one entry is a live, same-host, indexable page. If the file genuinely contains good entries and the count is still zero, wait one full crawl cycle before concluding anything — a newly submitted sitemap can take days to be read, and "zero" during that window means "not yet processed," not "rejected."

6. Lastmod lies: the dates Google has learned to ignore

The lastmod tag tells crawlers when a page last changed, and Google says it uses the value only when it is consistently and verifiably accurate. Two patterns destroy that trust. The first is stamping every URL with today's date on every regeneration — the sitemap claims the whole site changed daily, which is false, so Google stops believing any of the dates. The second is never updating lastmod at all, so genuinely changed pages look untouched and unchanged pages look fresh. Both produce the same result: Google ignores your lastmod values and falls back to its own crawl scheduling, which is slower for your real updates. The fix is to generate lastmod from the actual content modification time — the page's real last-edited timestamp from your CMS or database — and to leave it alone when nothing changed. A related mistake is using lastmod on a sitemap index to mean "these pages changed": on an index, lastmod describes when the child sitemap file changed, not when its pages did. And note what Google ignores entirely: priority and changefreq values have no effect on crawling or ranking, so tuning them is wasted effort that could go into accurate lastmod values instead.

Using a sitemap checker the right way

Before resubmitting anything, validate the file outside Search Console, because Search Console's feedback loop is measured in days while a checker answers in seconds. The best sitemap checker for this job is one that fetches the live URL (not a pasted copy), parses it as strict XML, and reports per-entry problems: which entries redirect, which 404, which are blocked by robots.txt, and whether the file exceeds the 50,000-URL or 50MB limits. Run it in this order: first the exact URL you submitted to Search Console, then each child if it is an index, then a sample of the entries themselves for status codes. Run the free robots.txt and sitemap checker on your sitemap URL — it validates both files together, which matters because a sitemap entry blocked by robots.txt is the single most common "reads fine, discovers nothing" cause, and checking the two files separately hides exactly that interaction. If the checker is clean and Search Console still reports an error, the difference is usually timing (an old cached read) or host scope (you checked a different host variant than the one submitted). Fix the file at the submitted URL, resubmit once, and then leave it alone — repeated resubmissions of an unchanged file do not speed up processing.

FAQ

Does submitting a sitemap guarantee my pages get indexed?
No. A sitemap is a discovery hint: it tells Google which URLs exist and when they changed. Google still decides independently whether to crawl and index each URL, based on quality, links, and crawl budget. A clean sitemap helps discovery; it does not override an indexing decision. If pages are discovered but not indexed, the answer is in the Pages report, not the Sitemaps report.

What is the best free sitemap checker for diagnosing these errors?
The best free sitemap checker fetches your live sitemap URL, validates it as strict XML, and checks each entry's status code and robots.txt accessibility — not just whether the file parses. A checker that only confirms "valid XML" will miss the most common real-world failure: entries that redirect, 404, or are blocked by robots.txt, which parse perfectly and still get discarded.

How long after fixing a sitemap error should I wait before re-checking?
Days, not hours. Google re-reads sitemaps on its own schedule; resubmitting after a fix is correct, but re-checking the same day usually shows the old status. Fix the file at the submitted URL, resubmit once, and check back after a few days. If the same error persists after a week, the fix did not address the actual cause — re-run the per-entry checks rather than resubmitting again.

Why does my sitemap show fewer discovered URLs than I submitted?
Because Google discards entries that redirect, return errors, are blocked by robots.txt, carry noindex, or are not the canonical version. Audit the sitemap's entries against their live status codes and canonical tags, remove the dead entries, and regenerate from your live URL list. The discovered count, not the submitted count, is the number that matters.

Do small sites even need a sitemap?
Not necessarily. Google's sitemaps overview says a small, well-linked site (roughly 500 pages or fewer) can usually be discovered through internal links alone. A sitemap still helps new sites with few external links, large sites, and sites with media or news content — but for a small site, a clean internal link structure matters more than a sitemap file.

Can one sitemap list URLs from another domain or subdomain?
Generally no: a sitemap's URLs must belong to the same host as the sitemap file itself, with cross-submission allowed only when all sites involved are verified in the same Search Console account and the setup is done deliberately. Listing another host's URLs in an ordinary sitemap just gets those entries ignored, which is another quiet route to a low discovered-URL count.