AI可见性审计漏掉的关系完整性：schema之外还要审实体连边

摘要：网站堆了几千行schema，单页验证全是绿勾，AI仍然不把你放进推荐名单，原因往往出在实体之间的关系没人审，标记数量未必不够。机器理解网站分四层：能不能抓到、能不能调用、能不能认出你是谁、能不能读懂这些实体之间怎么连。前三层大家都在做，第四层关系完整性几乎没人碰，AI可见性审计漏掉的就是这一层。本文把它拆成可执行的清单：实体关系图、六条必审连边、把hreflang从URL层升到知识层。做多市场、多法律实体、多产品线的出海站，最需要补这一层。

为什么schema做到几千行，AI仍不把你放进推荐名单？

很多技术SEO都遇到过这种情况：标记做得无可挑剔，结构化数据测试工具一片绿，单页验证条条通过，可到了AI概要、ChatGPT、Perplexity给用户推荐同类商家时，名单里就是没有你。

常见的第一反应是继续加标记：给产品补Offer，给组织补sameAs，给文章补author，越加越细。加到几千行，AI对你的识别仍然没有变化。这时要换个方向排查：缺的可能是标记之间的连接，而不是更多标记。

打个比方，公司的每份材料都准备得很完整：营业执照、产品手册、门店地址、服务条款，单独拿出来都没问题。但没有人把这些材料关联起来告诉机器：这个品牌归这家公司，这条产品线下有这几款，这项服务只在这几个市场提供，这些条款只对欧盟用户成立。机器拿到的是一堆散件，拼不出一台能跑的车。

AI系统的工作恰好是把散件拼成整车。它要综合信息、给出推荐、替用户执行操作，依赖的主要是实体之间的关系网是否完整，而不是单页有没有标记。单页验证只能证明零件合格，证明不了整车能开。这一层在审计里最容易被跳过，出问题时影响也最大。

更麻烦的是，站点规模越大，这个缺口越难被自己发现。小站只有几页，关系简单，断不了几条线；SKU上千、覆盖多个市场、标记做得最认真的大站，节点多，关系网密集，断了几条线很难察觉，验证器还会一路显示通过。等发现AI始终不推荐你时，这个盲区通常已经存在很久了。

AI可见性审计为什么要按四层拆开看？

把机器理解网站这件事拆开看，它是依次叠加的四层能力，不是一个开关。每一层都依赖下一层，底层缺失，上层就无从谈起。

L1是地基，解决能不能被抓取。抓取、渲染、可访问性都是技术SEO的老本行，市面上每个审计工具都在查，这里不展开。

L2在它之上，关注机器能否发现你的能力并与你交互。近两年出现的llms.txt、agents.md，以及把网站能力暴露成接口的Model Context Protocol官方规范，争夺的都是这一层的入口。需要提醒的是，这些代理标准的实际采用率远低于社交媒体上的热度：一份针对美、英、德高知名度网站的基准盘点发现，绝大多数站点没有暴露任何当下热门的代理发现机制。现在要不要为AI agent改造网站，本身就需要先做决策，这个问题我在网站要不要为AI agent改造里专门分析过。

L3再往上，关注AI能否认出你是谁，这是实体SEO的主场：通过结构化数据、知识图谱和跨平台一致的实体信号，让机器把零散的提及收敛成一个清晰可辨的实体。这张语义网络怎么搭，可以参考实体SEO指南。这一层近两年的竞争同样很激烈。

问题出在第四层。前三层大家都在加码，唯独L4，也就是机器能否读懂你的实体之间如何关联，几乎没人重视。多数所谓的AI可见性审计查到L3就结束了：确认AI认得出你，就算完成。可认出你，和读懂你与周围一切怎么关联，是两件不同的事。

为什么要分层，而不是合成一个AI可见度分数？因为四层的病因和解法各不相同。L1出问题属于工程工作，改robots、修渲染；L4出问题属于建模工作，要重新梳理实体关系。合成一个分数，你只知道分数低，却分不清是抓不到、没接口、认不出，还是关系断了，就像体检报告只写不及格，不告诉你哪个器官有问题。分层之后，每一层的问题都能对应到各自的修复动作。

