如何给页面添加 JSON-LD：放置位置、结构与实操步骤

Q: JSON-LD 应该放在 head 还是 body？

放在 head 或 body 都可以，Google 都能识别。推荐放在 中，便于集中管理、与其他 SEO 标签（title、canonical）放在一起。对于通过 JavaScript 动态注入的 JSON-LD，Google 也能在渲染阶段读取，但要注意渲染延迟——最稳妥的是在服务端就把 JSON-LD 输出到初始 HTML 中。

上一篇我们确定了用 JSON-LD。这一篇真正动手：把一段结构化数据加到页面里。好消息是，JSON-LD 是这三种格式里最容易上手的——它就是一段独立的 JSON，放进一个 <script> 标签即可，不用改动任何现有 HTML。这篇文章从放置位置讲到基本结构、字段填写、多类型并存和完整实操步骤。

放在哪里#

JSON-LD 写在一个 <script type="application/ld+json"> 标签里。这个标签可以放在 <head> 或 <body> 中，Google 两者都能识别。

推荐放在 <head>：与 title、canonical 等 SEO 元信息集中在一起，便于管理。
放在 <body> 也可以：例如由组件/模板在正文区域输出时。
关键是进入初始 HTML：最好在服务端就输出，避免依赖 JavaScript 渲染（原因见 JavaScript SEO 基础）。

最小可用示例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "如何给页面添加 JSON-LD"
}
</script>

type 写对，别用注释type 必须正好是 application/ld+json，写错 Google 不会解析。另外 JSON-LD 内部不能写注释（JSON 不支持 // 或 /* */），也不能有多余的尾逗号——这些都会导致解析失败。

基本结构拆解#

每个 JSON-LD 对象都有两个必备的"骨架"字段，其余是描述具体信息的属性。

字段	作用	值
`@context`	声明使用的词汇表	几乎总是 `"https://schema.org"`
`@type`	声明这是什么类型的事物	如 `Article`、`Product`、`FAQPage`
其余属性	描述该类型的具体信息	取决于 `@type`，如 `headline`、`author`

@context：告诉解析器"接下来的字段名按 schema.org 的定义来理解"。固定写 https://schema.org 即可。
@type：决定了这个对象描述的是文章、商品、还是问答等。它也决定了哪些字段可用、哪些必填。

嵌套对象与数据类型#

属性的值不只是字符串，还可以是数字、数组，或另一个带 @type 的对象。比如文章的作者不是一个简单的名字，而是一个 Person 或 Organization 对象：

