JSON-LD里@type写成简写，AI抓取时直接把价格字段截断了

上周排查自家商品页的GEO抓取异常，发现一个很隐蔽的坑：结构化数据里 @type 用了简写，导致AI在解析时把后面的 offers.price 字段直接截断。

现象

同一批商品页，用 Google Rich Results Test 检测全部通过，Schema 校验也没有报错。但把页面 URL 丢给三个AI搜索接口（这里不点名），返回的答案里商品价格全部缺失，或者显示为 null。

排查过程

1. 先排除页面速度因素：LCP 稳定在 1.8s，CLS 0.02，排除渲染阻塞。
2. 抓取日志对比：AI 爬虫的 UA 请求返回 200，HTML 完整，没有 304 缓存问题。
3. 逐字段比对：把 JSON-LD 拆出来，发现 @type 写的是 Product 没问题，但嵌套的 offers 里 @type 写成了 Offer——这个本身合规。问题出在字段顺序：price 被放在了 priceCurrency 后面，且 @type 和 price 之间隔了 6 个字段。

根因

拿三个不同模型版本的解析器做 A/B 测试（同一份 JSON-LD，只改字段顺序）：

• 顺序 A：@type → price → priceCurrency → availability，三个接口价格提取成功率 100%。
• 顺序 B：@type → availability → priceCurrency → price（中间插入 3 个无关字段），成功率掉到 40%，其中两个接口直接返回空。

推测是部分解析器对 JSON-LD 做流式截断时，字段深度超过阈值就丢弃尾部。不是语法错误，是解析策略差异。

修复方案

1. 把所有 offers 对象里的 price 和 priceCurrency 提到 @type 之后前两位。
2. 删掉 offers 里非必需的 @id 和 url 字段，减少嵌套深度。
3. 加了一条监控：每天用固定 UA 拉一次 JSON-LD，对比字段顺序和价格提取率，异常就告警。

验收口径提醒

这次踩坑还带出一个老问题：验收时得先定义分母。之前我们算「结构化数据完整率」用的是「字段存在数 / 总字段数」，但 AI 实际只消费前 N 个字段，按这个口径算出来 98% 完整，实际可用率只有 72%。后来改成「AI 实际提取到的字段数 / 我们期望它提取的字段数」，才对齐真实情况。

你们在测 JSON-LD 的时候，有没有遇到过字段顺序影响抓取结果的？尤其是 offers 嵌套超过三层的情况，解析器行为差异挺大的，想听听大家的实测数据。