Sitemap Validator

Give it a sitemap address. The service fetches the file and the page grades what came back, entry by entry.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

Sitemap Validator takes one address and does the network part on the processing service: it opens the URL you gave, follows as many as five redirects with every hop resolved and screened before a socket is opened, reads at most 5 MB of whatever answers, and hands the XML back to this page to be graded. Because the request originates on that machine and not in your browser, the address you type travels there over an encrypted connection and is written into the job row beside the fetched report; the two are dropped together when the job reaches its expiry a few hours later.

The grading is a real schema check rather than a head count. The root has to be <urlset> or <sitemapindex> and has to declare the sitemaps.org 0.9 namespace — on xmlns, or on xmlns:prefix when the document is written with a prefix — a missing XML declaration is noted, and a missing closing tag is reported as a truncated file. Each entry is then read on its own: a <loc> that is absent, relative, longer than 2,048 characters, carrying a space or an unescaped ampersand, or repeated from earlier; a <lastmod> that is not a W3C datetime or is dated in the future; a <changefreq> outside always, hourly, daily, weekly, monthly, yearly and never; a <priority> outside 0.0 to 1.0. Past 50,000 entries it errors, and it warns when the URLs span several hostnames, when http:// and https:// are mixed, and when every entry carries one identical priority.

One run can produce either of two views. If the address answers 2xx with a document whose root really is a urlset or an index, you get the graded report — type, entry count, size, then the errors and warnings written out — with a summary line above it repeating the count and the two tallies. Ticking List every URL found adds a table of addresses with their lastmod, changefreq and priority, and that table stops at the first 500 rows however many entries were parsed, so the checkbox promises more than it delivers on a large file. When the fetch lands somewhere else, the grader steps aside and the raw sitemap.json report is shown in its place. That JSON is also the download button under either view, and it is the only place the HTTP status and the address that finally answered are printed.

Three things it will not do. The input box is labelled as though pasted markup were accepted and there is a Load sample button that drops a specimen sitemap into it, but that path is not wired up: every run posts the box's contents as an address to fetch, so pasted XML comes back as an invalid URL. Nothing listed inside the sitemap is ever requested, so a file of five thousand dead pages still grades as five thousand clean entries. And a hostname that resolves to a loopback, link-local, private or carrier-grade NAT address is refused before any connection, with the same test repeated on each redirect target, so a sitemap that exists only on a laptop or behind a VPN cannot be reached from here.

How to use it

  1. Enter the sitemap's full URL. Scheme included, such as https://example.com/sitemap.xml. It has to be published where a crawler could reach it, because the request is made from the processing service rather than from your browser.
  2. Decide whether you want the entry table. Left off, List every URL found gives you the verdict and the findings alone. Turned on, it adds a row per entry with its lastmod, changefreq and priority — capped at the first 500 rows.
  3. Read the errors, then the warnings. Errors are what a parser will hold against the file: a wrong namespace, a relative <loc>, a lastmod in the wrong format, a changefreq outside the vocabulary. Warnings are advisory — duplicates, fragments, mixed schemes, a flat priority column.
  4. Open sitemap.json for the fetch itself. The download button carries the service's raw report, including the response code and the address that answered after any redirects. Neither of those figures appears in the graded view above it.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

A sitemap that quietly stopped being served

When the address returns 404 or 403, or a redirect lands on the home page, there is nothing to grade and the JSON report is shown instead — which is where the status you came for is written.

Auditing what a generator emitted

Templated sitemaps drift into relative <loc> values, unescaped ampersands inside query strings and dates written as DD/MM/YYYY. Every one of those is reported against the entry number that carries it.

Working through an index file

Run the index to see how many children it declares, then run each child address in turn. A changefreq or priority written inside an index is flagged, since the format does not permit them there.

Confirming a migration did not split the host

A rebuild that strands part of the site on the old hostname, or leaves some URLs on http:// while the rest moved to https://, is warned about rather than left for a crawler to discover.

Catching a file that outgrew the format

Anything past 5 MB is not read, and the missing closing tag that leaves behind is reported as truncation — a blunt but reliable sign that the sitemap needs splitting into an index.

Questions

Can I paste sitemap XML instead of a URL?
Not today, despite the input label and the Load sample button implying otherwise. Whatever sits in the box is posted to the service as an address, so pasted markup is rejected as an invalid URL. The file has to be published somewhere reachable first.
Does it check lastmod, changefreq and priority?
All three. A lastmod must be a W3C datetime, and one dated in the future is warned about; changefreq has to be one of the seven allowed words; priority has to sit between 0.0 and 1.0. It also warns when every entry shares a single priority value, which tells a crawler nothing at all.
Does it request the URLs listed inside the file?
No. Exactly one request is made, for the sitemap document itself. Whether each address it lists actually responds is a different job — Redirect Checker and HTTP Header Inspector handle that one URL at a time.
Where do I read the HTTP status?
In the downloadable sitemap.json, or on screen whenever the fetch did not land on a sitemap at all. The graded report is about the document's structure, so it prints the type, the count and the size but never the response code.
Why did it come back with no entries?
Almost always because the fetch never reached a sitemap: an error page, a redirect to somewhere unrelated, or a compressed .xml.gz whose bytes do not decode into XML. In each case the grading is skipped and the JSON shown in its place names the status and the final address.
Is a namespace prefix a problem?
Not for the grading. A <sm:urlset> root with xmlns:sm set to the 0.9 namespace passes, and its <sm:loc> entries are counted normally. The count field inside sitemap.json is worked out separately with a plain <loc> match, so that one number reads zero for a prefixed document even while the report above it is right.
How large a sitemap can it handle?
The response is cut off at 5 MB and the job at 30 seconds. A file cut short loses its closing tag, which surfaces as a truncation error rather than passing quietly, but the entries beyond the cut are never seen. Split anything that size into an index with smaller children.
Can it reach a staging or intranet sitemap?
Only when the hostname answers with a public address. The name is resolved first and refused if any address it returns is loopback, link-local, private or carrier-grade NAT, and each redirect target is put through the same test, so an internal-only sitemap has to be validated from inside that network.

Related tools