Schema 通过 Google 验证工具，不代表 AI 引擎就能抓取你的结构化数据，因为二者采用的解析路径并不相同。Rich Results Test 只检查 Google 支持的少数富媒体搜索结果类型是否符合条件；Schema.org Validator 只检查语法是否符合词汇规范。它们都不会告诉你，ChatGPT、Perplexity 或 Google AI Overviews 的爬虫究竟从页面中读到了什么。很多页面在验证工具中全部显示为绿色，却始终无法出现在 AI 答案中。问题就出在这道落差上。
为什么“验证通过”不等于“AI 能读取”
验证工具负责的是“合规检查”，不是“可读取性检查”。Schema.org Validator 会将 JSON-LD 与 schema.org 词汇表进行比对，确认类型和属性拼写是否正确、嵌套结构是否合法；Rich Results Test 则会模拟 Googlebot 渲染页面，判断页面能否触发某类富媒体搜索结果。完成这两项检查，你只知道“语法是否正确”以及“Google 是否可能展示富媒体搜索结果”。至于 AI 爬虫，很多只会直接抓取服务器返回的原始 HTML，不执行 JavaScript，也不关心页面是否符合富媒体搜索结果的资格。真正决定 AI 能否读取的，是 JSON-LD 是否存在于原始 HTML 中，以及各个实体之间是否建立了关联。
两款必备工具，各有各的验证盲区
先弄清两款工具各自负责什么，才能知道它们分别漏掉了什么。
- Rich Results Test（search.google.com/test/rich-results）：它会使用 Googlebot 实际渲染页面、执行 JS，并逐项列出检测到的富媒体搜索结果类型、错误和警告。它的盲区在于，只覆盖 Google 支持的大约三十种类型。如果你标记了 Organization、Person 等不会触发富媒体搜索结果的类型，工具可能显示“未检测到项目”，但这并不代表 Schema 无效。
- Schema.org Validator（validator.schema.org）：无论 Google 是否支持，它都会展示所有类型的完整实体树，特别适合检查语法和词汇。它的盲区在于，默认不会替你执行 JS。无论粘贴源代码还是提交 URL，拿到的往往都是未渲染版本。此外，它不会判断页面是否符合富媒体搜索结果资格，对某些语义错误也过于宽容。
结论很直接：两款工具都要用，同时要明确每一步究竟在检查什么。用 Schema.org Validator 检查语法和实体结构，用 Rich Results Test 检查 Google 富媒体搜索结果资格与渲染结果。但它们都无法回答“不执行 JS 的爬虫能不能看到这些数据”。这个问题必须通过下一步的源代码检查来确认。
一套可重复执行的 Schema 验证流程
把验证拆成固定步骤，并在每个页面、每次改版时执行同一份检查清单。这样就不必每次凭经验临时检查，也不会反复漏掉不同的问题。
- 将“渲染后”的 HTML 粘贴到 Schema.org Validator，确认语法和词汇正确；展开完整实体树，逐项检查类型和必需属性。
- 在 Rich Results Test 中输入正式 URL，确认 Google 能抓取渲染后的版本、目标富媒体搜索结果类型可以被识别，并且没有红色错误。
- 使用 curl 或 view-source 抓取“不执行 JS”的原始 HTML，搜索 application/ld+json，确认 JSON-LD 确实存在于服务器返回的内容中。这一步模拟了大多数 AI 爬虫的抓取方式。
- 检查 @id 与 @type 之间的交叉引用，包括 Organization、WebSite、Article 和 Person。确认各实体使用一致的 @id 串联成完整关系，让引擎能够判断作者属于哪家机构、文章属于哪个网站。
- 逐项对照 Schema 中的值与页面可见内容。价格、标题、评分和日期必须保持一致。信息不一致时，Google 可能直接忽略相关数据，AI 对页面的信任度也会下降。
- 保存一份基准快照；以后每次修改都重新执行完整清单，并通过差异对比排查回归问题。
那些语法通过、AI 却读不到的错误
Schema 即使通过语法检查，仍可能存在一整类“工具说没问题，AI 却读不到”的错误。我们为客户开展审计时，最常发现以下几种情况：
- JSON-LD 由前端框架或标签管理器在浏览器端注入，服务器返回的原始 HTML 中一行都没有。不执行 JS 的爬虫自然完全看不到。
- @id 缺失或不一致，导致实体无法关联，引擎不能把作者、机构和文章归入同一个知识图谱节点。
- 类型选对了，值却放错了字段：把币种填进 price、把整段描述塞进 name，或者在 offers 中漏掉 priceCurrency。
- 语法合法，但语义不完整：Product 没有 offers，Article 缺少 author 或 publisher，FAQPage 的 answer 是空字符串。
- 同一页面存在多份相互冲突的 JSON-LD，例如首页模板自带一份 Organization，页面中又输出一份，导致引擎无法判断该采用哪一份。
- 日期不符合 ISO 8601，图片使用相对路径而不是绝对 URL。这些问题可能通过较为宽松的验证器，却很容易在数据提取时被丢弃。
别只看验证工具，更要看“渲染后 DOM”和“源代码”之间的差异
要把验证做扎实，关键是同时查看页面的两个版本。打开 DevTools 的 Elements 面板，看到的是浏览器渲染后的 DOM，大致接近 Googlebot 看到的页面；使用 view-source 或 curl，看到的则是服务器最初返回的原始 HTML，也就是大多数 AI 爬虫看到的内容。如果结构化数据只存在于前者、不存在于后者，这道差异就是 AI 无法读取你的网站信息的原因。验证工具能帮你查看第一个版本，第二个版本则必须自己检查。
Schema 验证不是发布时做完一次就结束，而是每次改版都必须重新执行的质量关卡。一次 CMS 升级或模板调整，就可能让整棵实体关系树在毫无提示的情况下失效。— Tenten GEO Technical Audit Notes
把验证设为发布前的固定关卡
最实用的做法，是把这份清单纳入发布流程，而不是靠记忆临时检查。你可以在 CI 中加入脚本，抓取正式 URL 的原始 HTML，解析其中的 JSON-LD，对比必需属性和 @id 引用；只要发现缺失，就阻止部署。没有 CI 的团队，至少也应把上述六个步骤写进发布前检查清单，每次修改后逐项确认。结构化数据的价值，在于能够被机器稳定提取；这种稳定性来自流程，而不是某次手工验证碰巧没出错。如果你想知道，不执行 JS 的爬虫眼中的页面究竟是什么样，哪些 Schema 完全无法被 AI 读取，可以前往 /contact 预约一次 30 分钟的 GEO 诊断，我们会直接在你的实际页面上执行这套流程。