实体图和完整性图谱分别回答什么问题？

这里要区分两个概念：实体图和完整性图谱。

实体图解决身份问题。它把现实中的人、地点、物品、组织标成一个个节点，让机器知道苹果是一家公司而不是水果，知道你的品牌是一个确定的实体。Google结构化数据入门指南介绍的方法，主要作用就是帮机器识别节点。

身份只是起点。决定AI能否综合、推荐、替用户执行操作的，是节点之间的边：谁拥有谁、谁属于谁、谁在哪里可用、谁受哪条规则约束。完整性图谱要保证的，就是这些边在上下文中真实成立。

实体图告诉机器你是谁；完整性图谱告诉机器你和你的产品、服务、门店、市场、法规之间是什么关系，并检查这些关系是否正确、是否完整、放到具体市场和受众面前是否仍然成立。前者相当于名片，后者相当于关系网。AI给用户推荐时，依据的是关系网。

为什么这一代AI特别依赖关系？因为它做的三件事，综合、推荐、执行操作，都建立在关系上。综合，是把分散的信息组织成连贯的回答，依靠的是节点之间的边；推荐，是判断你是否适合某个用户和场景，判断的是你与需求之间的关系；执行操作，是替用户下单、预约、咨询，每一步都要确认主体、服务、市场是否对应。传统搜索给出10个蓝色链接，由用户自己拼凑；AI要直接给答案、给操作，拼凑的工作就落到它身上，关系少一条，它就会拼错一步。

这也解释了为什么单页schema全部正确，整体仍然出问题。schema验证只检查一张名片填得是否规范，看不到名片之间应有的连线是否断开。一堆合格的名片放在一起，机器依然拼不出一个可信、可推荐的你。

这里的关键词是上下文真实，需要多解释几句。它要求信息正确，还要求信息在具体语境中正确。同样一句“这款产品保修两年”，对美国用户成立，对德国用户可能就不成立：数据本身没错，只是被放到了不该适用的上下文里。完整性图谱要审的，就是每条边在它应当成立的市场、受众、辖区里是否依然成立。这一点，只靠把字段填对是查不出来的。

多市场品牌schema全部通过，AI为何答不出德国保修归属？

用一个场景说明，这是国际化业务做大后几乎必然遇到的问题。

设想一个做家居的中国品牌，出海几年，业务铺得不小：在美国用品牌A销售，在德国因为商标冲突只能用品牌B，旗下分了三条产品线，背后由两个不同的海外法律主体收款。这套结构营收表现不错，schema的每个部分也都做得很认真。

组织标记完整，每个站点的Organization信息齐全。产品标记完整，几百个SKU的Product和Offer一个不缺。本地站点标记同样完整，地址、语言、货币都标得清清楚楚。单独看任何一页，验证都能通过。

但当一个德国用户问AI：这个牌子的沙发在德国坏了能不能保修，该找谁？AI答不上来。因为没有任何结构化数据告诉它：品牌A和品牌B是同一个品牌；保修服务在美国由主体一提供，在欧盟实际由第三方负责；德国用户应当联系品牌B名下的本地客服，而不是美国总部。

品牌方当然清楚这些信息，但从来没有把这些连边用机器可读的方式表达出来：哪个产品通过哪项服务交付，哪项服务在哪个市场可用，哪个法律实体对哪个市场负责。schema描述了一个个孤立的节点，没有描述它们如何组成一个连贯运转的业务。AI读到的是一堆合格的零件，得不出德国能否保修的答案，于是干脆不推荐，更糟的情况是自行猜出一个错误答案。

问题出在关系没有建立，标记数量并不缺。再加一千行Product也解决不了，因为缺的是产品、服务、市场、主体之间那张没人画出来的关系网，产品信息本身已经够了。

另外，这个问题不分行业。把家居换成跨境SaaS，表现为不同地区的套餐、计费主体、数据合规条款对不上；换成B2B制造，表现为不同市场的认证、可售型号、售后网点关联不起来。只要业务涉及多市场、多主体、多产品线，schema全部通过和AI读不懂你，往往会同时出现。

