JSON-LD 结构化数据验证工具

粘贴HTML或原始JSON-LD即可验证FAQPage、BreadcrumbList、Article等结构化数据,快速发现缺失的必需属性以及Google富媒体搜索结果中常见的错误。

JSON-LD 结构化数据验证工具是什么

JSON-LD是一种标记格式,用于以机器可读的方式告诉Google页面内容的实际类型——是FAQ、文章还是面包屑导航等。只需将其以JSON形式写入<script type="application/ld+json">标签内,就能在完全不影响可见HTML的情况下添加结构化数据。如果实现正确,搜索结果中可能会出现富媒体搜索结果,例如可展开的FAQ摘要或面包屑导航,即使排名没有变化,也有助于提升点击率。

本工具会自动从粘贴的HTML中提取<script>代码块(也可直接输入原始JSON-LD),并针对检测到的FAQPage、BreadcrumbList以及Article类型(Article / NewsArticle / BlogPosting)逐一核对Schema.org规定的必需属性是否齐全。同时还会标记出容易在不知不觉中导致富媒体搜索结果失效的典型错误,例如acceptedAnswer.text被误写成对象而非纯字符串、position编号不连续等。在发布前或修改后进行这样的检查,可以比事后在Search Console中才发现问题更早地捕捉到错误。

JSON-LD 结构化数据验证工具的使用方法

  1. 准备页面的HTML源码或JSON-LD 可以是通过“查看网页源代码”获得的完整HTML,也可以只提取<script>标签中的内容。
  2. 粘贴到输入框,或通过URL获取 既可以直接粘贴文本,也可以针对已发布的页面输入其URL来获取内容。
  3. 查看检测到的实体及其验证结果 如果输入内容中包含多个<script>代码块或多个@type实体,每一个都会单独列出并验证。
  4. 修正标记为“缺失”或“警告”的项目 每个属性都会显示正常、警告或缺失中的一种状态,可据此直接定位到原始JSON-LD中的对应位置进行修正。
  5. 修正后重新验证,再进行发布 将修正后的JSON-LD重新粘贴进行验证,确认所有项目均显示正常后,再将修改应用到实际页面。

用好本工具的小技巧

  • FAQPage的acceptedAnswer务必将回答内容作为纯字符串放入text属性中,如果填入对象或数组,Google的富媒体搜索结果将无法识别。
  • BreadcrumbList的position需要从1开始连续编号,如果存在缺号或重复,将无法被识别为正确的面包屑导航。
  • Article的headline建议控制在110个字符以内,这是Google给出的大致标准,过长的标题在搜索结果中可能会被截断显示。
  • 即使粘贴整个HTML页面也没问题,工具会自动提取 <script type="application/ld+json"> 代码块中的内容进行验证,只粘贴JSON本身也同样有效。
  • 如果一个页面中放置了多种结构化数据,建议分别写在不同的 <script> 标签中,这样更便于维护和排查问题。

这些场景中可以派上用场

将FAQPage提交至Search Console前的确认

可以在发布前发现acceptedAnswer.text格式错误等会导致FAQ富媒体搜索结果无法显示的典型问题。

网站结构调整后检查面包屑导航

当分类或URL发生变化时,可以一次性确认BreadcrumbList的position编号是否仍然正确。

审查博客文章的Article结构化数据

可以快速检查headline是否超长、author/datePublished/image等推荐属性是否缺失。

排查富媒体搜索结果测试工具报错的原因

Google官方工具报错时,可以先用本工具缩小范围,明确具体是哪个属性存在问题,再进行修正。

词汇表

