实体一致性检查：跨页面、跨站核对 Schema @id 与 sameAs

输入同一个人或同一家公司出现的几个页面（可以跨网站），工具会把各页 JSON-LD 里的 Person 和 Organization 放在一起比对，列出 @id、属性和 sameAs 的不一致之处，并给出合并后的推荐写法。

要点

• 工具一次读取 2 到 10 个页面，把各页 JSON-LD 里的 Person 和 Organization 放在一起比对，列出 @id、属性和 sameAs 的不一致之处。
• 判断是不是同一个实体，主要看 @id 是否相同，以及 url 或 sameAs 里有没有共用的资料页；名称相同只作为辅助依据。
• 每条检查标出证据等级。Google 会不会跨页面合并相同的 @id 没有公开说明，所以相关检查是 D 级。
• 工具不打综合分，结果里给出合并后的推荐写法。

什么是实体，为什么要跨页面检查

在结构化数据里，实体是一个可以被单独识别的对象，例如一个作者、一家公司或一个品牌。Google 用知识图谱记录这些实体，ChatGPT、Perplexity 这类 AI 搜索产品回答「某人是谁」「某个品牌靠不靠谱」时，也要先确定说的是哪个实体。

一个作者通常会出现在很多地方：自己网站的关于页、每篇文章的 author、公司网站的作者页，以及 LinkedIn、GitHub 等平台的资料页。每个页面各写一份描述，时间一长就会出现差异，例如职位改了只更新了一处，头像换了旧页面没换，公司网站的作者页用了另一个 @id。单页检查工具只看一个页面，发现不了这类问题，因为每个页面单独看都没有错。

这个工具一次读取 2 到 10 个页面，把描述同一实体的内容放在一张表里比对。 工具判断「是不是同一个实体」，主要看 @id 是否相同，以及 url 或 sameAs 里有没有共用的资料页。名称相同只作为辅助依据：如果两处描述各有不同的 @id，又没有共用的链接，工具按两个实体处理，并给出提示。

怎么用

1. 每行填一个网址，例如实体主页（关于页或作者页）、一篇文章页、另一个网站上的作者页。可以一次粘贴多行网址，工具会自动拆成多行。
2. 如果某个页面的结构化数据是 JavaScript 插入的，或者页面需要登录，点「粘贴代码」，把 JSON-LD 或整页源码贴进去。网址这时只用来标明是哪个页面。Schema 可视化工具里的书签按钮可以复制浏览器渲染后的 JSON-LD。
3. 点「开始检查」。每一行会显示抓取进度和找到几段 JSON-LD。
4. 在结果里切换四个视图：
   • 问题清单：每条问题标出严重程度、证据等级和出处，展开后有原因、修改方法和可复制的代码。
   • 实体对照：每个实体一张表，每列是它在某个页面上的一处定义，取值不同的行会标黄。
   • 跨页实体图：左边是页面，右边是实体，连线表示哪个页面定义或引用了哪个实体。
   • 推荐写法：合并后的完整定义，以及每个页面应该保留的引用写法。

不想准备数据，可以先点两个示例。「Linus Li 的作者实体」会在线抓取本站关于页、一篇文章和筋斗云 SEO 网站的作者页；「常见错误」是一组虚构数据，覆盖了大部分检查项。

检查项与证据等级

工具不打综合分。每条检查都标出证据等级，说明 Google 有没有公开说过这件事：

• A 官方确认：Google 搜索中心文档或公开表态。
• B 文件佐证：法庭证词、判决书、泄露文档，存在但用法未知。本工具目前没有 B 级检查项。
• C 专利可能：专利或论文，不证明已经上线。本工具目前没有 C 级检查项。
• D 行业推测：行业经验或推断，Google 没有公开说明。

另有一个「规范」标记，表示规则出自 JSON-LD 或 schema.org 规范，而不是 Google 的说法。例如 JSON-LD 规范规定 @id 按字符串比较，这是确定的；Google 会不会跨页面合并相同的 @id，则没有公开说明。

