JSON-LD

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）	在 <script type="application/ld+json"> 中写入一段 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 不是因为它的解析效果更好，而是因为它与页面采用了不同的结合方式。

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

1. 与可见 HTML 完全解耦。 修改标记无需改动模板，也不会导致页面布局异常。修改页面中的价格展示时，不会因为改动同一组元素而连带破坏 Product 标记，因为二者原本就是分离的。
2. 可以在多种环节注入。 CMS、构建步骤和服务端中间件都可以将 script 块作为字符串输出。Microdata 与 RDFa 则要求模板引擎将属性逐一添加到渲染后的元素中。
3. 使用标准 JSON 解析器即可。 任何配有 JSON 解析器的系统都能解析其中的图结构，不必遍历 DOM，也不必解析 HTML 属性。这一点对下游工具最有用，对 Google 自身反而影响不大。
4. 错误仅影响标记本身。 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，表示后续键名应按 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 会渲染页面并执行 JavaScript」。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 标记	最强：AI features 是 Google 官方页面
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）。因此，仍应部署 JSON-LD：它在索引系统中确有价值，也不会在实时抓取场景中造成损失；理由并不是对话引擎会直接解析它。

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

两个校验工具的用途不同。Google 的 Rich Results Test 检查标记是否符合 Google 特定富结果功能的使用要求；通过测试并不代表标记在技术上完全无误，只代表 Google 可能将其用于某种富结果展示。Schema Markup Validator 是 Schema.org 官方的校验工具，用于检查词汇本身是否符合规范；通过校验也不代表 Google 一定会呈现相应内容。两个工具可以配合使用：先用 SMV 检查标记是否符合 Schema.org 规范，再用 RRT 检查 Google 是否可能据此呈现富结果。

JSON-LD 特有的常见问题，与 面向 AI 的 Schema.org 所述的词汇层面问题互不重叠：

失败形态	具体问题	后果
JSON 语法错误（缺少逗号、末尾多余逗号、键名未加引号）	整个标记块无法解析	整个标记块直接失效，不存在「部分采纳」
@context 缺失、拼写错误或使用了其他 URL	解析器无法将键名对应到 Schema.org 词汇	标记块可以解析，但读取系统无法正确解释其中的内容
使用单引号而非双引号	JSON 强制要求双引号	标记块解析失败
字符串里出现未转义的 </script>	HTML 解析器提前关闭了 script 标签	块被截断，紧跟其后的 HTML 也随之出错
多个块之间 @id 重复	写法符合规范，但会造成图中的实体关系混乱	不会出现明显的错误提示，下游工具可能把毫无关联的实体合并
标记与可见内容相矛盾	Google 和 AI 会分别读取到相互矛盾的信息	可能触发 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）：关于 AI 在实时抓取时如何读取 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）