Document-Level Diagnosis
Separate HTTP, content-type, XML parsing, root-element, and namespace failures instead of treating every bad response as the same error.
Sitemap Checker
TL;DR: XML Sitemap Validator checks validate sitemap format, url entries, and namespace compliance. so you can confirm the current issue, understand when it matters, and move directly into the next fix without leaving the browser.
Check sitemap integrity and crawlability signals.
Updated
Loading tool interface...
HTTP status and response content-type inspection XML well-formedness and root-element validation Sitemaps.org namespace detection URL-set and sitemap-index document support Missing, invalid, and duplicate location diagnostics W3C lastmod date checks and parsed entry metadata Child traversal up to four levels and 40 documents
What does XML Sitemap Validator do?
The Sitemap Checker fetches an XML sitemap from its live URL, verifies the HTTP response, parses the XML, and identifies whether the root document is a URL set or sitemap index. The report shows document diagnostics, extracted entries, duplicate counts, namespace status, and child sitemap results. It checks the files you submit; it does not claim that every listed page is indexable.
Start with a readable XML document: A standard URL sitemap uses `<urlset>` as its root and places each absolute URL in `<url><loc>...</loc></url>`. A sitemap index uses `<sitemapindex>` and lists child files in `<sitemap><loc>...</loc></sitemap>`. A missing closing tag, an unescaped `&`, or HTML returned by an error page can make the XML unreadable. The checker reports well-formedness separately from entry-level warnings.
Keep the sitemap namespace: Standard files declare `xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"` on the root element. A CMS template can produce XML that looks correct in a browser while omitting that namespace. PageChecks surfaces namespace state so you can fix the root declaration instead of editing each URL entry.
Use one preferred URL per page: Each `<loc>` should be an absolute HTTP or HTTPS URL that represents the version you want indexed. Do not list both HTTP and HTTPS, `www` and non-`www`, or parameter and clean variants for the same page. Remove entries that redirect, return 404, carry `noindex`, or canonicalize elsewhere. The checker validates entry structure and duplicates, but a separate crawl or indexability check is required to fetch every listed page.
Respect the protocol limits: One sitemap can contain no more than 50,000 URLs and must stay at or below 50 MB uncompressed. Those are sitemap protocol limits, not PageChecks processing limits. Split a larger inventory into child files such as `sitemap-products-1.xml` and `sitemap-products-2.xml`, then list them in a sitemap index. A child sitemap has the same 50,000 URL and 50 MB limits.
Know the interactive checker limits: PageChecks reads up to 2 MB per fetched sitemap document, follows child references to a depth of four, and processes up to 40 sitemap documents in one run. These bounds keep a browser-triggered validation request finite. A production file can satisfy the 50 MB protocol limit and still exceed this checker's 2 MB fetch cap. Split it into smaller child files when you need each part validated here.
Make lastmod truthful: `<lastmod>` accepts a W3C date such as `2026-08-27` or a full timestamp such as `2026-08-27T14:30:00+09:30`. Change it when the primary page content changes, not when a navigation fragment, analytics script, or deployment timestamp changes. Search engines may reduce trust in a lastmod feed that rewrites every URL every day without substantive edits.
Treat changefreq and priority as optional: `<changefreq>` and `<priority>` can appear in the protocol, and the checker exposes parsed metadata, but Google says it ignores these values. Do not let a generated `daily` or `1.0` value distract from the signals that can be verified: correct URLs, accurate lastmod dates, clean status responses, and internal links.
Use index files for operational ownership: Segment child sitemaps by stable sections such as products, articles, locations, or locales. A failing product export then appears in one child file instead of corrupting a single site-wide document. The checker follows index references and reports child results, subject to the 40-document and four-level bounds. Keep the index itself limited to sitemap locations, not page URLs.
Check the response, not just the filename: A URL ending in `.xml` can return a 404 HTML page, a login screen, or the wrong content type. PageChecks includes the sitemap HTTP status and response content type with the parse result. Fix server routing or access controls when the endpoint does not return the intended XML document.
Audit after migrations and CMS changes: A hostname change can leave old-domain locations in a newly generated sitemap. A route change can preserve deleted URLs or duplicate slash variants. Compare the extracted locations with the preferred production pattern, then run indexability and canonical checks on a sample from each template. Submit the corrected sitemap or sitemap index in the relevant search engine console after it is live.
When should you use XML Sitemap Validator?
XML Sitemap Validator is most useful when you need a direct answer on a live URL or draft before you change templates, ship content, or rerun a wider audit.
How to Use This Tool
- 1 Enter the live sitemap or sitemap-index URL, including the final HTTPS host and full path.
- 2 Confirm the endpoint returns a successful HTTP status, an XML response, and a well-formed `<urlset>` or `<sitemapindex>` root.
- 3 Review namespace diagnostics, entry counts, duplicate counts, and invalid or missing `<loc>` values.
- 4 Inspect `<lastmod>` values for valid W3C dates that reflect real page changes instead of deployment time.
- 5 For an index, review each child result and check whether the four-level or 40-document processing bound was reached.
- 6 Remove non-preferred URLs, fix the generator template, publish the file, and rerun the same live endpoint.
What should you do next?
After validating your sitemap, check robots.txt references and audit canonical alignment across listed URLs. Then move to the related checks below to confirm the fix on the live canonical page.
What You Get
Entry Integrity
Review location values, duplicates, date fields, and document counts before submitting a generated sitemap to a search engine.
Index Traversal
Follow child sitemap references through four levels and inspect up to 40 documents in one bounded validation run.
Transparent Limits
Distinguish the 50,000 URL and 50 MB protocol ceilings from the checker's 2 MB per-document fetch limit.
No False Indexability Claim
Use this report for sitemap structure, then fetch listed pages separately to verify status, robots, and canonical eligibility.
Frequently Asked Questions
Answers about XML Sitemap Validator
Submit the sitemap URL to the Sitemap Checker and review the document-level diagnostics. It checks the HTTP response, XML well-formedness, root type, namespace, URL entries, duplicates, and supported date fields.
Malformed XML, missing `<loc>` values, invalid URLs, duplicate entries, and a missing sitemap namespace are common failures. These errors can make a file unreadable or noisy, but a valid sitemap still does not guarantee that every listed URL is indexable.
Yes, the checker accepts both `<urlset>` files and `<sitemapindex>` files. For an index, it follows child sitemap references up to four levels and processes no more than 40 sitemap documents in one run.
Change `<lastmod>` only when the page's primary content changes. Use a W3C date such as `2026-08-27` or a full timestamp with a timezone; rewriting every date on every deploy makes the signal untrustworthy.
One sitemap can contain at most 50,000 URLs and be no larger than 50 MB uncompressed under the sitemap protocol. Split larger sets into child files and list those files in a sitemap index.
PageChecks limits each fetched sitemap document to 2 MB for a bounded interactive check. The protocol allows 50 MB uncompressed, so validate an oversized production set by splitting it into smaller child sitemaps and checking those files separately.
No, it validates the sitemap files and their entries rather than fetching every listed page. Use an indexability checker or crawl audit to verify each URL's status code, canonical, robots directives, and final index eligibility.
No, include preferred URLs that return 200 and are eligible for indexing. Remove redirects, 404s, blocked URLs, and pages with `noindex`; those entries send search engines to URLs you do not want selected.