检查项	判断方式	证据等级
同一实体用了不同的 @id	共用 url 或 sameAs 资料页，@id 不同	D，规范
同名但 @id 不同	没有共用的链接，工具按两个实体处理，只给提示	D，规范
@id 写法不一致	只差 http/https、www、大小写或结尾斜杠	D，规范
相对 @id	"#person" 这类写法在不同页面会变成不同的标识	D，规范
属性冲突	同一实体的 name、jobTitle、url、image、logo 取值不同	D，规范
按语言取不同的值	页面的 inLanguage 不同，每种语言各用一个 name 或 url（例如中文关于页和英文关于页）。只作说明，不算冲突	D
worksFor 指向不同组织	同一个人在不同页面的雇主 @id 或名称不同	D
内联定义缺 @id	其他页面已有 @id，这里却重新写了一份没有 @id 的定义	D
作者是纯文本，或没有 url / sameAs	文章的 author 只有名字	A
ProfilePage 缺 mainEntity	Google 把它列为必需属性	A
ProfilePage 与实体不对应	实体的 sameAs 指向的资料页，mainEntity 用了另一个 @id	D
sameAs 无效、指向平台首页或非资料页	例如 https://www.linkedin.com/、一个 GitHub 仓库	A
sameAs 重复、包含自己的 url	同一地址写了两次	D
引用的 @id 没有定义	输入的页面里都找不到定义	D
跨站链接只有单向	两个网站上的同一实体，只有一边链向另一边	D
没有 Wikidata 或 Wikipedia	sameAs 里没有知识库链接	D

给老手：各检查项的出处和工具的合并规则

出处

• Google 文章结构化数据的作者标记最佳做法：author.url 是「能唯一识别作者的网页，例如作者的社交媒体页面、关于页或简介页」；文档还说明 Google 能同时理解 sameAs 和 url 并用来区分作者。这一节没有提到 @id。
• Google ProfilePage 结构化数据：mainEntity 为必需属性，类型是 Person 或 Organization；sameAs 的说明是「其他外部资料页或主页的网址」。
• Google Organization 结构化数据：sameAs 是「其他网站上提供更多组织信息的页面，例如社交媒体或点评网站上的资料页」。
• JSON-LD 1.1 节点标识符：@id 是 IRI，同一文档内 @id 相同的节点表示同一个节点；相对 IRI 按文档基准地址解析。
• schema.org sameAs：能明确表明实体身份的参考网页，例如 Wikipedia 页面、Wikidata 条目或官方网站。

合并规则

• 判定为同一实体：类型同属 Person 或同属 Organization，并且 @id（规范化后）相同，或者有一个相同的有效 sameAs 资料页或 url（Person 的 url 如果只是网站首页，不算在这一条里）。
• 名称或别名相同（忽略大小写和空格），或者 Person 的 url 只是网站首页：只有在合并后不会把两个不同的 @id 并在一起时才合并。否则保持为两个实体，并报告「同名但 @id 不同」。
• 空白节点标识（_:b0）和粘贴代码里无法补全的相对 @id，只在各自的页面内有效。相对 @id 优先按 @context 里的 @base 补全，没有 @base 时按页面网址补全。
• 推荐的 @id：出现次数最多的写法。输入里没有 @id 时，按「实体主页所在域名 + /#person 或 /#organization」生成，并在结果里注明是建议值。
• 其他属性：优先取与推荐 @id 一致的那几处定义，再按出现次数取最多的值。alternateName 合并所有别名和其他写法的名称；sameAs 取所有有效链接的并集，去掉重复、平台首页和实体自己网站上的页面。
• 推荐写法只合并输入里已有的值，不补充任何没有出现过的信息。冲突的属性会单独列出，需要人工确认。

常见错误与修复示例

作者在文章里重复写了一份没有 @id 的定义。 关于页定义了完整的 Person，文章页的 author 却只写了名字：

"author": { "@type": "Person", "name": "Jane Doe" }

改成引用同一个 @id，同时保留 name 和 url。这样即使搜索引擎不跨页面合并 @id，也能通过 url 找到作者：

"author": {
  "@type": "Person",
  "@id": "https://example.com/#person",
  "name": "Jane Doe",
  "url": "https://example.com/about/"
}