嵌套对象示例

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "如何做好关键词研究",
  "image": "https://example.com/cover.webp",
  "datePublished": "2026-06-24",
  "author": {
    "@type": "Person",
    "name": "张三",
    "url": "https://example.com/authors/zhangsan"
  },
  "publisher": {
    "@type": "Organization",
    "name": "示例媒体",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

值类型	写法	示例
文本	字符串	`"headline": "标题"`
日期	ISO 8601 字符串	`"datePublished": "2026-06-24"`
数字	不加引号	`"ratingValue": 4.8`
多个值	数组	`"image": ["a.webp", "b.webp"]`
子对象	带 @type 的对象	`"author": { "@type": "Person", ... }`

必填字段与推荐字段#

每种结构化数据类型都有 Google 规定的必填（required）和推荐（recommended）字段。这是很多人忽略的关键点：

必填字段：缺少它们，该类型无法获得富媒体结果，测试工具会直接报错。
推荐字段：补全它们能提升富媒体结果出现的概率和展示的丰富度，测试工具通常以警告提示。

不同类型的字段要求差异很大，必须查阅 Google 官方文档中对应类型的页面。每种类型的具体字段，本栏目的「类型图鉴」会逐一展开。

以官方文档为准schema.org 上定义了某个类型的所有可能字段，但Google 实际用于富媒体结果的字段是其子集。判断"哪些字段对 Google 有用、哪些必填"，要看 Google 搜索中心的结构化数据文档，而不是只看 schema.org。

同页多个类型#

一个页面常常需要多种结构化数据。有两种写法，Google 都支持：

方式一：多个独立 script 标签（推荐）

分开写，清晰易维护

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

方式二：一个数组装多个类型

单个 script，数组形式

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

两者效果相同。推荐方式一：每个类型一个标签，增删某一类型时互不影响，排查问题也更直观。

手写还是动态生成#

少量固定页面可以手写 JSON-LD；但页面一多，靠模板或程序自动生成才现实。

方式	适合	注意
手写	少量、结构固定的页面	注意 JSON 语法，避免笔误
模板生成	静态站、SSG、CMS	把字段绑定到内容数据源
CMS 插件	WordPress 等	Yoast、Rank Math 自动输出
服务端动态	大型动态站	确保输出到初始 HTML

动态值要做转义当字段值来自内容（标题、描述等）时，如果文本里含有英文双引号、反斜杠或换行，必须做 JSON 转义，否则会破坏 JSON 结构。用程序生成时优先用语言内置的 JSON 序列化函数（如 JSON.stringify），而不是手工拼接字符串。

最重要的原则：与可见内容一致#

这是结构化数据的红线：JSON-LD 描述的内容，必须是页面上用户能真实看到的内容。

标记的标题、作者、日期、价格、评分，都要与页面可见信息一致。
不要标记页面上不存在的信息（如编造评分、虚标价格、隐藏的关键词）。
这既是 Google 的明确要求，违反还可能导致富媒体结果失效甚至人工处罚。

结构化数据的本质是把"页面已有的内容"翻译成机器能精确理解的格式，而不是凭空添加信息。准则与避坑的完整内容，会在本栏目「结构化数据准则与避坑」一篇专门展开。

完整实操步骤#

确定类型：判断页面内容属于哪种类型（文章用 Article、问答用 FAQPage、商品用 Product……）。
查官方字段要求：在 Google 文档查该类型的必填和推荐字段。
编写 JSON-LD：填入与可见内容一致的真实数据，注意 JSON 语法。
放入页面：用 <script type="application/ld+json"> 放进 <head>，确保在初始 HTML 中。
验证：用 Rich Results Test 和 Schema 校验工具检查无错误（详见下一篇）。
上线后监控：在 Search Console 的富媒体结果报告里跟踪状态（见本栏目相关篇）。

本站的 JSON-LD 实践#

你正在读的这篇文章，<head> 里就放着三段独立的 JSON-LD：

本页实际使用的三个标签

<!-- 1. Article：描述文章本身 -->
<script type="application/ld+json">{ "@type": "Article", ... }</script>

<!-- 2. BreadcrumbList：描述面包屑路径 -->
<script type="application/ld+json">{ "@type": "BreadcrumbList", ... }</script>

<!-- 3. FAQPage：描述文末常见问题 -->
<script type="application/ld+json">{ "@type": "FAQPage", ... }</script>

本站示范MagicSEO 全站文章都采用"多个独立 script 标签"的方式：Article + BreadcrumbList + FAQPage 各自一个标签，都写在 <head> 的初始 HTML 中（纯静态输出，无渲染延迟）。每段 JSON-LD 的字段都严格对应页面可见内容——面包屑就是页面顶部那条导航，FAQ 就是文末那几个问答，标题、日期与正文一致。你可以查看本页源码逐一核对，这正是"言行一致"的结构化数据实践。

添加 JSON-LD 清单#

script type 正好是 application/ld+json
含 @context（https://schema.org）与 @type
选对类型，并补齐该类型的必填字段
尽量补全推荐字段提升丰富度
所有字段值与页面可见内容一致
JSON 语法正确（无注释、无尾逗号、正确转义）
放在 head 的初始 HTML 中（避免依赖 JS 渲染）
多类型用多个独立 script 标签
用 Rich Results Test 验证通过
上线后在 Search Console 监控

常见问题#

JSON-LD 应该放在 head 还是 body？

放在 head 或 body 都可以，Google 都能识别。推荐放在 <head> 中，便于集中管理、与其他 SEO 标签（title、canonical）放在一起。对于通过 JavaScript 动态注入的 JSON-LD，Google 也能在渲染阶段读取，但要注意渲染延迟——最稳妥的是在服务端就把 JSON-LD 输出到初始 HTML 中。

JSON-LD 里的内容必须和页面可见内容一致吗？

必须一致。Google 要求结构化数据描述的内容必须是页面上用户真实可见的内容。在 JSON-LD 中标记页面上不存在的信息（例如虚构的评分、不存在的价格），属于违反结构化数据准则的行为，可能导致富媒体结果失效，甚至受到人工处罚。结构化数据是对可见内容的"翻译"，不是凭空添加信息。

一个页面可以放多个 JSON-LD 标签吗？

可以。一个页面可以有多个独立的 script 类型为 application/ld+json 的标签，分别描述不同类型（如 Article、BreadcrumbList、FAQPage）。它们互不干扰。也可以把多个类型放进一个数组里用单个 script 标签输出。两种方式 Google 都支持，分开写通常更清晰易维护。

添加了 JSON-LD 就一定会出现富媒体结果吗？

不一定。正确的 JSON-LD 是获得富媒体结果的前提，但不是保证。Google 会综合判断页面质量、内容是否符合对应类型的展示要求、是否违反准则等，再决定是否、何时展示富媒体结果。即使标记完全正确，Google 也保留不展示的权利。先把标记做对、用测试工具验证通过，是你能控制的部分。