# Schema结构化数据怎么生成？完整指南

> Schema 结构化数据，是用统一格式说明网页事实的一段代码。它会把页面中的标题、作者、日期、价格、地址等信息，整理成搜索系统更容易读取的字段。

来源：https://www.starbox.work/insights/geo-guide/geo106/（星盒AI 知识中心，更新于 2026-09-30）

Schema 结构化数据，是用统一格式说明网页事实的一段代码。它会把页面中的标题、作者、日期、价格、地址等信息，整理成搜索系统更容易读取的字段。

很多人第一次制作 Schema 时，会直接打开生成器、选择模板、填写内容，然后复制代码。这样虽然能得到一段代码，却没有解决三个更重要的问题：

1. 当前页面应该使用哪一种 Schema 类型？
2. 代码中的字段是否与页面实际展示的内容一致？
3. 代码发布以后，搜索系统能否从线上页面正常读取？

只要其中一项没有处理好，即使代码通过语法检查，也可能无法正常发挥作用。

先给出一套简单的选择方法：

- 只有少量固定页面，可以使用在线生成器。
- 文章页、产品页、门店页等同类页面会持续增加，可以使用 CMS（网站内容管理系统）插件或页面模板自动生成。
- 需要处理电商、知识库、门店库或多语言网站中的大量页面，可以使用代码批量生成。
- 无论采用哪种方式，都要依次完成 Schema 语法、目标搜索功能和正式线上页面三次校验。

生成工具可以帮助你整理字段并输出代码，但不能替你核对页面事实、选择合适的类型，也不能保证页面获得富结果、排名提升或被人工智能生成的答案引用。

这里所说的“富结果”，是搜索结果中带有图片、价格、评分等附加信息的增强展示。

## Schema到底是什么？

普通网页主要负责把内容展示给读者，结构化数据则负责把同一批事实重新整理，供搜索系统等机器读取。

例如，一篇文章可能包含标题、作者、发布日期、更新时间、头图和正文。结构化数据可以把这些信息整理成一个 `Article`，也就是“文章”类型。

不同页面通常会使用不同类型：

- 企业主页可以使用 `Organization`，表示企业或组织。
- 本地门店页面可以使用 `LocalBusiness`，表示本地经营场所。
- 产品详情页可以使用 `Product`，表示具体产品。
- 文章页面可以使用 `Article`，表示文章内容。

这些类型和字段来自 Schema.org。Schema.org 是用于查询 Schema 类型、属性及其定义的网站。

需要特别注意：Schema.org 收录的类型和属性很多，但搜索引擎只会为其中一部分提供富结果。Schema.org 中存在某个类型，并不代表搜索引擎一定支持相应的增强展示。

![Schema结构化数据怎么生成？完整指南](/static/img/insights/geo-guide/geo106-2.jpg)

## 生成器实际做了什么？

一款 Schema 生成器通常完成三件事：

1. 选择要描述的页面类型。
2. 把页面信息填入相应字段。
3. 输出 JSON-LD、Microdata 或 RDFa 格式的代码。

JSON-LD 是一种常用的结构化数据代码格式，通常集中放在网页的一段独立脚本中。

Microdata 和 RDFa 是另外两种结构化数据格式，它们会把相关属性直接写进 HTML 标签。HTML 是用于组织网页内容和结构的标记代码。

三种格式都可以表达结构化数据。区别主要在于代码写在哪里，以及后续如何维护。

![Schema结构化数据怎么生成？完整指南](/static/img/insights/geo-guide/geo106-3.jpg)

## 为什么多数网站会优先选择JSON-LD？

JSON-LD 通常放在下面这样的 HTML 脚本区块中：

```html
<script type="application/ld+json">
</script>
```

它不需要把结构化属性逐项写进正文标签，因此页面内容和结构化数据可以分别维护。一个页面中存在多个描述主体时，JSON-LD 也更方便表达它们之间的关系。

Google 搜索支持 JSON-LD、Microdata 和 RDFa。在网站条件允许的情况下，Google 官方通常建议使用更容易实施和维护的 JSON-LD。它便于统一生成，也较少因为页面模板调整而出现手工修改错误。

但这并不意味着 Microdata 和 RDFa 不合格。只要代码有效，并且符合对应搜索功能的要求，两种格式同样可以使用。

选择格式时，应考虑网站的实际情况：

