Schema 审计

1. 审计目标与判定依据

Schema 审计针对接手时网站已有的标记：有些由前任维护者部署，有些是三个插件长期累积的结果，也有些是你很久以前部署、如今已查不清来源的。相比发布前自查，这类审计更难，因为标记会被两类系统以不同方式读取，而标记不合规对两者产生的结果恰好相反。

读取方	读取方式	标记不合规时的结果
解析器：Google、Schema Markup Validator、Rich Results Test、Search Console	将 application/ld+json 作为结构化数据解析，直接丢弃不合规的标记	标记被直接丢弃，而且不会给出任何提示；失效的表现就是什么也没发生
实时抓取型模型：ChatGPT、Perplexity 抓取页面时	将整个块作为页面中的一段文字读取	仍会读取：错误内容会直接出现在回答中

第二种读取方式表明，业内的一项常见判断并不完整。「标记无效也无所谓，反正会被忽略」只适用于解析器。Mark Williams-Cook 用实验验证了另一种情况：他制作了一个虚构公司的页面，只在一段故意写错的 JSON-LD 中填写地址，其中的 @context 是伪造的，类型也是自定义的，结果 ChatGPT 和 Perplexity 仍在回答中给出了这个地址。他的解释是：「They were not parsing it as schema. They were doing what LLMs always do: Reading the visible-ish text of the page」（它们并没有把它当 schema 解析，只是照大模型一贯的做法，读页面上那些勉强算可见的文字，Search Engine Journal，2026）。一年前的一次受控测试从另一个角度得出相同结论：实时抓取的聊天机器人并没有从 JSON-LD 中以结构化数据的形式获取任何值（见 searchVIU，2025）。

因此，为审计发现排列优先级时，应当依据标记声明了哪些页面上并不成立的事实，而不是校验器报告了多少错误。某个块即使有三条词汇警告，只要内容与页面完全一致，便只是次要问题；另一个块可能顺利通过所有校验，其中声明的却是一个实际从未收取的价格，这才是全站代价最高的问题。

评估工作量前，需要明确这项审计能够达到的效果。Ahrefs 追踪了新增 JSON-LD 的 1885 个页面，并与约 4000 个条件相近的页面对照；结果显示，各 AI 平台的引用量都没有出现有意义的变化（见 Ahrefs，2026）。Google 的指引也明确指出，结构化数据*「isn’t required for generative AI search」（对生成式 AI 搜索不是必需的，AI optimization guide）。从业者常用作依据的 GEO 基准研究也无法证明标记的作用：该研究改写的是内容实质与结构，从未把标记作为变量进行测试（Aggarwal 等人，KDD ‘24，arXiv:2311.09735 · 论文摘要）。Williams-Cook 还指出了一项限制，说明「未观察到变化」这一结果有其适用范围：Ahrefs 的样本都是「already strong, well-understood entities」*（地位已经稳固、外界也认得清的实体），这些样本几乎没有实体消歧的空间。综合来看，合理的预期是：审计可以消除隐患、统一实体身份，但不会增加引用量。

2. 开始审计前：范围、抽样、证据

开始前需要确定四项内容，它们决定后续每项发现具体意味着什么。

决策	选项	经验法则
范围	整站／一套模板／某一类页面	应按模板抽样，而不是按 URL 数量抽样；同一模板上的一处问题，按 URL 列入报告时会变成数百条发现
抽样方式	每套模板选取两个 URL	分别选择一个典型页面和一个非典型页面，例如没有作者、没有配图、包含分页或商品已下架的页面。插件默认值往往只在非典型页面暴露
判定基准	有部署规范／没有部署规范	没有规范时，至少要确认标记与可见页面一致（§7）
证据来源	渲染后的 DOM／不执行 JS 的抓取／Search Console	三者回答的问题不同。只在开发者工具中查看渲染后的 DOM，是最常见的取证错误；这样会完全漏掉 §4 检查的问题

开始前应准备以下材料： 一份模板清单，注明现有布局及各布局读取的数据；一份 CMS、主题和插件清单，用于 §6 追查标记来源；一份经过确认的机构官方账号和标识清单，作为 §7 核对外部身份的依据。最好能取得 Search Console 权限；即使没有，四个层级中仍有三个可以完成。

以下情况适合开展审计： 接手由他人部署的网站时；CMS、主题或插件升级或更换后；网站迁移或改版后；机构实体发生变化时，例如改名、合并或被收购；完整 GEO 审计在结构与机器可读性层面发现异常时；以及厂商弃用正式生效时，其中一项将在本季度生效（§5）。如果首次爬取便发现网站完全没有标记，接下来应分阶段部署，见 Schema 部署。