现有AI可见性审计工具查了什么、漏了什么？

近两年AI可见性审计工具出现了很多，各有侧重，但整体来看大多停留在前三层，几乎没有工具真正覆盖第四层。对照如下：

前三类工具的盲区是同一个：各自把本层查得很细，却都默认实体之间的关系正确且完整。实际情况是，这张关系网恰恰最容易断。用三把不同的尺子量了三遍，结论都是合格，但没有一把量过连边。

因此，一份结果漂亮的AI可见性报告不能说明全部问题。报告全绿，只代表你通过了前三层检查，不代表AI能把你的业务理解成一个连贯整体。真正该问的是：有没有哪份审计拿着我的实体关系图，逐条核对了连边？如果没有，第四层就仍然是没人检查过的黑箱。

怎么快速判断一份审计是否覆盖了第四层？看交付物。只查前三层的报告，给出的是一组单页清单：这页缺schema，那页robots拦截了爬虫。覆盖第四层的审计，给出的是一张关系图加一份连边核对表，结论是跨实体的，例如品牌A和品牌B没有互相指认、保修服务没有标注市场。前者处理页面问题，后者处理关系问题。从交付物的形式，基本就能看出它查到了第几层。

关系完整性审计需要逐条核对哪六条实体连边？

关系完整性审计具体审什么？把抽象的关系落到实际，对出海和多市场站点来说，至少有六条连边需要逐一核对。它们不是新增的标记类型，而是已有节点之间应该连接却经常缺失的线。

• 品牌归属：哪个法律实体真正拥有这个品牌。一个集团下有多个主体、多个商标时，AI应当把信誉、评价、责任归到谁名下，不能靠猜测。
• 产品线隶属：哪些单品属于哪条产品线、哪个系列。产品线、系列、单品之间的层级关系断开，机器就无法理解某个系列的整体定位。
• 服务与市场：哪项服务只在哪些市场提供。保修、退换、本地配送、安装通常不是全球统一的，哪些市场有、哪些没有，必须写清楚。
• 渠道与能力：哪个渠道或网点能办理哪些业务。线上线下、不同站点、不同区域仓，能力范围各不相同。
• 辖区与规则：哪个国家或地区适用哪套规则。合规声明、税费、退换政策、数据条款都按辖区区分，一旦错配就会出事故。
• 全球与本地：哪些信息全球通用，哪些只在本地成立。价格、可用性、法律声明如果混为一谈，AI就会把美国的条款讲给德国用户。

这六条边正是单页schema验证覆盖不到的地方。验证器只会告诉你这一页的Product字段是否填全，不会告诉你这个产品与某项服务、某个市场之间的连接是否断开。关系完整性审计要做的，就是把这些线逐条接上，并确认接得正确。

核对时要用配对题，不要用是非题。不要只问品牌归属有没有标注，而要问这个品牌归属哪个主体，机器从标记中读出的答案是否正确。六条边中的每一条，都应当能从结构化数据里读出一个明确、唯一、正确的另一端。读出来为空、错误或存在多个模糊选项，都是需要补的缺口。

举一个最常见的缺口：辖区与规则这条边。某站把退换政策写成全站统一的一个版本，schema里也只有一份MerchantReturnPolicy，但欧盟的14天无理由退换和美国的政策并不相同。机器读到的是一份笼统的政策，于是把美国规则讲给了德国用户。修复方法是按applicableCountry把政策拆成对应各辖区的多份，让机器明确哪一份适用于哪个市场，而不需要删除政策。

如何用schema的@id把实体关系写进结构化数据？

这些连边大多不需要新造机制。Schema.org的数据模型文档中介绍的@id引用机制就是为此设计的：给每个实体分配一个稳定的@id，再在其他实体中通过这个@id引用它，节点之间就连上了。几组常用写法如下：

