你可能已经在网站的每个页面部署了 Schema，但 AI 引擎读取后，仍不知道这个 WebPage 属于哪个网站，也不知道网站由谁运营。问题不在标签数量，而在于这些标签彼此不认识。把 Organization、WebSite 和 WebPage 分别写成互不相连的 JSON-LD，就像递给机器三张毫无关联的名片。@graph 的作用，就是用明确的关系线把这三张名片串起来，让 AI 一次看懂整个网站的实体结构。
为什么分散的 Schema 无法让 AI 拼出完整的网站关系
大多数网站的 Schema 都由插件或 CMS 模板自动生成：首页输出 Organization，文章页输出 Article，定价页输出 Product，各写各的。单独看，每段标记都可能符合规范，也能通过 Rich Results Test。问题在于，当机器试图回答“这篇文章由谁发布，是否可信”时，它看到的只是一组悬空对象，没有任何字段说明 Article 的发布者就是首页中的 Organization。对于 AI 摘要和答案引擎而言，是否能把内容对应到一个真实、可验证的组织，是判断是否引用的重要依据之一。缺少这层关系，企业官方内容在机器眼中就可能退化成一段来源不明的文字。
@graph 到底解决了什么问题
@graph 是 JSON-LD 的顶层字段，值为数组，可以容纳多个实体对象。它把原本可能分散在多个 script 标签中的实体放进同一份文件、同一命名空间。关键并不只是“放在一起”，而是让这些对象能够通过 @id 互相引用：先为 Organization 声明一个 @id，再在 WebSite 的 publisher 中填写同一个 @id，机器就能判断两处指向的是同一实体，无须再次复制完整的 Organization。一次定义、处处引用，是知识图谱的基本思路；schema.org 支持 @graph，正是为了让页面表达实体之间的关系，而不只是罗列一组属性。
一个 script 标签就能容纳当前页面的完整 @graph，同时还能解决一个老问题：三个插件分别输出一次相同的 Organization，属性却互相冲突。在 @graph 中，这家公司只出现一次，成为全站唯一可信的数据源；后续维护时，也只需修改一处。
@id：给每个实体一个稳定的门牌号
@id 是整套写法的基础。它是全域唯一的标识字符串，通常采用 URL 加片段标识符的形式，例如 https://example.com/#organization 。该地址不一定需要能够打开，因为它的职责是标识实体，而不是充当链接。只要同一实体在网站各处始终使用同一个 @id，AI 就能把分散在不同页面的信息归入同一主体。当同一个 @id 同时出现在首页、文章页和定价页时，机器便可整合各页面对公司的描述，形成信息更完整、也更难伪造的实体档案。
- Organization 使用域名根地址加片段标识符，例如 https://example.com/#organization 。该值在全站唯一，并始终指向同一家公司。
- WebSite 使用域名根地址加 #website，代表整个网站实体。
- 每个页面的 WebPage 使用“页面 URL + #webpage”，具体值随页面变化。
- 片段标识符的命名应遵循团队统一规范（#organization、#website、#webpage），不要今天写 #org，明天又改成 #company。
- @id 上线后不要随意更改。更换 @id 相当于创建一个新实体，过去积累的关联也会随之断开。
三个实体应该如何互相指向
连接方向应符合清晰的层级逻辑：从小到大，从页面指向主体。WebSite 通过 publisher 指向 Organization，声明网站由这家公司运营；每个 WebPage 通过 isPartOf 指向 WebSite，表明自己属于该网站。如果页面介绍的就是公司本身，例如“关于我们”或定价页，还可以使用 about 或 mainEntity 指回 Organization。在文章页中，再让 Article 的 publisher 指向同一个 Organization 的 @id，发布者关系就完整了。
一份可以直接套用的完整示例
将下面的 @graph 放入页面 <head>，一个 script 标签即可容纳三个实体。每个实体只声明一次 @id，随后通过 @id 互相引用，无须重复复制 Organization。实际部署时，可以把 Organization 和 WebSite 抽成全站共用模板，只维护一份；WebPage 则根据各页面的 url、name 和 @id 动态输出。 { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
四类最常见的错误
- @id 不一致：首页写的是 #organization，文章页的 publisher 却填入另一个完整 URL，或漏掉井号后的片段标识符，机器便会把它们识别成两家公司。
- 在应该引用的位置塞入完整对象：在 publisher 中重新写了一遍整个 Organization，导致同一实体出现两个副本，属性还可能互相冲突。
- 实体处于悬空状态：WebPage 没有 isPartOf，Article 没有 publisher。对象本身虽然符合规范，却没有连接到网站主体。
- 使用会变化的 URL 作为 @id：一旦带跟踪参数或会话信息的 URL 发生变化，系统就会生成一个额外实体，所有关联都得重新积累。
要让 AI 信任你的网站，关键不是堆叠更多标签，而是把实体之间的指向关系交代清楚。
上线前务必检查这三件事
代码部署上去，并不等于部署正确。第一步，把完整的 @graph 粘贴到 Rich Results Test 或 Schema Markup Validator，确认语法没有报错。第二步，完成一个经常被忽略的检查：逐一提取所有被引用的 @id，核对它们是否确实在同一张图中完成定义，不要指向不存在的标识符。最后，在浏览器中加载页面并检查渲染后的 HTML，确认 script 确实成功输出；不少 SSR 或 CMS 会在这一步悄悄丢失相关内容。实体连接是技术型生成式引擎优化中回报较高的一项工作：投入时间不多，却会直接影响 AI 是否愿意把你视为可信来源。如果你不确定 Organization、WebSite 和 WebPage 是否真正连通，或 publisher 关系是否已经断开，可以预约一次 30 分钟的 GEO 诊断。我们会实际抓取网站渲染后的 HTML，逐条指出缺失的关系线。
