JSON-LD 如何帮助 AI 理解您的网站

Jun 3, 2026 · 5 min read

JSON-LD 是一种基于 <script> 标签的格式，用于将 Schema.org 词汇表作为结构化、机器可读的元数据嵌入 HTML 中。它使搜索引擎和 AI 系统能够识别实体——文章、组织、产品、面包屑导航、人物——而无需从正文中推断。对于 Google Search 而言，正确的 JSON-LD 可使页面符合特定搜索功能的条件，并有助于填充知识图谱。对于 GPTBot、ClaudeBot 和 PerplexityBot 等 AI 爬虫而言，有一个前端开发者普遍忽视的硬性限制：这些爬虫不执行 JavaScript，因此 JSON-LD 必须存在于服务器响应中，才能被它们读取。

本文将介绍 JSON-LD 的实际作用、适用场景与局限性、三个可直接参考的示例、导致客户端注入标记对 AI 爬虫失效的渲染差距，以及如何验证您所发布的内容。

核心要点

JSON-LD 是 Google 推荐的结构化数据格式，使用 Schema.org 词汇表以机器可读的形式描述实体及其关系。
包括 GPTBot、ClaudeBot 和 PerplexityBot 在内的 AI 爬虫不执行 JavaScript——通过 useEffect、Google Tag Manager 或任何客户端路径注入的 JSON-LD 对它们而言是不可见的。
AI Overviews 和 AI Mode 不需要特定的 AI 标记；适用标准 Google Search 的资格条件，结构化数据有助于内容解读，但不保证被收录。
Google 已于 2026 年 5 月停止在搜索结果中展示 FAQ 富媒体摘要，Search Console 和 Rich Results Test 的相关支持将于 2026 年 6 月移除；FAQPage 仍是有效的 Schema.org 类型，但已不再是获取富媒体摘要的有效策略。
从长期验证的角度来看，validator.schema.org 是更稳妥的默认选择——它可检查完整的 Schema.org 词汇表，而 Google Rich Results Test 仅涵盖 Google 支持的功能。

JSON-LD 是什么，为何存在

JSON-LD（JavaScript Object Notation for Linked Data，关联数据的 JSON 表示法）是 W3C 标准化的语法，用于以 JSON 格式表达关联数据。在 Web 领域，它几乎总是用于在文档的 <script type="application/ld+json"> 标签中嵌入 Schema.org 词汇表。这些数据描述页面的实体——页面内容是什么、由谁撰写、哪个组织发布、与其他页面的关联关系——以解析器可直接消费的形式呈现，无需读取正文。

引入 JSON-LD 的原因在于降低解读成本。如果没有结构化数据，爬虫就必须推断页面上的”Apple”指的是公司还是水果；署名”Jane Chen”是作者还是文章主题；标记中的价格属于页面上的产品还是侧边栏中的相关商品。Schema.org 为这些事实提供了明确的类型和属性。JSON-LD 将它们以独立于可见 DOM 的块形式传递，这正是 Google 推荐它优于 Microdata 和 RDFa 的原因——您可以在不修改布局的情况下生成和更新结构化数据。

有几点需要明确说明：JSON-LD 并非 Google 文档化排名系统中已确认的排名因素。它不保证富媒体摘要——符合资格是必要条件，但并非充分条件。它不保证被收录进 AI Overviews 或 AI Mode。AI 系统也不要求使用 JSON-LD，它们同样可以读取正文。JSON-LD 的作用在于减少推断工作量，从而提高正确解读的可能性，降低模糊内容被错误分类的风险。

JSON-LD 与 AI Overviews 及 AI Mode 的关系

AI Overviews 和 AI Mode 建立在 Google 现有搜索索引之上。Google 的官方指导明确表示，不存在专门针对 AI 的标记——页面通过与常规搜索相同的内容和结构化数据信号获得 AI 功能的资格。如果您的页面已被正确索引、结构合理，并与用户意图匹配，那么您为 Search 发布的结构化数据就是这些功能所依赖的数据。

客观来说：结构化数据有助于 AI 系统正确解读您的内容，但不能保证被纳入生成式答案。应将其视为消除歧义的手段，而非增长杠杆。

AI 爬虫的渲染差距

这是前端开发者最需要关注的技术要点，却在大多数 JSON-LD 相关文章中被忽视：AI 爬虫通常应被视为非渲染爬虫，因此结构化数据必须存在于初始 HTML 响应中。

