免费 Schema 标记检测工具
输入页面 URL,检查 JSON-LD 是否写入原始 HTML、能否正确解析、实体关系是否一致,以及标记内容是否与页面相符。每个问题都会附上对应证据。
免费使用,无需账号。每天可检测 8 次;登录后每天可检测 25 次。 使用 Google 登录
检测器直接读取原始 HTML,不执行 JavaScript,因此可以判断标记在客户端渲染前是否已经存在。词汇合规请配合 Schema Markup Validator 检查,Google 富结果资格请使用 Rich Results Test。
原始 HTML 中的 JSON-LD
这里展示本次检测使用的原始标记。有效 JSON 会重新排版,方便阅读;无法解析的内容则按原样显示,便于定位问题。
四级台阶
怎么读这些结论
- ✅ 在工具可检测的范围内没有发现问题。
- ⚠️ 需要查看具体提示并进行人工确认。
- ❌ 发现了明确问题,旁边会显示对应证据。
- N/A 页面没有与这项检测相关的内容。
1 · 覆盖(交付)
— 不执行 JavaScript 的爬虫能否收到这些标记?
检测内容
检查原始 HTML 中是否包含 JSON-LD,不执行 JavaScript。只在客户端渲染后出现的标记不会显示在这里。Microdata 与 RDFa 只作提示,不纳入检测。 手册对应章节 · 如何修复
2 · 有效
— 每个块都能解析吗?词汇表是 schema.org 吗?
检测内容
检查每个块的 JSON 语法和 @context 声明。无法解析的内容会附上原文,方便定位问题。完整的词汇合规仍需使用 Schema Markup Validator 检查。 手册对应章节 · 如何修复
3 · 一致
— 实体之间的关系是否一致?
检测内容
检查 @id 是否唯一、页面内引用能否解析、实体是否重复定义,以及是否有带稳定身份的 Organization 或 Person 节点。 手册对应章节 · 如何修复
4 · 属实
— 标记内容是否与页面和外部身份信息相符?
检测内容
对比标记标题与页面可见标题,检查作者是否可见、日期是否合理,并测试最多 10 个 sameAs 和 logo 地址能否访问。地址可访问并不代表身份一定正确,因此仍需人工确认。 手册对应章节 · 如何修复
人工内容核对
人工判断 标记中的每项信息是否也能在页面上看到,包括价格、评分、地址和描述?
这一步需要人工判断。请把标记与渲染后的页面逐项对照,确认每条信息都可见且准确。如果某个标记块无法与页面保持一致,应更新或删除标记。 手册对应章节
为什么不提供综合评分
单一分数会把性质完全不同的问题混在一起,也无法告诉你该从哪里修起。按照 Schema 审计手册的方法,本工具逐项报告结果。可引用性检测工具也采用同样的证据优先原则。
每条结论都对应可以直接核实的内容,例如冲突的 @id、无法访问的 sameAs 地址,或写在未来的日期。
检测流程
- 抓取原始 HTML,不执行 JavaScript,并收集其中的所有 JSON-LD 脚本块。
- 逐块解析 JSON,并检查 @context 声明。无法解析时,会显示相关原文。
- 检查实体关系,包括冲突的 @id、未解析的引用、重复定义,以及缺少 Organization 或 Person 节点等情况。
- 核对标题、作者和日期等可自动判断的信息,并测试最多 10 个 sameAs 与 logo 地址能否访问。
- 分别报告每个阶段的结果,并为所有警告和问题提供证据。
这个检测能判什么,不能判什么
- 这是单页检测。如果某个 @id 定义在站内其他页面,这里可能显示为未解析。需要检查全站实体关系时,请参考 Schema 审计手册。
- 本工具检查 JSON 语法、@context、实体关系和有限的页面对照。词汇合规请使用 Schema Markup Validator,Google 富结果资格请使用 Rich Results Test。
- 地址探测只能判断能否访问,不能证明身份。可访问的 sameAs 地址仍可能指向母品牌或同名实体。遇到拦截时会标记为需要人工核实,只有明确返回 404 或 410 才视为失效。
- 结构化数据没有带来更多 AI 引用的保证。它更实际的价值,是让实体信息保持准确和一致。相关证据见手册第 1 节。
- 页面没有结构化数据并不代表检测失败。如果你决定添加,可以按照 Schema 部署手册进行发布和验证。
常见问题
为什么不提供 0 到 100 的 Schema 评分?
单一分数会掩盖问题究竟出在标记交付、JSON 语法、实体身份,还是页面内容不一致。逐项结论更实用,因为你可以直接看到发生了什么,以及接下来该检查什么。
Schema Markup Validator 说我的页面没问题,这里为什么还能查出毛病?
Schema Markup Validator 主要检查词汇是否合规。本工具还会检查原始 HTML 是否包含标记、@id 是否冲突、引用能否解析、标记与页面是否一致,以及身份地址能否访问。两者回答的问题不同,适合配合使用。
开发者工具里明明能看到标记,这里却说没有。谁对?
开发者工具通常显示 JavaScript 执行后的 DOM,而本工具读取的是原始响应体。如果标记只在渲染后出现,两边的结果都可能正确。若希望不执行 JavaScript 的爬虫也能读取,请在服务器响应中直接输出 JSON-LD。
解析器会忽略坏掉的 JSON-LD,那它是不是无害?
结构化数据解析器会忽略无效的 JSON-LD,但有些系统仍可能把脚本内容当作页面文本处理。因此不要把无效标记视为无害,尤其当它与页面内容不一致时,应尽快修复或删除。
Google 已经不给 FAQPage、HowTo 出富结果了,我该删掉这些标记吗?
不必仅因为富结果停止展示就删除。内容准确的 FAQPage 或 HowTo 标记仍可能符合 Schema.org。只要它保持正确且维护成本可接受,就可以保留;如果已经过时或与页面冲突,则应更新或删除。
把这里查出的问题都修完,AI 引擎会更多地引用我吗?
目前没有可靠证据表明,仅靠修正 JSON-LD 就能增加 AI 引用。更合适的做法,是把结构化数据用于提供准确、一致的实体信息,而不是把它当作排名或引用保证。
相关阅读