标准 · 基础设施

JSON-LD

速览要点

JSON-LD 是什么: Schema.org 标记的 JSON 序列化格式（W3C 推荐标准，1.0 于 2014 年、1.1 于 2020 年发布）。三种格式之一（另两种是 Microdata 和 RDFa），也是 Google 官方推荐的那一种
Google 的官方态度: 「条件允许就尽量用 JSON-LD」，但同时表明三种格式在 Google 这边一视同仁；这是出于运维角度（易维护）的推荐，不是技术上的偏好
AI 对话引擎实际看到什么: 实时抓取的对话引擎（ChatGPT、Perplexity、Claude 直接抓取）把 JSON-LD 当作页面上的普通文字读，并不解析为结构化图（searchVIU 受控测试，2025-12）
放在哪里: 用 `<script type="application/ld+json">` 包裹，放在 `<head>` 或 `<body>` 都可以；同一页允许多个 script 块；由前端 JavaScript 注入的 script 块对不渲染 JS 的爬虫不可见
最值得优先做对的属性: `Organization` 或 `Person` 上的 `sameAs`：把你的实体显式连到知识图谱里同一个实体的权威条目上。详见 [实体识别](/zh/entity-recognition)

1. JSON-LD 是什么

JSON-LD 是 JSON for Linked Data 的缩写，W3C 给它的官方定义是「a lightweight syntax to serialize Linked Data in JSON」，即「在 JSON 里序列化关联数据的一种轻量级语法」。它的 1.0 版本于 2014 年正式落地，1.1 版本于 2020 年 7 月成为 W3C 推荐标准（W3C，2020）。简单说，JSON-LD 让一份 JSON 文档可以描述一张「带类型、有稳定标识」的实体（entity）图，任何懂 RDF 或关联数据的消费方都能直接读它。

放在 Schema.org 这个语境里，JSON-LD 是承载词汇的三种序列化格式之一，另两种是 Microdata 和 RDFa。词汇本身（Organization、Person、Article、sameAs、mainEntity 等）定义在 schema.org，跟你用哪种格式承载无关，JSON-LD 只是其中一种外壳。schema.org 的入门页说得直白：「你用 schema.org 的词汇，配合 Microdata、RDFa 或 JSON-LD 三种格式之一，把信息加进你的网页内容」（Schema.org Getting Started）。Schema.org 各类型与属性对 AI 引擎分别意味着什么，例如为什么做引用优化时 sameAs 远比 FAQPage 重要，详见面向 AI 的 Schema.org。

2. Schema.org 的三种序列化格式

三种格式描述的是同一张图，差别只在标记怎么织进页面。

格式	标准化时间	标记怎么承载	在页面上的位置	现在还能在哪看到
Microdata	HTML5（WHATWG / W3C，2011）	在可见元素上挂 HTML 属性（`itemscope`、`itemtype`、`itemprop`）	跟可见 HTML 缠在一起	老旧 CMS、早期电商模板
RDFa	W3C 推荐标准（RDFa 1.1，2015）	在可见元素上挂 HTML 属性（`vocab`、`typeof`、`property`）	跟可见 HTML 缠在一起	政府与学术机构的关联数据发布
JSON-LD	W3C 推荐标准（1.0 在 2014、1.1 在 2020）	一段 JSON 文档，写在 `<script type="application/ld+json">` 里	一个独立的 script 块，放在 `<head>` 或 `<body>`，不动可见 DOM	Google 的官方推荐选项，新做的 Schema.org 部署几乎都用它

下面三段代码声明的是同一个最小化 Organization，分别用三种格式写出来：

<!-- Microdata -->
<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">Example Co</span>
  <link itemprop="url" href="https://example.com">
  <link itemprop="sameAs" href="https://en.wikipedia.org/wiki/Example_Co">
  <link itemprop="sameAs" href="https://www.wikidata.org/wiki/Q000000">
</div>

<!-- RDFa -->
<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">Example Co</span>
  <link property="url" href="https://example.com">
  <link property="sameAs" href="https://en.wikipedia.org/wiki/Example_Co">
  <link property="sameAs" href="https://www.wikidata.org/wiki/Q000000">
