← Sitemap lastmod Freshness Check

Why sitemap lastmod freshness matters

Google's Search Central documentation on building a sitemap is direct about this: the <lastmod> field should name the date a page was last significantly modified, and the field is only useful to a crawler if it can be trusted. Google's own guidance says that when a site's lastmod values consistently don't hold up, it may choose to disregard the field for that site going forward — not just for the one wrong entry, but as a general policy toward a source that has proven unreliable.

That is a quiet failure, the same shape as a broken hreflang set: the sitemap still validates, the XML is still well-formed, and nothing in an ordinary QA pass shows anything wrong. The only symptom is that a crawler stops prioritizing your recently-changed pages the way the field was supposed to let it — because it decided the field was noise.

The pattern that causes this: freshness faking

Almost never intentional. The most common cause is a sitemap generator or static-site build step that stamps every URL with the current build timestamp by default, rather than the page's actual last-edited date — so a page nobody has touched in two years shows a <lastmod> of this morning simply because the site was redeployed. Run that build often enough and every single URL in the sitemap carries the same, constantly-advancing date, which is exactly the pattern that erodes trust in the field: a value that is always "today" carries no information about what actually changed.

<!-- every one of 400 URLs, regenerated on every deploy -->
<url><loc>https://example.com/</loc><lastmod>2026-06-15</lastmod></url>
<url><loc>https://example.com/about</loc><lastmod>2026-06-15</lastmod></url>
<url><loc>https://example.com/blog/post-from-2019</loc><lastmod>2026-06-15</lastmod></url>
<!-- ...397 more, all dated today, regardless of when the page last changed -->

A second common cause is a CMS whose "last modified" timestamp updates on any save, including one that changed nothing meaningful — a draft re-save, a metadata-only edit, a cache-busting republish. The date is technically accurate about when a database row was touched, but not about when a reader would notice the page changed, which is the distinction Google's documentation is asking site owners to make.

The other checks this tool runs

• Invalid format. The sitemap protocol requires a full W3C Datetime — a bare date or a full date-time with an explicit timezone. A bare time with no timezone, a slash-separated date, or a two-digit year all fail silently in some consumers rather than erroring loudly.
• Future-dated. A page cannot have been modified in the future — always a clock/timezone bug or an unreplaced placeholder.
• Duplicate or conflicting. The same URL listed twice with two different dates is a real conflict nothing consuming the sitemap can resolve on your behalf.
• Server mismatch (CLI only). Whether the live page's own HTTP Last-Modified response header actually confirms a change as recent as the sitemap claims — reported as a signal to check, not proof, since some servers send render time rather than content-edit time, or send no such header at all.

Common questions

Where does Google say lastmod has to be accurate?

Google's Search Central documentation on building and submitting a sitemap describes <lastmod> as the date the page was last significantly modified, and says the field is only useful if it is accurate — and that a crawler which finds a site's lastmod values are not reliable may choose to disregard the field for that site going forward, rather than continuing to trust a signal that has proven wrong.

What actually happens if lastmod stops being trusted?

The entire point of lastmod is to help a crawler prioritize what to recrawl — a page that changed yesterday deserves attention sooner than one that hasn't changed in a year. If a crawler decides a site's lastmod values are not reliable, it loses that prioritization signal for every URL in the sitemap, not just the ones with a wrong date — a site with mostly-accurate dates and a handful of faked ones can lose the benefit for all of them, because the crawler has no cheap way to tell which entries to still trust.

How does freshness faking happen in practice?

Almost never on purpose. The most common cause is a sitemap generator or static-site build step that stamps every URL with the current build timestamp by default, rather than the page's actual last-edited date — so a page nobody has touched in two years shows a lastmod of this morning simply because the site was redeployed. A second common cause is a CMS whose "last modified" field updates on any save, including a save that changed nothing (a draft re-save, a metadata-only edit, a cache-busting republish).

Is a uniform lastmod always wrong?

No — a genuine one-time event, like a full site migration, a CMS re-platform, or a bulk content re-license, can legitimately touch every page on the same day. That is why this tool reports a uniform pattern as a notice-severity statistical signal rather than a certain violation: it names the pattern and the share of URLs involved, and leaves the judgment of whether it reflects a real event to the person who knows their own site's history.

Check your own sitemap: Sitemap lastmod Freshness Check. See also: how this differs from XML-Sitemaps.com's Sitemap Validator.