3. 四级审计

前一级不成立，后一级便无从判断。层级越高，检查所需的工作越多，发现的问题也越重要。

级别	核心问题	检查方法	不成立的后果	谁能察觉
第 1 级 · 覆盖	这套模板是否输出标记块？不执行 JS 的爬虫能否获取标记块？	全站爬取并提取标记 + curl	后续三个层级都无法检查	不执行 JS 的爬虫
第 2 级 · 有效	每个标记块能否解析，词汇是否符合规范？	Schema Markup Validator · Rich Results Test · 无法解析的结构化数据报告	解析器将其丢弃，模型仍会读取	解析器
第 3 级 · 一致	实体图是否一致：@id 是否唯一、引用是否有对应节点、同一节点是否仅在一个位置输出？	人工检查实体图 + 排查重复输出	互不相关的实体被合并，或者同一实体被拆成两个	现有工具无法自动发现
第 4 级 · 属实	页面内容和外部信息能否证明标记声明的事实？	逐项比对 + 逐条打开 sameAs	这是唯一有明确处罚的问题类型	用户、Google 人工审核人员、实时抓取型模型

「谁能察觉」一列说明了为何必须按顺序检查这四个层级。现有工具都检测不到第 3 级问题，因此这类问题在接手时已有的网站上往往多年无人发现，只能依靠人工检查。第 4 级问题则是唯一会被真正追究的问题类型。

检查应按以上顺序进行。这类审计中最常见的误区，是逐页打开校验器，却没有发现整个网站的标记都由前端注入，AI 爬虫根本无法获取。§4 中的一条命令即可确认这一点。

对于单个页面，可以自动执行四级框架下的检查：免费的 Schema 标记检测工具只需一次不执行 JavaScript 的抓取，就能依次检查标记能否获取、能否解析、@context、页内实体图，以及 §7 中可由机器核实的部分，并为每项发现附上证据。它无法完成本手册所述的模板级抽样，因此只应作为 §2 抽样流程中的单页检测工具。

4. 第 1 级 · 覆盖：确认实际输出内容

需要收集两类证据，二者不可互相替代。

通过爬取提取标记可以确认哪套模板输出了哪些类型。任何能在全站范围内提取 JSON-LD 的爬虫都可以使用。这里以 Screaming Frog 为例，因为其公开文档可供核查。它*「built our own structured data validator into the Screaming Frog SEO Spider to help make the auditing process more efficient and at scale」*（把结构化数据校验器做进了自家爬虫，为的是让审计做得更省事、也能上规模，Screaming Frog），并将 JSON-LD、Microdata、RDFa、Schema.org Validation、Google Rich Result Feature Validation 分别设为独立选项。结果应以每个 URL 一行的形式呈现，注明检测到的类型与错误，再按模板归类。

不执行 JS 的抓取用于判断不渲染 JS 的爬虫能否获取标记。Googlebot 会执行 JavaScript，而目前观察到 GPTBot、ClaudeBot、PerplexityBot 都不会（见 JavaScript SEO basics）。每套模板运行一次以下命令即可：

# 不渲染的爬虫实际能收到几个块，按模板各取一个样本页
curl -sL https://example.com/your-page | grep -c 'application/ld+json'

这一级形成的覆盖清单应完整列入报告：

模板	抽样 URL	检出类型	不执行 JS 时能否获取？	判定
基础布局	/、/about	Organization、WebSite	是	正常
文章／博客	/blog/a、/blog/b	Article	是	正常
作者页	/authors/lee	无	—	未输出标记
商品页	/p/123、/p/discontinued	Product	否	爬虫无法获取

两种结果必须分别记录，因为修复方法不同。未输出标记是指该模板完全没有输出任何块，是否构成问题取决于部署规范；没有规范时，只有实体主体完全缺失才属于阻断级。爬虫无法获取是指渲染后的 DOM 中存在标记，原始响应中却没有，这是通过标签管理器或前端注入标记的典型表现。许多团队以为标记早已发布，实际上却从未被任何 AI 爬虫获取，原因就在这里。如何选择渲染方式，见 服务端渲染与客户端渲染；哪些引擎会执行 JavaScript，见 AI 爬虫。

5. 第 2 级 · 有效：检查解析与规范，正确理解报告

这些工具分别回答不同的问题。审计时尤其要明确它们各自不能说明什么。

工具	审计用途	不能说明什么
Schema Markup Validator	逐块检查词汇是否符合规范	Google 是否会实际展示相应的富结果
Rich Results Test	检查这个块是否满足 Google 某项具体富结果功能的资格要求	标记在技术上是否正确
无法解析的结构化数据报告	审计已有标记时优先使用：一次列出全站的语法错误	标记的语义是否正确；能解析不代表内容正确
富结果报告	查看全站状态和历史趋势，计数单位是条目	新发布页面的即时状态