</div>

<!-- JSON-LD -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}
</script>

区别一眼可见：Microdata 和 RDFa 都是织进可见 HTML 的，每个属性都必须挂到一个用户能看见的元素上；JSON-LD 是一段独立的块，与页面其余部分各自渲染。这种解耦，正是 Google 推荐它的原因。

3. 为什么 Google 推荐 JSON-LD

Google 的 Intro to How Structured Data Markup Works 把推荐说得很直接：

「In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.」（「一般来说，只要站点条件允许，Google 推荐用 JSON-LD 做结构化数据，因为对站长来说，它在大规模落地与维护时最省事。」）

同一页也讲清楚了：这个推荐出于运维角度，并非技术偏好。原文「all 3 formats are equally fine for Google, as long as they are valid and implemented properly per the feature’s documentation」，意思是三种格式在 Google 这里被同等对待，前提是格式有效、按文档正确实现。换句话说，Google 推荐 JSON-LD 不是因为它解析效果更好，而是因为它与页面的耦合方式不同。

按实际作用从大到小，原因有四：

与可见 HTML 完全解耦。 改动标记不会动到任何模板，也不会带来破版风险。改一处价格展示，并不会顺手让 Product 标记失效，因为两者本就不是同一组元素。
任何一层都能注入。 CMS、构建步骤、服务端中间件都可以把 script 块当作一段字符串输出。Microdata 与 RDFa 则要求模板引擎把属性逐一织进被渲染的元素。
标准 JSON 解析即可。 任何带 JSON 解析器的消费方都能读出这张图，不必遍历 DOM，也不必解析属性。这一点对下游工具最有用，对 Google 自身反而影响不大。
出错只影响自身。 JSON-LD 写错只会让这一块失效，页面其余部分照常工作。Microdata 或 RDFa 写错则可能与 HTML 渲染问题交织在一起。

另外两种格式仍有适用场景，只是范围很窄。已经全站铺了 Microdata 的老站可以保留现状，Google 解析它们的能力是一样的。RDFa 在政府与学术的关联数据发布里仍然常见，那里它的多词汇前缀确有用武之地。但凡是新部署，结论一律是 JSON-LD。

4. JSON-LD 结构：承载关键信息的四个关键字

JSON-LD 的关键字比绝大多数页面用得到的多得多：@id、@graph、@vocab、@reverse、@container，还有 framing、上下文覆盖另一个上下文等等。但落到 AI 引用这件事上，真正起作用的就四个。

关键字	它声明了什么	为什么对 AI 重要
`@context`	这张图用的是哪个词汇表	做 AI 优化时永远是 `https://schema.org`，相当于告诉解析器「下面这些 key 按 Schema.org 词汇解释」
`@type`	这个节点的类别	实体的类型：`Organization`、`Person`、`Article` 等，决定其他属性在这里是否有意义
`@id`	这个节点的稳定 URI	让跨页面、跨文档的引用能拼到同一个实体上，而不是各处冒出重复的「同名节点」
`sameAs`	同一实体在权威第三方源上的对应 URL	把你的标记与知识图谱（knowledge graph）显式连起来的属性，四个里效用最大

最小化的 Organization 块，把四个关键字都用上：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/example-co"
  ]
}

sameAs 是把你的实体显式连入知识图谱的关键属性，也正是 JSON-LD 真正被 AI 引擎用到的那一部分，尽管它们并不直接解析你的标记（§6 详述）。一条 sameAs 链接如何落地为一次实体解析，详见实体识别与知识图谱存在度。同一页面有多个实体时（既有 Organization，又有作者 Person，又有 Article），可以每个实体一个 script 块，也可以用 @graph 把它们装进同一个块；逐类型的模板与校验步骤见 Schema Implementation 操作手册。

5. 放置与输出：标记写在哪里、爬虫看得见什么

放置层面需要回答三件事，答案都不长。

