结构化数据上线前，我把JSON-LD用爬虫跑了一遍才发现字段冲突

上周给一个客户做结构化数据上线，差点翻车。

事情是这样的：产品页的 JSON-LD 里同时挂了 Product 和 FAQPage 两个 schema，前端同学分开写的，各自测试都过。合并部署到预发环境后，我用 curl 拉了一遍页面源码，把 <script type="application/ld+json"> 里的内容 parse 出来一看，Product.offers.price 是 1299（number），但 FAQ 里那段问答的正文写的是「1299 元起」，还有个 priceCurrency 漏了。

这三个问题单看都不严重，叠一起就麻烦了：

1. 类型不一致：number 和 string 混用，解析器行为不可控。有的会 fallback 到默认值，有的直接丢字段。
2. 正文和结构化字段对不上：FAQ 说「元起」，offers 是固定价。AI 抽取时到底信哪个？实测下来，正文权重和结构化字段权重在不同引擎里不一样，这种冲突就是给抽取器挖坑。
3. 必填字段缺失：priceCurrency 不写，跨区域展示时货币符号会乱。

我把验证流程固化成三步，分享下：

第一步：源码级 parse，不看渲染结果

很多人用浏览器插件看结构化数据，看到绿勾就放心了。但插件读的是渲染后的 DOM，SPA 场景下首屏 HTML 里可能压根没有 JSON-LD。我直接用 curl + Python 的 json.loads 把每段 ld+json 抠出来跑一遍，字段类型、嵌套层级、必填项全过一遍 schema 校验。这一步能拦住 80% 的低级错误。

第二步：字段口径对齐正文

我写了个小脚本，把 JSON-LD 里的关键字段（name、price、ratingValue、availability）和页面可见文本做字符串比对。凡是结构化字段和正文描述有出入的，全部标红。比如 availability: InStock 但正文写「预售」，这种就是典型的字段口径漂移，AI 引用时容易答错。

第三步：页面速度卡阈值

JSON-LD 是内联在 head 里的，字段一多，首屏 HTML 体积就涨。我实测过，一个页面塞了 6 段 ld+json，总体积多了 40KB+，LCP 从 1.8s 掉到 2.4s。所以我的做法是：非核心 schema 改成异步注入，或者干脆拆到独立端点。核心的 Product 保留内联，FAQPage、BreadcrumbList 这些按需加载。

最后说个判断依据：结构化数据不是给引擎看的装饰品，是给抽取器提供确定性输入的。字段类型、单位、口径，任何一个模糊点，都会被放大成引用错误。所以我现在的验收标准就一条——ld+json 能被严格 parse，且每个字段都能在正文里找到唯一对应的表述。

想问下各位：你们做 JSON-LD 校验是手工跑还是接了 CI？我目前是本地脚本 + 上线前手动跑一遍，感觉还是容易漏，有没有更稳的自动化方案？