Three captured pages scored full marks for schema, and one of them carried a date

What five captured pages carried, and what they did not

The count was run over the stored raw.html of each fixture with the same HTML parser the scanner itself depends on, then repeated over the stored rendered.html. Five things were counted: time elements and how many of them carry a datetime attribute, JSON-LD script blocks and how many of those hold any key named datePublished, dateModified, dateCreated or uploadDate, itemprop attributes naming a publish or modify date, and meta tags whose name or property mentions a date.

The totals across all five pages are one, four, one, zero and zero. One time element exists in the entire set. It is on the MDN HTML reference page, it carries datetime 2025-12-22T01:06:28.000Z, and that is 205 days before the capture ran. Four JSON-LD blocks exist across three pages, which matches the earlier count of JSON-LD on these same captures, and exactly one of those four holds a date. That one is Wikipedia's Article node, carrying datePublished 2001-04-27T04:55:28Z and dateModified 2026-07-02T11:51:30Z, a span of just over 25 years and a last change 13 days before we fetched it. No page in the set uses microdata for a date. No page in the set carries a meta tag naming one, so there is no article:published_time and no article:modified_time anywhere.

Two of the five pages therefore carry a machine readable date, by two different mechanisms, and neither page uses the other's. MDN uses the HTML time element, whose reference documentation says it may include the datetime attribute to translate dates into machine readable format, and MDN ships no JSON-LD at all. Wikipedia uses structured data and ships no time element. The three commercial homepages in the set, astro.build, gymshark.com and webflow.com, carry neither. That is not automatically a fault, and the section on what we did not measure says why, but it does mean a parser reading those three pages has nothing to date them by. Our methodology page describes what the capture stores and what it discards.

Where a date can reach a crawler, and which routes this scan reads

A date can travel from a server to a machine by at least five routes, and they are independent of one another. It can be printed in the visible prose, where it is readable but unlabelled and has to be inferred from the words around it. It can sit in a datetime attribute on a time element, which is the one HTML mechanism designed for exactly this. It can sit in structured data as datePublished or dateModified, where the schema.org definition of dateModified names it as the date on which the resource was most recently modified. It can arrive in the Last-Modified response header, which never appears in the page body at all. It can appear as a lastmod element in a sitemap, which is a different document entirely.

Nothing forces those five to agree, and nothing forces a site to use more than one. A page can print a visible Updated August 2026 in its footer while its only structured date says 2019, and no part of the stack objects. That is precisely what Google's guidance is written to prevent, and the next section quotes it.

The five routes also fail differently, which is why counting them separately is worth the trouble. A visible date survives any parser but has to be located and interpreted, and a page full of other dates makes that harder rather than easier. A datetime attribute is unambiguous but says nothing about whether the date is a publication, a modification or something else entirely, because the element does not carry that meaning on its own. A structured date names which of the two it is and is the only one of the three in-page routes that does. A response header is authoritative about the file and frequently wrong about the content, since a rebuild can change the header without changing a word. A sitemap entry is easy to generate and equally easy to generate falsely, which is why it is treated as a hint everywhere it appears.

What this scan reads is narrower than the five. It fetches robots.txt, it fetches the page as a baseline and again under each crawler token, and it stores status codes, redirects, the raw body and the rendered DOM. It does not store response headers, so the Last-Modified route is not merely unread here, it is not in the capture at all. It does not walk the sitemap. So of the five routes, this scan physically holds the evidence for three and discards the other two, which is a limit of the capture rather than a judgement about which route matters. If you want to see what a specific AI crawler is handed for one of your own pages, that is what our bot page documents about how we identify ourselves when we ask.

What Google's own documentation asks a page to carry

Three Google Search Central pages bear on this, and each carries its own stated update date in its footer. All three were read on 21 August 2026 and the quotations below are verbatim from them. This is reporting rather than measurement: Lantad has not tested what any of these does to a ranking or a citation.

Google's byline dates documentation, carrying Last updated 2025-12-10 UTC, opens with a caution against reading too much into any one signal. It states: "Google doesn't depend on a single date factor because all factors can be prone to issues. That's why our systems look at several factors to determine our best estimate of when a page was published or significantly updated." The same page asks site owners to add a user-visible date to the page and feature it prominently, to label it with text such as Publish or Last updated, and then to keep it consistent with the markup: "Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values." It also asks publishers to minimize other dates on the page, which is the instruction most often broken by a sidebar of recent articles.

Google's Article structured data documentation, also carrying Last updated 2025-12-10 UTC, is where the two properties are defined, and it places both under the heading Recommended properties rather than required ones. Its wording for dateModified is: "The date and time the article was most recently modified, in ISO 8601 format. We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot." The datePublished entry is worded identically apart from naming first publication.