优先查看无法解析报告，是因为它提供的信息最符合审计需要：其中列出的是*「could not be parsed because of a serious syntax error」（因严重语法错误而无法解析）的结构化数据，而且「All items in this report are critical structured data errors; there are no warnings or valid items.」（这份报告里全是严重错误，没有警告，也没有通过项）。它还明确指出了审计需要发现的问题：「The most common cause of a single error affecting multiple pages is an underlying template error」*（同一个错误波及多个页面，最常见的原因是模板层面出了问题）。重新校验时的状态变化，见 Fix structured data issues in Search Console。

报告清单反映的是网站现有的标记，不是 Google 支持的全部类型。 Google 写明，一份富结果报告出现的条件是*「only if: Google finds valid markup in your property, and The markup is a supported rich result type」*（当且仅当 Google 在你的资源里找到了有效标记，且该标记属于受支持的富结果类型）。因此，控制台显示哪些报告，取决于网站已有的标记，不能将其视为 Google 支持类型的完整清单。完整清单应以搜索结果外观库为准，其中列出的类型远多于任何单个网站的报告。控制台目录本身也未必及时更新：其中至今仍列有 practice problems 富结果报告，但更新日志已经将其列入移除计划。因此，某项报告仍在目录中，并不能证明对应功能仍受支持。

FAQ 的弃用过程仍在继续，需要区分各个时间节点。 FAQ 富结果自 2026 年 5 月 7 日起不再出现在 Google 搜索结果中；Google 又在 2026 年 6 月删除了 FAQ 富结果的文档（见 Search Central 更新日志 · Search Engine Land）。至于 Search Console API 对 FAQ 的支持，Google 已经宣布将其弃用，但目前尚未确认此项变更已经完成：截至 2026 年 8 月 11 日，Google 的 API 文档仍将其标为*「Upcoming deprecation」（即将弃用），原话是「We’ll be deprecating support for the FAQ search appearance in the Search Console API in August 2026」*（我们将在 2026 年 8 月弃用 Search Console API 对 FAQ 搜索外观的支持，Search Analytics: query），并未给出具体日期。如果报表流程需要查询这一外观类型，应实际调用 API 验证，不能只依据日历判断。

这个层级无法判断标记内容的实际影响。 校验不通过，只能说明解析器会丢弃这个块，并不表示其中的内容不会产生影响，因为 §1 所述的实时抓取型模型仍会读取它。因此，第 2 级只记录不符合规范之处；严重程度需待 §7 核实其声明内容后再确定。

6. 第 3 级 · 一致：检查实体图与输出来源

发布前自查没有与这一级对应的环节，因为一次部署天然只有一个输出方。接手已有网站时则不同：标记可能由多个位置输出，具体输出位置和数量也往往不明确。

先查清输出来源。 主题和 SEO 插件分别输出一份 Article，或者两个插件分别生成一个 Organization，是未经审计的网站最常见的结构性问题。通常可以根据字段风格、缩进和 @id 的命名习惯判断来源，再对照 §2 准备的插件清单确认。查清来源直接关系到修复工作：如果无法确定标记的输出来源，就无法把问题分派给具体负责人。

然后检查实体图。以下问题不会被任何现有工具报告：

检查项	问题表现	后果
@id 是否唯一	同一个 @id 对应两个不同的 @type	使用这些数据的系统会合并互不相关的实体
引用是否有对应节点	author 或 publisher 指向一个未定义节点的 @id	引用指向的对象不存在，实体图中没有对应节点
是否存在重复节点	两个 Organization 块使用不同的 @id，却指向同一家公司	同一身份被拆成两个节点，每个节点只能获得部分佐证
全站是否一致	不同模板中的 Organization.name 或 logo 不一致	同一实体在同一网站中出现相互矛盾的信息
是否存在悬空节点	某个 Person 节点没有在任何位置被引用为 author	这项身份声明与页面中的任何内容都没有关联

取得 §4 的爬取结果后，先提取全站所有 @id 并按值分组，检查同一个值是否对应多个 @type；再检查同一实体是否分散在多个 @id 中。这些引用规则的依据见 JSON-LD；引用不一致会如何影响实体识别，见 实体识别。为了避免问题再次出现，部署时应确保每页只有一个 @graph，节点之间通过引用关联，见 Schema 部署。

7. 第 4 级 · 属实：与页面一致，且有外部依据

