Sitemap Validator

How it works

A browser XML parser checks syntax without attaching user nodes to the document. A DOCTYPE or ENTITY declaration is rejected before parsing. Custom entity declarations, external DTDs and XML stylesheet retrieval are not part of the operation. The accepted root is urlset or sitemapindex in the exact http://www.sitemaps.org/schemas/sitemap/0.9 namespace. A prefix is allowed when it resolves to that namespace; an unnamespaced lookalike is not the same protocol document.

A urlset contains url entries with exactly one loc. Its optional core fields are lastmod, changefreq and priority. A sitemapindex contains sitemap entries with loc and optional lastmod; it does not use priority or changefreq. Repeated core fields, unknown fields in the sitemap namespace, nested elements inside a text-only core field and unexpected text at entry/root level are reported as errors. The inspector does not fix, drop or rewrite them. Comments and normal XML character escaping are handled by the parser.

Loc must contain a complete HTTP or HTTPS address below 2,048 characters, without raw spaces, control characters, backslashes, invalid percent escapes or embedded credentials. Outer whitespace is not silently trimmed. The URL parser normalizes hostnames and default ports for duplicate review; application-specific equivalence is not inferred. Distinct query ordering can still represent the same application page, and identical text does not establish which URL is canonical. A fragment produces a review warning rather than pretending to be a live crawl finding.

Lastmod accepts a real YYYY-MM-DD calendar date or a full date-time with seconds and timezone. Calendar arithmetic checks leap years instead of allowing JavaScript to roll February 30 into March. Changefreq must use a protocol value such as weekly or never. Priority is a decimal in the range 0 to 1. Google ignores changefreq and priority, so their presence is not a way to increase queue priority, rankings or crawl rate. Accurate lastmod values should represent meaningful page changes; syntax validation cannot verify when your page really changed.

An optional sitemap-file URL supplies context only and is never opened. It lets the report warn about listed addresses on another origin or outside the file's directory scope. Authorized cross-site submission and verified ownership can change what a search engine accepts. This local tool does not have that account evidence, so it raises a review question rather than declaring every different-origin entry universally invalid. Without context it can still flag that multiple origins appear in the supplied file.

Image, video, news and hreflang extension elements are recognized as outside the core sitemap namespace and counted, but their semantics and required fields are not validated. No XSD or remote schema is fetched. An extension can therefore be wrong even when the report has no core-protocol errors. The report explicitly retains that limitation instead of presenting a complete standards-conformance certificate. Sitemap indexes are inspected as supplied; their child sitemap URLs are not recursively downloaded.

The local limits are 2 MiB of UTF-8 input, 10,000 entries, 100,000 XML nodes and depth 16. Those bounds are intentionally smaller than the protocol's 50 MiB uncompressed size and 50,000-entry limits. A larger valid sitemap should be split for this inspector; exceeding a tool limit does not mean the original file violates the protocol. The first 200 findings appear in the interface and JSON, while error/warning totals count all findings. The JSON also contains accepted supplied URLs and lastmod text, so review private paths or query values before sharing it.

Source remains in browser memory. The widget does not fetch, submit or save the sitemap to a server. Editing the optional context or XML clears the old report, and a late file read cannot replace a newer edit. Clear removes current input but not files you already downloaded. After correcting a source file, verify actual production HTTP status, robots, canonical URLs and ownership separately, then submit only the changed sitemap through the intended search-engine account.

Common use cases

• Find the invalid date or missing loc behind a rejected sitemap file
• Review duplicate URLs without crawling private staging addresses
• Distinguish a sitemap index from an ordinary URL sitemap
• Prepare a concise JSON finding report for whoever maintains the source generator

Frequently asked questions

Standards and limitations

• Sitemaps.org: core XML protocol, URL requirements and limits
• Google Search Central: build and submit a sitemap
• Sitemaps.org: XML schema date and field definitions