**TL;DR** — Across 25 client sites through May 2026 we audited a signal every CMS exposes and almost no citation report controls for: the visible date on a page — the published-on or updated-on line a human reads and a structured `datePublished`/`dateModified` carries — and whether changing it, or earning it honestly, changes how often the AI Overview cites the page. Across 7,360 cited-passage events we joined each cited page to its visible dateline, its structured date metadata, and whether its main content had genuinely changed since that date. The headline is that freshness is conditional, not universal: on time-sensitive queries (anything carrying a year, "latest", "current", "2026", or a fast-moving topic) the cited page's content was a median 47 days old, while on evergreen queries (definitions, how-tos, stable facts) it was a median 2.3 years old and recency barely moved citation odds. The strongest predictor of being cited on a time-sensitive query was substantive content recency — a page whose main content had genuinely changed within 90 days was cited 3.4× more often than a comparable page untouched for over a year. The second was dateline visibility — a page exposing a clear, machine-readable `dateModified` plus a human-visible "Updated" line was cited 2.1× more often than a dateless page of identical content. The third, and the warning, was date-content agreement — pages that bumped `dateModified` without changing the content (a "freshness fake") were cited no more often than dateless pages and, on 6% of audited pages, were cited less, consistent with the freshness signal being discounted when the body did not move. One change — pairing a genuine content refresh with an honest, visible, structured dateline on time-sensitive pages — lifted cited-passage rate by 36% on the affected sites over a 30-day follow-up.
Why we ran this audit
Every client asks some version of the same question: "if I just update the date, will I get cited again?" It is the cheapest possible intervention — most CMSs will stamp today's date on a page with one click — and the folk belief that Google rewards recency makes it the first thing teams reach for when a page falls out of an answer card. We had strong priors that a bare date bump does nothing, but priors are not data, and we had been giving clients an opinion where they deserved a measurement. We needed to know whether the visible date is a citation lever at all, and if so whether it is the date itself that matters or the content change the date is supposed to represent.
The second motivation was the opposite failure. Several clients ran genuinely current pages — updated monthly with real new information — that carried no visible date and no `dateModified` at all, because their templates had never exposed one. If the composer uses freshness as a tiebreaker on time-sensitive queries, those pages were current but illegible: doing the expensive work of staying fresh while hiding the one signal that would let the composer know. We wanted to separate the cost-free fake (bump the date, change nothing) from the cost-free legibility fix (expose the date on genuinely fresh content) from the expensive real work (actually refresh the content), because all three get casually called "updating the page" and they do very different things.
How we ran the measurement
25 client sites — 9 SaaS, 7 publisher, 5 DTC, 4 B2B services — each with a fixed 200-query basket of its real in-market queries, which we hand-classified as time-sensitive or evergreen before any capture so the cut was not drawn post-hoc to fit the data. A query was time-sensitive if it carried a year, an explicit recency word ("latest", "current", "new"), or sat in a topic our clients update on a sub-quarterly cadence (pricing, regulation, platform features, benchmarks); evergreen otherwise. Twice daily through May 2026 we captured every AI Overview card and, for cards citing a client page, recorded three dates: the human-visible dateline on the page, the structured `datePublished`/`dateModified` in the page's markup, and — the expensive part — whether the main content had genuinely changed since the stated `dateModified`, which we established by diffing archived snapshots of the main content region and counting a change only when substantive text, not boilerplate or ads, had moved. The cited-passage cohort was 7,360 events.
Two normalisation moves matter. We measured content age, not date-stamp age, as the real variable — a page can claim any `dateModified` it likes, so we treated the stamp as a claim and the diffed content change as the fact, which is the only way to separate honest freshness from a date bump. And we report time-sensitive and evergreen queries entirely separately rather than blending them, because the median cited-content age differs by more than a year between the two and any single averaged "freshness effect" would be an artefact of the query mix rather than a real signal. The 47-day and 2.3-year medians are the two populations reported apart for that reason.
The shape of the freshness pattern
The flat headline first. Freshness is conditional, and the condition is the query. On time-sensitive queries the cited page's content was a median 47 days old and the age distribution was tight — 71% of cited pages had content under 120 days old, and content older than a year was cited on only 12% of time-sensitive events despite making up most of the eligible corpus. On evergreen queries the same measurement inverted: the cited page's content was a median 2.3 years old, recency barely shifted the odds, and a two-year-old definitional page was cited as readily as a two-week-old one. The composer is not globally biased toward new pages; it applies a recency preference sharply on queries whose answer can go stale and essentially not at all on queries whose answer does not.
The most decision-relevant cut was that on time-sensitive queries recency competed with, and sometimes beat, raw authority. We had assumed a high-authority stale page would hold its citation against a fresher but weaker page; on time-sensitive queries it often did not. Among time-sensitive events where a strong-but-stale page and a weaker-but-fresh page both ranked, the fresh page took the citation 58% of the time — authority bought back some of the recency gap but did not erase it. On evergreen queries the same matchup went the other way, authority winning 74% of the time. Freshness is not a universal ranking factor the composer always applies; it is a factor whose weight the composer turns up precisely when the query implies the answer could have changed.
Driver one: substantive content recency, not the date stamp
The single strongest predictor on time-sensitive queries was whether the main content had genuinely changed recently. A page whose content had substantively moved within 90 days was cited 3.4× more often than a comparable page whose content was untouched for over a year, and the relationship tracked content-diff recency, not stamp recency — when the two disagreed (a fresh stamp on stale content, or a stale stamp on freshly changed content) it was the content change that predicted citation, not the date in the markup. The composer behaves as though it is reading the actual content for signs of currency — new figures, current-year references, changed specifics — rather than trusting the date a page asserts about itself, which is exactly what you would design if you knew date fields were trivially gameable.
We ran a structural test on 17 time-sensitive pages across 9 clients that had fallen out of citation, each genuinely out of date. We did real refreshes — updated the figures, replaced superseded references, added the current-year specifics the query implied — and stamped an honest `dateModified` reflecting the actual change. Over the 45 days that followed, 12 of the 17 pages re-entered the citation set on at least one target query, and the gain tracked how much the content actually moved: the pages with the largest substantive change recovered fastest and most durably. The lever was the content work; the date stamp was just the honest label on it.
Driver two: dateline visibility makes real freshness legible
Holding content recency constant, the second driver was whether the page exposed its date at all. A page carrying both a machine-readable `dateModified` and a human-visible "Updated on" line was cited 2.1× more often than a page with identical, equally-fresh content but no exposed date in any form. The two surfaces compounded: structured date alone bought most of the gain, the visible line added the rest, and pages that had genuinely fresh content but exposed it nowhere were leaving the entire signal on the table. This is the cheapest honest win in the whole audit — it adds no content work, it simply stops hiding freshness the page already has, and it only helps pages that are actually current.
We ran a structural test on 14 pages across 8 clients that were genuinely maintained — real monthly updates — but exposed no date because their templates lacked the field. We added a correct `dateModified` to the structured data and a visible "Updated" line reflecting the true last-substantive-change date, and changed nothing about the content. Over the 60 days after the change, 9 of the 14 pages improved their cited-passage rate on time-sensitive queries, confirming the signal was being read once it was legible. Crucially we did not touch the dates on pages that were not actually fresh, because exposing a stale date is worse than exposing none — it advertises the staleness the composer was about to detect anyway.
Driver three: date-content agreement, and the freshness fake that backfires
The third driver was the warning. Pages that bumped `dateModified` to a recent date without changing the main content — the one-click "freshness fake" every client is tempted by — were cited no more often than dateless pages of the same content, and on 6% of audited pages were cited measurably less after the fake bump than before it. The reading consistent with the data is that the composer cross-checks the asserted date against the content and discounts, or distrusts, a recency claim the body does not support; a page that says "updated today" over year-old text is making a claim the content visibly contradicts, and the contradiction appears to cost more than saying nothing. Date-content agreement, not date recency, is what the signal rewards.
We confirmed this deliberately on 11 pages across 6 clients where a previous team had bumped dates without refreshing — pages carrying a recent `dateModified` over demonstrably old content. We did not bump the date further; we either did the real refresh to make the existing recent date honest, or where the content genuinely could not be refreshed we reverted the date to the true last-change date. Over the following 45 days, the pages we made honest-by-refreshing recovered citation, and the pages we made honest-by-reverting held steady rather than declining further — both better than the fake-fresh state they started in. The actionable rule is blunt: never advance a date you cannot back with a content change, because the composer appears to check.
What changed in our content checklist
Three changes. We split "update the page" into three named actions in every brief — refresh (change the content), expose (surface the date on genuinely fresh content), and revert (correct a dishonest date back to truth) — because lumping them as "updating" was letting clients reach for the cost-free fake when only the expensive refresh moves citation. We made an honest, visible, structured `dateModified` a template requirement on every time-sensitive page, set to the true last-substantive-change date and never advanced without a corresponding content change. And we added a query-class gate to refresh prioritisation: we spend refresh budget on time-sensitive pages where recency is a live citation factor and stop pushing pointless date-driven refreshes on evergreen pages where a two-year-old answer is cited as readily as a new one.
We dropped one habit. We had quietly tolerated the date bump as a harmless first try — cheap, fast, probably useless but unlikely to hurt. The audit shows it is not harmless: on a meaningful minority of pages a recency claim the content does not support cost citation rather than merely failing to add it. So the date bump left our toolkit entirely. Freshness is now something we earn in the content and then label honestly, never something we assert in the metadata and hope the composer believes.
- 01Freshness is conditional on the query. Time-sensitive queries cited content a median 47 days old; evergreen queries cited content a median 2.3 years old — spend recency effort only where the query implies the answer can go stale.
- 02Refresh the content, do not bump the date. Genuine content change within 90 days was cited 3.4× more; 12 of 17 stale pages recovered after a real refresh, tracking how much the content actually moved.
- 03Expose the date you have earned. A visible "Updated" line plus structured dateModified was cited 2.1× more than identical dateless content; 9 of 14 genuinely-fresh-but-dateless pages improved once the date was legible.
- 04Never fake freshness. Date bumps over unchanged content were cited no more than dateless pages and less on 6% of cases — the composer appears to cross-check the date against the body, so date-content agreement is the signal, not recency.
Where this argument breaks
For evergreen pages the entire freshness apparatus is overhead and a refresh-for-recency programme is wasted budget — a stable definitional answer is cited at two years as readily as at two weeks, and the right move is to leave it alone and stop stamping pointless dates on it. For news and genuinely real-time queries the recency window is far tighter than our 47-day time-sensitive median — for breaking topics the cited content is often hours old and no amount of structure substitutes for actually being first, which is a publishing-speed problem, not a metadata one. For pages where the original publish date is itself a trust signal (a primary-source study, an original dataset, a dated announcement) advancing `dateModified` can be counter-productive even when honest, because readers and the composer may value the original `datePublished` as provenance — there the move is to expose both dates, not to privilege modification recency. For Chinese-language AI search (文心一言, 元宝, 通义) the recency preference on time-sensitive queries was stronger still in our parallel audit — those engines leaned harder on fresh content and the visible-date gain was larger — but they were also more forgiving of a missing structured date when the on-page text carried an obvious current-year reference, so the in-body recency cue matters relatively more there and the markup field relatively less. Our window was 60 days and the cohort was 25 sites; the medians are point estimates that will differ by vertical and by how fast each topic actually moves. Outside those carve-outs the lesson holds: in 2026 the AI Overview applies a recency preference precisely on queries whose answer can go stale, it reads the content for genuine currency rather than trusting the date a page claims, the cheap honest win is exposing the date on pages that are actually fresh — and the one move that can actively cost you is stamping a recent date on content that has not changed.