需要分别核实内部内容与外部身份。

内部核对需要逐项比对。 将输出的标记块与渲染后的页面并列检查，确认标记声明的每项事实都能在页面上找到，包括作者、日期、价格、评分、描述和地址。现有工具无法完成这一步，而内容不属实是唯一有明确处罚的问题类型。Google 明确说明了处罚结果及其范围：「A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.」（结构化数据的人工处罚会让一个页面失去以富结果形式展示的资格，但不影响它在 Google 网页搜索里的排名，General Structured Data Guidelines）。实时抓取型引擎带来的风险更为直接，因为它们根本不会将标记作为结构化数据解析。对这些引擎而言，标记只是一段页面文字；凡是页面本身无法佐证的内容，都会成为页面之外的另一套说法。

外部核对需要逐条确认身份。 打开每个 sameAs 目标，确认链接可以访问，指向的确实是同一个实体而非母公司、兄弟品牌或同名者，并确认账号至今仍在维护。还要检查 logo 是否返回 404，以及标记中填写的 Wikidata 条目是否真实存在，而不是占位内容。sameAs 只能声明当前实体与某个外部实体相同，不能证明所指的外部实体确实存在，见 知识图谱存在。

以下问题经常出现，表中按发现方式分类，而不是按修复方式分类：

发现	发现方式	重要性
dateModified 取自构建时间	全站 dateModified 高度雷同，而且都等于最近一次部署的时间	标记中声明了一次从未发生的编辑，而且与页面日期不一致
作者是插件默认值或站点名	Person.name 等于站点名、admin，或者 CMS 的默认值	声明了一个外部无从佐证的身份
sameAs 指向死链或另一个实体	逐条打开 sameAs 链接，再由人工确认身份	公开网页可以直接证明身份声明有误
价格、评分或库存与页面不一致	在商品模板上逐项比对标记与页面内容	这是触发人工处罚最典型的问题
机构描述和「关于我们」页不一致	在基础布局上逐项比对标记与页面内容	实时抓取型模型会同时读到两个版本的事实

对于第一项，需要参考 Google 关于日期的说明，因为问题源于默认设置，并非人工录入错误：发布日期必须描述页面本身，不能使用未来的时间，而且*「Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values」*（要确保结构化数据里的日期，和用户可见的那个日期一致，Article publication dates）。

如果一个标记块无论如何修改都无法与页面内容保持一致，就应删除该标记块，而不是删除页面中的事实。

8. 按类型检查缺项

缺少字段的问题，优先级比内容有误低一档；应据此排序，而不是按照一份追求齐全的清单补充所有字段。还需明确一点：所谓的「必填字段」清单是制定者自行设定的规范，并不代表 Google 的要求。Google 明确表示，Organization 和 Article 都没有必填属性，只有推荐属性（见 Organization · Article）。

类型	常见缺项	代价	属于第几级
Organization	没有 @id；sameAs 为空或只包含社交账号；logo 无法访问	实体没有固定标识，每个页面都会生成一个新节点	3／4
Person	没有 sameAs；作者使用插件默认值；author 只是字符串，没有对应节点	声明了一个无从佐证的身份	3／4
Article	author 是字符串而非节点引用；缺少 dateModified，或该值取自构建时间	作者身份和更新时间都缺乏依据	3／4
Product	缺少 gtin、sku、brand；offers 与页面价格不一致	部分问题影响富结果资格，其他问题会导致标记与页面不一致	2／4
FAQPage	包含用户不会提出的问题；用于没有问答内容的页面	标记描述了页面不存在的结构，而且自 2026 年 5 月起也无法获得 Google 富结果展示	4
ImageObject／VideoObject	缺少 caption、description 或 transcript；装饰性图片也添加了标记	只有带有文字说明的字段才能补充实质信息	2
BreadcrumbList	与页面上可见的面包屑不一致，或者页面根本没有面包屑	声明了一个并不存在的层级	4

Product 所列问题确实存在，但确定优先级时应置于 AI 相关问题之后。缺少 gtin 影响的是富结果资格，属于电商和 SERP 问题，并非检索问题；如果 Product 标记与页面内容不一致，则属于 §9 所述的阻断级问题。

9. 严重级别与修复条件

严重级别采用完整 GEO 审计和爬虫访问审计的相同分级，判定依据是问题所属的审计层级，以及页面中能否找到对应事实。

