Machine-readable dates

Declare when each substantial page was published and last updated, in a form machines can parse - not just a date printed in the text. Search engines and AI assistants weight freshness heavily when deciding what to rank and what to cite, and a page they cannot date is a page they cannot trust to be current.

A visible date alone does not do this job. "05/06/26" in a byline is ambiguous to a machine three times over: May or June, published or updated, and which year format. The date has to be declared in metadata with an unambiguous format, and the visible date should agree with it.

Why it works

When an answer engine chooses between two pages making the same claim, "how current is this?" is part of the judgment. A page that declares its dates answers the question; a page that declares nothing loses to dated content even when it is better written. This costs you citations and rankings silently - there is no error, no warning, just other people's pages being chosen over yours.

Declared dates also compound with everything else you publish. Comparison content, statistics, pricing, product claims - all of it is more citable when an assistant can see it was updated recently, and more suspect when it could be from any year.

How to do it

Declare dates in one of these forms, listed strongest first. You only need one, but they can coexist and agree.

1. Structured data (strongest)

Add datePublished and dateModified to the page's - typically an Article or BlogPosting in . This is the form answer engines extract most reliably:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to reconcile corporate card statements",
  "datePublished": "2026-05-01T09:00:00Z",
  "dateModified": "2026-07-10T14:30:00Z"
}
</script>

Use full ISO 8601 timestamps with a timezone. If the page has never been updated, dateModified equals datePublished.

2. Date meta tags

If you cannot emit structured data, the established meta tags carry the same information:

<meta property="article:published_time" content="2026-05-01T09:00:00Z">
<meta property="article:modified_time" content="2026-07-10T14:30:00Z">

3. A visible date that machines can also read

The <time> element makes a human-visible date machine-readable in one stroke:

Last updated <time datetime="2026-07-10">July 10, 2026</time>

This only works as a dating signal when the page contains one unambiguous date - a page scattered with <time> elements (event listings, comment threads) tells a machine nothing about the page itself. Prefer it as a companion to structured data, not a substitute.

Everywhere, not by hand

Do not do this page by page. Most platforms and SEO plugins can emit datePublished and dateModified automatically from the editorial dates they already store - turn that on and the whole site is covered, including every page you publish next year. If you build your own templates, wire the dates into the article template once.

While you are there, keep your XML sitemap's <lastmod> values wired to the same editorial dates. Sitemaps do not date pages for citation purposes, but crawlers use <lastmod> to decide what to revisit, so a fresh page gets re-crawled - and its new date noticed - sooner.

Keep the dates honest

dateModified must mean the content genuinely changed. Answer engines cross-check declared dates against content, archives, and their own crawl history:

Do not bump the date on every republish or template change. A page whose dateModified updates weekly while its text never changes reads as manipulation, and the date stops being believed.
Do not backdate or future-date. A declared date after the crawl, or before the site existed, is discarded.
Make the visible date match the declared date. A byline saying 2023 under metadata saying this year is a contradiction, and contradictions are resolved against you.

The flip side: when you genuinely refresh a page - new statistics, updated pricing, corrected claims - update dateModified in the same commit. An honest update you never declared is a citation you never earned.

What does not work

A date only in visible text. Ambiguous to machines, as above.
The HTTP header. It describes the server response, not the content. On dynamically generated sites it changes with every request, which is exactly why consumers distrust it. Fine to serve, but never your only signal.
Dates only in the URL (/blog/2024/06/...). A weak hint at publication date, silent about updates, and it fossilizes the page: the URL still says 2024 after your 2026 refresh.

How Silktide helps

Silktide reads the dates your pages declare - structured data first, then date meta tags, then a single unambiguous <time datetime> element - and uses them across its reporting:

The Content dates check flags substantial, indexable pages that declare no publication or update date at all.
Presence's Velocity screen charts publishing cadence from these same declared dates, so undated pages drag its accuracy down.

If Silktide cannot date your pages, neither can the engines you are trying to be cited by - the check is a direct preview of how your site reads to them.

Content dates - the Silktide check that flags undated pages
Structured data markup - the full technique the strongest form of this belongs to
Comparison pages - late-funnel content where a stale or missing date is most expensive
- why answer engines are the audience for these signals