What does a sitemap validator check?
A sitemap is the one file a site hands to a search engine that is allowed to be wrong in silence. A `<loc>` with a typo, a `lastmod` that is not a date, a namespace dropped by a template, an index pointing at a child that 404s — none of it stops the site working, and all of it quietly costs indexing, because a crawler that cannot read the file simply carries on without it. This validator fetches the sitemap a site actually serves, parses it as XML, and checks it against the sitemap protocol line by line.
It finds the file the way a crawler does rather than asking you for the exact address. Enter a site and it reads robots.txt for the `Sitemap:` line, then tries the conventional names — `/sitemap.xml`, `/sitemap_index.xml`, `/wp-sitemap.xml`. Enter an address that ends in `.xml` and that exact document is validated instead, which is what you want when a file has already been reported as broken.
The result is a short list of checks with a verdict each, plus the entries themselves so a bad value is visible in place. The score is only there to make the list scannable: a sitemap with seven warnings is usually working fine, while a single failed check — a root element that is not `<urlset>`, or a document that is not XML at all — means every crawler is discarding the whole file.
How to validate a sitemap
- Enter the site address — `https://example.com` — and the sitemap is found the way a crawler finds it, starting with the `Sitemap:` line in robots.txt. If you already know the file, paste its full address instead and that one document is validated.
- Press Validate sitemap. One request is made for the file; nothing else on the site is fetched or crawled.
- Read the checks in order. The first four decide whether the file can be used at all: is it well-formed XML, is the root element `<urlset>` or `<sitemapindex>`, is the namespace declared, does the size and entry count stay inside the limits.
- Work through the warnings on the values — a `lastmod` that is not a W3C datetime, a `changefreq` outside the seven allowed words, a `priority` that is not between 0.0 and 1.0. Each of those is silently discarded by crawlers rather than being treated as an error.
- Look at the entry table for the flagged rows: the value that caused each flag is shown next to the URL, so a template that stamps every page the same is obvious at a glance.
- Fix and re-run. If the sitemap is generated by a CMS plugin, the fix usually belongs in the template rather than in the XML, so the next regeneration does not undo it.
Sitemap validation limits and rules
| Item | Limit |
|---|---|
| Checked | Well-formed XML, root element, namespace, entry count, file size, lastmod, changefreq, priority, duplicate URLs, cross-host URLs, robots.txt declaration |
| Protocol limits | 50,000 URLs and 50 MB uncompressed per file, both enforced by search engines and checked here |
| Entries echoed | First 100, with the flags for each |
| Indexes | A `<sitemapindex>` is validated as an index, and its children are listed rather than followed — following every child would mean fetching a whole site |
| File discovery | robots.txt first, then /sitemap.xml, /sitemap_index.xml, /wp-sitemap.xml, /sitemap-index.xml, up to 6 candidates |
| Request | One GET per candidate until one answers HTTP 200 with a body; no cookies or credentials of yours are sent |
| Rate limit | 40 validations per minute per visitor |
| Not included | Whether the URLs listed actually work, whether they are canonical, and whether they agree with what robots.txt allows — the broken link checker and the audit cover those |
| Not verified | gzip compression on the wire is decoded before it is measured, so the size shown is the uncompressed size the protocol limits |
When to use it
- Checking that a sitemap has not been silently broken by a theme update, where the XML now starts with a stray blank line before the `<?xml` declaration.
- Confirming that a sitemap index still points at children that exist after a plugin was changed or a language was added.
- Auditing `lastmod` before switching it on: a site that stamps every URL with the same timestamp is telling crawlers the values are meaningless.
- Confirming the namespace survived a hand-edited template, since a sitemap without it is tolerated by Google and rejected by most other tools.
- Finding out which of several candidate sitemaps a site is actually serving, when robots.txt is silent and the site returns something for all of them.
Is it private?
The file has to be read by this site's server: a browser will not let a page fetch and parse another origin's XML cross-origin, so a page-only tool could never report on anyone else's sitemap. When you press the button, your browser sends the address to this site's own endpoint, which requests the sitemap once — or the handful of conventional names when the address is a site — and returns the checks. The site you check sees requests from this server and never learns who asked. No cookies, credentials or browser details are forwarded, and the address and the file are not stored; the result is shown to you and dropped.
Frequently asked questions
For a small site that links to itself properly, no — crawlers find pages by following links, and a sitemap only helps. It earns its place in three cases: a large site where some pages are buried deep, a site with pages that have few or no incoming internal links, and a site that needs to tell crawlers about a `lastmod` date. If none of those apply, a broken sitemap is not costing you anything, which is worth knowing before you spend an afternoon on it.
Four things, in order of frequency: whitespace or a BOM before the `<?xml` declaration, because the declaration has to be the very first thing in the file; an unescaped `&` inside a URL, where a query string contains `&sort=` and should be written `&`; a template that emits a stray tag around the entries; and a character that is not valid in XML, such as a control character copied in from a database. The parser's message names the line, and the fix is almost always in the generator rather than the file.
A W3C datetime, which in practice means `2026-10-26` or the fuller `2026-10-26T04:13:06+00:00`. A date on its own is valid and is what most sites use. What is not valid: `26/10/2026`, `October 26, 2026`, a Unix timestamp, or an empty element. Crawlers drop a value they cannot parse, so the entry survives and the date does not — which is the failure mode people miss, because nothing looks broken.
They are optional, and Google has said for years that it ignores both. They are not harmful, but a value outside the allowed set is discarded and tells you the generator is guessing. If you are writing a sitemap by hand, leaving both out is the honest choice; if a plugin writes them, `changefreq: weekly` and `priority: 1.0` on every URL is a sign it is not really tracking anything.
Because the protocol only allows a sitemap to list URLs on the host it was served from. A file at `https://www.example.com/sitemap.xml` that lists `https://example.com/...` entries will have those entries ignored — which is a common outcome of a site that switched between the two hostnames and left the generator pointing at the old one. The fix is either to serve the sitemap from the host it lists, or to list the URLs as they actually are.
No, but it is the only reliable way for crawlers to find it. Without a `Sitemap:` line, a crawler tries the conventional names, and if yours is called something else it may never be read at all. A `Sitemap:` line costs one line in a file you already have, works for sitemaps at any path, and is the reason this validator reports whether the line is there.
Related tools
Written and maintained by Md. Nur Hossain Repon.