Content Freshness: When Updating Old Content Actually Matters

Most "refresh your old content" advice treats freshness as a universal good, which produces a predictable failure: a quarterly sweep that changes a date, swaps a few adjectives, and republishes. That is not a content update. It is a date change, and Google's own helpful-content guidance names it as a warning sign. The useful question is narrower — which of your pages contain claims that decay, how fast they decay, and what a real update to each one costs.

Freshness is three different things

The word covers three separate mechanisms that people routinely conflate.

Factual currency is whether the claims on the page are still true. A page listing an API's crawler tokens, a price, a legal threshold, or a plugin's minimum PHP version is wrong the moment the underlying fact moves. This is the only kind of freshness that is unambiguously worth money, because a stale page here is not merely under-performing — it is misinforming.

Date signalling is what the page tells machines about when it was published or changed. Google documents two ways to supply it — a prominent, user-visible date labelled "Posted", "Published" or "Last updated", and structured data such as Article or BlogPosting carrying datePublished and dateModified. Google is explicit that it "doesn't depend on a single date factor because all factors can be prone to issues", and that its systems look at several factors to estimate when a page was published or significantly updated.

Query-level recency is whether the topic itself demands recent information. "What is a canonical tag" does not. "Which AI crawlers does OpenAI publish" does, because the answer changed twice in the last two years. Recency demand is a property of the question, not of your site.

Only the first two are under your control. Treating all three as one knob is why freshness programmes waste effort.

Decay classes: a way to decide what to review, and when

Rather than a blanket cadence, classify each page by what actually goes stale in it. This is our own framework, not a provider recommendation — evidence tier EMERGING PRACTICE — but it is falsifiable: you can check whether the claims in a class have in fact changed since the last review.

Two of those rows are the ones people get wrong. Rewriting a news post so it stays "current" destroys the record and produces a page whose date claims a recency the analysis does not have. And leaving a volatile reference page on an annual cycle guarantees that for most of the year it is quietly wrong.

When an update genuinely earns its cost

An update is worth doing when at least one of these is true:

• A named fact on the page is now false. Highest priority, always. A wrong crawler token or a wrong price is a correctness defect, not a marketing task.
• The page is missing a development that a reader would expect it to cover. If a subject moved and your page does not acknowledge the move, the omission is visible to readers.
• The page answers a question adjacent to the one now being asked. Search and answer-engine phrasing shifts; a page written for "how do I block AI bots" may now need to address "should I".
• The page is structurally unretrievable. A wall of text with no headings is a retrievability problem you can fix while you are in there — see passage-level content structure.
• You can add information the page did not previously contain. Google's guidance frames quality around original information, substantial description and insightful analysis. Adding a section that answers something the page ducked is an update. Rewording the introduction is not.

When it does not

• When the only change would be the date. Google's self-assessment questions ask directly: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" It is listed among the signals of content produced primarily for search engines rather than people.
• When the page is thin and the honest fix is deletion or consolidation. A weak page updated is still a weak page. Merging it into a stronger pillar and redirecting is usually the better move; see pillar pages and topic clusters.
• When the page is dated analysis. Backdating a 2024 benchmark to 2026 misrepresents when the measurement was taken. That falls under our own prohibition on fabricating measurement context, and it damages the page's credibility with any reader who checks.
• When you are refreshing at scale to produce volume. Google defines scaled content abuse as generating many pages "for the primary purpose of manipulating search rankings and not helping users". A refresh programme that rewrites hundreds of pages with a model and no editorial review is the same behaviour with different inputs.

Date honesty

This is the part with actual provider guidance behind it, and it is cheap to get right.

For Article markup specifically, Google states there are no required properties — you add the properties that apply to your content — and that dates should be in ISO 8601 format, with a timezone recommended because Googlebot's timezone is otherwise assumed. dateModified is meant to reflect when the article was most recently modified. Nothing in that page instructs you to move it for a trivial edit, and moving it for a trivial edit is exactly what the helpful-content guidance warns about.

Two practical conventions follow. Keep datePublished immutable once a page is live. Move dateModified only when a human made a substantive change, and record what the change was — a visible "Updated 9 September 2026: revised the crawler table after OpenAI added OAI-AdsBot" is more useful to a reader than a bare timestamp, and it makes the claim auditable.

