给JSON-LD里每个实体固定@id后，AI拼答案的串台率从22%掉到3%

上周给一个做工业传感器的客户做GEO排查，发现个挺隐蔽的问题：AI在回答「XX型号和YY型号区别」时，经常把两个型号的参数张冠李戴，比如把A的防护等级安到B头上。

我先怀疑是参数页本身写乱了，逐行核对了一遍，原文没问题。然后抓了页面渲染后的DOM，发现每个产品卡片的JSON-LD都是独立的Product块，但内部Organization、Brand、Manufacturer这几个节点全是内联展开的，也就是说同一个品牌名在20个Product块里各写了一遍。

关键点在这：AI聚合多个页面的实体时，靠的是节点标识做消歧。内联展开的节点没有稳定@id，模型在跨页面拼信息时很容易把A页面的Brand节点和B页面的Product节点错配。我做了个对照——给所有Product块里的Brand、Manufacturer、Organization统一加上绝对URL形式的@id（比如 https://example.com/#organization），Product自己的@id用带型号的canonical URL。改完重新跑了两周抓取。

数据：

• 抓取频次从每天2次涨到每天9~11次（这个之前聊过，不展开）
• 更关键的是AI答案的实体错配率，我拿40条涉及多型号对比的query跑批，改之前有9条把参数安错了型号（22.5%），改之后只剩1条（2.5%）
• 那1条我查了，是旧版页面没做301，还挂在CDN上

几个实现细节，踩过的：

1. @id必须是绝对URL，相对路径模型不认，别偷懒
2. 同一实体在不同页面引用时，@id字符串要完全一致，大小写、末尾斜杠都不能差
3. Product的@id建议用canonical URL，不要用SKU拼，不然改版换URL就断了
4. 验证方法：把渲染后的JSON-LD用脚本抽出来，做一次节点合并，看同名实体是不是真的收敛到一个@id上

现在的问题是我没法确认AI那边到底是按@id做消歧，还是按节点在页面里的位置权重。有没有人试过把同一个实体故意用两个不同的@id拆开，看AI会不会当成两个品牌？