SEO Tools·5 min read

How to Validate an XML Sitemap Before Google Reads It

A sitemap is a promise to search engines: here are the pages worth crawling. When the file is broken, the promise is worthless, and Search Console often reports it with a vague line such as Couldn't fetch or Has errors. The XML Sitemap Validator reads the file the way a parser does, checks every entry against the sitemaps.org protocol and Google's rules, and then tests whether the listed URLs actually answer with 200. This guide walks through what it checks, a worked example, and the fixes for the errors people hit most.

Open the free XML Sitemap Validator All insights

Why a sitemap can look fine and still fail

Browsers forgive. Parsers do not.

Open a sitemap in a browser and it usually looks tidy: a tree of loc tags, dates and URLs. That view hides the problems that matter. Browsers repair small XML mistakes quietly, while a search engine's parser stops at the first one. A single ampersand written as & instead of & inside one URL is enough to make the whole file unreadable.

Other failures are not syntax errors at all. A sitemap can be perfectly valid XML and still list 404 pages, URLs that redirect, relative paths such as /about, or dates in a format no crawler understands. Search engines then spend crawl requests on addresses you never meant to promote, and your submitted and indexed counts drift apart.

What the validator checks, in order

Enter a sitemap URL, or just a domain, and press Validate. With a domain, the tool finds the sitemap through robots.txt and common paths first. It then fetches the file and runs its checks from the outside in, because a problem at the top makes everything below it meaningless.

The file is XML at all, not an HTML error page or a compressed .gz download.
The XML is well formed, with nothing before the declaration and every & escaped.
The root is urlset or sitemapindex, with the sitemaps.org namespace.
Every loc is a full http or https URL, under 2,048 characters, with no spaces, on the same host as the sitemap.
lastmod uses the W3C format and is not in the future; changefreq is one of the seven allowed words; priority sits between 0.0 and 1.0.
No URL is listed twice, the file stays under 50,000 URLs and 50 MB, and image and hreflang entries have the namespaces they need.

A worked example with four entries

Input: a pasted sitemap with four url entries.

Press Try sample and the validator loads a short file with typical mistakes. The first entry, the homepage with lastmod 2026-09-01 and priority 1.0, passes. The second has lastmod 01/09/2026 and changefreq sometimes, which produces two errors: the date is not a W3C date, and sometimes is not an allowed value. The third lists /contact, a relative path, so it is reported as not a full URL. The fourth repeats the homepage and gets a duplicate warning.

Output: three errors, one warning, and a red summary telling you search engines may skip the broken entries. Each issue shows the loc it belongs to, so you can find the line in your CMS or plugin settings instead of scanning the whole file. Fix the date to 2026-09-01, drop or correct the changefreq, write the full contact URL and remove the duplicate, then validate again until the summary turns green.

Sitemap indexes and child files

Larger sites split their URLs across several files and list those files in a sitemap index. WordPress plugins do this by default, with names such as post-sitemap.xml and page-sitemap.xml. A clean index can still point at broken children, so checking the index alone proves little.

When the validator finds a sitemapindex, it checks the index itself and then fetches and validates up to 25 of the child sitemaps it lists. Each child gets a row with its URL count and error count, and every issue in the list says which file it came from. A child that returns 404 or an error page shows up as Failed, which is a common leftover after a plugin change.

Checking that listed URLs return 200

Valid XML is half the job. The other half is whether each listed URL deserves to be there. Google's guidance is to list canonical URLs you want in search, and a URL that redirects, returns 404 or throws a server error does not qualify.

After validation, press the Check URLs button. The tool sends a HEAD request to up to 500 listed URLs and lists every one that does not return 200 directly, with its status or the address a redirect ends on. Redirects are the usual find after a migration or a switch from http to https: the sitemap still lists old addresses that now hop to new ones. Replace each with its final URL. Some servers answer 403 or 405 to automated HEAD requests while working fine in a browser, so open those by hand before you remove anything.

Common mistakes when fixing a sitemap

Most sitemap problems come from generators and plugins rather than hand edits, so fixes belong at the source. Editing the XML directly only lasts until the plugin rebuilds it.

Setting every lastmod to today's date. Search engines learn to ignore dates that change on every build; the validator warns when all URLs share one date.
Listing noindex or canonicalised pages. They send mixed signals; keep only the version you want indexed.
Forgetting the https switch. The sitemap and its URLs should use the same protocol and host as the live site.
Submitting the index and a child as separate sitemaps, which doubles the reporting and hides which file has the problem.
Leaving a sitemap URL in robots.txt after the file moved, so crawlers keep requesting a 404.

Where the validator fits with the other sitemap tools

Use the XML Sitemap Generator to build or rebuild a file; it can import an existing sitemap, scan the pages, drop noindex and canonicalised URLs and split large lists into an index. Run the result through the validator before you upload it. Add a Sitemap line with the Robots.txt Generator, and use the Robots.txt Tester to confirm the listed URLs are not blocked, because a URL that is both in the sitemap and disallowed sends Google two opposite messages. Then submit the sitemap in Search Console and compare the submitted and indexed counts a week later.