JSON-LD
一种以JSON格式编写结构化数据的规范。以独立代码块的形式嵌入<script type="application/ld+json">标签内,可以在不改变现有HTML布局的情况下添加面向搜索引擎的信息。
Schema.org
由Google、微软、雅虎等共同制定的结构化数据词汇表,定义了FAQPage、Article等各类内容对应的类型(@type)及其属性。
FAQPage
用于向Google说明常见问题及答案的Schema.org类型。mainEntity中包含Question类型的数组,每个Question都必须包含name(问题文本)和acceptedAnswer.text(答案文本)。
BreadcrumbList
表示面包屑导航(页面在站内层级结构中的位置)的Schema.org类型。itemListElement中包含ListItem数组,每个元素都必须包含position(顺序)、name和item。
富媒体搜索结果
在搜索结果中显示超出普通标题和描述的额外信息(例如FAQ折叠展开显示、面包屑导航显示等)的功能,前提是结构化数据已被正确实现。
必需属性
Google要求某类型富媒体搜索结果得以显示所必须具备的属性,缺失时该富媒体搜索结果将完全无法显示。相对而言,推荐属性即使缺失也可能显示,但具备时效果更佳。
Google Search Console
用于查看网站搜索表现及索引状态的Google官方工具,其“增强功能”报告可以显示Google实际是如何解读已发布页面中的结构化数据的。

常见问题

JSON-LD是在独立于HTML正文的<script>标签内以JSON格式记录结构化数据的方式。而Microdata和RDFa则是直接嵌入到HTML标签的属性(如itemprop)中,因此需要改动现有的HTML结构。Google近年来推荐使用JSON-LD,凭借其易于实现的特点,目前已成为主流方式。

结构化数据本身并不是直接影响搜索排名的因素。但如果FAQPage、BreadcrumbList等被正确实现,搜索结果中可能会显示富媒体搜索结果(例如FAQ的折叠展开显示、面包屑导航显示),从而有望提升点击率(CTR)。

Schema.org规范要求acceptedAnswer.text必须是纯文本字符串。如果误将text的值设置为对象或数组(例如嵌套成{"value": "回答内容"}这样的结构),Google的富媒体搜索结果测试工具会将其标记为警告或错误。

完全没有问题。FAQPage、BreadcrumbList、Article等多种类型的结构化数据,可以分别写在同一页面中不同的 <script type="application/ld+json"> 标签内。本工具也会从一次输入中一并检测并验证多个代码块、多个实体。

可以在Google Search Console的“增强功能”报告中查看,或使用Google官方的“富媒体搜索结果测试”工具,针对实际已发布的URL确认Google是如何解析的。本工具更适合在发布前的草稿阶段或修改后进行自我检查时使用。
工具君

闲话 ― JSON-LD为何取代了Microdata与RDFa

JSON-LD(JSON for Linking Data)最初是W3C社区小组在2010年代初期制定的一种关联数据格式。与Microdata、RDFa等传统结构化数据写法(直接将标记嵌入HTML元素的属性中)不同,JSON-LD可以作为一段独立的JSON,完整地写在<script>标签内,因此在添加或删除结构化数据时完全不会破坏现有的HTML布局。Google从2015年前后开始将JSON-LD定位为推荐格式,如今的富媒体搜索结果文档也几乎都以JSON-LD的写法为前提进行说明。

本网站自身的FAQ区块也是如此运作的:作者只需撰写一次问答内容,系统便会在后台自动生成对应的FAQPage格式JSON-LD。这样一来,人类阅读的可视化手风琴列表与搜索引擎读取的结构化数据无需重复手动维护两份,其中一处修改后另一处也会自动同步,从而避免了显示内容与结构化数据不一致的问题。

即使JSON在语法上完全正确,如果缺少Schema.org要求的必需属性,或者缺少Google建议提供的推荐属性,富媒体搜索结果(例如搜索结果中的FAQ展开显示、面包屑导航显示等)也可能无法生效。acceptedAnswer.text这类嵌套层级较深的属性,正是实现时容易出错的典型案例。在发布前使用此类工具进行机械化检查,可以比事后在Search Console的“增强功能”报告中才发现错误更早地发现问题。