The short version
A sitemap validator checks one sitemap file against the sitemaps.org protocol: the root element, the namespace, absolute URLs, XML-escaped ampersands, valid W3C dates in lastmod, and Google's stated ceilings of 50,000 URLs or 50MB uncompressed.
Validator or checker: which do you want
These get conflated and they answer different questions. Our sitemap checker discovers what sitemaps exist on a site, follows indexes, and reports whether they respond. This validator takes one sitemap and inspects its contents.
So use the checker when you are asking whether a site has a working sitemap and where it lives. Use the validator when you have a file, possibly one not published yet, and want to know whether it is correct before it goes live.
The validator accepts pasted XML for exactly that reason. Validating a file you have generated but not deployed is the point at which fixing it is cheapest.
The errors that actually break a sitemap
Four of them, and they are worth knowing because most validators bury them in cosmetic warnings.
| Error | Why it breaks | Fix |
|---|---|---|
| HTML instead of XML | Crawlers get no URLs at all, and it looks fine in a browser | Find what is serving that path |
| Relative URLs in loc | The protocol requires absolute URLs including the protocol | Write the full https:// URL |
| Unescaped ampersand | Invalid XML, so the parse can fail outright | Write & as & |
| Malformed lastmod | Not a valid W3C date, so the value is unusable | Use YYYY-MM-DD or a full timestamp |
The limits, from Google directly
Google's documentation states that "all formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs." You are bound by whichever you reach first, and gzip does not help because the ceiling is on the uncompressed size.
Long URLs, or sitemaps carrying image and video extensions, can hit 50MB well before 50,000 URLs. The validator reports both numbers so you can see which one you are close to.
Past either limit, split the file and reference the parts from a sitemap index.
Warnings you can safely ignore, and one you should not
If the validator flags priority or changefreq, that is informational rather than a fault. Google states it ignores both values. Leaving them in costs nothing; tuning them is wasted effort.
The warning worth acting on is every lastmod carrying the same date. Google says it uses lastmod only when the value is "consistently and verifiably" accurate, which means a crawler can compare your claim against the page. A generator stamping today's date on every URL at every build has made the field demonstrably wrong, and at that point it would be better omitted entirely.
So there are two good states for lastmod: accurate, or absent. Automatically current is the bad one.
Questions about this tool
What is the difference between this and the sitemap checker?+
The checker discovers which sitemaps a site has and whether they respond. The validator inspects one sitemap's contents against the protocol, and accepts pasted XML so you can check a file before publishing it.
Do sitemap URLs have to be absolute?+
Yes. The protocol requires the full URL including the protocol, so https://example.com/page rather than /page. Relative URLs are a genuine error rather than a style preference.
Why does an ampersand break my sitemap?+
Because a bare & is not valid XML. It must be written as &. This commonly appears in URLs with multiple query parameters and can cause the whole file to fail parsing.
It warns about priority and changefreq. Should I remove them?+
No need. Google states it ignores both values, so they are harmless. The warning exists so you do not waste time tuning them.
Why flag identical lastmod dates?+
Google uses lastmod only when the value is consistently and verifiably accurate. A generator writing the current date to every URL every build makes it verifiably wrong, so the field stops being useful and would be better left out.