直接答案：零请求解析 25 个首页：只有 5 个页面有 JSON-LD（共 5 段），其中 3 段直接拼接两个对象、无法解析；可解析的 2 段里，只有 1 段声明 dateModified（E24，类型 WebPage，2024-07-14）。article:modified_time、<time datetime>、可见“更新于”三类命中全部为 0。任何结构化更新日期只命中 1/25。
第 22 期看了版权年份、lastmod 与首页日期，第 24 期看了它们一天内的稳定性。这一期补第四个信号：页面自己声明的“更新日期”到底有多少、写在哪、能不能解析。
方法：四个位置，零请求
沿用第 4 期缓存的 25 个首页 HTML（2026-10-31 至 11-01），不发起任何网络请求。对每个页面检查四个位置：JSON-LD 的 dateModified / datePublished、meta 的 modified / last-modified / date、<time datetime>、以及可见文本里的“更新于 / 最后更新 / last updated”。
| 位置 | 解析方式 | 判定边界 |
|---|---|---|
| JSON-LD | 逐段 json.loads，展开 @graph 与数组 | 解析失败单独计数；只取第一个 dateModified / datePublished |
| meta | 扫描 <meta> 的 name/property 与 content | 属性顺序不限；内容为空不计 |
<time> | 只取带 datetime 的标签 | 文本里的日期不算 |
| 可见文字 | 去掉 script/style 后匹配“更新于”等 | 只认目标年份开头的日期串 |
结果：5 段 JSON-LD，3 段解析失败
| 位置 | 命中页面 | 命中段落 | 说明 |
|---|---|---|---|
| JSON-LD 任意 | 5 | 5 | E09、E12、E14、E23、E24 |
| JSON-LD 可解析 | 2 | 2 | E12（4 个实体，无日期）、E24（6 个实体，WebPage 日期） |
| dateModified | 1 | 1 | E24：2024-07-14T06:24:39+00:00，类型 WebPage |
| datePublished | 1 | 1 | E24：2023-10-13T05:17:06+00:00 |
| meta modified | 0 | 0 | 没有 article:modified_time 或 last-modified |
<time datetime> | 0 | 0 | 首页没有带 datetime 的 time 标签 |
| 可见“更新于” | 0 | 0 | 没有可识别的可见更新日期 |
| 任何结构化更新日期 | 1 | — | 仅 E24 |
3 段为什么解析失败：两个对象直接拼在一起
E09、E14、E23 的 JSON-LD 都是这种形态：两个完整的 {...} 对象首尾相接，既没有数组方括号，也没有 @graph 包裹。单看第一段完全合法，但整段交给解析器就是非法 JSON。常见原因是 CMS 对多个实体分别序列化后直接拼接，模板没有补上 [ ] 或 @graph。
后果很直接：搜索引擎拿到整段后可能整段忽略，即使第一个对象里写了 WebSite 或 Organization。这不是“有没有 JSON-LD”的问题，而是“这段 JSON 是否有效”的问题——第 23 期的本地检查器也把解析失败单列为错误。
唯一的 dateModified：WebPage，不是文章
E24 的 dateModified 是 2024-07-14，类型是 WebPage，不是 Article 或 BlogPosting。它描述的是页面对象，不是某篇文章的修订时间；把它直接当“首页最近更新”仍然要谨慎。
更有意思的是同一个站点有三个不同年份：页脚版权 2023、JSON-LD dateModified 2024、sitemap 最新 lastmod 2026-10-28。三个字段都能叫“日期”，含义却不同；本期只记录差异，不推断哪个真、哪个假。
为什么首页的更新日期这么少
- 首页通常不是文章：CMS 往往只在文章模板输出
dateModified，首页模板不输出。 - 没有约定就不写：结构化日期不是必填字段，很多模板只放 Organization 和 WebSite。
- 写了也可能坏：本次 5 段里 3 段因拼接而无效。
- 可见日期更少：B2B 首页很少把“最后更新”直接展示给访客。
因此，“首页没有 dateModified”不能反推“站点不更新”；它只说明这个位置没有可解析的声明。
对验收的启示
- 先验 JSON-LD 是否有效，再谈字段。 拼接多个对象会让整段失效，和“没写”一样不可用。
- 把首页与文章页分开验收。 首页没有 dateModified 是常见现象，文章页才更适合检查修订日期。
- 四类位置分别记录。 JSON-LD、meta、time、可见文字互不替代，命中率也不同。
- 不要把 dateModified 当唯一更新证据。 它是页面声明，仍需版本记录或内容 diff 佐证。
- 冲突要并列展示。 像 E24 的 2023 / 2024 / 2026 三个日期，应同时列出而不是取其一。
局限
- 只测首页：文章页、产品页可能完全不同，本期不外推。
- 零请求复用缓存：缓存时间是 2026-10-31 至 11-01，不代表今天。
- 正则 + JSON 解析：不执行 JS，脚本注入的 JSON-LD 看不到。
- 有效样本很小：只有 5 页有 JSON-LD，3 段无效，能比较的只剩 2 段。
- 25 家 pilot：不外推行业总体，也不评价站点质量。
数据与复算
匿名数据：equipment-date-fields-pilot-2026.csv（25 行：sample_id、JSON-LD 段数与有效性、类型、dateModified / datePublished、meta、time、可见更新、是否一致）。仓库内为 docs/research/2026-11-date-fields-pilot.csv。
解析逻辑：scripts/date_fields_probe.py；单元测试 scripts/test_date_fields_probe.py（20 项，无网络）。运行：
python -m unittest scripts.test_date_fields_probe
配套：新鲜度信号 pilot（三个信号横截面）、约 1 天复测（字段稳定性）、新鲜度信号检查器（同规则本地工具）、HTTP 日期头 pilot（Last-Modified 与缓存头）。
数据来源与口径
- schema.org
dateModified：schema.org。 - JSON-LD 1.1：w3.org。
- 样本与规则：第 4 期首页缓存、第 22 期解析口径；零网络请求。