另一个网站的作者页用了别的 @id。 例如个人网站用 https://example.com/#person，合作网站的作者页写了 "@id": "#author"。相对地址会按那个页面的网址补全，结果是另一个标识。两边的 Person 应该使用同一个绝对地址，作者页的 ProfilePage.mainEntity 也指向它。

sameAs 写了平台首页或帖子。 https://www.linkedin.com/、https://github.com/用户名/某个仓库 都不能说明是哪个人，应该换成 https://www.linkedin.com/in/用户名/、https://github.com/用户名 这类资料页。

同一个人的雇主写成了两家公司。 个人网站的 worksFor 引用 https://example.com/#organization，公司网站的作者页却内联了一个没有 @id、名称也不同的 Organization。如果它们是同一家公司，就选定一个 @id，把其他名称放进组织的 alternateName。

个人网站和公司网站怎么共用一个作者实体

作者同时在个人网站和公司网站发表文章时，比较稳妥的做法是：

1. 在个人网站的关于页放完整的 Person 定义，固定一个 @id，例如 https://你的域名/#person，并给关于页加 ProfilePage。
2. 公司网站作者页的 ProfilePage.mainEntity 和每篇文章的 author 都使用同一个 @id，同时写上 name、url 和 sameAs，取值与个人网站逐字一致。
3. 两边互相链接：个人网站 Person 的 sameAs 写公司网站的作者页，公司网站的 url 或 sameAs 写个人网站。

可以点上面的「Linus Li 的作者实体」示例，查看本站和筋斗云 SEO 网站的实际标记，以及工具找到的差异。

常见问题

Google 会跨页面合并相同的 @id 吗？

Google 没有公开说明（D 行业推测）。JSON-LD 规范只规定同一个文档里 @id 相同的节点是同一个节点。Google 的文章结构化数据文档说明它用 author 的 url 和 sameAs 区分作者（A 官方确认），所以工具建议在每处引用都保留 name 和 url，不只写一个 @id。

一定要用 @id 吗？只写 url 和 sameAs 行不行？

只写 url 和 sameAs 也符合 Google 文档的要求。@id 的作用是让多处描述共用一个标识：同一页面上的多个节点可以直接合并，跨页面时也减少了只靠名称匹配的不确定性。两者可以同时使用。

@id 用什么格式？必须能打开吗？

@id 是标识符，不要求能打开。常见写法是「网站首页 + #person」或「关于页网址 + #person」。它必须是完整的绝对地址，并且定下来以后不要再改，否则旧页面和新页面又会变成两个实体。

sameAs 应该放哪些链接？

放这个实体自己的资料页：LinkedIn、GitHub、X、知乎、Crunchbase 的个人或公司页，另一个网站上的作者页，以及已有的 Wikidata 或 Wikipedia 条目。不要放平台首页、单篇帖子或别人的页面。自己网站上的页面用 url 表达即可。

个人网站和公司网站都写了作者信息，会不会被当成两个人？

如果两边的 @id、名称、职位和 sameAs 一致，并且互相链接，被识别为同一个人的可能性更大。Google 没有公开实体合并的具体规则（D 行业推测），所以工具能做的是把可见的不一致都找出来。

为什么某个网址抓不到 JSON-LD？

工具由本站服务器抓取页面的原始 HTML，只返回其中的 JSON-LD。JavaScript 插入的结构化数据、需要登录的页面、拦截服务器请求的网站都会抓不到。这时可以改用「粘贴代码」。抓取有频率限制：每个 IP 每小时 30 次，服务器缓存命中也计入次数。不关闭页面再次检查时，工具会复用已经抓取成功的网址，改了一行再检查不会重复计数。如果检查中途达到上限，剩下的行不再抓取，并自动展开粘贴代码框。

工具会保存我的数据吗？

粘贴的代码只在你的浏览器里处理，不会上传。填写的网址和代码会保存在你自己浏览器的本地存储里，方便下次打开时继续，点「清空」即可删除。

延伸阅读

• Schema 可视化工具：检查单个页面的 JSON-LD 关系图、必需属性和格式错误
• AI 爬虫 robots.txt 检测：确认 AI 搜索爬虫能抓取你的关于页和文章页
• 更多免费 SEO 与 GEO 工具