OpenAI 的 GPTBot 获取 HTML，不渲染客户端 JavaScript。
Anthropic 的 ClaudeBot 作为标准 HTTP 爬虫运行，不执行 JS。
PerplexityBot 同样只读取原始 HTML。

Googlebot 是个例外：它通常会在延迟处理阶段渲染 JavaScript，因此客户端注入的 JSON-LD 最终会被 Search 处理。但 AI 爬虫不会等待。如果您的 JSON-LD 只在水合（hydration）之后才存在，它对目前读者最常询问的那些系统而言是不可见的。

在实际前端应用中，一种常见的生产故障模式是：开发者在 useEffect 钩子中添加 JSON-LD，或通过 Google Tag Manager 推送。该块出现在渲染后的 DOM 中，Rich Results Test（会执行渲染）显示其有效，团队便认为大功告成。然而与此同时，所有非渲染爬虫看到的 HTML 响应中根本没有任何结构化数据。

解决方法是将 <script type="application/ld+json"> 块放入初始服务器响应中。

按框架进行 JSON-LD 服务端渲染

框架	JSON-LD 的放置位置
Next.js App Router	在 Server Component 中内联 `<script type="application/ld+json">`，或使用 Metadata API 的 `other` 字段
Next.js Pages Router	在 `next/head` 的 `<Head>` 中内联 `<script>`，通过 `getServerSideProps`/`getStaticProps` 路径渲染
Nuxt 3	在服务端上下文中调用 `useHead`，传入 `script` 条目
Astro	直接在 `.astro` 模板中内联 `<script type="application/ld+json">`（默认静态，无需 JS 执行）
SvelteKit	在 `<svelte:head>` 块中包含脚本，由服务端渲染

各技术栈的原则相同：JSON-LD 块必须存在于服务器返回的字节中，而不是浏览器在首次渲染后添加的字节中。

三个可用的 JSON-LD 示例

以下示例使用 2026 年 3 月 19 日发布的 Schema.org 30.0 版本词汇表。

BlogPosting（Article 的子类型）

在 Schema.org 层级中，BlogPosting 是 Article 的子类型，而 Article 本身又是 CreativeWork 的子类型。声明 "@type": "BlogPosting" 会隐式继承所有 Article 属性，无需同时声明两者。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://openreplay.com/blog/json-ld-ai-search#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://openreplay.com/blog/json-ld-ai-search"
  },
  "headline": "How JSON-LD Helps AI Understand Your Website",
  "description": "A frontend-focused guide to JSON-LD, Schema.org, and the server-rendering requirement for AI crawlers.",
  "image": "https://openreplay.com/images/blog/json-ld-ai-search.png",
  "datePublished": "2026-05-20T09:00:00-04:00",
  "dateModified": "2026-05-20T09:00:00-04:00",
  "author": {
    "@type": "Organization",
    "name": "OpenReplay Team",
    "url": "https://openreplay.com"
  },
  "publisher": {
    "@id": "https://openreplay.com/#organization"
  }
}
</script>

在长篇文章页面上使用此标记。mainEntityOfPage 将文章与其规范 URL 关联；dateModified 很重要，因为当时效性是查询信号时，Google 会使用该字段。

Organization

Organization 类型描述发布实体。使用 sameAs 指向规范的外部资料页——这是系统将您的品牌与同名其他实体区分开来的方式。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://openreplay.com/#organization",
  "name": "OpenReplay",
  "url": "https://openreplay.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://openreplay.com/images/logo.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://github.com/openreplay",
    "https://www.linkedin.com/company/openreplay",
    "https://x.com/OpenReplayHQ"
  ]
}
</script>

在全站范围内部署一次——通常放在每个页面的文档 <head> 中。在其他 schema 块中复用该 @id（如上方 BlogPosting.publisher 所示），使单一规范的 Organization 定义在各处被引用，而非重复声明。

BreadcrumbList

BreadcrumbList 描述页面在网站层级中的位置。Google 支持面包屑富媒体摘要，同样的数据也有助于 AI 系统理解网站结构。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://openreplay.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://openreplay.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How JSON-LD Helps AI Understand Your Website"
    }
  ]
}
</script>

最后一项省略了 item，因为它就是当前页面。position 从 1 开始计数。

保持结构化数据与可见内容一致

Google 的结构化数据指南明确规定：JSON-LD 中的内容必须与页面上显示的内容相符。标记页面上不存在的评论、未显示的价格，或与可见署名相矛盾的作者姓名，都存在被手动处罚的风险。结构化数据应当描述页面内容，而不是用 DOM 中未经证实的声明来”增强”页面。