• 品牌归属：在Brand上使用parentOrganization，或在Product的brand中用@id指向唯一的Organization，把品牌和背后的法律主体绑定。
• 产品线隶属：使用isPartOf或ProductGroup，让单品指回所属产品线，机器就能把分散的SKU归入同一个系列。
• 服务与市场：在Service、Offer上用areaServed标明该服务、该报价覆盖哪些地区，机器就不会对未覆盖的地区做出错误承诺。
• 多市场品牌互指：用sameAs把同一品牌在不同市场使用的不同名称、不同站点互相关联，告诉机器品牌A和品牌B是同一个品牌。

用@id建立连接的基本结构如下：

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#org-us", "name": "主体一" },
    { "@type": "Brand", "@id": "https://example.com/#brand-a",
      "name": "品牌A", "parentOrganization": { "@id": "https://example.com/#org-us" } },
    { "@type": "Service", "@id": "https://example.com/#warranty-de",
      "name": "保修服务", "areaServed": "DE",
      "provider": { "@id": "https://example.com/#org-eu" } }
  ]
}

这里的@graph把多个实体放在同一个结构中，再通过@id互相引用，名片由此连成关系网。难点不在语法，schema.org早已提供了这些属性；难的是先把关系梳理清楚，知道该连哪条线、连到哪个@id。语法只是执行层面的工作，建模才需要真正思考。

所以不要指望插件一键生成就能解决问题。插件可以批量输出Product，但它不知道某个SKU属于哪条产品线、某项服务只在哪个市场提供，这些信息只有你自己掌握，必须由你来连接。工具负责把线画规范，连线的方向由你决定。

还有一个常见错误：@id必须全站统一且保持稳定。同一个主体在首页用一个@id，在产品页又换成另一个，机器会把它当成两个不同的实体，原本用来建立关系的连线反而把实体拆成了两半。给每个核心实体设定一个唯一、长期不变的@id，然后在各处引用它，这是关系网成立的基础，比多写几种类型重要得多。

国际站如何把hreflang从URL层升级到知识层？

六条连边中，出海站最常出问题的是最后两条：辖区与规则、全球与本地。这一层最具代表性的老工具，就是被误用得最严重的hreflang。

多数人对hreflang的理解停留在URL层：告诉Google这个页面的德语版在哪里、法语版在哪里，让搜索引擎把正确的页面给到正确的用户。这部分仍然要做，具体做法可以参照Google多地区多语言版本(hreflang)官方指南。但它解决的只是同一内容在不同语言下的对应，属于页面层。

AI时代需要补的是知识层的对应。机器需要知道的不只是这一页有德语版，还包括：在德国市场，这个品牌叫什么，由哪个主体负责，哪些服务可用，价格和条款按哪一套执行。这属于事实问题，翻译解决不了：同一个集团在不同市场，事实本身就不同。

知识层的hreflang要回答的是：对于给定的市场和受众，关于你的哪些事实是正确的。德国用户对应的保修方、法国用户适用的退换期限、美国用户熟悉的品牌名，都是这张表里不同的单元格。只在页面头部加一行hreflang标签，机器只知道存在德语版，不知道德语版背后的事实与英语版完全不同。

这也是国际化SEO最反直觉的地方：最难的不是把hreflang标对，而是把跨市场的实体、主体、服务、条款对齐成一张机器可读的事实表。这个问题我在国际化SEO最难的不是hreflang里详细分析过，跨语言的实体对账才是大站真正卡住的地方。把hreflang从URL层升到知识层，实际上就是补齐关系完整性的最后两条边。

上线llms.txt、接入MCP之前，为什么要先补关系完整性？

这一节主要写给急着上线llms.txt、接入MCP的团队。

为机器开放可读入口本身没有错。但入口只有在通向准确、关联完整、上下文清晰的信息时才有价值。如果入口背后的关系模型本身残缺或有错，这个入口带来的不是机会，而是一条把错误信息更快传播出去的通道。

