Sitemap gives an older change than the page itself

For every crawled page that is in the sitemap with a valid <lastmod>, we compare two claims the same site makes about the same page: <lastmod> from the sitemap and dateModified from the structured data (JSON-LD) on the page. A finding is raised when the page gives a change more than 2 days later (tolerance_days: 2 in config/seo.json). The report gives the number of such pages out of those compared and one example with both values.

Which dateModified we take: only from nodes describing this page, namely …Page types (WebPage, FAQPage, CollectionPage…), …Article types (Article, NewsArticle, TechArticle…), BlogPosting, Recipe, HowTo, Report, CreativeWork; and only when their url or @id does not point to another address. BreadcrumbList, WebSite, Organization, comments and reviews are not counted. When a page carries several values differing by more than the tolerance (typically a list of articles), we skip it as ambiguous.

The 2-day tolerance covers time zones, rounding to a day (2026-09-12 versus 2026-09-11T22:00:00Z is the same instant) and sitemap caching in content management systems.

A bulk change is not reported. When at least 3 contradictions have dateModified within 7 days of each other (bulk_change_min_pages, bulk_change_window_days), we treat it as a technical re-save (a migration, a template change) and leave those pages out of the finding. When measured on 15 Sep 2026, this removed 13 of 19 contradictions on techcrunch.com: videos from 2020–2023 had dateModified from 7–10 May 2024.

What the check does not do:

• It cannot tell which of the two dates reflects reality. dateModified also moves with an insignificant change; then <lastmod> is fine. The finding text says so and the recommendation is conditional.
• It does not report the opposite direction: the sitemap newer than the page. Google counts a change of links as significant, which an article's dateModified may not capture.
• It does not compare the Last-Modified header. The crawler does not store it, and on static hosting it carries the file's deployment time rather than a content change; it would produce false findings on an honest sitemap.
• It does not compare a visible <time datetime> or the article:modified_time meta tag; those are often the publication date or a comment date.
• It does not compare page content between two audits. We considered it as the strongest evidence, but it cannot be done without a high risk of false findings; the reasoning is in docs/moduly-auditu.md.

The finding is site-level and informational, with no effect on the score (reasoning under SEO-15).

For visibility in AI answers we have no documented effect.

In its sitemap documentation Google writes that it uses <lastmod> if it is “consistently and verifiably (for example by comparing to the last modification of the page) accurate”. How exactly it determines the “last modification of the page” it does not say, and we do not know whether it reads dateModified for that. So the finding does not claim Google sees the contradiction; it only claims that if the content really changed after the <lastmod> date, Google may ignore it.

The contradiction itself, on the other hand, is a fact: two values the site itself publishes about the same page disagree. And what always holds for structured data holds here too: it does not replace the page content, it only describes it.

First find out why the dates differ, and only then change anything; aligning them blindly can break <lastmod>.

• The content substantively changed after the <lastmod> date → fix the sitemap generator so it takes the date of the last significant update (main content, structured data, links). Typically it takes the publication date instead of the modification date.
• The sitemap comes from a cache → make sure it is refreshed after a page is edited.
• dateModified was moved only by a technical save (a migration, a bulk edit) → leave the sitemap alone. Consider whether dateModified should capture such changes at all.