1 · 覆盖（交付）
—不渲染的爬虫到底收不收得到这些标记？
免费 Schema 标记检测工具
输入页面 URL，按 Schema 审计手册的走法逐级判定它的 JSON-LD：不渲染的爬虫收不收得到、能不能解析、实体图接不接得上、页面和标记的断言对不对得上。每条负面结论都引用证据原文。这里没有 0 到 100 的综合分，这正是设计意图。
只抓取一次原始 HTML，不执行 JavaScript：这正是不渲染的 AI 爬虫收到的响应体，也是浏览器开发者工具回答不了的交付问题。Google 的两个验证器负责词汇合规与富结果资格；本工具负责它们看不到的那几级：交付、实体图一致性，以及属实性中机器可验的部分。
四级台阶
怎么读这些结论
- ✅ 机器能测量的部分，这一级成立。
- ⚠️ 有事项需要你自己判断或动手核实，具体见对应发现。
- ❌ 发现了明确的问题形态，证据就引用在旁边。
- N/A 页面上没有这一类可判定的对象。这不是失败。
2 · 有效
—每个块都能解析吗？词汇表是 schema.org 吗？
3 · 一致
—实体图接得上吗？
4 · 属实
—页面和外部世界认同标记的断言吗？
人工对照阅读
人工判断标记断言的每一项事实（价格、评分、地址、描述）都能在页面上看到吗？
永远不由机器判定。这是唯一有明文处罚记录的检查，也是没有任何工具会替你跑的检查：把输出的块和渲染后的页面并排放好，逐项确认断言的事实确实可见，每个模板两分钟。当一个块无论如何改不到与页面一致时，删块，永远不要删页面上的事实。 手册对应章节
为什么没有综合分
Schema 审计手册在严重级别一节的结尾写明了本工具遵守的规则：不要把发现压缩成一个分数。公式不公开的 0 到 100 综合分是传闻，不是测量。这与可引用性检测工具对可引用性评分的态度一脉相承。
工具交付的是手册真正的交付物：逐条发现加引用证据。被定义成两种东西的 @id、返回 404 的 sameAs 目标、写在未来的日期，每一条你都能在几秒内对照自己的页面复核。
检测流程
- 抓取页面一次，只取原始 HTML，不执行 JavaScript。这是刻意为之：它就是不渲染的 AI 爬虫摄取的响应体。收集其中全部 JSON-LD 脚本块。
- 逐块解析并检查 @context。解析失败的块会引用原文而不只是计数，因为解析器丢弃它之后，实时抓取的模型仍会把它当页面文本读进去。
- 读实体图：同一 @id 被定义成两种东西、指向页面上不存在节点的引用、被重复定义的实体，以及页面上有没有 Organization 或 Person 主干。
- 核对机器核对得了的断言：标题对照可见标题、作者的形态与可见性、日期自洽性；再对每个 sameAs 与 logo 地址各做一次存活探测，至多十个。
- 按四态结论逐级报告（✅ / ⚠️ / ❌ / 不适用），每条负面结论都引用确切证据。
这个检测能判什么，不能判什么
- 这是单页视角。某个 @id 引用若由站内另一页的标记定义，这里会显示为未解析；发现文本会说明这一点，而不是断言它坏了。跨页的实体图阅读属于审计手册的整站抓取步骤。
- 解析与 @context 之外的词汇合规是 Schema Markup Validator 的问题，Google 功能资格是 Rich Results Test 的问题。本工具检查的是它们都看不到的那几级，不替代其中任何一个。
- 探测结果说的是存活，不是身份。能应答的 sameAs 目标仍可能指向母品牌或同名者，确认是否同一实体要靠你阅读。拒绝数据中心访问的站点报为无法核实，而不是失效；只有明确应答 404/410 才称为失效。
- 不要期待干净的标记带来引用增长。Ahrefs 对 1885 个页面的对照实验没有发现有意义的变化，Google 也明确结构化数据不是生成式搜索的必需项。标记的诚实价值是清除隐患、让实体身份可解析，证据见手册第 1 节。
- 完全没有标记的页面并不算失败。覆盖卡会告诉你属于哪种情形：从未输出，还是由客户端脚本注入而 AI 爬虫根本看不到。若决定部署，Schema 部署手册是从零开始的阶梯。
常见问题
这个工具为什么拒绝给 0 到 100 的 Schema 评分？
因为它落地的那本审计手册明文禁止：交付物是逐条发现加严重级别，公式不公开的综合分是传闻而不是测量。两个工具算出来的分数互不相同，也都无法验证。这里每条结论都引用证据，你可以逐条对照自己的页面复核；一个数字除了虚假的权威感之外什么也添不上。
Schema Markup Validator 说我的页面没问题，这里为什么还能查出毛病？
因为验证器查的是词汇合规，那只是四级台阶里的第二级。被定义成两种东西的 @id、解析不到任何节点的引用、没有外部来源能佐证的作者、失效已久的 sameAs 目标，这些在任何验证器里都是绿色的，因为它们都不是词汇错误。审计手册的经验法则正是：第三、四级的发现，恰恰是验证器展示不了的那部分。
开发者工具里明明能看到标记，这里却说没有。谁对？
都对，而这正是发现本身。开发者工具显示的是执行完 JavaScript 之后的渲染 DOM；本工具读的是原始响应体，也就是 GPTBot、ClaudeBot、PerplexityBot 收到的内容，目前没有观察到它们执行 JavaScript。由标签管理器或前端框架注入的标记只存在于前者：发布了，但没有交付给任何相关方。解决办法是改为服务端输出。
解析器会忽略坏掉的 JSON-LD，那它是不是无害？
不是，这也是整个审计里最反直觉的一点。解析器丢弃无效块，所以好事不会发生；但实时抓取页面的模型（带浏览的 ChatGPT、Perplexity）会把这个块当作页面上的更多文本读进去。Mark Williams-Cook 为此发布过一家虚构公司，其地址只写在故意弄坏的 JSON-LD 里，ChatGPT 和 Perplexity 照样返回了那个地址。坏块断言什么，什么就仍在被端给真正要紧的消费者。
Google 已经不给 FAQPage、HowTo 出富结果了，我该删掉这些标记吗？
不该。过时但属实的标记不构成发现：它仍是有效的 Schema.org，没有处罚，删除也换不来任何收益。清理这类标记是一张工作量很大而回报为零的工单，审计预算常常就耗死在这里。本工具把这类类型作为备注呈现，正是为了避免有人把它当任务立项。标记只有在断言与页面矛盾时才值得删除。
把这里查出的问题都修完，AI 引擎会更多地引用我吗？
证据的答案是否定的。Ahrefs 追踪了 1885 个添加 JSON-LD 的页面并设对照组，没有发现有意义的引用变化；Google 也明确结构化数据不是生成式搜索的必需项。干净的审计买到的东西更窄，但仍然值得：没有任何标记断言页面否认的事实（唯一有明文处罚的类别），以及一个指向单一身份、不自相矛盾的实体图。把 Schema 当身份基础设施看待，而不是引用杠杆。