Content Freshness Signals and AI Citations

A freshness signal is any machine-readable indicator of when a piece of content was published or last substantively updated. Content freshness matters to ranking and retrieval systems because some queries have answers that change over time, and a system has no way to know whether a given page reflects the current state of a fast-moving topic unless the page tells it when it was last true.

Why this affects AI citations

Queries with an implicit or explicit time component — "best X 2026," "current pricing for Y," "latest version of Z" — put a ranking or retrieval system in a position where it has to guess how current a candidate source is before deciding whether to cite it. A system generating an answer to a time-sensitive question has a strong incentive to prefer sources it can confidently date over ones it can't, because citing an undated source risks presenting stale information as current and being wrong in a way that's easy for a user to catch.

Undated content isn't automatically treated as bad content, but it is treated as higher-risk content for exactly the queries where freshness matters, and the ranking layer's response to risk it can't verify is generally to route around it rather than gamble on it. A page with clear, consistent date signals removes that specific source of hesitation — whatever the ranking or retrieval system decides about the content's substance, at least it isn't also having to guess how current that substance is.

Three machine-readable date signals

The visible date is what a human reader sees on the page — typically near the headline, formatted however your site's design shows it. This is what a person skimming the page checks first, and it's also readable by any system doing basic text extraction even without parsing structured markup, since it's part of the page's visible content rather than hidden metadata.

Meta tags, specifically article:published_time and article:modified_time (part of the Open Graph-adjacent meta tag conventions widely used across the web), live in the page's head section and are read by crawlers and social/link-preview systems without requiring them to parse the visible body content at all.

JSON-LD dates — datePublished and dateModified on an Article-typed structured data block, as covered in the schema markup guide — are the most explicitly machine-readable of the three, sitting in a dedicated structured data format rather than being inferred from formatting or extracted from a meta tag's attribute value.

Why do all three need to agree?

Redundancy across independent signals is what makes a claim trustworthy to a system that can't simply ask you whether it's true. If only the visible date is present, a system that only parses structured data or meta tags gets nothing. If only JSON-LD is present, a human skimming the rendered page (or a system doing lightweight text extraction without a full structured-data parser) sees no date at all. And if the three signals disagree with each other — a visible date that doesn't match the JSON-LD dateModified — that disagreement is itself a bad signal, suggesting the page's metadata isn't being maintained carefully, which invites doubt about the rest of the page's accuracy too.

Having all three present and in agreement costs little once the underlying date values are tracked in one place in your content pipeline, and it removes any single point of failure in how a date gets communicated to whatever system is reading the page.

Honest updating

dateModified should change only when the content's substance changes — a real correction, a meaningfully expanded section, updated figures or examples. It should not change every time you fix a typo, adjust a CSS class, or otherwise touch the page without changing what it actually says. Bumping the modification date without a substantive edit is a form of fake freshness, and it's a detectable one: comparing a stated modification date against the actual content, or against an archived or cached prior version of the same page, isn't a hard technical problem for any system built to check it, human or automated.

The cost of getting caught doing this isn't abstract. Once a date signal is found to be unreliable on one page, the reasonable response from any system (or reader) that noticed is to discount that signal sitewide, not just on the one page where it was caught — which defeats the entire purpose of having freshness signals in the first place. Honest dating, updated only for real changes, is what makes the signal worth anything at all.

What counts as a real update?

A reasonable line: if you'd be comfortable explaining the specific change to a reader who asks "what's different since last time," it's a real update. Correcting an inaccurate claim, adding a new section, updating a figure that's changed, revising an example that no longer applies — all real. Fixing a broken link, adjusting spacing, correcting a typo that didn't change meaning — not substantive enough on their own to justify a new dateModified, though there's no harm in keeping an internal changelog of minor fixes separately if that's useful to you.

Implementation

Visible date, using semantic markup rather than a plain styled <span> (search engines and accessibility tools both benefit from a proper time element with a datetime attribute):

Published <time dateTime="2026-07-11">July 11, 2026</time>.
Updated <time dateTime="2026-07-11">July 11, 2026</time>.

Meta tags in the page head:

<meta property="article:published_time" content="2026-07-11T00:00:00Z" />
<meta property="article:modified_time" content="2026-07-11T00:00:00Z" />

JSON-LD, as part of the Article block described in the schema markup guide:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "datePublished": "2026-07-11",
  "dateModified": "2026-07-11"
}

All three should read from the same underlying date values in your content source — frontmatter fields in an MDX file, database columns in a CMS — rather than being set independently in three places where they can drift out of sync through simple human error.

How to check

View page source and look for a visible date near the headline, the article:published_time and article:modified_time meta tags in the head, and datePublished/dateModified inside any application/ld+json block. Check that the three values actually match each other, not just that all three are present — a mismatch is itself a problem worth fixing even if no single signal is missing.

The CitationsAI Inspector extension checks for date signals as part of its audit and flags pages where no visible date, date meta tag, or JSON-LD date is found at all — the baseline case of a completely undated page, which is the highest-priority version of this issue to fix.

How to fix it

If you have none of the three signals, add all three, sourced from a single date value in your content pipeline so they can't independently drift. If you have some but not others, add the missing ones using the same source date. If you have all three but they disagree, pick the correct value (usually your CMS or file system's actual last-substantive-edit date) and correct the others to match.

Going forward, update dateModified (and the matching visible and meta-tag dates) only alongside real substantive edits, as part of your normal editing process rather than as an afterthought — the discipline of updating dates honestly is worth more, cumulatively, than the one-time work of adding the signals in the first place.