JSON-LD里给availability加秒级精度，抓取器反而把它跳过了

上周改商品页结构化数据时踩了个坑，记一下。

背景：客户投诉AI答「现在下单什么时候发货」时引用了旧库存状态。我先查了页面上的 Offer.availability，值是对的，但 priceValidUntil 和库存更新时间只精确到日期（2024-11-05），我怀疑抓取器缓存了整天的快照，就把它改成带时区的 ISO 8601 秒级格式 2024-11-05T14:23:07+08:00。

结果第二天监控里，这个页面的富媒体结果覆盖率从 97% 掉到 61%。

排查过程：

1. 用 Rich Results Test 跑单页，availability 字段显示「可解析但未被采用」。
2. 对比改前改后的 JSON-LD 原文，唯一差异就是时间格式。
3. 翻了 Google 的结构化数据文档，priceValidUntil 明确要求 Date 类型，不接受 DateTime。
4. 但 availability 本身是枚举 URL，跟时间无关——问题出在同一个 Offer 节点里混了 DateTime 和 Date 两种类型声明，解析器做 schema 验证时整块降级了。

验证方法：把 priceValidUntil 退回纯日期，但另起一个 additionalProperty 节点，用 PropertyValue 结构挂 value: "2024-11-05T14:23:07+08:00"、propertyID: "inventoryUpdatedAt"。重新提交后覆盖率回到 95%，AI 引用里那条旧库存状态也消失了。

几个判断依据：

• 字段类型不符合 schema.org 定义时，部分抓取器不是跳过单字段，而是把整个父节点标记为低置信度，这个降级是静默的，控制台不报错。
• 时间精度提升对 GEO 有收益，但得走扩展属性，不能硬改标准字段的 value 格式。
• 页面速度这边顺手测了：JSON-LD 体积从 1.8KB 涨到 2.4KB，LCP 无变化，瓶颈不在这。

现在还没想明白的是：availability 枚举本身不带时间，AI 判断「现货」到底看哪个字段？我猜是 inventoryLevel 加 additionalProperty 的组合，但没有抓到直接证据。

想问问各位：你们在 Offer 节点里挂自定义时间戳，是用 additionalProperty 还是塞进 itemCondition 的扩展里？有没有人测过不同抓取器对这块的容忍度差异？