Run any sitemap through a free checker and you get a wall of red text. Missing namespace. Priority out of range. Three hundred URLs sharing the same lastmod date. It reads like the whole file is falling apart, and most of it won't move your indexing at all. A sitemap validator catches two very different classes of problem: the kind that stops Google from reading the file, and the kind Google reads fine and quietly ignores. Confusing the two means spending an afternoon fixing decimals nobody checks while a genuinely broken namespace sits untouched three lines up.
What actually goes into a sitemap entry
Every <url> block needs exactly one tag: <loc>, the absolute URL. Everything else is decoration Google is free to ignore. Per the sitemaps.org protocol, <lastmod>, <changefreq> and <priority> are all optional, and Google's own guide to building a sitemap says plainly that it ignores <priority> and <changefreq> — the fields exist, Google reads them, and does nothing with what it finds. <lastmod> gets more respect, but only when it's trustworthy: Google checks it against real changes on the page and stops believing it the moment every URL in your sitemap carries the same timestamp because a deploy script stamps the current time on every build.
| Tag | Required | Format | What Google does with it |
|---|---|---|---|
<loc> | Yes | Absolute URL, http/https, escaped | Fetches exactly this URL |
<lastmod> | No | W3C datetime, e.g. 2026-01-15 | Used only when consistently accurate |
<changefreq> | No | always / hourly / daily / weekly / monthly / yearly / never | Ignored |
<priority> | No | 0.0–1.0 | Ignored |
You can spend an afternoon tuning every page to a precise 0.7 priority. Nobody at Google will ever look at the number.
The two limits that force a sitemap index
A single sitemap file holds at most 50,000 URLs and 50MB uncompressed, per the sitemaps.org protocol — raised from a 10MB ceiling in November 2016 once the search engines agreed the old number no longer fit real sites. Cross either limit and you split the URLs across several sitemap files, then list those files in a sitemap index: a small XML file whose only job is pointing at your real sitemaps, up to 50,000 of them. Our XML Sitemap Generator does this splitting automatically once a crawl passes the URL count, so you don't have to watch the counter yourself.
A sitemap can only speak for its own directory
A sitemap can only list URLs at its own location or a level below it, per the sitemaps.org protocol — a sitemap served from /blog/sitemap.xml can list /blog/post-1/ but not /shop/product-1/. Google flagged this explicitly back in 2006, when sites first started splitting sitemaps by section: each file still has to live at or above every URL it lists.
Errors that break parsing vs. errors that just annoy Google
Not every red line in a validator report means the same thing. Roughly three tiers, in order of how much they matter:
Fatal. The file isn't valid XML, or the sitemap namespace is missing or wrong. Either one stops parsing before Google gets near your URLs — the whole sitemap gets thrown out, not just the broken entry.
Structural. A <loc> that's missing, relative, or contains an unescaped & where it needed &. These break the individual entry rather than the whole file — though a generator that forgets to escape ampersands usually breaks every entry with a query string at once.
Signal-quality. Everything else: duplicate URLs, a lastmod date identical across hundreds of entries, a sitemap never mentioned in robots.txt. None of these stop Google from reading the file. They just make it less trustworthy — like a résumé listing three job titles for the same role. Nobody rejects it outright, they just squint.
| Error | Tier | Effect |
|---|---|---|
| Not well-formed XML | Fatal | Whole file discarded |
| Missing or wrong namespace | Fatal | Whole file discarded |
Missing or relative <loc> | Structural | That entry discarded |
Unescaped & in a URL | Structural | Often many entries discarded at once |
| Over 50,000 URLs / 50MB | Structural | File rejected until split |
| Duplicate URL | Signal-quality | Wastes crawl attention, doesn't block it |
lastmod identical across most URLs | Signal-quality | Google stops trusting lastmod sitewide |
| URL blocked by robots.txt but listed in sitemap | Signal-quality | Contradictory signal, not a hard block |
That last row is more common than it should be. KeyCDN's writeup on the issue and the recurring threads in Google's own Search Console help community describe the same setup: a staging subfolder or a filtered category page gets disallowed in robots.txt after the sitemap was generated, and nobody regenerates the sitemap. According to SE Ranking's analysis of more than 418,000 site audits, close to 18% of sitemaps contain a URL that actually resolves to a redirect instead of a 200 status — a single-vendor figure, worth reading as "this happens constantly" rather than a precise industry constant, but it matches what turns up when you check a sitemap that hasn't been regenerated in a while.
Not a documented Google rule
Two more checks show up in most validators, ours included, without one specific Google sentence behind them: listing canonical URLs only, and keeping a sitemap to a single host. Tool vendors agree on both as good practice, and our own Sitemap Validator flags a sitemap that mixes domains or lists near-duplicates differing only by protocol or a trailing slash — but that's inferred guidance, not a documented rule, worth saying plainly instead of dressed up as gospel.
Reading the Search Console report without guessing
Search Console's Sitemaps report shows one of three statuses per submitted file. "Success" means Google fetched it and found no errors — URLs inside still have to earn indexing on their own merits, the status only covers the file itself. "Has errors" means Google read the file but flagged at least one problem inside it; entries that parsed cleanly are still queued despite the flag. "Couldn't fetch" means Google never got past requesting the file, commonly because the sitemap address is wrong or the file itself is blocked by robots.txt.
| Status | Meaning | Typical cause |
|---|---|---|
| Success | Fetched and parsed, no errors found | — |
| Has errors | Fetched, at least one issue flagged | Bad tag values, invalid dates, some entries invalid |
| Couldn't fetch | Google never retrieved the file | Wrong URL, blocked by robots.txt, server error |
Worth knowing before a strict validator report sends you into a panic: Search Console parses more leniently than the written protocol. SEOTesting's sitemap validator draws the same distinction between strict, spec-exact checking and the looser extraction Google actually runs — a file that fails strict validation can still show "Success" in Search Console because Google salvaged the URLs it could parse. We couldn't independently confirm exactly how far that tolerance extends, and that's genuinely unclear rather than a gap we're glossing over. Treat a strict validator's findings as worth fixing regardless; a file sitting at the edge of what Google currently tolerates isn't guaranteed to stay there.
Checking a sitemap without opening a terminal
Running the checks above by hand means opening the file, cross-referencing the spec, and hoping you didn't miss a stray ampersand three thousand lines down. Our free Sitemap Validator does the cross-referencing: paste the XML or point it at a live sitemap URL, and it flags every error and warning above with the exact line number. Don't know your sitemap's URL? The "find by domain" mode checks the usual locations and your robots.txt for a Sitemap: line. It also checks the live HTTP status of every URL inside, up to 200 per run, and separately verifies hreflang alternates for self-references and reciprocity — the same reciprocal-tag rule covered in our hreflang generator guide. Nothing you paste or fetch leaves your browser.