A separate signal worth keeping honest is <lastmod> in your XML sitemap. The sitemaps protocol defines it as "the date of last modification of the page". A sitemap generator that stamps today's date on every URL at every build is emitting noise, and it is the most common way a WordPress site accidentally tells crawlers that its entire archive changed overnight. Note also that <changefreq> is documented as "a hint and not a command", and <priority> explicitly "does not affect how your pages are compared to pages on other sites" — neither is a freshness lever.

What freshness does not do

There is no documented mechanism by which a recent date improves how AI answer engines treat your page. Google's guidance on AI Overviews and AI Mode is unambiguous in the other direction: "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary", and "You don't need to create new machine readable files, AI text files, or markup to appear in these features." Google's publication-dates page, read in full, is about how dates are determined and displayed. It makes no claim about ranking. Neither do we.

What is defensible is narrower and mechanical: a retrieval system that surfaces your page in an answer will often surface the date alongside it, and a reader deciding whether to trust a claim uses that date. A page that is demonstrably current is more likely to survive a human's credibility check. That is a HYPOTHESIS about citation behaviour and an observation about readers — not a ranking claim, and not something to score a site on.

The distinction that has to survive: crawled ≠ retrieved ≠ cited ≠ recommended. A fresh date affects none of those arrows directly.

How a freshness rule should work

A freshness check that flags every page older than N months is worse than no check. It generates a queue nobody works, and it pressures the team toward exactly the date-shuffling that Google names as a warning sign. A rule that is worth shipping is tiered by evidence and separates correctness defects from suggestions.

Tier 1 — date integrity. Scored. These are compliance checks against documented guidance, and a failure is a real defect:

• A visible date exists and is labelled.
• Structured-data dates exist and are valid ISO 8601.
• The visible date and the structured date agree.
• No date is in the future.
• dateModified is not earlier than datePublished.
• Sitemap lastmod is not uniformly equal to the build date across the whole corpus.

Tier 2 — staleness by decay class. Reported, weakly weighted. The page is past the review interval for its class. This is EMERGING PRACTICE: the class assignment is a judgement, and the interval is ours, so it belongs in a review queue rather than in a defect count. It should be sorted by consequence — a stale volatile-reference page outranks a stale explainer by a wide margin.

Tier 3 — "refresh this to improve AI visibility". Not scored, and shown separately. HYPOTHESIS. It must not be phrased as a fix, and it must not contribute to any status band. This is the tier where most freshness tooling quietly cheats.

SiteRank AI's GEO readiness audit includes a content freshness check built on this split. It reports a status band — good, needs attention, critical, or not measured — with the counts behind it, never a 0–100 score, and every finding carries its tier. Tiers below EMERGING PRACTICE are excluded from the band calculation at the query level, so an experimental idea cannot leak into a number. The full definitions are in the measurement methodology.

The other half of a working rule is prioritisation by traffic and by link position. A stale page that three pillar pages link into does more damage than a stale orphan, because the orphan is not being read. Combining staleness with internal-link centrality gives a queue that a small team can actually clear — see internal linking for SEO, retrieval and AI.

Evidence classification

Key takeaways

• Separate factual currency, date signalling and query-level recency. Only the first two are yours to control.
• Classify pages by what decays in them. Volatile reference pages need a 30–90 day cycle; dated analysis should never be refreshed at all.
• Date integrity is the part with real provider guidance behind it, and it is cheap: visible date, matching structured data, no future dates, honest sitemap lastmod.
• Changing a date without a substantive change is named in Google's own self-assessment questions as a warning sign.
• A freshness rule must separate date-integrity defects from staleness suggestions from unproven AI-visibility claims, and must not score the last group.

Official sources & further reading

• Article dates in Google Search results — Google Search Central
• Creating helpful, reliable, people-first content — Google Search Central
• Article (Article, NewsArticle, BlogPosting) structured data — Google Search Central
• AI features and your website — Google Search Central
• Google Search spam policies — Google Search Central
• Sitemaps XML format — sitemaps.org

Related reading

• Pillar pages and topic clusters
• Internal linking for SEO, retrieval and AI
• Passage-level content structure
• Citation-worthy content for AI systems
• SiteRank AI's topical authority analysis