A sitemap update date does not add up

Why it matters

Google uses <lastmod> only when it is consistently and verifiably accurate, and it should reflect the last significant update to the page's main content, structured data or links; a changed copyright date does not count.

What to do

Look at the finding: it names the reason and shows the dates and, for a comparison, the previous audit it was compared with.
Check how your sitemap generator fills lastmod; some plugins stamp every entry with the time the sitemap was regenerated.
Set it to use each page's real modification date, and leave lastmod out where no reliable date exists.

When to leave it as it is: if a date moved because you changed something the check cannot see, such as structured data or links, the date may be right; the check compares only the page's visible text.

What we read

We read valid <lastmod> values from your XML sitemaps. A date without a time is in the future when it is later than the audit's date in UTC; a date and time, when it is more than five minutes later than the moment the audit was evaluated. This needs no previous audit.

For listed pages reached as HTML, directly or through a redirect, we compare the previous eligible audit's lastmod value and complete visible-text fingerprint, including the menu and footer. Text comparisons require the same desktop or smartphone collection profile. We use server-rendered text, including pages whose only rendering limitation is lazy-loaded images; script-built shells, incomplete text and multiple dates cannot support the comparison.

Example & evidence

Illustrative example — one page in two audits, not a live audit.

In the previous audit, https://bakery.example/sitemap.xml listed /about/ with this date, and the page's text had a fingerprint we call H here:

<url><loc>https://bakery.example/about/</loc><lastmod>2026-09-10T02:00:00+00:00</lastmod></url>

In the next audit, the sitemap plugin had stamped the time it rebuilt the file, while the page's text still had fingerprint H:

<url><loc>https://bakery.example/about/</loc><lastmod>2026-09-24T02:00:00+00:00</lastmod></url>

The date moved but the text did not, so the page is reported with both dates and both fingerprints.

Correct the generator, then run a new audit. While the URL remains listed with a valid lastmod, a finding about a date moving without a text change stays open until a comparable, complete text reading proves a change; merely keeping the new date unchanged does not close it. A complete sitemap check and a sufficient re-check of the same URL can also confirm that the URL or its valid lastmod has left this check's scope.

Confirm & check again

Check for yourself: compare your sitemap's lastmod for a page with the date you last really edited it; regenerate the sitemap without editing anything and see whether the dates move.

Check again: Full audit — Run a new site audit. While the URL remains listed with a valid lastmod, it needs a sufficient re-check: a future date must no longer be in the future; an unchanged date after a text change must move past the finding's recorded date; a date change without a text change needs a changed, complete text fingerprint under the profile that established the finding. A finding can also close when a complete sitemap check confirms that the URL or its valid lastmod has been removed and a sufficient re-check of the same URL confirms that it has left this check's scope. Absence alone does not prove a fix. Missing or incomplete evidence keeps the unresolved finding open. Dismissing a finding does not remove this technical obligation.

Limits & sources

Two audits are compared, not what happened between them. Changes to structured data, links or meta tags do not change the text fingerprint, so a date that moved for them is reported, and a site-wide text change, such as a new footer year, changes every page's fingerprint.

Changing the audit's collection profile does not count as a text change. An open finding about a date moving without a text change keeps the profile of its original text fingerprint. While the URL remains listed with a valid lastmod, a later smartphone audit cannot close a desktop-anchored text comparison without comparable evidence, even if it reports and later clears a separate future-date warning.

Confidence: Medium because a changed or unchanged fingerprint is a sign, not proof, of a meaningful update.

Sources

Google, Build and submit a sitemap — says Google uses lastmod only when it is consistently and verifiably accurate, and that it should reflect the last significant update. Checked 25 September 2026.

Editorial review: 2 November 2026

A sitemap date is not a valid date — the date is not written in an accepted form; this check reads only valid dates.
A sitemap cannot be fetched or read — the sitemap failed, so no dates could be read.