这一点容易被忽略：代理访问让信息更容易被获取，如果信息本身不完整，不完整的内容也会更容易被检索、被引用、被当作事实传播。过去错误信息藏得较深，很少被挖出来；现在你亲手修了一条专用通道，把它直接送到AI面前。机器顺利进入，读到的却是一张缺了一半的关系网，然后很笃定地把缺失的部分猜出来告诉用户，这比它完全找不到你麻烦得多。

所以顺序不能颠倒：先把关系建对、建全，再开放机器可读的入口。L2的代理就绪，前提是L4的关系完整。底层关系模型残缺时，MCP接得越完善、llms.txt写得越详细，错误传播得越快越广。好比把一条断头路修成八车道高速，车只会撞得更整齐。

这条原则也提供了一个判断标准：在系统补齐关系完整性之前，不要急于把自己定位成AI-ready。能被机器调用，和值得被机器调用，差的就是这张关系网是否完整。先问自己：机器从我开放的入口进来，读到的是不是一套正确且完整的关系？答不上来，就先不要开放。

如何把AI可见性审计升级为关系完整性审计？

要把现有的AI可见性审计升级为包含关系完整性的审计，可以按下面五步走。

第一步，先把基础的可见性审计做扎实。L1到L3同样重要，它们是关系完整性的前提：抓取不到、识别不出，讨论连边就没有意义。抓取、内容、实体、AI可见度这套完整诊断如何安排，可以对照企业网站SEO审计该查什么逐项检查，先把前三层的基础打好。

第二步，画一张实体关系图。列出业务中所有的实体：法律主体、品牌、产品线、单品、服务、门店或区域、目标市场，然后在它们之间连线，标明谁拥有谁、谁属于谁、谁在哪里可用、谁受哪条规则约束。这张图不需要工具，一块白板就够，重点是把默认存在于脑中的关系第一次明确画出来。很多缺口在画图时就会暴露，比如某条产品线和某个主体之间是什么关系，连你自己都说不清楚。

第三步，逐条检查每条连边是否已在结构化数据中表达。针对关系图上的每一条线提问：机器能从我的标记中读出这条关系吗？品牌归属是否用parentOrganization或brand连接？产品线隶属是否有isPartOf？服务与市场是否有areaServed？同一品牌在多个市场使用的名称是否用sameAs互相指认？图上有而标记里没有的连边，就是需要补的缺口。

第四步，跨市场对账。按市场建立一张事实表，每个市场一列，逐格填写品牌名、负责主体、可用服务、适用条款、价格口径，确认机器在每个市场读到的事实都正确。这一步就是前文所说的知识层hreflang，也是出海站最容易出错、价值最高的一步。

第五步，把它变成例行工作。关系网不是建一次就一直有效：上线新产品线、进入新市场、更换海外主体、修改退换政策，关系都会随之变化。保哥的建议是把关系完整性审计纳入季度复盘，跟随业务的实际变化滚动更新，不要等出了问题再回头补。

如何确认修复有效？最直接的方法是拿你最关心的几个真实问题去问AI，比如某产品在某市场是否保修、某条款对哪些用户适用，看它能否答出并答对。修改前它回答含糊或张冠李戴，修改后能直接答对，这条边就算接通了。这比看验证器的绿勾可靠得多，因为你检验的正是AI最终读出的答案。

单一市场的小独立站需要做关系完整性审计吗？

读到这里，有人可能会想：我只是一个单一市场的小独立站，没有那么多主体和市场，这套方法是不是只适合大集团？

关系完整性的精细程度取决于业务复杂度，但起点对所有站点都一样。即使只有一个市场、一个主体，你仍然有实体：品牌、几条产品线、几款主推单品、退换和配送政策。用isPartOf、brand等机制把它们之间的隶属和归属关系明确连接起来，成本很低，却能让AI更早把你理解成一个连贯的整体，而不是一堆零散页面。

需要把它作为系统工程认真对待，是在以下几种信号同时出现时：开始进入第二个、第三个市场；为了合规或商标原因，在不同地区使用了不同主体或不同品牌名；产品线多到客户自己都容易混淆；保修、退换、配送等服务开始按市场区分。命中两条以上，关系完整性就从加分项变成了必做项。

