结构化数据工具怎么选？富媒体测试、Schema Validator 与 URL 检查分工
三个常用工具解决的问题不同：富媒体测试看 Google 富媒体资格，Schema Validator 查语法，URL 检查看真实索引版本。本文给出排查顺序。
这三个工具不能互相替代。 Rich Results Test 用来判断页面是否满足 Google 当前支持的富媒体类型及必填字段；Schema Markup Validator 更适合检查通用 Schema.org 语法；Search Console URL 检查则回答 Google 实际抓取、选择 canonical 和索引的页面版本是什么。正确顺序是“本地语法 - 富媒体资格 - 线上抓取与索引”。
Rich Results Test 解决什么
它适合检查 Article、Product、Breadcrumb 等 Google 支持的搜索展示类型，能区分错误与非阻断警告，也可以测试代码片段或线上 URL。但通过测试不等于一定展示富媒体，搜索系统还会考虑页面质量、政策和查询场景。
Schema Markup Validator 解决什么
Schema Validator 更关注 Schema.org 词汇是否能被解析，适合发现类型、属性、嵌套和 JSON-LD 语法问题。它可能接受 Google 搜索并不使用的属性，所以“语法有效”不能直接推导为“Google 富媒体合格”。
URL 检查解决什么
Search Console URL 检查用于确认 Google 选择的 canonical、最后抓取时间、索引状态、抓取到的 HTML 和增强功能。页面刚修复时，可先做实时测试，再根据业务优先级请求重新编入索引；实时测试成功仍不代表立即收录。
如果还要判断页面体验，另用PageSpeed Insights 与 Search Console 协作流程；要观察生成式搜索表现，可参考Search Console 生成式 AI 报告读法。
推荐的五步排查顺序
- 在模板或预发布环境检查 JSON-LD 是否可解析；
- 用富媒体测试确认目标类型和必填字段；
- 打开线上源代码，确认标记没有被缓存或脚本改写；
- 用 URL 检查核对 Google 抓取版本、canonical 和索引条件；
- 修复后保留测试时间、URL、错误截图和再次抓取结果。
不要只复制工具给出的“通过”截图，还要检查结构化数据是否与页面可见标题、作者、日期、价格和库存一致。
常见误判
- 把 Validator 通过当成富媒体展示承诺；
- 在草稿代码中通过，却没有验证生产 URL；
- 页面写一个 canonical，站点地图和内链指向另一个版本；
- Product 标记填了页面看不到的价格或库存；
- FAQ 标记与可见问答不一致，或为了展示而堆砌重复问题。
Google 已在 2026 年 5 月停止 FAQ 富媒体展示，因此 FAQ 仍可用于帮助用户和表达内容结构，但不应把它当作可见搜索特效承诺。
常见问题
Rich Results Test 通过后为什么搜索里没有富媒体？
通过只表示技术上具备资格，不代表搜索结果一定采用。还需检查索引、canonical、内容质量、政策以及当前查询是否适合该展示。
测试代码和测试 URL 有什么区别？
代码测试适合开发阶段快速排错；URL 测试更接近生产环境，但仍需通过 URL 检查确认 Google 实际抓取的版本。
每次改文章都要跑三个工具吗？
普通正文修改可抽样验证；模板、类型或关键字段发生变化时，应至少跑通语法、富媒体资格和线上索引版本三个层级。
核验来源
- Google Search Console：Rich Results Test
- Google Search Central：Structured data general guidelines
- Google Search Console：URL Inspection tool
- Schema.org Validator
工具界面和支持类型会更新，实际判断以各官方文档当前说明为准。