给结构化数据里的日期字段统一口径后，我发现AI摘要引用的时间戳全乱套

上周排查AI摘要引用不准的问题，顺手把全站结构化数据里的日期字段拉了个清单，结果发现一个挺低级的坑：同一个「发布日期」，Article 里用的是 ISO 8601 带时区的格式（2024-11-03T08:00:00+08:00），FAQPage 的 dateModified 却是纯日期（2024-11-03），面包屑里的 datePublished 又混进了本地化格式（2024年11月3日）。三种写法并存，人眼看没问题，但 AI 抓取解析时对时区的处理完全不一样。

我做了组对照：把同一篇长文的日期字段统一成带时区的 ISO 8601 后重新提交 sitemap，隔 48 小时看日志，AI 摘要里引用的「更新时间」从原来的随机漂移变成了稳定值。之前那个纯日期格式的 FAQPage，解析器默认按 UTC 零点算，跟正文里写的「11月3日上午发布」差了 8 小时，摘要里直接把这个时间点当成了「过时信号」处理。

更麻烦的是页面速度这块的耦合。我顺手用 PageSpeed Insights 跑了一遍，发现日期字段统一后，LCP 没变，但 TTFB 在首次抓取时高了 40ms 左右——怀疑是结构化数据块变大导致解析队列变长。把 JSON-LD 从内联挪到 head 末尾、压缩掉多余的空白字符后，这个差值回到个位数。所以我的判断是：日期口径统一是第一步，但得同时盯住结构化数据块对首屏解析的阻塞，不然修了引用准度、丢了速度分。

现在我的验收流程是：先锁死所有 date 字段的格式口径（统一 ISO 8601 + 时区），再跑一轮 Lighthouse 确认结构化数据没拖慢首屏，最后才看 AI 摘要的引用时间戳是否稳定。三步里任何一步不过，都不签字。

想问下各位，你们站里 dateModified 和 datePublished 的口径是怎么定的？有没有遇到过 AI 摘要把「修改时间」当成「发布时间」来引用的？