- 新网站的页面模板统一，开发人员也能维护字段对应关系，可以优先使用 JSON-LD。
- 旧网站已经稳定使用 Microdata 或 RDFa，而且没有事实错误和功能缺失，就没有必要只为更换格式而重做全站。

格式只是信息的表达方式。真正需要长期维护的，是页面内容与结构化数据之间的同步关系。

## 生成代码前，先整理页面事实

不要等到打开生成器以后，才临时从页面上寻找内容。更稳妥的做法，是先建立字段清单，确认每个值是什么、来自哪里、由谁维护。

字段清单至少应包含：

- 页面 URL，也就是网页地址
- 页面类型
- 页面主要描述主体的名称
- 标题
- 作者或发布主体
- 发布日期与更新时间
- 图片
- 描述
- 规范 URL，也就是希望搜索系统认定为主要版本的页面地址
- 当前类型特有的价格、地址、营业时间或常见问题等字段

每个字段都要标明来源。字段值应来自页面当前可以看到的内容，或者来自能够与页面同步更新的内容系统字段。

如果某个字段只在生成器中手工填写，页面更新后，结构化数据很可能仍然保留旧标题、旧价格、旧日期或旧图片。此时代码语法可能没有任何问题，但它描述的已经不是当前页面。

结构化数据必须与页面主要内容一致。页面没有展示的事实、已经过期的价格、虚构的评价或容易造成误解的字段，即使通过语法校验，也不合格。

## 还要说明不同对象之间的关系

一个页面可能同时出现文章、作者、发布企业和网页本身。一个网站也可能在首页、文章页、产品页和门店页中反复提到同一家企业。

如果每个页面都创建一个名称相同、彼此却没有关联的企业对象，搜索系统就更难确认这些信息是否指向同一个主体。

这时可以使用稳定的 `@id`。`@id` 可以理解为某个对象固定使用的识别地址。同一家企业出现在不同页面时，应尽量使用一致的 `@id`。

文章作者、发布组织、产品品牌和页面本身也应分别描述，再通过相应属性建立关系。不要把不同主体混成一个对象，也不要在每个页面反复创建互不关联的重复对象。

## 页面少：使用在线Schema生成器

如果只有几张固定页面，可以使用在线生成器。基本流程是选择类型、填写页面事实、导出 JSON-LD，再交给开发人员或通过网站后台插入页面。

在线工具使用成本较低，适合了解字段设置，也适合制作一两个样板页面。选择工具时，重点检查三项能力：

- 能否导出完整的原始代码。
- 是否覆盖网站实际需要的 Schema 类型。
- 是否允许修改全部必要字段。

只能预览结果、不能导出代码的工具，不适合正式使用。

在线生成器的主要问题不在代码输出，而在版本管理和内容同步。页面标题、价格、日期或图片发生变化后，手工生成的代码不会自动更新。

当页面超过十几张，或者同一种页面模板反复出现时，继续逐页复制粘贴，很容易造成字段遗漏和内容不一致。这时应及时改用自动读取页面字段的生成方式。

## 同类页面持续增加：使用CMS插件或模板模块

文章页、产品页、门店页等重复页面，更适合通过 CMS 插件或模板模块生成。

这类工具可以读取页面标题、作者、日期、主图和自定义字段，再按照统一模板输出 JSON-LD。页面内容更新时，结构化数据也可以跟随相应字段更新。

选择插件或模板模块时，不要只看它宣称支持多少种 Schema，还要检查以下问题：

- 页面字段能否准确对应到结构化数据字段。
- 模板能否覆盖网站现有的页面结构。
- 单个页面出现特殊情况时，能否单独调整。
- 生成的代码能否导出和检查。
- 插件或模板更新后，能否重新执行校验。

自动填充不代表内容一定正确。默认作者、默认图片、空字段和过期数据，仍然需要人工抽查。

还要检查重复输出。同一个页面可能同时由网站主题、CMS 插件和自定义代码生成结构化数据。如果三处代码描述的是同一个对象，却使用了不同的价格、图片或规范 URL，就会产生冲突。

所以上线前不能只确认“网页源代码里已经有 Schema”，还要检查是否存在重复对象和不一致字段。

## 页面多：使用代码批量生成

电商、知识库、门店库或多语言网站通常需要通过代码生成结构化数据。

开发人员可以从集中存放页面信息的数据库或数据接口读取字段，再根据不同页面类型输出 JSON-LD，并把校验加入网站的构建或发布流程。

