什么是 JSON-LD？
JSON-LD 的全称是 JavaScript Object Notation for Linked Data，可以理解为“用 JSON 表达网页实体关系的一种结构化数据格式”。普通网页主要写给人看，搜索引擎虽然可以抓取文字、标题、图片和链接，但很难百分之百判断页面中的每一段信息分别代表什么。JSON-LD 的价值在于，它用机器更容易理解的方式说明页面里有哪些实体、实体之间有什么关系，以及这些信息应该如何被解释。
例如，一篇文章页面里会有标题、作者、发布时间、摘要、主图和发布机构。用户看到这些内容时能自然理解它们的含义，但搜索引擎需要额外线索。Article 类型的 JSON-LD 可以明确告诉搜索引擎：这个页面的主体是一篇文章，headline 是标题，author 是作者，datePublished 是发布时间，publisher 是发布机构。这样做不能强制搜索引擎展示富媒体结果，但它能降低理解成本，提高页面被正确解析的概率。
JSON-LD 通常放在 <script type="application/ld+json"> 标签中。它不会直接改变页面视觉效果，也不需要把属性塞进每一个 HTML 元素里。对站长来说，这种方式更容易维护，因为结构化数据与页面布局相对分离：前端模板可以继续服务用户体验，JSON-LD 则专门服务搜索引擎、知识图谱和其他数据消费方。
JSON-LD 适合哪些页面？
常见适用场景包括文章页、产品页、FAQ 页面、面包屑导航、本地商家页面、课程页面、活动页面和软件应用页面。并不是每个页面都需要复杂的结构化数据。最稳妥的做法是从页面真实内容出发：页面展示了什么，就生成什么；页面没有展示的信息，不要为了“看起来更丰富”而强行写入。
对于内容站，Article、BlogPosting、FAQPage、BreadcrumbList 往往最常见。对于电商站，Product、Offer、AggregateRating、Review 需要特别谨慎，因为价格、库存、评分和评论必须与页面展示内容一致。对于本地服务类网站，LocalBusiness、PostalAddress、OpeningHoursSpecification 可以帮助搜索引擎识别商家名称、地址、电话和营业时间。
JSON-LD 与 Microdata 有何区别？
Microdata 是另一种结构化数据写法，它把 itemscope、itemtype、itemprop 等属性直接写在 HTML 标签上。比如一个产品名所在的 <h1> 可以带上 itemprop="name"，价格所在的元素可以带上 itemprop="price"。这种写法的优点是数据与可见内容靠得很近，不容易完全脱离页面；缺点是维护成本较高，尤其当页面模板复杂、组件嵌套深、前后端多人协作时，结构化数据属性会散落在许多 HTML 节点中。
JSON-LD 的写法更集中。你可以在一个脚本块里描述完整实体，而不必修改每个展示元素。对于 WordPress 主题、Shopify Liquid 模板、Nuxt 或其他现代前端项目，JSON-LD 更适合做成可复用组件或由工具生成。它也更便于版本控制、代码审查和自动化测试，因为结构化数据通常是一个清晰的对象。
维护方式的差异
Microdata 更像“把标签贴在页面元素上”，JSON-LD 更像“给页面附上一份机器可读说明书”。如果你的页面由多个模块拼成，Microdata 往往需要进入每个模块修改属性。JSON-LD 则可以在页面顶部、底部或组件统一输出。对非技术团队来说，JSON-LD 也更容易复制、检查和发送给开发人员。
风险控制的差异
两者都必须遵守同一个原则：结构化数据要与用户可见内容一致。JSON-LD 因为和页面视觉代码分离，所以更容易出现“页面内容改了，JSON-LD 没改”的问题。上线前应建立检查清单：标题是否一致，价格是否一致，库存是否一致，FAQ 的问题与回答是否在页面可见，面包屑链接是否真实存在。这个工具提供的可视化预览可以帮助你先看清实体关系，但最终仍要以页面真实内容和官方测试结果为准。
如何把生成的代码嵌入 WordPress？
WordPress 的嵌入方式取决于你是否使用主题、区块编辑器、SEO 插件或自定义代码插件。最简单的方式是使用支持插入 head 或 footer 代码的插件，把生成器输出的 <script type="application/ld+json"> 代码粘贴到对应页面。适合单页落地页、少量文章页或临时验证场景。
如果你管理的是长期内容站，更推荐把 JSON-LD 写进主题模板或通过自定义字段动态生成。例如文章页可以从 WordPress 的标题、摘要、特色图片、作者和发布日期读取数据，再输出 Article JSON-LD。这样当编辑修改文章标题或发布日期时，结构化数据会跟着更新，减少人工复制错误。
WordPress 操作建议
第一步，确认页面类型。文章页使用 Article 或 BlogPosting，产品页如果由 WooCommerce 管理，优先检查 WooCommerce 或 SEO 插件是否已经输出 Product 结构化数据，避免重复。第二步，把工具生成的 JSON-LD 复制到页面专属代码区域，或交给开发者放入 single.php、page.php、区块模板或主题组件中。第三步，发布前查看页面源码，搜索 application/ld+json，确认代码确实出现在最终 HTML 中，而不是只存在于后台编辑器里。
如果同一个页面已经由 SEO 插件输出了结构化数据，不要盲目添加第二份相同类型的数据。重复的 Article、Product 或 FAQPage 可能让测试结果变得混乱。更好的做法是选择一个权威来源：要么使用插件配置，要么关闭插件对应输出，改用自定义 JSON-LD。
如何把生成的代码嵌入 Shopify？
Shopify 站点通常通过 Liquid 模板控制页面输出。产品页常见文件包括 main-product.liquid、product.json 对应的 section，或主题中的 product snippet。你可以把生成器输出的 Product JSON-LD 放到产品模板里，但实际项目中更推荐使用 Liquid 变量动态填充名称、图片、价格、货币、库存和品牌。
例如，产品名称应来自 product.title，价格应来自当前变体，图片应来自 product.featured_image，库存状态应根据可售状态输出 https://schema.org/InStock 或 https://schema.org/OutOfStock。这样当商家在后台更新价格或库存时，JSON-LD 不会停留在旧值。
Shopify 操作建议
先打开主题代码编辑器，定位产品页 section 或 snippet。把工具生成的代码作为结构参考，而不是永远手动粘贴固定值。然后用 Liquid 变量替换示例内容。保存后打开一个真实产品页，在浏览器中查看源码，确认最终输出的是标准 JSON，而不是残留了未解析的 Liquid 标记。
Shopify 商店还要特别注意多币种、变体价格和应用重复输出。有些 SEO 应用、评论应用、订阅应用会自动插入 Product、Review 或 AggregateRating 结构化数据。如果你同时手写一份，Google 的测试工具可能看到多个产品实体。上线前建议保留一份主数据源，并确保评分、评论数、价格和库存与页面可见内容一致。
如何嵌入自定义 HTML 网站？
自定义 HTML、Nuxt、Next、Astro、Laravel、Rails 或其他项目都可以输出 JSON-LD。最通用的方法是在页面模板中加入脚本标签：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Example Article"
}
</script>
这段代码可以放在 <head> 中，也可以放在 <body> 中。关键不是位置，而是搜索引擎抓取最终 HTML 时能够看到有效 JSON-LD。如果你的网站大量依赖客户端渲染，要确认搜索引擎和测试工具能看到注入后的脚本。对重要页面，服务端渲染或静态生成通常更稳妥。
自定义站点操作建议
在静态 HTML 中，你可以直接复制生成器输出的完整代码。对于模板型网站，应把字段绑定到数据库或 CMS 数据，避免每个页面手动维护。对于前端框架，要注意 JSON 序列化安全，避免用户输入破坏脚本结构。通常做法是使用框架提供的 head 管理能力或把 JSON 对象安全序列化后写入 application/ld+json。
嵌入后请检查三件事：页面源码里是否存在脚本标签；脚本内容是否是合法 JSON；结构化数据中的 URL、图片、价格、日期、作者等字段是否与页面可见内容一致。不要把测试页面、占位图、虚假库存或不存在的评价写进正式页面。
如何使用 Google Rich Results Test 进行验证？
Google Rich Results Test，即 Google 富媒体结果测试工具，是上线前必做的检查。它可以读取一个在线 URL，也可以直接测试一段代码。对于还没有发布的页面，可以先使用代码测试，把生成器输出的脚本连同必要 HTML 片段粘贴进去。对于已经发布的页面，建议使用 URL 测试，因为它更接近 Googlebot 实际抓取页面时看到的结果。
验证步骤
第一步，打开 Google Rich Results Test。第二步，选择 URL 或代码模式。第三步，运行测试并等待结果。第四步，查看检测到的结构化数据类型，例如 Article、Product、FAQPage 或 BreadcrumbList。第五步，展开每个项目，检查错误、警告和字段详情。
错误通常代表必须修复的问题，例如缺少必填字段、JSON 格式无效、URL 不可访问。警告不一定阻止富媒体结果，但可能影响展示完整度，例如缺少推荐字段。修复后应再次测试，直到关键错误消失。对于产品和评论类数据，还要结合 Google 搜索中心文档确认当前政策，因为这些类型更容易因为页面内容不一致或滥用标记而失去资格。
验证后的上线清单
验证通过并不代表一定获得富媒体展示。Google 是否展示富媒体结果，还会受到页面质量、站点信任、抓取状态、内容相关性和搜索结果布局影响。因此上线后还应在 Google Search Console 中观察增强功能报告、索引状态和实际搜索表现。如果 Search Console 报告结构化数据错误，应以报告中的具体 URL 为单位排查，而不是只看模板代码。
建议每次改版、换主题、安装 SEO 插件、调整产品模板或修改 FAQ 内容后重新验证。结构化数据不是“一次生成永久有效”的资产，它和页面内容一样需要维护。把生成、嵌入、验证、监控放进发布流程，才能真正降低搜索引擎误解页面的风险。
使用本生成器的推荐流程
先选择最贴合页面内容的 Schema 类型，不确定时从最简单的类型开始。然后填写页面真实存在的字段，不要为了通过测试而添加用户看不到的信息。接着观察右侧关系图，确认实体之间的层级是否符合预期。最后复制 JSON-LD，嵌入 WordPress、Shopify 或自定义网站，并使用 Google Rich Results Test 验证。
如果验证结果出现错误，回到表单逐项修改。常见问题包括 URL 漏写协议、图片地址不可公开访问、日期格式不规范、价格缺少货币、FAQ 回答为空、面包屑 position 顺序不正确。修复这些基础问题后，再考虑更高级的 Schema 扩展。
JSON-LD 的目标不是“堆更多字段”，而是准确表达页面已经提供的内容。结构化数据越真实、越稳定、越容易维护，它对长期 SEO 和站点质量的帮助越可靠。