最简单的起步动作是：今天就画出实体关系图，画在一张纸上也可以。列出你的主体、品牌、产品线、服务、市场，互相连线，再挑出三条你认为最关键、却很可能没有在标记中表达的关系，验证机器是否能读到。大概率你会在半小时内找到至少一条断开的连接。把它补上，就是这套方法带来的第一项收益。

往后拉开差距的，是能否把实体、产品、服务、位置、品牌、市场之间的关联表达清楚，schema、页面和AI接口的数量决定不了这一点。认出一个实体只是起点，AI还得读懂它和周围怎么连。

常见问题解答

完整性图谱和知识图谱、实体图是一回事吗？

不是一回事，两者是上下游关系。实体图和知识图谱解决身份问题，把人、地点、物品、组织标成机器能识别的节点。完整性图谱在此基础上再进一层，关注节点之间的边是否正确、是否完整：谁拥有谁、谁属于谁、谁在哪个市场可用、谁受哪条规则约束。前者让机器认出你，后者让机器读懂你与周围如何关联。AI给用户推荐时，依据的是后者这张关系网，光有前者这张名片不够。

schema已经做得很全，还需要做关系完整性审计吗？

需要，而且schema越全越应该做。schema完整，证明的是每一页的字段填写规范，属于单页验证；关系完整性审计检查的是页面与页面、实体与实体之间应有的连接是否断开，属于跨实体检查。两者覆盖的盲区完全不同。实际情况往往是，标记做得最认真的大站最容易在关系上出问题：每个节点都合格，连边却无人维护，机器依然拼不出一个可推荐的你。

关系完整性审计具体查哪些东西？

核心是六条连边：品牌归属哪个法律实体、单品属于哪条产品线、哪项服务在哪些市场可用、哪个渠道能办理哪些业务、哪个辖区适用哪套规则、哪些信息全球通用而哪些只在本地成立。审计方法是先画一张实体关系图，把这些关系明确列出来，再逐条检查它们是否已在结构化数据中表达、表达是否正确。验证器覆盖不到这一层，需要人拿着关系图逐条核对。

接入MCP、写好llms.txt，是否就等于关系完整了？

不等于，而且顺序颠倒反而更危险。MCP和llms.txt解决的是机器能否进入、能否调用你，属于代理就绪层。它们让信息更容易被获取，但如果底层关系模型本身残缺或有错，开放入口只会让错误信息更快被检索和引用。正确顺序是先把关系建对建全，再开放机器可读的入口，否则就像把一条断头路修成八车道高速。

单一市场的小独立站也需要管关系完整性吗？

需要，只是精细程度低很多。即使只有一个市场、一个主体，你也有品牌、产品线、单品、退换和配送政策这些实体，用isPartOf、brand把它们之间的隶属关系明确连接起来，成本很低，却能让AI更早把你理解成一个整体。需要作为系统工程来做，是在你进入多个市场、使用多个主体或品牌名、产品线增多、服务按市场区分的时候：命中两条以上，它就从可选项变成必做项。

知识层hreflang和普通hreflang有什么区别？

普通hreflang作用于URL层，告诉搜索引擎同一页面的德语版、法语版分别在哪里，解决的是语言版本的对应。知识层hreflang作用于事实层，要让机器知道在某个具体市场里，关于你的哪些事实成立：在这个市场用什么品牌名、由哪个主体负责、哪些服务可用、条款按哪一套执行。同一个集团在不同市场，事实本身就不同，翻译解决不了，需要把跨市场的实体和事实对齐成一张机器可读的表。

没有开发资源，关系完整性审计可以从哪一步开始？

从一张纸开始，不需要任何工具。列出你的法律主体、品牌、产品线、单品、服务、市场，互相连线，这张实体关系图就是整套审计的骨架。画完后挑出三条你认为最关键、却很可能没有在标记中表达的关系，手动检查机器能否读到。这一步没有成本，却几乎一定能让你当场发现至少一条断开的连接。之后要补标记、做跨市场对账，再按优先级逐步安排资源。

权威参考资料