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