这对 AI 系统同样重要。如果您的可见正文与 JSON-LD 内容相互矛盾，您制造的正是结构化数据本应消除的那种歧义。

发布前进行验证

以下两个工具可覆盖完整的验证工作流：

工具	检查内容	最适用场景
Google Rich Results Test	Google 支持的富媒体摘要类型的资格验证	Article、Product、Breadcrumb 等类型的部署前检查
Schema Markup Validator	对完整 Schema.org 词汇表的符合性检查	通用验证；适用于 Google 不作为富媒体摘要展示的任何类型

Rich Results Test 会渲染页面（因此能看到 AI 爬虫看不到的客户端注入 JSON-LD）。要确认非渲染爬虫实际看到的内容，可对您的 URL 运行 curl -A "GPTBot" https://your-page，并在响应中搜索 application/ld+json。如果该块不在原始 HTML 中，AI 爬虫就不会看到它。

Google Search Console 的”增强功能”部分会报告解析错误以及 Google 跟踪的结构化数据类型的资格状态。将其用于持续监控，而非部署前验证的替代工具。

关于 FAQPage 的说明

FAQPage 仍是有效的 Schema.org 类型，Google 仍将其用于内容理解。但 Google 在其 FAQPage 文档中指出，FAQ 相关的 Search 功能正在被移除：FAQ 富媒体摘要已于 2026 年 5 月停止在搜索结果中展示；Search Console 报告和 Rich Results Test 支持将于 2026 年 6 月移除；Search Console API 支持将于 2026 年 8 月随之停用。如果您现在选择实施 schema 以获取可见的富媒体摘要效果，FAQPage 并非合适的选择。如果您确实有 FAQ 页面并希望在语义层面留存记录，可以实施它——但不应将其作为抢占搜索结果版面的手段。

这也是 validator.schema.org 成为长期验证工作更稳妥默认选择的原因：它不依赖于 Google 选择以富媒体摘要形式展示哪些功能。

优先发布什么

如果您从零开始，最具价值的实施顺序是：在全站部署一个 Organization 块，在除首页外的每个页面添加 BreadcrumbList，在编辑内容上添加 Article/BlogPosting。所有内容均采用服务端渲染。使用两种工具进行验证。然后用非渲染 User-Agent 检查原始 HTML 响应，确认 AI 爬虫确实能接收到您编写的内容。

结构化数据本身不会推动排名提升，也不能让您的内容进入 AI Overviews。但它能做到的是——在正确发布的情况下，可靠地消除导致搜索引擎和 AI 系统误读内容的推断猜测。对于前端团队而言，最重要的工作不是选择添加哪些 schema 类型，而是确定它们在渲染管线中的位置。将 JSON-LD 放入服务器响应中，其余的交给内容本身。

常见问题

使用 JSON-LD。Google 明确推荐它优于 Microdata 和 RDFa，因为它存在于与可见 DOM 解耦的单一 script 块中，这意味着您可以在不修改布局标记的情况下生成和更新结构化数据。三种格式都能表达 Schema.org 词汇表，也都能被 Google 解析，但 JSON-LD 更易于维护、更易于服务端渲染，也是 Google 在其结构化数据文档中的示例所使用的格式。

可以。Google 支持单个页面上有多个独立的 script 标签，这是组合 Organization、BreadcrumbList 和 BlogPosting 等类型的标准模式。另一种方式是在单个 script 中使用 @graph 键包含一个图数组，每个实体拥有自己的 @id。两种方式均有效；当实体之间通过 @id 相互引用时，@graph 模式更为简洁，因为它为每个实体保留了单一的规范定义。

仅当 JSON-LD 存在于初始服务器响应中时有效。在水合后才注入结构化数据的 SPA，对 GPTBot、ClaudeBot 和 PerplexityBot 等非渲染爬虫而言是不可见的。解决方法是对需要结构化数据的页面采用服务端渲染或静态生成——使用 Next.js、Nuxt、Astro 或 SvelteKit 的 SSR 或 SSG 模式——确保 script 标签在任何 JavaScript 执行之前就存在于 HTML 字节中。

仅在文章实质性内容发生变化时更新 dateModified——包括更正、新增章节、更新事实、刷新示例。不要在每次部署时或进行错别字修正、样式调整等表面性编辑时更新它。Google 将 dateModified 作为时效性查询的新鲜度信号，在没有真实内容变化的情况下虚增该值，违反了结构化数据必须与可见内容相符的规定，存在被手动处罚的风险。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.