AI 答案引擎到底是怎么解析您的 @graph 的

Schema 校验器查的是语法。它告诉您 JSON-LD 是不是格式正确。它不告诉您 AI 引擎拿它做了什么。

过去一年,我用 RankLabs 把同一组 @graph 载荷跑过五个 AI 引擎,看它们在哪里分叉。差别一点都不细微。有些引擎激进地合并实体。有些拆开。有一个完全无视 sameAs 链。还有一个会沿着它跟到三跳深。如果您的团队把 AI 引擎优化当成一件事而不是五件事,您一定会上线一份帮到两个引擎、伤到三个引擎的工作。

这是那份现场指南。

为什么 @graph 形态首先就重要

把每个实体放进各自的 JSON-LD 块,与放进单一聚合 @graph,这个选择不是装饰。AI 引擎先抽取实体,然后跑一个解析步骤 —— 把共享 @id 或通过 sameAs 连起来的实体合并。分散在多个块时,合并是按块发生(或失败)的。在 @graph 里,合并发生在整篇文档内,因为每一处引用都明确绑定到 @id。

具体来说:如果您在一个 script 标签里发出 Organization,在第二个 script 标签里从 Product 引用它,有些引擎会把这两份当作不连接的两份文档,拒绝合并。同样的载荷做成单一 @graph 就会干净地解析,因为引用是本地的。

我测过的所有引擎都更偏好聚合的 @graph。没有引擎对它惩罚。这是一个单边选择。

ChatGPT:激进合并,@id 上很严格

OpenAI 的网页抓取器(以及由它衍生的 ChatGPT 浏览工具)在 @id 一致时会激进地合并实体。如果您的 Organization 有一个稳定的 @id,而且每个 Product、每个 Article、每个 BreadcrumbList 都一致地引用它,ChatGPT 会把整个网站收敛成一个知识单元,在各种查询类型上都自信地引用您。

如果 @id 漂移了(把页面 URL 当作 id 是这个 bug 最常见的形态,见 Commerce 诊断目录里的 #1 bug),ChatGPT 会把每一处引用当作不同的 organization。它不会仅靠名称匹配就合并。结果是:本应提到您的查询,引用了拥有稳定 @id 的对手。

我测到的:@id 结构一致的品牌,在相关查询上的引用次数比内容相同但 @id 不稳定的品牌多 40 到 70%。变量是 @id 结构,不是内容质量。

实用规则:在写任何 Schema 之前先选定 @id 约定,绝不动摇。品牌实体用 https://yoursite.com/#organization。商品用 https://yoursite.com/products/{slug}#product。文档化。在 CI 里强制。

Perplexity:沿着 sameAs 走,引用权重高

Perplexity 沿着 sameAs 链跟得比任何其他引擎都狠。如果您的 Organization 的 sameAs 包含 Wikidata、Wikipedia、已验证的社交账号,Perplexity 会把这些当作信心信号,在构建答案时给您加权。

如果 sameAs 是空的或指向死链,Perplexity 会扣分。我看到过品牌仅仅加上一个 Wikidata sameAs 引用,在同一查询上从「未被引用」变成「被引用」,没有任何其他变更。

Perplexity 还有一个特点:它带显式 URL 出处地引用。Perplexity 上的引用份额是比那些不带出处只做总结的引擎更干净的信号。如果您要为 AEO 进展做基线,Perplexity 是首先要追踪的引擎。

实用规则:每个主要实体(Organization、个人品牌的 Person、主力 Product 线)都配一个指向规范外部识别符的 sameAs 数组。Wikidata 第一,Wikipedia 第二,官方社交第三。

Claude:保守合并,对结构敏感

Anthropic 的解析器是这五个引擎里最保守的。它不会合并没有通过 @id 显式相连的实体。它对结构也读得更字面:如果您的 Article 实体的 author 设成嵌套的 Person 对象而不是一个回指规范 Person 的 @id 引用,Claude 会把那个作者当作跟您 Organization 引用的人不同的另一个人。

修法跟 ChatGPT 那一个相同(永远引用,绝不嵌套),但 Claude 对同一个 bug 罚得更狠。

Claude 对 description 字段也加权很高。主要 Person 与 Organization 实体上一段好的 description 会实质影响 Claude 在总结您时怎么描述您。马虎的 description 会原文出现在答案里,有时候持续好几年。

实用规则:把 description 字段当作标题来写。它就是标题。

Gemini:被 Google 既有信号加权

Gemini 坐在 Google 更广泛的基础设施里,因此能拿到 Google 十几年累积的抓取记录、链接图、实体关联。结果是:Gemini 对 Schema bug 最宽容,对更广泛的话题权威性最不宽容。

您可以上线完美的 JSON-LD,但如果 Google 对您站点既有的话题评估跟查询不匹配,Gemini 仍然不会引用您。反过来,您可以上线平庸的 JSON-LD,如果 Google 已经在这个话题上信任您,仍然可能被引用。

Gemini 是 Schema 必要但不充分的引擎。在这里,内容深度和权威性比在其他引擎更重要。

实用规则:在 Schema 工作的范围里把 Gemini 排在最后。最后修。先修内容。

Google AI Overviews:结构化数据优先,引用谨慎

AI Overviews 从给常规搜索用的同一份抓取里抽取,但对 @graph 抽取加权很高,而且偏好引用拥有丰富、形式良好结构化数据的网站。代价是它经常在没有明显出处的情况下做总结,所以归因比 Perplexity 难追踪。

最狠击中 AI Overviews 的 bug 模式是 JS 渲染 Schema 问题(目录里的 #8 bug)。Googlebot 会渲染 JS 用于索引,但 AI Overviews 抽取流水线在很多情况下读的是初始 HTML 响应。仅在 hydration 之后才存在的 Schema 对 AI Overviews 这条路径不可见,即使常规 Google 搜索把页面排得很好。我在多个合作里发现这种问题,团队都因为 Search Console 报告校验有效就以为 Schema 没事。

实用规则:在初始响应里以服务端发出 Schema。永远。

这意味着什么对合作范围

五个引擎不可互换。帮 ChatGPT 的工作(稳定 @id)跟帮 Perplexity 的工作(sameAs 链)不一样,跟帮 Google AI Overviews 的工作(服务端渲染)又不一样。一个有用的 Sprint 范围按您最想赢的引擎排工作,而不是按哪些修复在 PPT 里看着最炫排。

我给 Sprint 定范围时,会问哪个引擎在驱动品牌最想拥有的查询。然后架构决策与按模板的实现就优先做这些引擎最敏感的 Schema 模式。校验器套件把规则编码进去。

如果您不知道哪些引擎对您重要,那就是 Audit 回答的问题。RankLabs 把您的优先查询跑过全部五个,报告谁在引用您、谁在引用对手、结构性差距在哪。没有这个基线,您只是在猜。

引擎不是魔法。它们各有规则。尊重规则的 Schema 工作会赢。不尊重的不会。