How the checker finds your sitemap
If you enter a sitemap URL, we start there. If you enter a domain, we read its robots.txt and use the Sitemap: lines, the way crawlers do. If there are none, we try /sitemap.xml and /sitemap_index.xml. A sitemap index is followed to its first 10 child sitemaps. We handle XML, gzipped XML and plain-text sitemaps (one URL per line).
What we check
- It’s really a sitemap. A 200 response with
<urlset>or<sitemapindex>, not an HTML error page. - Size limits. At most 50,000 URLs and 50 MB uncompressed per file. Bigger sites split into several files listed in an index.
- lastmod you can trust. Missing dates, invalid formats, dates in the future, and the tell-tale sign of a build script: every URL sharing one date.
- One version of each URL. A mix of
httpandhttps, or ofwwwand non-www, means the sitemap disagrees with your canonicals. - Other hosts. URLs on a different domain than the sitemap, which only work with cross-site verification.
What a healthy sitemap looks like
It lists only URLs you want indexed: final URLs that return 200, are self-canonical and aren’t blocked by robots.txt or noindex. No redirects, no parameters, no paginated duplicates. Each lastmod is the date the page’s content last changed, not the date you deployed. Large sites split by page type (products, posts, docs) so Search Console can report indexing per group.
A sitemap index with honest lastmod dates was part of the technical base we built for our own product, described in the Versely case study. Every result here includes a sample of URLs so you can spot-check them; run any that look old through the redirect checker.
Limits
We read up to 10 MB per file and 10 child sitemaps per check, with a time budget of about 25 seconds. We don’t fetch the listed pages themselves, so we can’t tell you which URLs redirect or return errors, only what the sitemap claims.