Schema.org JSON-LD 解密：新手指南

“结构化数据”听起来可能有些令人生畏，但它本质上是为搜索引擎提供清晰、标准化页面内容摘要的一种方式。谷歌、必应等搜索引擎依赖这些结构化信息来展示丰富网页摘要 (rich results) ——那些带有图片、评分或面包屑导航的醒目搜索结果片段。本文将详细解析如何为博客文章手动编写 Schema.org 结构化数据，并采用 JSON-LD 格式，同时以 BlogPosting (文章) 和 BreadcrumbList (导航路径) 为例进行说明。我们将解释 JSON 中每个部分的含义——从 @type​、@id​ 到 headline​ 和 publisher​——以及 WebSite、WebPage、BreadcrumbList 和 BlogPosting 等实体之间是如何关联的。读完本文，即使你使用的是没有插件的自定义博客，也应该能自信地编写自己的 schema 标记。

Schema.org 和 JSON-LD 是什么（为什么你应该关心）？

可以将结构化数据看作是你博客文章的一种“营养标签”或速查表。它以标准化的方式明确地告诉搜索引擎你内容的关键细节。Schema.org 是一个制定这套标准词汇（如 BlogPosting、WebPage、ImageObject 等）的组织（由谷歌、微软等公司支持）。JSON-LD (JavaScript Object Notation for Linked Data) 是我们用来在页面上嵌入这些信息的格式——它基本上是一个位于 HTML 中的 JSON 脚本。这是谷歌推荐的格式，因为它清晰且与可见内容分离（相比于将微数据分散在 HTML 标签中，这种方式更不容易出错）。

简单来说，添加 schema 标记就像给搜索引擎一份结构化的博客文章“简历”。搜索引擎不再需要猜测标题是什么、作者是谁、发布日期是什么等等，因为你已经明确提供了这些信息。根据谷歌的说法，“结构化数据是一种用于提供页面信息和对页面内容进行分类的标准化格式”。通过这样做，你可以帮助搜索引擎更好地理解你的页面，并以更丰富的方式呈现它。例如，带有文章 schema 的页面有资格获得更丰富的搜索结果，如带有更大图片的标题文本，或在摘要中显示面包屑导航。这些增强功能使你的搜索结果更具吸引力，并可能提高点击率——研究表明，带有结构化数据的页面点击率提高了 25% ！

JSON-LD 与传统 Meta 标签对比： 这与我们熟悉的 <meta>​ 标签（如 description 或 keywords）有何不同？Meta 标签确实很重要，但它们只提供非常基本的信息（标题、描述等），主要用于索引和简单的摘要。 “Meta 标签是基础的 HTML 标签，用于告知搜索引擎诸如页面标题和描述之类的信息……Schema 标记则更进一步。它提供关于你博客文章的详细信息，包括作者、主题以及发布时间。” （How to Implement Schema Markup for Blog Posts）概括而言，meta 标签影响搜索结果片段的文本内容，而 schema JSON-LD 则可以影响片段的​结构​和额外元素（例如显示面包屑导航、发布日期、评论的星级评分等）。它不会直接提高你的排名，但它能改善你在搜索结果中的外观，从而显著增加用户互动。

实例解析：博客文章的 JSON-LD 标记（含面包屑导航）

让我们从一个例子开始。以下是一个博客文章页面的 JSON-LD 结构化数据示例，分为两部分：一部分用于博客文章内容 (BlogPosting​ schema)，另一部分用于面包屑路径 (BreadcrumbList​ schema)。在实际操作中，这些代码会放在 HTML 的 <script type="application/ld+json">​ 标签内。

BlogPosting schema 示例（更多详见 BlogPosting - Schema.org Type）：

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/my-first-post",
  "url": "https://example.com/blog/my-first-post",
  "headline": "My First Blog Post",
  "image": "https://example.com/images/first-post.jpg",
  "datePublished": "2025-05-01T14:30:00Z",
  "dateModified": "2025-05-02T10:00:00Z",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Blog",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/images/logo.png"
    }
  },
  "description": "This is a short summary or excerpt of my first blog post.",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/my-first-post"
  }
}

BreadcrumbList schema 示例（更多详见：BreadcrumbList - Schema.org Type）：

{
  "@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": "My First Blog Post",
      "item": "https://example.com/blog/my-first-post"
    }
  ]
}

如果这些看起来让人眼花缭乱，别担心！接下来，我们将逐个解析这些示例中的主要字段和实体，以理解它们的含义以及它们之间的相互关系。

解析博客文章 Schema：关键字段详解

