In one sentence: freshness is not whether you edited the page, it is whether a machine can tell when the substance last changed — and most "updated" pages carry no reliable signal of that at all.

Why it matters more here than in search

An engine constructing an answer is choosing between passages, and time-bound claims compete directly: a pricing sentence dated this quarter beats an undated one, because the undated one cannot be placed at all. In search, freshness is one ranking input among many. In an answer, it is often the tiebreak between two passages saying different things.

The signals, and how much they are worth

SignalReliabilityCommon failure
A date in the visible text of the claimHighest — it scopes the claim itselfNobody writes it
dateModified in Article schemaHigh, if it is honestSet to build time on every deploy, so it means nothing
Visible "last updated" lineMediumUpdated when a typo was fixed
lastmod in the sitemapMediumEvery URL claims today
HTTP Last-ModifiedLow — reflects the file, not the meaningChanges on every rebuild

The self-inflicted failure

A static site rebuilds nightly. Every page's dateModified and sitemap lastmod become today. Within a month, every date signal on the site is worthless, and crawlers learn to ignore the field — which also means the pages you genuinely did update no longer stand out.

Derive dates from the content's own history, never from the build. If your CMS records when the body last changed, that is the only date worth emitting.

Write the date into the claim

The strongest signal is also the cheapest and the one almost nobody uses: put the date inside the sentence that carries the time-bound fact. "As of September 2026, the Pro plan is £49 per month" survives being extracted; "pricing starts at £49" does not, because a year from now it is either still true or quietly wrong and nothing on the page says which.

This also solves the reason pages hedge. Teams write "pricing varies" to avoid being wrong later. A dated number is a better answer to that fear than a vague one, because it scopes exactly what was claimed and when.

A review cadence, not a refresh ritual

Mark the pages carrying time-bound facts — prices, integration lists, vendor behaviour, anything sourced from documentation that changes. Give them an owner and a review date. Then when you review, either confirm the date or change the fact; do not touch the file otherwise. Editing a page to make it look fresh teaches your own systems to lie.