发现	严重级别	判定依据
标记声明的事实在页面中根本不存在	阻断级	这是唯一有明确处罚的问题类型，而且实时抓取型模型会直接读取
实体主体完全缺失，或全站标记都无法解析	阻断级	后续所有层级都无法判断
块仅在渲染后存在，不执行 JS 时无法抓取	阻断级	审计范围内的爬虫都无法获取这些标记
多个位置输出同一实体，或一个 @id 对应两个实体	重大级	实体会在没有报错的情况下被错误合并或拆分
sameAs 目标已失效，或指向的不是同一个实体	重大级	公开网页可以直接证明身份声明有误
词汇警告、推荐字段缺失	次要级	但如果某项具体功能依赖这些字段，严重程度需要提高
已弃用但与页面一致的 FAQPage 或 HowTo	不算发现	它们仍是有效的 Schema.org 类型，不会受到处罚，删除也没有收益

是否修复可依据一项标准判断： 只有三种情况需要修改标记：标记与可见页面矛盾、标记导致后续层级无法判断，或者标记造成实体图关联错误。「已经不产生富结果」不属于其中任何一种。按照弃用清单全面清理会产生大量工作，却没有收益；上表最后一项，恰恰是多数团队接手已有网站后耗费审计预算的地方。

不要将这些发现合并为单一分数。如果算法不公开，却只提供 0 到 100 的综合评分，这样的分数只是一项无法核查的判断，并非测量结果；可引用性审计对可引用性评分也采用相同原则。报告应逐项列出发现及其严重级别。严重级别也不等于优先级：将清单转为计划前，还要根据影响大小、结论可信度和修改难度重新排序，完整 GEO 审计在各层面采用的也是这套方法。

10. 报告内容与复检节奏

每次审计的报告均应包括：

• 报告概要：审计日期、范围内的模板、抽样 URL、本次采用的判定基准，以及是否有 Search Console 证据。
• 覆盖清单：按模板列出 §4 中的表格，并注明「不执行 JS 时能否获取」。
• 发现清单：逐项说明标记声明、相关证据、所属层级、严重程度，以及修复责任所在层面（模板层、插件层、内容层或实体层）。
• 按优先级排列的修复项：即 §9 中重新排序后的清单。
• 与上次审计的差异：说明本次发生了哪些变化，以及变化来自内部修改还是厂商调整。

复检应由变更触发，而不是只按日历安排。 触发条件包括模板或主题变更、CMS 与插件升级、机构实体变化、渲染方式迁移，以及厂商弃用正式生效。固定日程只需保留一项：每季度抽查一次价值最高的几套模板。

构建流程中值得加入一项低成本检查：每套模板选取一个代表性 URL，断言这些页面的 @id 集合没有冲突，而且标记块的数量不少于上一次构建。这样可以及时发现插件升级后实体主体被意外删除或重复输出的问题，而这正是 §6 所述的工具无法报告的问题。

11. 影响审计准确性的常见陷阱

• 只在开发者工具中审计渲染后的 DOM。 这样会完全漏掉 §4 所述的标记获取问题，而后续所有层级都建立在第 1 级之上。
• 把校验器全部通过视为审计通过。 第 3 级和第 4 级问题在任何校验器中都能通过。
• 将 Rich Results Test 用作正确性检查。 它检测的是标记是否符合某项功能的资格，而不是标记在技术上是否正确。
• 只抽查主要模板。 插件默认值往往只在非典型页面暴露，例如没有作者、没有配图、商品已下架或分页列表的第 7 页。
• 将自己控制台中的报告清单视为 Google 的支持范围。 只有当网站已存在受支持类型的有效标记时，对应报告才会出现。
• 将已弃用但内容准确的标记列为问题。 由此增加的工作没有任何收益（§9）。
• 审计自己上周刚部署的标记。 这属于发布前自查，应使用发布前校验流程，见 Schema 部署。
• 期待审计通过后引用量增加。 现有证据无法支持这一因果关系（§1）；开展审计是为了消除矛盾并统一实体身份。
• 只审计一次。 插件升级便可能改变标记结果，而这一变化无需人工操作也会发生。

12. 延伸阅读

• 概念层：面向 AI 的 Schema.org 说明每种类型对引擎的意义，以及标记为何不能提高引用量；JSON-LD 说明 @id、@context、@graph 的引用语义
• 实体层：实体识别 说明身份声明如何得到确认；知识图谱存在 说明 sameAs 所指的外部实体
• 相邻流程：Schema 部署 介绍分阶段部署和发布前校验；AI 爬虫访问审计 将相同的比对方法用于访问检查；完整 GEO 审计 则涵盖 Schema 审计之外的其他层面
• 抓取方式：服务端渲染与客户端渲染 和 AI 爬虫 说明哪些引擎会执行 JavaScript
• 关于评分：可引用性 说明为什么逐项给出通过或不通过的结论，比提供一个综合分数更可靠