Freshness: date, revise, prove. What engines and AI expect from up-to-date content

A reader who puts a question to an assistant in 2026 wants an answer that holds in 2026. Search engines, classic and generative alike, know this and take the date of a piece into account, above all on subjects where the facts move: regulation, prices, versions, market figures. Many publishers have drawn a bad habit from it, that of changing an article's date without changing a line of it. The practice is detectable and counterproductive. Here is what engines actually read, how they check it, and how a media property that publishes a lot organizes its updates.

What Google reads, and where

Google documents, on its page about Article structured data, two properties taken from schema.org: datePublished and dateModified. The second has to carry the date of the last substantial change to the content, and Google asks, in its guidance on dates, that it match the date visible on the page. The sitemap carries a third signal, lastmod, which Google uses to decide what it reloads first, provided it is reliable, as the page on building a sitemap explains.

The point that matters is consistency. Google compares what the structured data says, the displayed date, the sitemap lastmod and, where they exist, the HTTP last-modification headers. When those sources contradict one another, it stops trusting them and falls back on its own observation: did it see the content change between two passes? A site whose sitemap announces a change on every page every day, without a single one changing, teaches Google that its lastmod means nothing. We documented that case in "A sitemap with identical dates is useless".

What generative engines do with dates

A generative engine that answers with sources looks for relevant passages, then weights them. On a question whose answer depends on time, it favors passages carrying a recent date, and it reads that date wherever it is available: in the structured data, in the text, sometimes in the URL. Google states on its page about AI features in search that its generated answers rely on the same signals as classic search, with no special markup; freshness is one of them.

There is a consequence publishers underestimate: a generative engine may cite the passage that carries its own date. "Since August 2, 2026, article 50 has applied" is a datable, quotable passage. "The regulation changed recently" is neither, and it ages badly. Writing dates into the text, in full, is a freshness practice as much as a citability practice, along the lines we set out in "Answer first, qualify second".

Why the false signal costs more than it brings in

Redating an article without modifying it produces three effects, all of them negative.

1. The loss of trust in the signals. The engine observes that the date changes and the content does not. The risk is that it learns this site's dates are noise and stops taking them into account, including for real updates. No engine documents that behavior: it is a deduction, not a measurement. The two effects also follow one another in time rather than coexisting. The engine first reloads on the strength of the announced dates, and it is the repeated finding of unchanged content that then leads it to distrust them.
2. The waste of crawl budget. Every page announced as modified gets reloaded. On a media property with five hundred articles, announcing five hundred fictitious changes every day means asking for five hundred reloads for nothing, at the expense of the pages that really are new.
3. The risk of contradiction. An article "updated in September 2026" that quotes a 2024 price or an abandoned software version loses all credibility with an attentive reader, and a generative engine willingly displays the date it finds in the passage it cites.

Google's search quality rater guidelines devote several pages to the notion of up-to-date content, and explicitly separate the subjects where the date counts from those where it does not. A guide to laying a roof does not need rewriting every month; a page on renovation grants does.

What a real revision looks like

A revision that justifies a new modification date changes something a reader could notice: a figure replaced by a more recent one, a section added on a new fact, a recommendation withdrawn because it no longer holds, a source replaced by an up-to-date one. Fixing a typo, changing an image or rephrasing a title is not a revision, and must not modify dateModified.

The rule is easy to hold over ten articles and impossible to hold from memory over five hundred. That is where organization counts.

Organizing revision at scale

A media property that publishes several pieces a week builds up a few hundred articles in a year, some of them carrying perishable facts. That revision work stays workable without tying up a full-time team, provided it is tooled.

The reference base. If the facts, the figures and the positions come from one shared reference base rather than from each article, updating a fact in the base makes it possible to find every article that uses it. A price changes: you know which articles quote it. A regulatory deadline is pushed back: you know which articles announced it. Without a reference base, that search is done by hand, which means it is not done.

Marking the perishable facts. At the writing stage, every dated or numerical claim is identified as such, with its source and its presumed date of validity. A monthly review lists the claims whose validity has run out, and the editor decides, for each one, whether to verify it, correct it or withdraw it. It takes a few hours a month, and it bears on the passages engines reread the most.

Measurement. The logs say which pages robots reread after a change, and Search Console says which ones are losing impressions. A page slipping on a query whose answer has changed is a candidate for revision before the reference base even flags it. We described that reading in "Reading an access log in 30 minutes".

Signaling the change, without abusing it

Once the revision is done, it still has to be made known. Three channels, to be used together and only for real revisions: updating dateModified in the structured data and the date visible on the page; updating the lastmod of that URL, and of that one alone, in the sitemap; and, for the engines that support it, a direct notification through IndexNow, which tells Bing and its partner engines that a URL has changed, without waiting for their next pass.

The server adds one last signal, often forgotten: the Last-Modified and ETag headers, and honoring conditional requests. A robot that asks "has this page changed since my last visit?" and gets an honest answer, yes or no, stops reloading blind, and concentrates its passes on what actually moves.

Freshness is an asset, not a setting

A media property whose dates are reliable is a media property engines reread when it asks them to, and cite with the right date. A media property that redates everything gains nothing in the short term and loses, in the medium term, the only thing that counts: the trust engines place in its signals. What separates the two is the organization: a shared reference base, a regular review of the perishable facts, a measurement of what the robots reread. It is one of the reasons we hold that a corporate media property is built on a reference base before it is built on articles.