An updated date is a claim that the post now says something new

A "last updated" date is not metadata about a database row. It is a claim made to the reader and to search engines that the page now says something it did not say before. An engine that revises old posts has to be able to back that claim with the revision itself, visibly, or the date is an assertion with no evidence behind it. The cheapest way to make a blog look maintained is to move its dates, and the cheapest way for an automated blog to do that is by accident.

Google defines the date by what changed, not when you saved

Google's own documentation is unusually consistent on this. Its sitemap guidance says lastmod should reflect "the last significant update to the page", names the main content, the structured data and the links as significant, and names a changed copyright year as not. It adds that Google uses the value only if it is consistently and verifiably accurate, which means a site that stamps every save teaches Google to ignore its dates altogether.

The byline-dates page says Google looks at several factors to estimate when a page was published or significantly updated, and asks that the visible date and the structured date match. And the people-first content guidance, the same document behind our argument that Google does not penalize AI content, puts the warning as a plain question: are you changing the date of pages to make them seem fresh when the content has not substantially changed?

None of this says a modified date is a ranking trick that works. It says the date is a statement about the content, and that a false one costs you the credibility of the true ones.

An engine turns every save into a revision

A human editor who changes a post usually decides whether to change its date. A content system rarely asks. Most CMSs keep one updatedAt timestamp per document and move it on any write: a new hero image, a fixed typo, a corrected alt attribute, a translation saved into another locale. Templates then feed that timestamp straight into dateModified and the sitemap, because it is the field that exists.

That is harmless on a blog edited twice a year. On an automated blog it is a policy. An engine touches the archive constantly, and every maintenance pass it runs, however cosmetic, re-dates every page it touched. The result looks like the freshness gaming Google's question describes, produced by nobody's intention, at the scale of the whole archive.

Our own dates say September 7, and they are wrong

We checked ours before writing this. Our structured data sets dateModified from Payload's updatedAt, and so does our sitemap. Seventeen of our posts, published between 29 August and 6 September, carry a modified date of 7 September, all stamped within five minutes of one another. That was the afternoon we regenerated hero images whose files had been lost from storage. Not one sentence of those seventeen posts changed.

So a reader of our oldest posts sees "Generated 29 Aug", while the markup and the sitemap tell Google the post was updated nine days later, with nothing visible to explain the difference. That is the mismatch the byline-dates page asks you to avoid. There is a second fault underneath it: updatedAt is a single timestamp shared by both languages, so a correction saved only into a Finnish post also moves the date on the English one.

What a revision owes the reader

The fix is to separate the editorial date from the system timestamp. A post needs its own revisedAt field, set only when the argument changes, and the template should read dateModified from that field rather than from the row. A swapped image, a typo, a repaired link or an alt-text backfill leaves it alone.

When revisedAt does move, the page should say why, in one visible sentence near the date: what changed and, where it matters, what the post used to claim. That is the part an engine is genuinely good at, because it knows exactly what it rewrote and can describe the difference the moment it publishes it. It also fits the decay clock we described in every post has a half-life: a revision prompted by a source that moved should name the source.

The concessions are real. A changelog line will not rank anything; Google's systems do not depend on a single date. Deciding what counts as significant is a judgment, and a hero swap arguably edits the structured data Google lists. And a visible note on every trivial fix is clutter that trains readers to skip it, which is why the threshold matters more than the format.

The date is part of what the post claims

Readers and search engines both use a modified date as shorthand for "this was checked recently". That shorthand only works while the dates are true. An automated blog that lets its database write them will spend that trust without deciding to, a few hundred pages at a time.

Treat the date as a sentence in the post. Move it only when the argument moves, and say what moved.