写在文档的什么位置。 Google 把 JSON-LD 描述为「一段嵌入 HTML 页面 <head> 与 <body> 元素里的 <script> 标签里的 JavaScript 标记」，两处都合规。General Structured Data Guidelines 只附加了一条：标记应当「放在它所描述的那个页面上」。实务中通常放在 <head>，因为这样标记排在 body 之前，查看源代码时一眼可见；放进 <body> 同样合规，不少 CMS 插件就是这么生成的。

多块写法。 Google 的文档没有规定每页 JSON-LD 块的数量上限，每个实体单独一个块（Organization 一个、Article 一个、BreadcrumbList 一个）是生产环境中常见的写法。要合并就用 @graph 把多个实体装在同一个 script 块里，这更多是写法风格的取舍，并非合规性问题。

前端 JS 注入的 JSON-LD。 由客户端 JavaScript 写进 DOM 的标记，只有会执行 JavaScript 的消费方才能读到。Google 的 JavaScript SEO basics 明确表示 Googlebot 会执行：「Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.」即「一旦资源允许，一个无头 Chromium 就会渲染页面并执行 JS」。AI 爬虫的实际情况完全不同，且更值得参考的是观测数据，而非厂商文档（厂商文档大多对渲染这一层语焉不详）：

爬虫	会执行 JS 吗	看得见客户端注入的 JSON-LD 吗	依据
Googlebot / Google AI Overviews	会（WRS）	看得见	Google 官方文档
Bingbot / Bing Copilot	部分情况	部分情况	Bing 文档，实务上参差不齐
GPTBot / ChatGPT-User（实时抓取）	按观测结果不会	看不见	OpenAI 官方文档对此未明示；观测见 searchVIU
ClaudeBot / Claude 直接抓取	按观测结果不会	看不见	Anthropic 官方文档对此未明示；观测同上
PerplexityBot / Perplexity-User	不稳定	不稳定	Perplexity 官方文档对此未明示；观测同上

服务端渲染或构建期注入的 JSON-LD，上表中每一行都能读到；而客户端注入的 JSON-LD，只有 Googlebot 能稳定读到。要让 AI 真正能看到你的标记，就把它与可见内容放在同一层渲染输出；更完整的渲染权衡，详见 SSR for AI Crawlers。

6. AI 引擎实际是怎么读 JSON-LD 的

实际机制因场景而异，可以分成两类，并且目前的证据已经足够把话说清楚。

场景	JSON-LD 怎么被读	证据强度
Google AI Overviews / AI Mode	走 Google 既有的结构化数据系统：AI 搜索复用同一套索引解析流程，Google 明确表示无需专门的 AI 标记	最强，Google 自己的 AI features 页面
Bing Copilot	走 Bing 索引，微软方面已确认会使用结构化数据	强，厂商确认
ChatGPT / Perplexity（实时抓取）	页面被抓取并渲染为文字，JSON-LD 被当作页面上的普通文字来读，不解析为结构化数据	强（反向证据），受控测试
Claude / Gemini 直接抓取	与上同：没有证据显示答案生成时存在专门的 JSON-LD 解析	与上同

走索引那一侧，Google 在 AI features and your website 里说得很清楚：「You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.」即「这些 AI 功能不需要你新建专门的机器可读文件或标记，也无需添加什么『AI 专用的 schema.org 结构化数据』」。JSON-LD 进入 Google AI Overviews，走的就是它一直以来进入 Google Search 的同一套索引流程。

让人意外的是另一侧。2025 年 12 月 searchVIU 的一次受控测试，把价格只写进 JSON-LD，向五个 AI 系统提问，没有一个实时抓取的对话引擎能取出这个值。他们的结论明确：「Current AI chatbots do NOT use JSON-LD Schema Markup during direct retrieval. Instead, they exclusively extract visible HTML content.」即「目前的 AI 对话引擎在直接抓取过程中并不使用 JSON-LD Schema 标记，它们只从可见的 HTML 内容中提取信息」。2026 年 2 月还有一项独立观察（Search Engine Roundtable）：ChatGPT 与 Perplexity 连语法错误、编造出来的 JSON-LD 里的值也会照样讲出来，可见它们是把标记当作页面上的文字阅读，并非将其解析为结构。

