Your sitemap says every page
changed today. Is that true?
Paste a sitemap URL. This reads every <lastmod> date in it — including inside a sitemap index and gzipped children — and tells you whether Google is likely to trust it. Free, no signup, no stored data.
Sitemaps are a trust signal.
A fake one spends that trust.
The <lastmod> tag in a sitemap exists to tell Google one thing: when this page actually changed, so the crawler knows whether it's worth a fresh look. Most site generators get this wrong in one of two ways.
The common one: a build script calls new Date()and writes it into every URL on every deploy. Redeploy on a Tuesday afternoon because you fixed a typo in the footer, and the sitemap now claims every page on the site changed at that exact moment — the homepage, the pricing page, a blog post from two years ago, all of it. Google sees this pattern repeat across enough sites that it starts discounting <lastmod> entirely. The cost isn't abstract: it's the page that did genuinely change losing the faster recrawl priority it earned.
The quieter one: a single hardcoded date, set once at launch and never touched again. Not actively harmful, but useless — it carries no information about which pages are actually stale.
This tool reads the real distribution of dates in a live sitemap and tells you which pattern you're looking at.
One of four outcomes,
every time.
Same thresholds this studio uses internally to gate its own client sites before a deploy ships: 50% or more dated today is the leak; 90% or more sharing one date is the frozen constant; zero <lastmod> tags is missing; anything else with a real spread is healthy.
| Verdict code | Level | What it means |
|---|---|---|
lastmod-now-leak | Error | Half or more of the <lastmod> dates in the sitemap equal today. That's a build-time timestamp, not a real edit history — it tells Google every page changed on every deploy, which trains Google to stop trusting the field. |
lastmod-frozen-constant | Warning | Ninety percent or more of the dates are the exact same single value. Safe, but blind — Google can't tell your oldest page from your newest. |
lastmod-missing | Warning | No <lastmod> tag anywhere in the sitemap. Zero recrawl signal. |
lastmod-healthy | Info | Dates vary per page in a way that looks like a real edit history. This is the shape Google trusts. |
Before you paste a URL in.
Why does a fake <lastmod> date actually hurt my SEO?
Google uses <lastmod> as one signal for deciding how often to recrawl a page. If every URL in your sitemap claims to have changed today, on every single deploy, Google eventually learns the field is noise and stops factoring it into recrawl priority. The pages that DID genuinely change lose the faster recrawl they'd otherwise earn — you've spent your credibility on pages that didn't change.
How do I generate a truthful <lastmod> instead?
Derive it from the real last-change date of whatever composes the page — a blog post's frontmatter date, or the git commit date of a page's source file for anything static or programmatic. Write that to a manifest at build time rather than calling new Date() on every deploy. On Vercel specifically, watch out for shallow clones: a build-time git log on a depth-1 checkout returns the deploy commit's date for every file, which is the same now()-leak in disguise. Generate the manifest where full git history exists (local dev or CI with a full checkout) and commit it, so the shallow production build reads the honest, already-computed dates instead of trying to recompute them.
Does this tool store or share the sitemap I check?
No account, no email, no stored copy of your data. The check runs, the report renders in your browser, and nothing about your sitemap is logged beyond a short server-side cache (10 minutes) used only to avoid re-fetching the same URL back-to-back.
What sitemap formats does it handle?
Plain sitemap.xml files, sitemap index files (it follows every child <sitemap> automatically), and gzipped .xml.gz sitemaps. It caps out at 50,000 URLs and 50 child sitemaps per check — past that it reports on what it fetched and flags the run as truncated rather than guessing.
Technical SEO that this tool feeds into.
I build the honest version
of this into every site I ship.
Every sitemap I generate for a client derives <lastmod> from a git-committed manifest, not a build-time timestamp — the same pattern that produces a “healthy” verdict above. If a sitemap fix on your site turns into a bigger technical SEO conversation, send the details.