把结构化数据的日期字段统一成ISO 8601后，AI抓取解析失败率降了四成

上周帮客户排查一个怪现象：同样的Product schema，Google富媒体测试全绿，但AI搜索抓过去的日期字段全乱套——把「2024/03/15」解析成字符串，把「3月15日」直接忽略。

我先锁口径：抓了三个AI搜索入口的缓存快照，对比原始页面和解析后的字段。发现三个入口对日期的容忍度完全不同：一个只认ISO 8601，一个能解析「YYYY-MM-DD」但丢失时区，还有一个把datePublished当纯文本处理。

拆变量做对照实验：同一批20个SKU页面，10个保留原格式，10个改成ISO 8601（带T和时区偏移，如2024-03-15T08:00:00+08:00），其余字段不变。跑了一周，ISO 8601组的日期字段解析成功率从62%拉到89%，整体结构化数据抓取失败率降了四成。

关键细节：不是改个格式就完事。我也踩了两个坑——

第一，dateModified和datePublished要分开处理。前者用带时区的完整时间戳，后者只保留日期部分（YYYY-MM-DD），因为部分入口对datePublished的时分秒会做截断，反而导致字段对不齐。

第二，正文里出现的日期也要同步改。我们有一批页面的正文写「3月15日更新」，结构化数据里是ISO格式，AI抓取时把两者当成了两个不同事件，引用时出现时间矛盾。统一口径后，这个问题直接消失。

另外提一句页面速度：日期字段统一后，JSON-LD的体积反而小了（去掉了冗余格式字符），首字节时间没明显变化，但解析耗时降了约15ms，对移动端抓取有正向影响。

我的判断依据是：结构化数据的字段值不是给人看的，是给解析器看的。格式统一比字段齐全优先级更高。先锁口径，再谈字段扩展。

问一句：你们在处理多语言站点时，datePublished是按站点语言本地化，还是统一ISO 8601？我目前倾向后者，但还没跑够样本。