We couldn't find a machine-readable last-updated date

The check looks for a machine-readable date across every crawled page, in four places: JSON-LD (dateModified or datePublished), schema.org microdata (itemprop="dateModified" or itemprop="datePublished", since 19 September 2026), the <time datetime="…"> element, and Open Graph article elements (article:modified_time, article:published_time). It is enough for a single page to carry one in any of those.

Microdata is a full alternative here, not a fallback: Google's documentation states that JSON-LD, microdata and RDFa are all equally fine for it as long as the markup is valid.

As with AUTH-02, the finding says “we did not find” rather than “is missing”, and for the same reason. A date written only in the text (“Updated 10 September 2026”) passes as not found, even though it is on the page. It is a limit of a deterministic check, not a claim about your site.

What the check does not do:

• It does not read dates out of text. Not from an article header, not from a footer.
• It does not verify the date is true. A dateModified of today on a page untouched for three years passes, and that is one of the commonest untruths on the web.
• It does not distinguish publication from modification. Either one will do.
• It does not check for a date on every page. One date anywhere silences the finding for the whole site.
• It cannot see RDFa. The third valid format for structured data is one we do not read yet, so a date stated only there escapes us. That is an admitted gap in the check.
• It cannot see values injected by JavaScript unless the page was sampled through a browser.

The finding is site-level; severity is warning.

We have no evidence that stating an update date improves your chances of being cited in an AI answer, hence the “effect not demonstrated” class. In the Princeton experiment, the field's only peer-reviewed one, the measured factors were quotations (+41 %), statistics (+33 %) and links to sources (+28 %). A date was not among them.

What we do know about dates is a different matter, and worth mentioning because it is practical: language models have a fixed cut-off in their training data, and when answering a question with a time dimension they reach for content whose age they can tell. So a date on your content is information a model can use. That it uses it in your favour is not documented.

One thing is documented, though, and it counts against you: among the warning signs of content written for search engines rather than people, Google asks outright whether you are changing the date of pages to make them seem fresh when the content has not substantially changed. Rewriting dateModified to today on a three-year-old text claims nothing about quality; it states an untruth.

And as with AUTH-02: domain authority, backlinks and domain age have no documented support in the context of AI visibility, and we keep them out of the score.

The practical conclusion: add the date, because it is honest towards your reader and costs one line in a template. But add a truthful date, and while you are at it, consider whether that content needs rewriting rather than re-tagging.

The best route is to add the date to the JSON-LD you probably already have, using both properties (publication and last change):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose a heat pump",
  "datePublished": "2026-03-04",
  "dateModified": "2026-09-10"
}
</script>

If your site is marked up with microdata, stay with it and add the date in that same format; the check accepts it just like JSON-LD, and so does Google. The attribute can hang directly on the <time> element you already have:

<article itemscope itemtype="https://schema.org/BlogPosting">
  <h1 itemprop="headline">How to choose a heat pump</h1>
  <time itemprop="dateModified" datetime="2026-09-10">10 September 2026</time>
</article>

In the visible text, the <time> element carries the machine-readable value and the human-readable text in one:

<p>Updated <time datetime="2026-09-10">10 September 2026</time></p>

What to watch out for:

• Use YYYY-MM-DD in the datetime attribute and in JSON-LD. A local format such as “10/09/2026” belongs in the visible text, not in the machine value.
• The date must match what is visible. A contradiction between markup and text is worse than no date at all.
• Change dateModified only on a real content change. Rewriting it on every deployment turns the date into nonsense, and Google lists that among its warning signs.
• Fixing a typo is not an update. An update date should mean something changed that makes the text worth reading again.
• For pages where a date makes no sense (a price list, a contact page, the home page), do not invent one. The finding is site-level, so articles and news, where a date belongs, will silence it.

And a last point that matters more than this whole finding: if adding dates turns up content whose truthful date would be three years old, that is a finding in itself. Markup will not fix it.