Content Dates — datePublished, dateModified and a Visible Date
Show the publication and update date visibly on the page, and mirror the same dates in datePublished and dateModified. Google documents both ways. Whether AI assistants use dates to rank or select sources has not been shown.
datePublished and dateModified to your Article JSON-LD with exactly the same dates. Change dateModified only when the content really changes. Use ISO 8601 in the markup (YYYY-MM-DD, optionally with time and timezone).Why do dates on a page matter?
For Google: Google shows a byline date in search results when it considers it useful. According to its documentation on byline dates, Google “doesn't depend on a single date factor” and looks at several factors to estimate when a page was published or significantly updated. It recommends two things: a user-visible date that is featured prominently and clearly labelled, and structured data with datePublished and/or dateModified. Google does not guarantee that a date will be shown.
For ChatGPT and Claude: According to the study above, they remove JSON-LD when fetching a page live. Whatever date you put only in the markup does not reach them. A date written in the visible text does. If readers of AI answers should learn how current your page is, the date has to be on the page.
What is open: We do not know whether Perplexity, ChatGPT, Claude or Google AI Overviews treat recency as a ranking signal, or whether they penalise missing or inconsistent dates. We found no study that answers this. We will not claim an effect we cannot show.
How does datePublished work in Schema.org?
datePublished is a property of the Schema.org CreativeWork type (and its subtypes such as Article, BlogPosting, NewsArticle). It states when the content was first published. Google recommends adding it to a CreativeWork subtype such as Article or BlogPosting. Set it once and do not move it later: the date should describe the actual first publication.
How does dateModified work in Schema.org?
dateModified is a property of the Schema.org CreativeWork type that records the most recent update. Update it when you revise the content. We recommend not bumping it for trivial changes (fixing a typo, changing CSS) — otherwise the date stops telling readers anything. Substantive changes (new section, updated facts, revised statistics) do warrant a new date.
What counts as a substantive update?
A substantive update changes the informational value of the page for a reader. Examples: adding or replacing a code snippet, updating statistics or prices, adding a new section, revising a recommendation based on new information, or correcting a factual error. Formatting changes, typo fixes and visual redesigns are not substantive updates. This is our editorial recommendation; Google speaks of pages that were “significantly updated”, without defining the term.
What about Open Graph date tags?
The Open Graph protocol defines article:published_time and article:modified_time for pages of type article:
<meta property="article:published_time" content="...">— Open Graph article published time.<meta property="article:modified_time" content="...">— Open Graph article modified time.
You can add them, but neither Google's documentation on byline dates nor the study above covers them. We do not know whether search engines or AI assistants use them for dates. Treat them as optional; the visible date and the JSON-LD are the documented ways.
Step-by-step — add dates to your pages
- Add a visible, labelled date to every article: “Published …” and, if it applies, “Last updated …”. Render it in the server-side HTML.
- Add
datePublishedto your Article JSON-LD on every published page. - Set
dateModifiedto the same value asdatePublishedwhen you first publish. - Create a process (a CMS field, a deploy script or a commit hook) that updates
dateModifiedand the visible “Last updated” date together whenever content changes. - Check that the visible date and the markup show the same date. Google: “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values.”
- Validate the markup with Google's Rich Results Test.
Code example — visible date plus JSON-LD
<!-- Visible date: part of the page text that is fetched -->
<p class="byline">
Published: <time datetime="2026-04-16">16 April 2026</time> ·
Last updated: <time datetime="2026-10-16">16 October 2026</time>
</p>
<!-- JSON-LD structured data: same dates as the visible byline -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Your Article Title",
"datePublished": "2026-04-16T09:00:00+02:00",
"dateModified": "2026-10-16T14:30:00+02:00",
"author": {
"@type": "Person",
"name": "Your Name"
},
"publisher": {
"@type": "Organization",
"name": "Your Organisation",
"url": "https://example.com"
},
"url": "https://example.com/your-article",
"mainEntityOfPage": "https://example.com/your-article"
}
</script>
<!-- Optional: Open Graph article tags (use by search/AI not documented) -->
<meta property="article:published_time" content="2026-04-16T09:00:00+02:00">
<meta property="article:modified_time" content="2026-10-16T14:30:00+02:00">Google: “The date is required; the time is not”, but it recommends a time and timezone in the markup for added precision. In the visible text, time and timezone are optional even if the markup has them.
Common mistakes to avoid
- Date only in the schema, not visible on the page: ChatGPT and Claude strip JSON-LD when fetching live (see box above). Without a visible date, they cannot tell how current the page is.
- Markup differs from the visible text: Google asks for matching visible and structured dates. The study found the same problem with FAQ markup: when markup and visible text disagreed, Gemini Pro gave the outdated markup answer 8 out of 20 times. Keep every date identical in both places.
- No dates at all: Neither Google nor readers can tell when the page was written. Add at least a visible publication date and
datePublished. - Backdating or future dates: Google: “Don't specify future dates, or the date of the action described on the page.” The dates must describe when the page itself was published or updated, not the events it covers.
- Bumping
dateModifiedwithout real changes: The date then misleads readers. Change it only together with the content. - Non-ISO dates in the markup: Schema.org dates use ISO 8601 (
YYYY-MM-DDorYYYY-MM-DDTHH:MM:SS+02:00). The visible date can be human-readable, e.g. “16 October 2026”. - Wrong timezone: If you add a timezone, Google asks for the correct one, taking daylight saving time into account.
- Dates only injected by JavaScript: They are missing from the delivered HTML. We cannot say for every crawler and assistant whether it runs JavaScript. Render dates server-side to be safe.
- Many other dates on the page: If Google picks the wrong date, it suggests “removing some or all other dates that appear on the page”.
Official sources
- Google — Influence your byline dates in Google Search
- Google — Article structured data documentation
- Rick Ramos (14 Oct 2026) — Schema markup gives AI assistants nothing plain text doesn't
- Schema.org — datePublished property
- Schema.org — dateModified property