上述 BlogPosting JSON-LD 代码段包含多个属性。每个属性在向搜索引擎描述你的博客文章方面都扮演着特定角色。让我们逐一了解主要的属性：

  • ​ ​@context​​ – 该字段定义了 JSON-LD 的上下文或词汇表。我们将其设置为 "https://schema.org"​，表示所使用的术语（如 headline、publisher 等）均来自 Schema.org 的词汇表。 @context​ 实际上是告诉解析器：“请根据 Schema.org 的定义来解释这些键。”
  • ​ ​@type​​ – 该字段指明我们正在描述事物的类型。此处为 "BlogPosting"​，这是博客文章的 schema 类型（一种更具体的 Article 子类型）。这一点至关重要：@type​ 就像告诉搜索引擎：“这个 JSON 对象描述的是一个 BlogPosting（博客文章）。 ” 类似地，在我们的数据中，作者有 @type: "Person"​，发布者有 @type: "Organization"​ 等。每个 @type​ 值都对应 Schema.org 中该实体的定义。
  • ​ ​@id​​ – 该字段为此特定项目提供唯一标识符。在 JSON-LD 中，@id​ 通常是一个 URL (或 URI)，用以唯一标识所描述的实体。在我们的示例中，我们使用博客文章的 URL 作为其 @id​。这可能看起来与 url​ 字段有些重复（确实，我们在这里将两者设置为了相同的 URL），但 @id​ 有其特殊用途：它允许其他 schema 项目明确地引用此对象。可以将 @id​ 视为数据的永久链接或锚点。例如，如果同一位作者出现在多篇文章中，我们可以为该作者指定一个 @id​，并在其他地方引用该 @id​ 以将数据链接起来。 “@id 创建了唯一标识符，而 url 属性则告诉搜索引擎在哪里找到该实体的主页。两者都是必需的……” 实际上，许多简单的 schema（如上例）会将 @id​ 设置为页面 URL，并且也包含一个 url​ 字段——这同时满足了标识和链接的需求。
  • ​​url​​ – 项目的公开 URL（通常是网页 URL）。在我们的 BlogPosting 中，url​ 是可以阅读该博客文章的链接。这有助于提高清晰度，尽管如果 @id​ 与 URL 相同，搜索引擎已经知道了地址。包含 url​ 是一个好习惯，可以明确告知爬虫“这是此内容的网页 URL”。在某些 schema 中（如上面的 BreadcrumbList），每个 ListItem 的 item​ 字段实际上就是指向该面包屑页面的 URL。
  • ​​headline​​ – 顾名思义：博客文章的标题。这应该与你文章页面上的标题匹配或非常相似。在我们的示例中，"headline": "My First Blog Post"​ 清晰地标明了文章的名称。（保持简洁；谷歌可能会截断过长的标题。）
  • ​​image​​ – 代表该文章的图片 URL。这通常是你文章的特色图片（封面图）。在 JSON-LD 中，你可以提供单个字符串 URL、URL 数组，或使用 ImageObject​。我们的示例保持简单，只用了一个图片 URL。谷歌的指南鼓励使用高分辨率图片，有时甚至是多个版本（用于不同的宽高比），但至少应在此处包含一个优质的图片 URL，这样你的文章才可能在搜索结果中以漂亮的缩略图形式显示。
  • ​​datePublished​​ – 文章的发布日期，采用 ISO 8601 格式 (YYYY-MM-DDThh:mm:ssZ)。它告知搜索引擎内容最初发布的时间。在我们的示例中，"2025-05-01T14:30:00Z"​ 对应于 2025 年 5 月 1 日 UTC 时间 14:30。该字段有助于谷歌在摘要中显示日期，这对于新闻或博客文章很常见。
  • ​​dateModified​​ – 文章最后更新的日期（同样采用 ISO 格式）。如果你经常更新文章或有编辑日期，请包含此字段。它向搜索引擎提供关于内容时效性的更准确信息。此字段是可选的，但建议在进行重大更改时保持更新。
  • ​​author​​ – 博客文章的作者。在 schema 中，作者可以是 Person (个人) 或 Organization (组织)。最好指定一个 Person，并包含姓名（以及可选的链接或个人资料）。在我们的示例中，我们使用了一个带有 @type: "Person"​ 的对象，外加作者的姓名和 URL（可能链接到作者的简介页面）。这明确地告诉搜索引擎文章是谁写的。（如果你的博客没有单独的作者页面，可以省略 author​ 下的 url​，但仍需提供姓名。）
  • ​​publisher​​ – 文章的发布者。这通常是更广泛的实体——通常是你的网站或公司。我们通常使用 Organization 作为发布者（如果是个人以其名义发布，则为 Person）。我们的示例将发布者定义为一个名为 "Example Blog" 的 Organization。我们还为该组织添加了一个 logo​。徽标以 ImageObject​ 的形式提供，并带有其自身的 url​。包含发布者徽标尤其对 Article schema 有益，因为谷歌可以在某些丰富网页摘要或谷歌新闻中显示一个小徽标。author 指的是文章的创作者，而 publisher 则是以其名义发布文章的实体（例如，新闻网站或博客名称）。谷歌的指导是使用适当的类型：Person 代表个人，Organization 代表组织。
  • ​​description​​ – 博客文章的简短描述或摘要。这就像一个总结，说明文章的内容。它可能与你的 meta description 相似。它不总是在搜索结果中显示（谷歌可能会使用你的 meta description 或内容片段），但在 schema 中包含它作为文章内容的快速摘要是很有用的。
  • ​​mainEntityOfPage​​ – 这个字段有点元数据性质：它将 BlogPosting 链接到其所在的 WebPage。在我们的 JSON 中，我们设置了 "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/blog/my-first-post" }​。这表示：“此网页的主要实体是这篇博客文章。 ” 它有助于阐明博客文章是该页面的主要主题（而不是，比如说，一个列出多篇文章的页面）。我们通过相同的 URL 来识别 WebPage（注意 WebPage 的 @id​ 就是页面 URL）。这种连接对于搜索引擎了解 BlogPosting 并非凭空存在的数据——它存在于一个特定的页面（类型为 WebPage）上——非常有用。多数情况下，谷歌可以自行判断，但明确声明可以消除歧义，尤其是在页面上可能存在多个项目时。