这一结论应当稳妥地理解，不宜过度推演。在被实时抓取的页面上，JSON-LD 并不会带来负面影响，只是没能把这种格式本该带来的解析优势真正发挥出来。实体层面的收益仍可传递到这些模型，但传递途径是模型先验与知识图谱，而非你 script 块里的那段 JSON。Search Engine Land 把这个平衡讲得比较稳：「Schema markup is infrastructure, not a magic bullet. It won’t necessarily get you cited more, but it’s one of the few things you can control that platforms such as Bing and Google AI Overviews explicitly use.」即「schema 标记属于基础设施，并非灵丹妙药，它未必能直接换来更多引用，但它是为数不多既由你完全掌控、又确为 Bing 与 Google AI Overviews 所用的东西」（Jurenka，2026）。结论是：还是要写。写它的理由在于它在索引侧确有价值，而在实时抓取侧也不会造成任何损失，并不是因为对话引擎会去解析它。

7. 校验、常见错误与反模式

两个校验工具，定位完全不同。Google 的 Rich Results Test 检查的是你的标记能否进入 Google 那几个具体的富结果功能；通过它并不代表标记在技术上完全无误，只代表 Google 会考虑把它用在其中某个展示位上。Schema Markup Validator 是 schema.org 官方的校验工具，检查的是词汇本身是否符合 Schema.org 规范；通过它也不代表 Google 一定会渲染任何东西。两个工具串起来用：先用 SMV 看「标记本身在 Schema.org 上是否成形」，再用 RRT 看「Google 会不会据此呈现一个富结果」。

JSON-LD 特有的失败形态，与面向 AI 的 Schema.org 词汇层面的反模式互不重叠：

失败形态	问题在哪	后果
JSON 语法错（少逗号、末尾多逗号、key 没加引号）	整块解析不出来	这一块直接失效，没有「部分采纳」一说
`@context` 缺失、拼错或写成了别的 URL	解析器无法把 key 对应到 Schema.org 词汇	块能解析，但对消费方而言形同空说
用了单引号而非双引号	JSON 强制要求双引号	块解析失败
字符串里出现未转义的 `</script>`	HTML 解析器提前关闭了 script 标签	块被截断，紧跟其后的 HTML 也随之出错
多个块之间 `@id` 重复	写法合规，但图变得混乱	不会有明显报错，下游工具可能把毫无关联的实体合并
标记与可见内容相矛盾	同时触发多种问题，见下文	触发 Google 人工处罚；同时，把标记当作文字阅读的 AI 也会读到这处矛盾
客户端注入，遇到不渲染 JS 的爬虫	标记对它不可见	对这一类消费方而言，等同于未加标记（见 §5 表格）

整张表里最关键的一条，对应面向 AI 的 Schema.org §7 词汇层面的同名问题：无效或与可见正文相矛盾的 JSON-LD，比完全不加更糟。 标记与可见正文对不上，会同时招来 Google 的结构化数据人工处罚与 AI 文字读取问题：实时抓取的引擎本就把 JSON-LD 当作文字阅读，于是它们手上会同时握有两份相互矛盾的事实，结果是哪份都不会被采信。

8. 下一步去哪里看

你想做的事	起点
理解 Schema.org 词汇及它对 AI 的信号意义	面向 AI 的 Schema.org
在站点上全面部署 JSON-LD：模板、流程与校验	Schema Implementation
弄清楚 `sameAs` 怎样把实体显式连入知识图谱	实体识别
看实体存在度最终落在哪里	知识图谱存在度
在全站审计里检查 JSON-LD 部署	完整 GEO 审计
让标记到得了非 Google 的 AI 爬虫	SSR for AI Crawlers · AI 爬虫
让一个段落真正能被 AI 答案直接引用	可引用性

术语与邻近条目见 GEO 术语表。

References

W3C 与 Schema.org：

W3C — JSON-LD 1.1: A JSON-based Serialization for Linked Data（推荐标准，2020-07-16）
Schema.org — Getting Started · Schema.org 词汇 · Schema Markup Validator

