XML Sitemap Checker Guide: Validate Your Sitemap Before Search Engines Read It

An XML sitemap is a machine-readable list of a site's pages, offered to search engines as a guide to what exists and what has changed. It does not guarantee that pages will be indexed, but it helps search engines discover pages they might otherwise miss, especially new pages, deep pages, and pages reached through few internal links. A sitemap with errors, however, helps nobody: search engines may ignore the whole file, or trust it less, and the site owner, believing discovery is handled, may not notice that pages are missing from search results.

The XML Sitemap Checker tool validates pasted sitemap content: its XML structure, its URL entries, its dates, and its conformance to the sitemap format. It checks the content you paste; it does not fetch your live sitemap, crawl your site, or submit anything to a search engine. That scope makes it a pre-publication check: paste the sitemap you intend to publish, fix what the checker flags, and only then put it live, so search engines meet a clean file on their first visit rather than a broken one they must learn to distrust.

A sitemap entry has a small set of fields. The location is required: the full, absolute address of the page, including the protocol and domain. The last-modified date is optional but useful: the date the page last changed, in a standard format. The change frequency and priority fields are optional, and search engines treat them as hints at most, often ignoring them entirely. The structure is simple, which makes errors easy to spot once you know what to look for, and easy to introduce when the file is generated by hand or by a misconfigured plugin.

What to know before you start

First, the XML itself must be well-formed. Every opening tag needs its closing tag, special characters in addresses must be escaped, and the document must declare the sitemap namespace. A single unescaped ampersand in an address, a missing closing tag, or a malformed declaration breaks parsing, and a file that does not parse is not a sitemap with errors; it is not a sitemap at all. The checker reports the first parsing problem it meets, and fixing parsing problems is strictly sequential: fix the first, re-check, and repeat, because later errors may be consequences of the first rather than independent faults.

Second, each URL must be valid and consistent. Addresses must be absolute, not relative, and must use the site's canonical form: the same protocol, the same domain spelling, and the same trailing-slash convention as the pages themselves. A sitemap that lists addresses with a different protocol or domain from the live pages creates confusion about which addresses are canonical, and search engines may trust the sitemap less for it. Each listed address should also correspond to a real, indexable page: a sitemap full of redirected, missing, or blocked pages wastes the search engine's attention on addresses it cannot use, and dilutes the attention available for the pages that matter.

Third, dates and limits must be honest and respected. A last-modified date should reflect a real change to the page, not the date the sitemap was generated, because search engines learn to ignore dates that always claim freshness. A single sitemap is limited to 50,000 URLs and 50 megabytes uncompressed; larger sites must use a sitemap index file that points to multiple sitemaps, each within the limits. A sitemap that exceeds the limits may be truncated or ignored, silently dropping the pages beyond the limit, which are usually the newest or least linked pages, exactly the ones the sitemap exists to surface.

A worked example you can follow

Take a sample sitemap with 120 URLs. Suppose the checker reports 4 problems: 1 malformed entry, 2 URLs using the wrong protocol, and 1 URL that is a duplicate of another entry. The error rate is 4 divided by 120, or about 3 percent, but the impact is larger than the percentage suggests, because the malformed entry may break parsing for the entries after it, depending on where it sits. Fix the malformed entry first, re-check, and confirm the remaining problems are still 3, not a different number, because a parsing fix can reveal or remove downstream errors. Then fix the 2 protocol mismatches and remove the duplicate, bringing the problem count from 4 to 0 across two re-checks.

Now check the dates in the same sample. Suppose 100 of the 120 entries carry last-modified dates, and 90 of those claim the same recent date, the date the sitemap was generated. That pattern, 90 divided by 100, or 90 percent, sharing one date, suggests the dates were stamped by the generator rather than reflecting real changes. The honest fix is to carry real modification dates from the content system, or to omit the date field where the real date is unknown, because an omitted date is neutral while a false date teaches search engines to ignore your dates. After the fix, the dates should vary in a way that matches the site's real publishing history.

Consider the limits with a larger sample. A site with 60,000 pages cannot fit in one sitemap, because 60,000 exceeds the 50,000 limit by 10,000. The correct structure is a sitemap index pointing to at least 2 sitemaps: for example, one with 50,000 URLs and one with 10,000, which is 2 files for 60,000 pages. Each file must itself be valid, and the index must list each file's address. The checker should be run on the index and on each sitemap, because an index pointing at a broken sitemap is no better than no index at all.

Common mistakes to avoid

The first mistake is checking a draft sitemap but publishing a different one, for example by regenerating it afterwards without re-checking. Always check the exact file you publish. The second mistake is listing every address the site ever had, including redirected, removed, and blocked pages, instead of the pages that should be discovered. A sitemap is a recommendation, and recommending dead pages wastes trust. The third mistake is faking freshness by stamping every entry with today's date, which search engines notice and discount.

The fourth mistake is forgetting the sitemap after launch. Pages are added, removed, and changed, and a sitemap that is never regenerated becomes a stale map that misleads rather than guides. Regenerate on publication of new content, or on a schedule that matches the site's publishing pace, and re-check after regeneration, because a generator can break as surely as a hand-written file.

Checking the result before you finish

A passing check means the XML parses, every URL is absolute and canonical, the dates are honest, and the limits are respected. After the check passes, publish the file at the expected address, confirm it is served with the correct content type, confirm the site's robots file or search console points at it where applicable, and fetch the published file to confirm it matches the checked draft character for character. Then monitor search coverage over the following weeks: pages listed in the sitemap should appear in search results more reliably than unlisted ones, and any listed page that remains undiscovered deserves a separate investigation.

For companion checks, the XML Formatter & Validator tool validates XML structure generally, the On-Page SEO and Redirect Checker tool examines the pages the sitemap lists, and the Sitemap Checker Guide covers sitemap checking from another angle. A clean sitemap, published and maintained, is a quiet but real advantage for any site that wants its pages found.