Read the Evidence, Maintain the Content

CH.01

What Freshness Studies Actually Measure

Page age, retrieval activity, and visible citations are different measurements. Start with the study population and date definition.

A page can remain useful for years, while a recent pricing comparison can become inaccurate quickly. Age alone does not tell you whether the information still answers the reader’s question. Check the facts, sources, and query context before deciding that a page needs an update.

Ahrefs published an analysis of 16.975 million cited URLs on July 28, 2025. Using crawler first-seen dates as a publication-age proxy, it reported a mean age of 1,064 days for URLs cited across ChatGPT, Perplexity, Copilot, and Gemini. This is a cross-sectional comparison of already-cited URLs. It does not show that every page expires after three months, or that updating one page will increase its citations.

CH.02

Age Distribution Is Not a Single Page’s Half-Life

Comparing pages from different years does not measure the same page losing citations over time.

Gander’s April 7, 2026 report compares unique sources retrieved by ChatGPT, Google AI Overviews, Gemini, and Perplexity during Q1 2026. Only 17.4% of the URLs contained a year in the path, and its year-cohort comparisons use that subset. The report calls the pattern a half-life, but this comparison is not a longitudinal test of one unchanged page’s citation count.

A lower share for older URL cohorts can reflect publication volume, topic mix, source availability, or retrieval behavior. It cannot by itself establish automatic annual decay for each page. Gander also distinguishes sources retrieved while composing an answer from the links shown in the final response; those layers cannot be treated as the same citation metric.

• →Record whether the study measures URLs, retrieval events, or visible citations.
• →Keep the year-in-URL subset and collection period explicit; undated URLs are not proven old or fresh.
• →To measure change for your pages, repeat the same prompt set and record model, date, cited URL, and content changes.

CH.03

dateModified Records an Update; It Is Not a Published Weight

Google recommends clear, consistent date information and uses several signals to estimate when a page was published or significantly updated.

Google’s byline-date documentation recommends visible publication or update dates alongside datePublished and/or dateModified in appropriate structured data. It does not publish a ranking of freshness weights for those fields. The practical task is to describe the page accurately, rather than to assign a citation multiplier to one JSON-LD property.

Keep datePublished as the original publication date. After a substantive revision, set dateModified to the actual update date and align the equivalent visible update date. Publication and modification dates have different meanings and need not be identical. Check timezone and avoid future dates or dates that describe an event instead of the page.

CH.04

Make Useful Changes, Then Record the Date

Changing a date alone adds no new information. Google’s people-first guidance explicitly questions date changes made to appear fresh without substantial content changes.

Do not stamp every page with today’s date as a freshness tactic. Google advises against changing dates to make unchanged content seem new. The official guidance does not disclose a universal body-hash check, a specific AI penalty, or a fixed reward for each type of edit. Keep an editorial change record so the displayed date has a clear basis.

A useful revision corrects obsolete facts, replaces evidence with a verified current source, or answers a question that the earlier version missed. Changing a year label alone is not new evidence. Keep a short record of what changed and why the reader needs it.

CH.05

Set a Review Cadence by Content Type

The intervals below are Tenten planning recommendations. They are not model expiry rules, and a review does not require a change when the content remains accurate.

Prioritize reviews by business value and how quickly the underlying facts change. Pricing and software versions need faster checks than stable definitions. A scheduled review should decide whether a correction is needed; it should not force a rewrite or date change merely to meet a freshness target.

The discipline of scheduling is "tier it, don't average it." The wrong move is to set a rigid rule like "update the whole site once every six months": the result is a pricing page sitting three months stale while nobody touches it, while a long-tail piece nobody asks about gets refreshed right on time. The right move is to let high-value, high-time-sensitivity content eat most of the update budget, let evergreen content backstop on a steady quarterly or semiannual rhythm, and let low-intent content be triggered entirely by rescan signals.

CH.06

The Freshness Ops Checklist: A schema + scheduling Operations SOP

Use this monthly checklist as a Tenten planning routine. Assign a reviewer; the checklist is not an automated engine requirement.

The first five chapters were concepts; this one nails them into a process. Freshness almost never collapses from not understanding it: it collapses because no fixed person does a fixed check at a fixed time. This SOP has exactly one design goal: make "meaningful update + dateModified sync" a calendar event, not something that rides on memory.