晓名 AI
在结构化数据的技术实现中，JSON-LD 是最常用也最受推荐的格式。作为 W3C 的推荐标准，JSON-LD 提供了将 Schema.org 词汇序列化为机器可读格式的规范方法。理解 JSON-LD 的原理、用法及其在不同 AI 引擎中的实际表现，是实施有效 GEO 策略的技术基础。
JSON-LD 是 Schema.org 的三种序列化格式之一，也是 Google 官方推荐的格式。它写在独立的 script 标签中，无需改动可见 HTML，维护更方便。采用既有搜索索引的 AI 会按结构化数据解析它；实时抓取的对话引擎则把它当作页面上的普通文字读取。
关键洞察：JSON-LD 的价值在于它同时服务于两种场景：对于依赖搜索索引的 AI（Google AI Overviews、Bing Copilot），它被解析为结构化数据；对于实时抓取的对话引擎（ChatGPT、Perplexity、Claude），它作为页面文字被读取。无论哪种情况，JSON-LD 都不会对页面造成负面影响，因此部署它是一项低风险的基础工作。
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。
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 推荐它的原因。
为什么 Google 推荐 JSON-LD
Google 在 中明确写道：
「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，也不必解析 HTML 属性。这一点对下游工具最有用，对 Google 自身反而影响不大。
- 错误仅影响标记本身。JSON-LD 写错只会使相应标记块失效，页面其他部分仍可正常工作。Microdata 或 RDFa 写错则可能与 HTML 渲染问题互相影响。
另外两种格式仍有适用场景，只是范围很窄。已经全面采用 Microdata 的旧站可以保留现状，Google 解析三种格式的能力相同。RDFa 在政府与学术机构发布关联数据时仍然常见，因为它的多词汇前缀在这类场景中确有用途。对于新部署，统一选用 JSON-LD。
JSON-LD 与前端框架的集成
在现代前端框架（如 React、Vue、Angular）中，JSON-LD 的部署需要特别注意输出时机：
- 服务端渲染（SSR）：在服务器端生成完整的 HTML 时，JSON-LD 应与可见内容一并输出。这是最可靠的方式，确保所有爬虫都能读取标记。
- 静态站点生成（SSG）：在构建时生成静态 HTML，JSON-LD 可以直接嵌入模板中。Next.js、Nuxt.js 等框架都支持这种方式。
- 客户端渲染（CSR）：如果 JSON-LD 由客户端 JavaScript 动态注入，只有执行 JavaScript 的爬虫（如 Googlebot）才能读取。这对于 AI 爬虫来说是不够的。
建议优先使用 SSR 或 SSG 方式部署 JSON-LD，以确保所有爬虫都能读取标记。如果只能使用 CSR，应考虑将关键的结构化数据同时写在可见 HTML 中，作为冗余备份。
JSON-LD 与多语言站点的配置
对于多语言站点，每个语言版本都应独立部署相应的 JSON-LD 标记。常见做法包括：
- 为每个语言版本创建独立的 JSON-LD 块
- 使用
inLanguage属性明确标识语言 - 确保每个语言版本的实体信息（名称、链接、sameAs）都使用该语言的正确内容
- 避免在不同语言版本之间共享 JSON-LD，除非内容是真正多语言的
错误的多语言配置可能导致实体信息混乱，影响 AI 对品牌身份的识别。建议在多语言站点上线前，使用 Schema Markup Validator 逐一验证每个语言版本的 JSON-LD。
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 | 将你的标记与知识图谱中的同一实体明确关联，是四个关键字中效用最大的一个 |
下面这个最小化的 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 引擎提供价值的部分，尽管这些引擎并不直接解析页面上的标记（见下文）。sameAs 链接如何帮助完成实体解析，详见 实体识别 与 知识图谱存在度。同一页面包含多个实体时（既有 Organization，又有作者 Person，还有 Article），可以为每个实体使用单独的 script 块，也可以用 @graph 将它们纳入同一个块；不同类型的模板与校验步骤见 Schema Implementation 操作手册。
放置与输出：标记写在哪里、爬虫看得见什么
关于放置和输出方式，需要回答三个问题。
写在文档的什么位置。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。
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：它在索引系统中确有价值，也不会在实时抓取场景中造成损失；理由并不是对话引擎会直接解析它。
校验、常见错误与反模式
两个校验工具的用途不同。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 的爬虫 | 标记对它不可见 | 这一类读取系统会将页面视为没有标记（见上文表格） |
尤其需要注意 面向 AI 的 Schema.org §7 所述的同类问题：无效或与可见正文相矛盾的 JSON-LD，比完全不加更糟。标记与可见正文不一致，既可能触发 Google 的结构化数据人工处罚，也会使 AI 读取到相互矛盾的文字。实时抓取的引擎原本就把 JSON-LD 当作文字读取，因此会同时获得两组互相矛盾的事实，最终无法采信任何一组。
下一步去哪里看
| 你想做的事 | 建议阅读 |
|---|---|
| 理解 Schema.org 词汇及它对 AI 的信号意义 | 面向 AI 的 Schema.org |
| 在站点上全面部署 JSON-LD：模板、流程与校验 | Schema Implementation |
了解 sameAs 如何将实体与知识图谱中的同一实体明确关联 |
实体识别 |
| 了解实体存在度的具体表现 | 知识图谱存在度 |
| 在全站审计里检查 JSON-LD 部署 | GEO 审计 |
| 让非 Google 的 AI 爬虫也能读取标记 | SSR for AI Crawlers · AI 爬虫 |
| 让一个段落真正能被 AI 答案直接引用 | 可引用性 |
中国企业实施 JSON-LD 的特别考量
对于面向中国市场的企业，JSON-LD 的实施需要结合本地技术生态的特点进行调整：
首先，国内主流 CMS 和建站平台对 JSON-LD 的支持程度不一。WordPress 通过 Yoast SEO 或 Rank Math 等插件可以方便地添加 JSON-LD；国内平台如 Shopify、有赞、微盟等的支持程度需要单独评估。建议优先使用已经内置结构化数据支持的工具，以减少手动配置的错误。
其次，国内搜索引擎对结构化数据的处理与 Google 存在差异。百度搜索对 JSON-LD 的支持相对保守，主要集中在 BreadcrumbList 和 Article 类型上。百度 AI 搜索的引用来源更多依赖内容本身的质量和相关性，而非结构化标记。因此，国内企业实施 JSON-LD 时，应将其视为提升搜索引擎理解度的辅助手段，而非主要的 GEO 策略。
第三，国内 AI 引擎如文心一言、通义千问等，目前尚未公布对结构化数据的明确支持政策。建议关注各厂商的官方文档更新，及时调整实施策略。
第四，跨国企业应特别注意 JSON-LD 的多语言支持。如果企业网站包含多个语言版本，每个语言版本都应独立部署相应的 JSON-LD 标记，并使用 inLanguage 属性明确标识语言。
常见问题解答
JSON-LD 比 Microdata 或 RDFa 更好吗？
三种格式表达的是同一套 Schema.org 词汇，Google 也表示「三种格式在 Google 这里受到同等对待」。Google 推荐 JSON-LD，是因为它写在独立的 script 标签中，与可见 HTML 完全分离，增删标记无需改动模板，也不会导致页面布局异常。只有两种情形可以例外：站点已经全面采用 Microdata，迁移成本高于收益；或是在仍普遍采用 RDFa 的政府及学术关联数据发布场景中。新部署应统一选用 JSON-LD。
ChatGPT、Claude、Perplexity 会读我的 JSON-LD 吗？
在答案生成阶段，它们不会把 JSON-LD 作为结构化数据解析。2025 年 12 月的一次受控测试只把价格写入 JSON-LD，再向五个系统提问，结果没有一个实时抓取的对话引擎能够取得这个值。2026 年 2 月的另一项独立观察发现，ChatGPT 与 Perplexity 甚至会复述语法错误或虚构的 schema 中的值，可见它们只是把标记当作页面上的普通文字读取，并未解析其中的结构。这些模型仍可从实体信息中获益，但信息来自知识图谱，而不是在抓取页面时解析 JSON-LD。
script 标签放在页面什么位置？
Google 明确表示，script 标签可以放在 <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 检查标记是否符合 Google 特定富结果功能的使用要求；通过测试不代表标记在技术上完全无误，只代表 Google 可能将其用于某种富结果展示。schema.org 官方的 Schema Markup Validator 检查词汇是否符合 Schema.org 规范；通过校验也不代表 Google 一定会呈现相应内容。两者各有用途：用 RRT 检查富结果资格，用 SMV 检查词汇是否正确。完整的部署流程见 Schema Implementation 操作手册。
延伸阅读
JSON-LD 实施的最佳实践
为了确保 JSON-LD 发挥最大效用，建议遵循以下最佳实践：
实施前准备
- 审计现有标记：检查站点是否已有 Schema.org 标记，识别缺失或错误的标记
- 确定优先级：根据业务目标，确定优先实施哪些类型（Organization > Person > Article > FAQPage）
- 收集实体信息：收集 Wikipedia、Wikidata、社交媒体等权威来源的 sameAs 链接
- 制定模板：为常见内容类型（文章、产品、FAQ、HowTo）制定 JSON-LD 模板
实施过程中的注意事项
- 保持与内容一致：JSON-LD 中的信息必须与可见正文一致，不一致会导致 Google 人工处罚
- 使用绝对 URL：URL 属性应使用完整的绝对 URL，而非相对 URL
- 避免嵌套过深：虽然 JSON-LD 支持嵌套，但过于复杂的嵌套可能增加维护难度
- 定期校验：使用 Schema Markup Validator 和 Rich Results Test 定期校验标记
- 版本控制：将 JSON-LD 模板纳入版本控制系统，便于追踪变更
实施后的验证与监控
- Google Search Console：在 Search Console 中检查结构化数据报告，确认标记是否被正确识别
- 爬虫模拟：使用 Googlebot 工具模拟爬虫访问，确认 JSON-LD 是否被正确渲染
- 引用监控：监控 AI 引擎中的引用情况，评估 JSON-LD 对实体识别的帮助
- 错误预警：设置自动化测试，及时发现 JSON-LD 语法错误或内容不一致
JSON-LD 与 AI 内容生成的关系
虽然实时抓取的 AI 引擎不会解析 JSON-LD，但结构化数据仍然对 AI 内容生成有间接影响：
- 知识图谱增强：正确的 JSON-LD 标记有助于增强知识图谱中的实体信息，这些先验知识会被 AI 模型调用
- 搜索索引质量：结构化数据有助于搜索引擎更好地理解页面内容，从而提高索引质量，间接影响依赖搜索索引的 AI 引擎
- 内容可信度：完整的实体信息（如作者、机构、sameAs 链接）有助于提升内容的可信度，进而影响 E-E-A-T 判断
因此，JSON-LD 的实施价值不仅在于直接的解析效果，更在于它对整体内容质量和可信度的提升。