Google's review snippet documentation carries a more recent Last updated of 2026-07-24 UTC and lists datePublished under Recommended properties for Review, defined as "The date that the review was published, in ISO 8601 date format." That page matters here because one of our five captures ships six Review nodes, and the section after next counts what they carry. Nothing on these pages speaks for the AI answer surfaces beyond Google's own; what we can say about those is in the guide to getting cited in AI Overviews.

What this scanner requires of structured data, and it is not a date

Here is the part that is inconvenient for us. The requirements this scanner grades JSON-LD against live in one exported constant, SCHEMA_REQUIREMENTS in core/src/schema.ts, and they are deliberately short. Article requires headline. Organization requires name and url. Product requires name. FAQPage requires mainEntity. BreadcrumbList requires itemListElement. That is the whole table. Five types, seven required properties between them, and not one of them is a date.

An entity whose type is not in that table is not failed, either. It is scored 1 with the comment that there is nothing further to require at the entity level, so an unrecognised type costs nothing. A page whose entire structured data is unrecognised types is capped, but a page carrying one recognised business type beside anything else is not. The result is visible in the stored golden files: gymshark.com, webflow.com and en.wikipedia.org all score exactly 1.0 on the schema sub-score, and the schema sub-score is worth 10 points of the 100 in the composite, with parity at 50, access at 25 and structure at 15.

So the scale says those three pages have nothing left to fix in their structured data, and two of the three do not say when anything on them was written. That is a real limit of the grade and not a rounding error, and it is the same class of gap as the one recorded when text hidden in a hydration payload scored the same as no text at all. A requirements table is a design decision by whoever wrote it, not a measurement of what matters, and this post is not evidence that adding datePublished would move any score anywhere. It is evidence that our own scale is currently blind to the question, which is worth stating plainly on the site that sells the scale. What the scale does measure, and how the weights were chosen, is set out in the research page and applies the same way on a hosted storefront as it does anywhere else, which is what the Shopify guide covers for that stack. Whether a date belongs in the requirements table at all is a generative engine optimization question we have not answered with evidence, and we are not going to answer it by assertion.

Six review nodes, an author on each, and no date on any

One page in the set is worth pulling apart on its own. The webflow.com capture ships a single JSON-LD block holding 96 typed nodes, which is the same count an earlier post arrived at from the other direction. Among those nodes are six of type Review and one AggregateRating. Parsed key by key, each of the six Review nodes carries exactly four keys: @type, author, reviewBody and publisher. There is no datePublished on any of them, and no reviewRating either.

Set that against the Google page quoted two sections up, which lists datePublished under Recommended properties for Review and defines it as the date the review was published. A review is the case where a date is not a formality. The text of a testimonial about a software product says nothing about whether it was written last month or in 2019, and the node offers no way to tell. Six of them sit on the page in that state, and the page still takes a perfect schema sub-score from us, because Review is not in our requirements table and Organization, which is also present, is complete.

None of this says webflow.com is doing anything wrong. Their nodes are well formed, they parse, and datePublished is recommended rather than required by the publisher whose guidance we quoted. What it does show is how far a page can be from carrying a usable date while every automated check that looks at it, ours included, returns a pass. That is the same shape as the finding that an h1 inside a header element counted as no h1 at all: the check answered the question it was written to answer, and the question was narrower than the reader assumed. Whether an undated testimonial affects how a model resolves who a company is belongs to entity confidence, which is a different measurement from this one, and what actually gets quoted back to a user is the subject of the guide to being cited in ChatGPT.

What this count did not measure, and why it matters here

The counts above are narrow on purpose, and the narrowness cuts against the conclusion in places, so it is stated rather than buried. We counted markup and nothing else. A page can print Last updated 4 August 2026 in plain words in its footer and carry no attribute at all, and that page would appear in our table as a zero while a human reader is perfectly well served. Four of the five captures are homepages or reference pages rather than dated articles, and Google's byline date guidance is written for content where a date is part of the meaning. A shop's front page is not obviously that.

The capture also does not store response headers, so we cannot say what any of the five servers returned in Last-Modified, and it does not fetch sitemaps, so lastmod is outside the evidence too. Five pages captured once is a small sample and a single moment: nothing here supports a claim about the web, only about these five files. Above all, this post contains no test of effect. Nothing measured here shows that adding datePublished changes whether an answer engine cites a page, and the honest position is that we have not run that experiment.

What the count does support is narrower and still worth having. On these five pages the schema sub-score and the presence of a machine readable date are close to unrelated: the page carrying the most complete date information scores 1.0, another page carrying a date scores 0.0, and two pages carrying none score 1.0. A scale that separates those cases would be a different scale from the one we ship today. The same discipline of counting what is there rather than what should be there produced the alt text count over 466 captured images and the sixty crawler probes where eleven got a different answer. If you want the broader sample rather than these five files, that is what the crawlability study holds, and the vocabulary this post leans on is defined under AI visibility.