1. Check a sitemap
2. Entries found
| loc | lastmod | Format | Live check |
|---|
No <url> or <sitemap> entries found — is this a sitemap XML document?
Findings
Prefer a CLI, or want this as a CI gate?
The CLI fetches the sitemap and every URL's live headers over real HTTP — no cross-origin restriction, because it isn't a browser, and it only reads response headers, never the page body:
node check.mjs https://example.com/sitemap.xml --json node check.mjs https://example.com/sitemap.xml --max-urls 200 node check.mjs https://example.com/sitemap.xml --uniform-threshold 0.8 --uniform-min-count 10
Get check.mjs, fetch-url.mjs, and engine.mjs from the repo — plain Node 18+, nothing to install. It only ever talks to the sitemap URL and the <loc> URLs that sitemap names — nothing goes through this site. Exit code 1 when a danger-severity finding is produced, the sitemap can't be fetched, or a URL's live headers can't be fetched (unverified is not the same as confirmed-clean).
What's checked
| Check | What it flags | Severity | Needs the CLI? |
|---|---|---|---|
| Invalid format | <lastmod> isn't a valid W3C Datetime, or names a calendar date/time that doesn't exist (e.g. Feb 30) | Danger | No |
| Future-dated | <lastmod> is after today — never legitimate | Danger | No |
| Duplicate / conflicting | The same <loc> listed twice — once harmlessly (same date) and once dangerously (different dates) | Notice / Danger | No |
| Uniform pattern | A large share of URLs all claim the exact same date — the freshness-faking anti-pattern | Notice | No |
| Server mismatch | The live page's own HTTP Last-Modified header doesn't confirm a change as recent as the sitemap claims | Notice | Yes |
More: why lastmod freshness matters, and the most common ways it breaks. See also: how this differs from XML-Sitemaps.com's free Sitemap Validator.
Common questions
What is sitemap "freshness faking"?
It's when a sitemap generator stamps every URL's <lastmod> with the current date on every build or deploy, regardless of whether the page actually changed — rather than only updating the date for pages with a real, significant content change. Google's own sitemap documentation says <lastmod> should reflect a genuine change, and that it may stop trusting a site's <lastmod> values if they consistently don't hold up, which defeats the entire point of having the field: helping a crawler prioritize what actually changed.
Why is a future-dated lastmod always wrong?
A page cannot have been last modified in the future — that's not a judgment call, it's a fact about time. A future <lastmod> is either a clock or timezone bug in whatever generated the sitemap (a server set to the wrong timezone can push a same-day timestamp past midnight UTC), or a placeholder value that was never replaced with the real date.
Why can't the browser check the live pages too?
A page's fetch() to a different origin either fails outright (in the default cors mode, if the target doesn't send an Access-Control-Allow-Origin header naming this tool's origin) or succeeds as an opaque response (in no-cors mode) whose headers — including Last-Modified — cannot be read by JavaScript at all, by design. Either way, this page cannot reliably read a cross-origin page's own response headers unless that page's server opts in, which ordinary third-party sites have no reason to do. The zero-dependency CLI has no such restriction because it isn't a browser tab.
Is this a full technical-SEO audit?
No. It checks specific, mechanically verifiable properties of a sitemap's <lastmod> values — format validity, plausibility, internal consistency, and (via the CLI) agreement with each page's own HTTP headers. It is not a crawl of your whole site, not a ranking guarantee, and not a determination that your sitemap is otherwise correct.