Google Search Central：

Intro to How Structured Data Markup Works — JSON-LD 推荐、放置位置、三种格式等同
General Structured Data Guidelines — 排名影响、人工处罚
AI features and your website — 不需要专门的 AI 标记
Understand the JavaScript SEO basics — Googlebot 通过 WRS 执行 JavaScript
Rich Results Test

AI 爬虫文档：

OpenAI — Overview of OpenAI Crawlers
Anthropic — Does Anthropic crawl data from the web?
Perplexity AI — Perplexity Crawlers

独立来源／行业：

searchVIU — Schema Markup and AI in 2025: What ChatGPT, Claude, Perplexity & Gemini Really See（2025-12-02）：实时抓取下 JSON-LD 消费方式的受控测试
Search Engine Land — How schema markup fits into AI search — without the hype（2026-03-25）
Search Engine Roundtable — ChatGPT & Perplexity Treat Structured Data As Text On A Page[观察]（2026-02-03）

常见问题

JSON-LD 比 Microdata 或 RDFa 更好吗？

三种格式承载的是同一套 Schema.org 词汇，Google 也表示「三种格式在 Google 这里被同等对待」。Google 推荐 JSON-LD，原因在运维层面：它写在一个独立的 script 标签里，与可见 HTML 完全解耦，增删标记不会动到任何模板，也不会带来破版风险。例外只有两种情形：站点已经全站铺了 Microdata，迁移成本高于收益；以及 RDFa 仍流行的政府／学术关联数据发布。新做的部署一律选用 JSON-LD。

ChatGPT、Claude、Perplexity 会读我的 JSON-LD 吗？

在答案生成阶段不会按结构化数据来读。2025 年 12 月的一次受控测试把价格只写进 JSON-LD，向五个系统提问，没有一个实时抓取的对话引擎能取出这个值。2026 年 2 月还有一项独立观察：ChatGPT 与 Perplexity 连语法错误、编造出来的 schema 里的值也会照样讲出来，可见它们是把标记当成页面上的普通文字阅读，并未解析为结构。实体层面的收益仍能传递到这些模型，但传递途径是知识图谱，而不是抓取时解析你页面上的 JSON-LD。

script 标签放在页面什么位置？

Google 明确说 `<head>` 或 `<body>` 都可以，实务中以放在 `<head>` 居多。同一页放多个 `<script type="application/ld+json">` 块也合规：一个 Organization、一个 Article、一个 BreadcrumbList 是常见的分块写法；想合并就用 `@graph`，把多个实体装进同一个块。比放置位置更要紧的是输出方式：由前端 JavaScript 注入的标记，对不执行 JS 的爬虫不可见，所以服务端渲染或构建期注入更稳妥。

JSON-LD 里哪些关键字对 AI 最重要？

真正承载关键信息的就四个。`@context` 声明这张图用的是哪个词汇表，做 AI 优化时永远是 `https://schema.org`。`@type` 是节点的类别（`Organization`、`Person`、`Article`），决定其他属性是否有意义。`@id` 是节点的稳定 URI，让跨页面、跨文档的引用能指向同一个实体，而不是各自冒出一份重复。`sameAs` 列出同一实体在权威源上的对应 URL（Wikipedia、Wikidata、官方社交账号），把你的标记显式连到知识图谱里同一个实体；四个属性里最该优先做对的就是它。

JSON-LD 怎么校验？

两个工具，定位完全不同。Google 的 [Rich Results Test](https://search.google.com/test/rich-results) 看你的标记能不能进 Google 那几个具体的富结果功能，通过它不代表标记技术上没问题，只代表 Google 会考虑把它用在其中某个展示位上。schema.org 官方的 [Schema Markup Validator](https://validator.schema.org/) 校验的是词汇是否符合 Schema.org 规范，通过它也不代表 Google 一定会渲染什么。两者各有用处：富结果资格看 RRT，词汇正确性看 SMV。端到端的部署流程见 [Schema Implementation](/zh/playbooks/schema-implementation) 操作手册。

参考来源