aeo/freshness-signals checks every page for a real modification signal — a JSON-LD dateModified, an article:modified_time meta tag, or a visible 'Last updated' line — warns at medium confidence when none exists, then drops to an info note when the best date it can parse is older than the staleness default of 180 days Google has long associated with how AI Overviews weigh recency.
Optimize your content to trigger Google AI Overviews and answer engine summaries:
aeo/freshness-signals asks one question of every crawled page: does it carry evidence that it has been touched recently. The rule looks for a true modification signal in three places — a dateModified field anywhere in the page's JSON-LD (found by a recursive walk), a modification meta tag (article:modified_time, last-modified, dc.date.modified, or a <time datetime> element), or visible 'Last updated', 'updated on', 'revised', or 'last modified' text in the rendered content.
A datePublished alone is deliberately not enough. A page born in 2019 and never edited has a publication date but no modification signal, so it falls through to a warning at medium confidence — medium because evergreen pages like an about, pricing, or policy page may legitimately omit a modified date, and re-stamping them would mislead readers.
When a modification signal does exist, the rule parses the best date it can find and measures its age. If that age exceeds maxStaleDays — 180 days by default — it emits an info finding at low confidence, because stale by the clock is not always stale by meaning. The two findings sit at different severities on purpose: a missing signal is a warning, an old-but-present date is only an info note.
AI engines and the AI Overviews layer prioritise content that can prove it is current, because a synthesised answer that cites a stale page inherits that page's staleness. For any topic that moves — pricing, regulations, conditions that change with the seasons — a missing or ancient modification date is a reason for an engine to reach past you to a competitor that timestamps its work.
The rule catches the failure mode programmatic templates fall into most often: the body binds live data, but the template never surfaces a dateModified, so a page that was regenerated this morning looks, to a crawler, exactly as old as the day it was first published. The data is fresh; the signal is not. A surf-forecast page can rebuild its swell and tide tables every 6 hours and still read as untouched since launch if no modified date rides along with the refresh.
Both findings are gentle by design — a warning for the missing signal, an info note for the aged date — because freshness is contextual. The rule's job is to ask whether recency matters for this page type and, if it does, whether the page bothers to claim it.
/forecast/ocean-beach-weekly on a tide and surf-forecast site. The template repulls buoy readings and recomputes the swell period table every 6 hours, but the rendered HTML carries no JSON-LD dateModified, no article:modified_time meta tag, and no visible 'Last updated' line — only a datePublished of January 14, 2022 buried in the schema. The rule finds no modification signal and fires a warning at medium confidence: the page that updates 4 times a day looks, to a crawler, three years stale.
The same /forecast/ocean-beach-weekly page, instrumented to timestamp its refresh. Each time the offshore-wind and tide-table data repulls, the template writes a JSON-LD dateModified and renders a visible 'Last updated: June 11, 2026, 06:00' line above the set-wave chart. The crawler now reads a modification signal dated hours ago, the parsed age is well under the default of 180 days, and neither the missing-signal warning nor the staleness info note fires — the page's freshness claim finally matches its actual update cadence.
Freshness is not a spam policy and not a lever you can pull with a fake timestamp — Google has been explicit for years that re-dating a page without changing it does nothing, and can erode trust if the claimed date and the actual content diverge. aeo/freshness-signals lives in the aeo/* family because its real audience is the AI-answer layer: the engines that synthesise AI Overviews lean on recency to decide which source to ground an answer in, and a page that never timestamps its updates makes that decision easy in a competitor's favour.
This rule (in @pseolint/core, MIT-licensed at github.com/ouranos-labs/pseolint) is deliberately the gentlest member of its family. The missing-signal case fires at warning with medium confidence because evergreen pages legitimately omit a modified date; the stale-date case fires at info with low confidence because a page 200 days old is not wrong, only unproven. Neither is a verdict.
What the rule cannot do is judge whether your content is actually current — it reads the claim, not the truth behind it. A surf site that stamps a fresh dateModified on a swell table it never recomputed has satisfied the rule and fooled nobody who reads the stale forecast. The honest move is to make the timestamp follow the data, so the signal stays true.
Caldervale Cycling Routes maintains 680 route-guide pages. None carry a dateModified field in JSON-LD, no article:modified_time meta tag, and no visible 'Last updated' line -- the three modification signals aeo/freshness-signals scans for. The rule walks each page's JSON-LD with a recursive search, then checks meta tags (dc.date.modified, last-modified, any time[datetime] element), then looks for the visible phrases 'Last updated', 'updated on', and 'revised'. Finding none of the three, pseolint emits a medium-confidence warning on every route page. A secondary staleness check on pages that do carry at least one date signal finds 214 route pages whose best-parseable date is older than 180 days -- those fire an additional info note. Head of content Rhiannon Pryce added a dateModified stamp to all JSON-LD route schemas and a visible 'Last reviewed: March 2025' line, clearing both findings.
Want to know whether this rule actually fires on your site?
Run pseolint against your sitemap. The audit is free, takes about a minute, and returns a per-URL list of every rule that fired — including this one — with the exact metric values so you can prioritise the fix queue.