这些是 BlogPosting schema 中的关键字段。它们共同描绘了一幅详细的图景：“此页面 (WebPage) 主要是一篇 BlogPosting，具有这样的标题，由这位作者撰写，于此日期发布，等等。 ”

理解 BreadcrumbList Schema（导航结构）

在第二个 JSON 代码段中，我们有一个 BreadcrumbList。面包屑导航是网站上的一种导航辅助工具（通常你会在页面顶部看到类似首页 > 博客 > 文章标题这样的路径）。在 JSON-LD 中标记它有助于搜索引擎理解网站层级，并可能在搜索结果中显示面包屑路径而不是完整的 URL。实际上，谷歌声明面包屑标记有助于在搜索结果中对页面进行分类。顾名思义，BreadcrumbList 包含一个有序的 ListItem 条目列表，每个条目代表路径中的一个“面包屑”。

在我们的示例中，BreadcrumbList 有三个 ListItem：

  • 位置 1：首页 – 链接到主页。
  • 位置 2：博客 – 链接到博客版块页面。
  • 位置 3：我的第一篇博客文章 – 链接到当前页面。

每个 ListItem 都有一个 name​（该面包屑的文本）和一个 item​（它指向的 URL）。position​ 表示顺序（从根/主页的 1 开始）。这种结构化的面包屑告诉爬虫“首页 > 博客 > 我的第一篇博客文章”是此内容的路径。它等同于你可能在页面上直观显示的面包屑导航。

这些面包屑导航有何帮助？ 它们通过显示清晰的路径来改善搜索结果片段，这比长 URL 更友好。谷歌可能不会显示 example.com/blog/my-first-post​，而是显示首页 > 博客 > 我的第一篇博客文章。它为用户提供了关于页面在网站中所处位置的上下文信息。打个比方，搜索结果中的面包屑导航就像是你网站结构的一个小型路径图。实施 BreadcrumbList 标记 “就像面包屑小径一样……显示了到达某个页面所必须经过的不同层级” ，并帮助搜索引擎在搜索结果中呈现面包屑路径。

需要注意的一点是：在某些 JSON-LD 示例中（包括一些 SEO 插件生成的示例），你可能会看到面包屑项目的结构略有不同——有时 item​ 是一个带有 @id​ 和 name​ 的对象，而不是直接的 URL。两种方法都传达相同的信息。我们的示例使用了一种简单的形式，其中每个 item​ 都是一个直接链接。

这些 Schema 实体之间如何关联

