JSON-LD 里 @id 和 url 谁先谁后，我实测抓取顺序差了 11 次

上个月我在调一个商品详情页的 JSON-LD，发现一个特别磨人的细节：@id 和 url 这两个字段的先后顺序，居然会影响 AI 抓取时对实体主键的识别。

先说场景。页面是标准的 Product schema，嵌套了 Offer 和 AggregateRating。最初我把 url 放在 @id 前面，跑了一批 200 条问句的抓取日志，统计下来实体解析失败（AI 把同一个商品当成两个实体）出现了 17 次。失败样本里，AI 给出的理由集中在「缺少唯一标识」或「URL 与标识冲突」。

我把字段顺序调成 @id 在前、url 在后，其他不动，同一批问句重跑。失败次数从 17 降到 6。剩下的 6 次我翻了日志，是 @id 用了相对路径，改成绝对 URL 后只剩 2 次，且都是因为页面 canonical 标签和 @id 不一致。

我的判断依据有三条：

1. @id 是 JSON-LD 里的实体主键，解析器大概率按字段出现顺序做第一轮实体去重，url 被当成了属性而不是键。
2. 页面速度这块我没动，LCP 稳定在 1.8s，所以排除加载时序干扰，变量只有字段顺序。
3. 抓取日志里 @id 在前的样本，AI 引用时给的实体描述更稳定，不会在「商品」和「优惠」之间反复横跳。

踩坑细节：别在 @id 里用带跟踪参数的 URL，我一开始图省事复制了带 utm 的链接，结果 AI 把同一商品按渠道拆成了三个实体，比字段顺序问题还严重。另外 AggregateRating 嵌套层级超过两层时，字段顺序的影响会被放大，建议把 rating 的 @id 也显式写出来。

现在我的模板固定为：@context → @type → @id（绝对 URL、无参数）→ name → url → 其余属性。跑了两周，实体解析失败稳定在 2 次以内。

想追问一句：你们在 @id 和 canonical 不一致的时候，是改 @id 对齐 canonical，还是反过来改 canonical？我目前是前者，但不确定对多语言站是不是最优解。