Direct answer: A zero-request parse of 25 homepages: only 5 pages carry JSON-LD (5 blocks), and 3 of those blocks concatenate two objects and cannot be parsed. Of the 2 parseable blocks, only 1 declares dateModified (E24, type WebPage, 2024-07-14). article:modified_time, <time datetime> and visible “last updated” all scored zero. Any structured update date appears on just 1 of 25 homepages.
Study 22 covered copyright year, lastmod and homepage dates; study 24 checked their stability over a day. This one adds the fourth signal: how many pages declare an update date at all, where it lives, and whether it parses.
Method: four places, zero requests
Using the 25 cached homepages from study 4 (2026-10-31 to 11-01) with no network request, each page is checked in four places: JSON-LD dateModified / datePublished, meta modified / last-modified / date, <time datetime>, and visible “last updated” text.
| Place | Parsing | Boundary |
|---|---|---|
| JSON-LD | json.loads per block, expanding @graph and arrays | Failures counted separately; first dateModified / datePublished only |
| meta | <meta> name/property plus content | Attribute order irrelevant; empty content ignored |
<time> | Only tags with datetime | A date in the tag text does not count |
| Visible text | Scripts/styles removed, then “last updated” patterns | Only dates starting with the target year |
Result: 5 JSON-LD blocks, 3 unparseable
| Place | Pages | Blocks | Note |
|---|---|---|---|
| Any JSON-LD | 5 | 5 | E09, E12, E14, E23, E24 |
| Parseable JSON-LD | 2 | 2 | E12 (4 entities, no dates), E24 (6 entities, WebPage dates) |
| dateModified | 1 | 1 | E24: 2024-07-14T06:24:39+00:00, type WebPage |
| datePublished | 1 | 1 | E24: 2023-10-13T05:17:06+00:00 |
| meta modified | 0 | 0 | No article:modified_time or last-modified |
<time datetime> | 0 | 0 | No time tag with datetime on any homepage |
| Visible “last updated” | 0 | 0 | No recognisable visible update date |
| Any structured update date | 1 | — | E24 only |
Why three blocks fail: two objects pasted together
E09, E14 and E23 all use the same shape: two complete {...} objects back to back, with no array brackets and no @graph wrapper. The first object alone is valid, but the block as a whole is not valid JSON. A common cause is a CMS serialising several entities separately and a template concatenating them without [ ] or @graph.
The consequence is direct: a parser may discard the whole block, even if the first object contains WebSite or Organization. This is not a question of “having JSON-LD” but of “having valid JSON” — the study-23 local checker also reports parse failures as errors.
The only dateModified: WebPage, not an article
E24's dateModified is 2024-07-14 and its type is WebPage, not Article or BlogPosting. It describes the page object, not an article revision, so treating it as “when the homepage was last updated” still needs care.
More interestingly, the same site carries three different years: footer copyright 2023, JSON-LD dateModified 2024, and sitemap lastmod 2026-10-28. All three can be called “a date”, but they mean different things; this study records the difference and does not decide which is true.
Why homepages rarely carry an update date
- A homepage is usually not an article: CMSs often emit
dateModifiedonly from article templates. - Nothing requires it: structured dates are optional; many templates output only Organization and WebSite.
- Written but broken: 3 of the 5 blocks here are invalid because of concatenation.
- Visible dates are rarer still: B2B homepages seldom show “last updated” to visitors.
So “no dateModified on the homepage” does not mean “the site never updates”; it only means this location holds no parseable claim.
What this means for acceptance
- Validate JSON-LD before reading fields. Concatenated objects invalidate the block and are as unusable as no markup at all.
- Accept homepages and article pages separately. A missing dateModified on a homepage is normal; article pages are the better place to check revisions.
- Record the four places separately. JSON-LD, meta, time and visible text do not substitute for one another and have different hit rates.
- Do not treat dateModified as sole update evidence. It is a page claim; version records or a content diff still have to back it up.
- Show conflicts side by side. For E24's 2023 / 2024 / 2026, list all three rather than picking one.
Limits
- Homepages only: article and product pages may differ; no generalisation.
- Cached, zero-request: captures date from 2026-10-31 to 11-01, not today.
- Regex plus JSON parsing: no JavaScript execution, so script-injected JSON-LD is invisible.
- Tiny effective sample: only 5 pages have JSON-LD, 3 blocks are invalid, leaving 2 to compare.
- 25-site pilot: no industry claim and no quality judgement.
Data and reproduction
Anonymised data: equipment-date-fields-pilot-2026.csv (25 rows: sample_id, JSON-LD block count and validity, types, dateModified / datePublished, meta, time, visible updates, agreement). The repository keeps docs/research/2026-11-date-fields-pilot.csv.
Parser: scripts/date_fields_probe.py; unit tests: scripts/test_date_fields_probe.py (20 tests, no network). Run:
python -m unittest scripts.test_date_fields_probe
Related: the freshness-signal pilot (three-signal cross-section), the one-day recheck (field stability), the freshness checker (same rules locally), and the HTTP date headers pilot (Last-Modified and cache headers).
Sources and definitions
- schema.org
dateModified: schema.org. - JSON-LD 1.1: w3.org.
- Sample and rules: study-4 homepage cache and the study-22 parsing definitions; zero network requests.