结构化数据与 JSON-LD：实用 SEO 实施指南

前端工程

结构化数据可以帮助搜索引擎理解页面内容。JSON-LD 是目前最常用的实现方式之一，因为它把机器可读的数据和可见 HTML 分离，维护起来更清晰。

结构化数据可以让页面具备展示增强搜索结果的资格，但不保证一定出现富结果。Google 和其他搜索引擎会根据页面质量、查询意图、资格规则和很多其他信号决定最终展示方式。

常用参考：

结构化数据有什么作用

结构化数据为页面内容提供明确语义。搜索引擎不只看到文字，还能理解页面是一篇文章、一个产品、一个软件应用、一组面包屑导航、一个 FAQ 区块，或其他可识别实体类型。

好的结构化数据应该：

  • 与页面可见内容一致。
  • 使用最具体且相关的 Schema.org 类型。
  • 包含必需字段和推荐字段。
  • 在内容变化后保持准确。
  • 上线前通过验证。

不要用结构化数据描述用户看不到的内容。这是常见质量问题，也可能让标记失去展示资格。

为什么通常选择 JSON-LD

结构化数据有多种格式，但 JSON-LD 通常最容易维护。

格式 添加方式 维护成本
JSON-LD <script type="application/ld+json"> 代码块 与 HTML 分离，维护清晰
Microdata 写在 HTML 元素属性里 模板改动时容易损坏
RDFa 写在 HTML 元素属性里 功能强，但复杂度更高

使用 JSON-LD 后，前端 HTML 结构变化时，不必到处修改结构化数据属性。

JSON-LD 基础结构

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "结构化数据与 JSON-LD：实用 SEO 实施指南",
  "description": "学习如何安全添加 JSON-LD 结构化数据。",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

核心字段包括：

  • @context：通常是 https://schema.org。
  • @type：Schema.org 类型，例如 Article。
  • 属性字段：描述实体的信息，例如 headline、author、datePublished。

Article 标记

编辑类内容可以使用 Article、BlogPosting 或 NewsArticle。普通博客文章通常适合 BlogPosting。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "如何安全拆分 PDF",
  "description": "一篇关于提取和拆分 PDF 页面的方法指南。",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

日期要真实。不要为了让内容看起来更新，就在没有实际修改时刷新 dateModified。

面包屑结构化数据可以帮助搜索引擎理解页面层级。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

JSON-LD 中的面包屑路径应该与用户能理解的页面导航一致。

FAQPage 标记

只有当页面上真的有可见问答内容时，才添加 FAQPage 标记。不要为了争取富结果而硬塞虚假的 FAQ。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据能保证富结果展示吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不能。结构化数据可以让页面具备资格，但搜索引擎会决定是否展示增强结果。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LD 是否必须匹配页面可见内容？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "是的。结构化数据应该描述用户也能在页面上看到的内容。"
      }
    }
  ]
}
</script>

FAQ 标记不是抢占搜索结果空间的捷径。只有当它确实能帮助用户理解页面时才使用。

SoftwareApplication 标记

在线工具、Web App 或可下载软件页面，可以使用 SoftwareApplication 描述页面提供的功能。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

只填写真实字段。如果添加评分、评论、价格或平台支持说明，它们必须能被页面可见内容和真实产品状态支撑。

多个 JSON-LD 区块

一个页面可以包含多个结构化数据实体。例如，一篇博客文章也可以有面包屑。

可以使用多个独立脚本：

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

也可以使用数组：

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

在模板系统里，多个独立脚本通常更容易维护。

验证流程

上线前建议使用简单流程：

  1. 从页面同一份元数据生成 JSON-LD。
  2. 检查它是不是合法 JSON。
  3. 用 富结果测试 检查 URL 或代码。
  4. 页面被索引后，在 Search Console 中监控结构化数据报告。
  5. 大改设计、路由或 CMS 模板后重新检查。

验证通过说明语法和部分资格规则满足要求，但仍然不保证一定出现富结果。

常见错误

标记与可见内容不一致

如果 JSON-LD 里写了评论、FAQ、价格或作者信息，用户也应该能在页面上看到或验证这些信息。

类型选择错误

不要因为产品富结果看起来吸引人，就把所有工具页都标成 Product。类型必须匹配页面实际内容。

虚构评分或评论

评论和评分标记需要真实、可见的评论内容。不要编造聚合评分。

日期不真实

datePublished 和 dateModified 应该反映真实内容生命周期。只有发生有意义修改时才更新修改日期。

URL 无法访问

图片、Logo、规范页和页面 URL 应该使用绝对地址，并且可以被抓取。

多语言页面不匹配

多语言站点中，每个本地化页面的结构化数据应使用该页面语言，并配合页面里的 canonical 和 alternate 链接策略。

实施建议

  • 从 CMS 或页面元数据生成结构化数据，不要每页手写。
  • 正确转义用户生成内容，保证 JSON 合法。
  • 每类页面维护一个可复用模板。
  • 测试有代表性的页面，不要只测首页。
  • 改路由、Slug、作者资料或图片生成逻辑后重新验证。
  • 优先处理错误，警告可以作为后续优化项。

发布前清单

发布 JSON-LD 前确认：

  • 标记描述的是页面可见内容。
  • Schema.org 类型符合页面。
  • 必填字段完整。
  • URL 是绝对地址且可抓取。
  • 日期、作者、标题和描述与页面一致。
  • 适用页面通过富结果测试。
  • 发布后继续看 Search Console 报告。

结构化数据不是强行获取富结果的技巧，而是让页面含义更清楚的方式。当它准确、可维护，并与可见内容一致时，搜索引擎更容易正确理解页面。

本站提供浏览器本地工具，免注册即可试用 →

#JSON-LD#结构化数据#SEO#Schema.org#富摘要