dateModified schema: 38 of 195 pages never showed the date, and 74 of 81 disagreed with their own server

What does Google require of a dateModified schema value?

Two pages carry the rules and they are worth separating, because one is about the markup and the other is about the page. Google's Article structured data reference, last updated 2026-09-08, lists datePublished and dateModified as recommended rather than required properties, defines each as a date and time "in ISO 8601 format", and adds that "we recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot". It also notes that the Rich Results Test does not warn about either property, which matters more than it sounds: a tool that stays silent on an optional field is a tool that will not catch any of the defects below.

Google's publication dates documentation, last updated 2025-12-10, is the one that constrains the page rather than the markup. It asks site owners to "add a user-visible date to the page and feature it prominently", states that "the date is required; the time is not", and then sets the rule this measurement tests against: "make your dates and times consistent. Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values." It also says not to "specify future dates, or the date of the action described on the page", and explains why it hedges at all, which is that "Google doesn't depend on a single date factor because all factors can be prone to issues".

Schema.org's definition of dateModified is narrower still: "the date on which the CreativeWork was most recently modified or when the item's entry was modified within a DataFeed", with Date or DateTime as the expected types. Date in that vocabulary means an ISO 8601 date. So three primary sources agree on the shape, one of them asks for agreement with the visible page, and none of them asks for anything a content management system cannot emit automatically. The interesting question is not whether the rules are reasonable. It is what sites actually ship.

How many pages declare a date, and on what type?

228 of the 922 readable interior pages declared at least one date, across 338 dated nodes. 192 of the 228 carried both a datePublished and a dateModified, 32 carried a datePublished alone, and 4 carried a dateModified alone, which is the odder of the two one-sided cases: a page claiming to have been changed on a date it will not say it was created.

The type carrying the date is not what the guidance assumes. WebPage led at 93 nodes, ahead of BlogPosting at 86, NewsArticle at 59 and Article at 58, with PodcastEpisode at 30 and CollectionPage at 9. Google's dates guidance is written around a "subtype of CreativeWork", which WebPage is, so none of this is wrong. It does mean that 73 of the 228 dated pages were not an Article subtype at all, and a reader hunting for article freshness by looking only at Article nodes would miss a third of the dates in this corpus.

Looking the other way is less comfortable. 162 of the 922 pages typed themselves as an Article subtype. 35 of those 162 carried no dateModified anywhere on the page, and 7 carried no date of any kind. An Article with no date is not a specification violation, since both properties are recommended rather than required, but it is a page asserting it is a dated work and then declining to say when. That is the same gap author schema showed on the same corpus, and it has the same cause: the type is emitted by a template and the properties are filled in by a human who did not.

The dated pages were real pages rather than stubs, with a median of 1,290 words of extracted prose. They cluster where you would expect: 35 in the news stratum, 33 in SaaS, 25 in the WordPress small-business stratum, 20 in education and 16 in healthcare. 142 came from the industry frame and 86 from the platform frame, so this is not one content management system's behaviour leaking into every number.

38 pages declared a date no reader could see

This is the finding the documentation points straight at, so the test was built to be hard to argue with rather than impressive. For each page with a dateModified that parsed, Lantad extracted the visible text, stripped script and style content and markup, and asked one question: does the four digit year of that date appear anywhere in the text at all? Not in the right format, not near a label, not prominently. Anywhere.

On 38 of the 195 pages it did not. A date whose year is absent from the entire visible page cannot be the "user-visible date" the guidance asks for, in any language and under any date format, because the digits are not there to find. The hosts include gov.uk, berkeley.edu, abc.net.au, fastly.com, grist.org, italia.it, australia.com, germany.travel, brex.com and travelers.com, alongside a long tail of small-business sites in the WordPress stratum such as slickfish.com, landscapevermont.com and iowacityanimalclinic.com. The same test on datePublished is worse: of 223 parseable values, 61 had no year anywhere in the visible text, archives.gov and docker.com among them.

A looser test gives a larger number and a weaker claim, which is why it is reported second. Restricting to the 191 pages whose text reads as English, and looking for the date rendered in any of eighteen common formats, 86 carried the date visibly and 105 did not. That 105 is the more realistic figure for how often the markup date is invisible, and it is also the one to treat with care: a non-English month name, a date split across elements, or a format outside the eighteen would all land a page in it wrongly. The 38 is the number that survives any objection.

Why it matters is narrower than the usual claim, and worth stating precisely. Nobody has shown that an answer engine ranks on a date, and this post does not. What a mismatch costs is certainty. A machine reading the page sees one date in the markup and no corroboration in the prose, which is exactly the condition Google says it hedges against when it declines to depend on a single factor. The same structure shows up wherever markup and page are allowed to drift apart, from FAQ answers that are not on the page to canonical tags naming a URL the page was not served at. A claim only a machine can read is a claim nobody checks.

74 of 81 pages disagreed with the Last-Modified header their own server sent

99 of the 228 dated pages sent a Last-Modified response header, and on 81 of those the header and a non-empty dateModified could both be parsed into a day. 7 agreed. 74 did not, and the direction is the part worth reporting: on all 74 the header was the later of the two. Not one page in the corpus claimed a modification date more recent than the date its own server reported. The median distance was 88 days and the tail is long: 4,524 days on slickfish.com, whose markup says 15 May 2014 while its server answered with 3 October 2026, 2,180 on berkeley.edu, 2,125 on growforagecookferment.com and 1,443 on archives.gov.