既然我们已经分别研究了 BlogPosting 和 BreadcrumbList，让我们放眼全局，看看它们是如何协同工作的。在一个完整的博客页面结构化数据实现中，你可能会有几个实体协同工作。主要的通常包括：WebSite、WebPage、BlogPosting 和 BreadcrumbList。它们通常按以下方式连接：

  • WebSite – 这代表你的整个网站。它通常包括网站名称，可能还有一个 @id​（通常是你的主页 URL 或一个稳定的标识符，如 https://example.com/#website​），有时还有一个搜索操作（用于在搜索结果中添加搜索框）。WebSite 实体不在我们上面的示例中，但通常会在全站范围内包含一个。它基本上是说“这是一个名为 X 的网站”。WebSite 可以链接到 WebPage（使用像 isPartOf​ 这样的属性，反之亦然）。例如，一个 WebPage 可能有 "isPartOf": { "@id": "https://example.com/#website" }​ 来表明它是该网站的一部分。
  • WebPage – 此实体描述一个特定的网页。在我们的示例中，我们通过 mainEntityOfPage​ 嵌入了一个最小化的 WebPage（仅包含 @id​ 和 @type​）。一个更完善的 WebPage schema 可以包括页面的 name​（标题），甚至是对面包屑的引用。例如，我们文章的 WebPage 可能有 "breadcrumb": { "@id": "https://example.com/blog/my-first-post#breadcrumb" }​，指向 BreadcrumbList 的 @id​。WebPage 也可以被更具体地类型化（有时是 "WebPage": "BlogPosting"​ 组合或作为 Article 页面）。核心思想是：WebPage 是 BlogPosting 所在的容器页面。通俗地讲，WebSite 是你的整个博客，WebPage 是该博客中的一个页面（在本例中，是显示单篇文章的页面）。
  • BlogPosting – 这是主角：页面上的实际文章内容。它通过 mainEntityOfPage​ 链接到 WebPage，并承载有关文章的所有详细信息（作者、日期等，如上所述）。如果你把网站比作一本书，那么 BlogPosting 就像一个章节或故事，而 WebPage 就是印有这个故事的书页。BlogPosting 关注的是内容，而 WebPage 是承载该内容的媒介/显示方式。
  • BreadcrumbList – 此实体在某种程度上是独立的，但它间接地相关联，因为它描述了此页面如何融入网站的导航结构。如果使用 @id​ 引用，WebPage 可以引用 BreadcrumbList（如前所述，通过 breadcrumb​ 属性）。在我们的简单示例中，我们没有给 BreadcrumbList 一个 @id​，但本可以这样做（例如，在 BreadcrumbList 中设置 "@id": "https://example.com/blog/my-first-post#breadcrumb"​，然后在 WebPage 对象中使用相同的引用）。然而，即使没有明确链接，搜索引擎也会解析页面上的 BlogPosting 和 BreadcrumbList 脚本，并理解面包屑适用于此页面（因为面包屑的最后一项与页面 URL 匹配）。BreadcrumbList 提供了页面在网站层级结构中所处位置的上下文，这补充了 BlogPosting 的信息（内容的性质、时间、作者等）。

这些 schema 实体像一个团队一样协同工作：WebSite 是整个团队（你的网站），WebPage 是一名队员（特定页面），BlogPosting 是该队员的统计数据（内容详情），而 BreadcrumbList 则是连接队员与团队结构的战术手册（导航路径）。当你在页面的 HTML 中包含所有这些（通常作为一个组合的 JSON-LD 脚本或多个脚本）时，你就在为搜索引擎描绘一幅完整的图画。你等于在说：“这个页面是我网站的一部分，这是它的导航路径（首页 > 博客 > 文章），这个页面上的主要内容是一篇博客文章，详情如下。 ”

整合所有内容（及 SEO 益处）

如果你在没有插件的情况下构建博客，手动添加这种 JSON-LD 是完全可行的。你可以参照上面的示例模板，为每篇文章更新值（标题、日期、名称、URL 等），并将其包含在 HTML 的 <head>​ 或 <body>​ 底部。起初可能感觉繁琐，但一旦理解了各个部分，就会变得很简单。而且回报是值得的：你正在帮助搜索引擎更智能地索引你的内容，并增强你的网站在搜索结果页面上的显示效果。

回顾一下这样做的好处：Schema 标记不会直接提升你的谷歌排名，但它可以显著改善你的搜索结果显示方式，使其更有可能吸引点击。你会得到诸如面包屑路径（而非 URL）、可能被纳入丰富网页摘要功能，以及通常更专业的摘要外观。谷歌和必应都需要这些信息——这是它们使网络更具语义化努力的一部分。通过提供结构化数据，你实际上是在用它们的语言进行交流。正如谷歌文档所指出的， “添加结构化数据可以使搜索结果对用户更具吸引力” （即丰富网页摘要）。用户在点击之前就能看到更多上下文信息（如你的博客名称、文章图片、发布日期等），这有助于建立信任和相关性。

最后，务必测试你的 schema！使用谷歌的富媒体搜索结果测试 (Rich Results Test) 或 Schema.org 的架构标记验证器 (validator) 来确保你的 JSON-LD 没有错误。一个微小的语法错误就可能使整个脚本失效。测试工具会告诉你谷歌是否能读取你的标记，以及它是否有资格获得丰富网页摘要。并且请记住，虽然 schema 有助于改善外观，但你仍应拥有良好的 meta 标签（标题、meta description）——它们与结构化数据协同工作，以实现最佳的 SEO 效果。