一套能够用于正式发布的批量生成方案，至少要具备四项能力：

1. 必要字段缺失时阻止发布。
2. 稳定生成 `@id` 和页面 URL。
3. 区分测试环境地址与正式网站地址。
4. 模板发生变化后，重新检查所有相关页面。

每次生成的结果还应保留版本记录，以便追溯某个页面在某次发布时具体输出了什么。

使用代码生成，并不意味着可以自行创造 Schema 类型和属性。类型与属性仍应来自 Schema.org；如果希望页面获得某种搜索功能，还要以目标搜索引擎的官方文档为准。

工具负责批量处理并保持格式一致，人工仍要负责核对页面事实、选择类型，并判断内容是否符合搜索功能政策。

批量模板上线前，还要处理以下常见情况：

- 特殊字符是否经过正确处理，避免破坏代码格式
- 空字段是否被正确删除或阻止发布
- 同一字段包含多个值时，是否按列表形式正确输出
- 多语言内容是否使用了对应语言的字段值
- 规范 URL 是否正确
- 图片 URL 是否可以正常访问
- 测试域名是否已经替换为正式域名

任何一项没有处理好，都可能让一批页面同时出现错误。

## 一段JSON-LD代码包含什么？

下面是一段简化的文章页示例，只用于说明代码结构，不能直接复制到所有页面：

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "页面上实际显示的标题",
  "datePublished": "2026-08-11",
  "dateModified": "2026-08-11",
  "author": {
    "@type": "Person",
    "name": "页面上实际显示的作者"
  },
  "mainEntityOfPage": "https://www.example.com/article"
}
```

其中：

- `@context` 表示这段代码使用 Schema.org 的词表。
- `@type` 表示当前描述的对象类型，这里是文章。
- `headline` 表示文章标题。
- `datePublished` 表示发布日期。
- `dateModified` 表示最后更新时间。
- `author` 表示文章作者。
- `mainEntityOfPage` 指向这篇文章所属的主要页面。

正式使用时，需要根据页面实际内容和目标搜索功能的官方文档，补充必填字段与推荐字段。

示例中的标题、日期、作者和 URL 都不能原样保留。如果需要加入图片，也必须使用当前页面实际采用的图片地址。代码应由页面字段生成，不能把示例文字固定在模板中。

## 代码生成后，必须完成三次校验

生成代码只是第一步。要确认结构化数据能够正式使用，需要依次完成三类检查。

### 第一次：检查Schema语法

可以使用 Schema.org Markup Validator，也就是 Schema.org 提供的标记校验工具，检查以下内容：

- 代码中的括号、引号和逗号是否完整。
- 属性名称是否存在。
- 字段值的类型是否正确。
- 多个对象之间的关系是否已经连接。

这次校验要回答的是：这段代码是不是有效的 Schema.org 标记？

### 第二次：检查目标搜索功能

使用目标搜索引擎提供的测试工具，检查当前类型是否受到支持、必填字段是否齐全，以及页面是否符合对应功能政策。

以 Google 搜索为例，Rich Results Test 是 Google 的富结果测试工具，用于检查页面是否满足其支持的富结果类型和字段要求。

测试通过，只代表页面具备获得相应展示的资格，不代表搜索结果一定会采用这种展示。

这次校验要回答的是：这个页面是否具备对应增强展示的资格？

### 第三次：检查正式上线页面

页面发布后，还要使用搜索引擎提供的 URL 检查工具，查看搜索系统实际获取到的页面版本。

需要确认：

- JSON-LD 确实出现在搜索系统获取到的页面中。
- 结构化字段与页面可见内容一致。
- 代码没有被页面模板、缓存或发布流程遗漏。
- 页面没有受到错误的抓取或索引设置阻挡。

“抓取”是搜索系统读取网页内容的过程，“索引”是搜索系统把页面信息收录到可检索资料中的过程。

这次校验要回答的是：正式上线的页面能不能被搜索系统正常读取？

三次校验不能互相替代：

- Schema 语法有效，不代表它属于搜索引擎支持的富结果类型。
- 富结果测试通过，不代表代码已经成功部署到正式页面。
- 正式页面可以读取，也不代表页面一定会获得增强展示。

## 六类工具分别解决什么问题？

| 工具类别 | 适用场景 | 必须具备的能力 | 应保留的交付物 |
|---|---|---|---|
| 在线生成器 | 1—10张固定页面 | 类型选择、字段编辑、代码导出 | JSON-LD文件 |
| CMS插件或模块 | 重复页面模板 | 字段对应、模板覆盖、单页调整 | 自动生成的代码 |
| 自定义模板脚本 | 批量页面或多语言网站 | 版本记录、重复测试、环境区分、字段缺失时阻止发布 | 批量输出记录 |
| Schema.org校验器 | 所有页面 | 语法、词表、对象关系检查 | 校验结果 |
| 搜索功能测试工具 | 需要增强展示的页面 | 支持类型、必填字段、政策检查 | 功能测试结果 |
| 线上URL检查工具 | 已发布的真实页面 | 抓取、页面生成、代码读取状态 | 线上验收记录 |

如果团队只处理一个企业官网，可以先通过在线工具了解字段，再把确认后的类型和字段交给网站模板统一维护。

如果网站每周都会新增文章、产品或门店页面，应尽早接入 CMS 字段或代码模板。

判断方案是否合适，不看使用了多少工具，而要看页面更新后，结构化数据能否同步更新。

## 一套可以直接执行的完整流程

1. 盘点网站现有的页面模板，为每类页面选择一个主要 Schema 类型。
2. 建立字段清单，确认每个值来自页面可见内容，或来自能够同步更新的系统字段。
3. 根据页面数量和更新频率，选择在线生成器、CMS 模块或代码模板。
4. 生成 JSON-LD，重点检查 `@type`、`@id`、URL、日期、图片和不同对象之间的关系。
5. 使用 Schema.org 校验器消除语法和词表错误。
6. 使用目标搜索引擎的功能测试工具，检查必填字段和政策要求。
7. 正式发布后抽查线上页面，并保存代码、校验结果、版本记录和负责人信息。

第一次实施时，可以先选择3—5个有代表性的页面作为样板。样板完成三次校验后，再把模板应用到其他同类页面。

这样可以先发现字段来源、对象关系和内容同步问题，避免同一种错误同时出现在全站页面中。

## 常见问题

### 必须购买付费生成器吗？

不必。

页面较少时，使用能够导出代码的在线工具，再结合官方文档和校验器，就可以完成生成与检查。

页面较多时，主要成本来自字段维护、模板开发和发布后的重复检查，而不在生成按钮本身。

### 一个页面可以放多个Schema吗？

可以。

一个页面可以描述多个相关对象，但要明确它们之间的关系，并保证所有字段都与页面主要内容一致。

不要为了增加代码数量而堆叠无关类型，也要避免插件和自定义代码重复输出同一个对象。

### JSON-LD应该放在页面哪里？

JSON-LD 通常放在 HTML 的 `<head>` 或 `<body>` 脚本区块中。`<head>` 是存放页面标题、说明等信息的区域，`<body>` 是存放页面主要可见内容的区域。具体插入方式由网站使用的框架和模板决定。

关键不在位置本身，而在于搜索系统获取线上页面时能够读到这段代码，并且代码字段能够与页面内容同步。

### 为什么生成器没有报错，搜索功能测试仍然不通过？

因为两类工具检查的内容不同。

生成器或 Schema.org 校验器主要检查代码格式、词表和字段值类型；搜索功能测试还会检查搜索引擎是否支持当前类型、必填字段是否齐全，以及内容是否符合对应功能政策。

通过语法检查，不等于通过搜索功能检查。

### 页面更新后，需要重新生成吗？

需要同步更新。

只要标题、作者、日期、价格、库存、图片、地址等结构化字段发生变化，JSON-LD 就要随之更新。

使用字段对应关系和模板生成时，可以自动完成同步；手工生成的页面则需要重新核对并发布代码。

### 做了Schema，就会被AI引用吗？

不能保证。

AI 是人工智能的英文简称。Schema 可以让页面中的对象、属性和关系表达得更明确，但人工智能生成内容的系统是否抓取、理解、选择和引用页面，还取决于页面可访问性、内容质量、来源可信度、问题匹配程度和系统自身策略。

结构化数据同样不能保证排名或富结果。它的直接作用，是让页面事实更便于机器识别；是否采用这些信息，仍由搜索系统决定。

## 官方核验入口

- [Google Search Central：结构化数据入门](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- [Google Search Central：结构化数据通用规范](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [Schema.org词表与类型](https://schema.org/docs/schemas.html)
- [Schema.org Markup Validator说明](https://schema.org/docs/validator.html)