The honest reading is not that 74 sites are lying. MDN's reference for Last-Modified describes it as "a date and time when the origin server believes the resource was last modified" and notes that "it is less accurate than an ETag for determining file contents". On a dynamically assembled page the origin frequently believes the resource was modified at the moment it was assembled, which is why so many of these headers read as the day of the request. The header is a cache validator, not an editorial claim, and treating it as one would be the same error in the other direction.

What the one-sidedness does establish is that these two fields are not generated from the same fact. Where they agreed, they agreed because something tied them together; where they disagreed, the schema value was always the older, which is the signature of a human-entered or build-time date sitting beside a machine-generated one. That is a different problem from sitemap lastmod disagreeing with the same header on 340 of 440 pages, though it has the same shape, and it is why 28 pages in this set declared a dateModified more than two years before the request while serving a header from this week.

For a site owner the practical test is cheap and does not require either of these numbers. Ask what writes your dateModified, ask what writes your visible date, and ask whether those are the same thing. If the answer is a template default, a theme setting, or nobody, the field is decoration. Our methodology describes how we read markup rather than trust it, and what GPTBot sees will show you the delivered HTML a fetch-only reader gets, which is the only copy of your page that any of this is true of.

14 values on 9 hosts were not dates

Both Google's Article reference and schema.org's Date type ask for ISO 8601. 14 of the 338 date values in this corpus, on 9 hosts, were something else, and the specific failures are more instructive than the count.

Two were the empty string. nikkei.com declares a NewsArticle with datePublished 2026-10-04T05:00:00+09:00 and dateModified "", and hdfcbank.com declares a BlogPosting with datePublished "Sep 18,2026" and the same empty dateModified. An empty value is worse than an absent one, because the property is present, so a validator checking for presence passes it and a parser reading it gets nothing.

Three published a day that cannot be resolved without knowing the country. bhf.org.uk carries 01/10/2026 10:59:04 on a NewsArticle about an obituary, which is 1 October under British convention and 10 January under American. santander.com publishes 29-09-2026 15:30 CEST, which puts a timezone abbreviation where ISO 8601 wants an offset. The rest are locale strings that a template rendered for display and then also emitted as data: practo.com with "2 March, 2020" and "30 April, 2021", mejuri.com with "Tue Mar 11 2025", uxcel.com with "Jan 09, 2025", whipsaw.com with "Sep 28, 2026", and buk.cl with "mayo 18, 2026, 2:52:07 a. m." in Spanish.

Three smaller defects round it out. 8 values on 5 hosts carried a time with no timezone offset, including zendesk.com and siigo.com, which by Google's own note means Googlebot's timezone is assumed rather than the publisher's. On 4 pages the dateModified was earlier than the datePublished: germany.travel, metlife.com, outseta.com and scalekit.com, the last two by under a minute, which reads like two timestamps taken at different points in one build rather than an editorial claim. germany.travel is the clearest case, declaring a datePublished of 2026-10-04 00:01:00, the day of our request, against a dateModified of 2026-09-23. And nothing was future-dated, which is the one rule in the guidance that this corpus kept.

None of these would be caught by a tool that only asks whether the property exists. That is the argument for reading the value, and it is the same argument the schema markup validator finding made about 117 of 612 home pages and the missing @id finding made about 313 of 615. A property present and unusable is the normal failure mode of structured data for AI, not an exotic one.

What this does not measure

This is a census of delivered markup on one page per host on one day. It is not a measurement of crawler behaviour, and the distance between those two is where most claims about freshness go wrong.

No engine was queried. No server logs were held. No page was requested twice, so a site that rewrites its dateModified to the current day on every response is indistinguishable here from one that updated genuinely, and only one page in the whole corpus, trustmrr.com, happened to declare a dateModified matching the day of our request. Nothing in these figures supports a claim that ChatGPT, Google's AI Overviews or any other reader weights a date, prefers a fresh one, or notices a mismatch. Lantad itself does not read one: the string DATE_FIELDS appears nowhere in core/src/schema.ts, and SCHEMA_REQUIREMENTS there asks an Article for exactly one property, which is headline.

The method has four limits worth naming. One interior page was read per host, chosen by following the home page's own links and preferring a content-looking path, so this is a sample of each site's interior rather than its archive. No JavaScript was executed, so a date injected client side is absent, and 27 of 404 home pages gained structured data when a browser ran them, so that gap is real and measured. The visible-text test reads the extracted prose of the delivered HTML, so a date rendered into an image or a shadow root would be missed. And the 497 hostnames that returned no readable interior page are absent from every rate here, which biases the set toward sites that answer a crawler at all.

The corpus is also an editorial sampling frame assembled for platform and industry coverage rather than a random draw, the same frame behind our published research and our earlier counts of AI crawler access. Every number above describes these 1,419 hostnames on 4 October 2026 and nothing wider. What generalises is not the proportion but the mechanism: a date in the markup is written by one process, a date on the page by another, and nothing in a content management system forces them to agree. That is checkable on your own site in a minute, which is more useful than any figure here, and it is the kind of gap that decides whether your prose and your markup tell a reader the same story.