# Schema结构化数据到底应该怎么用？

URL: https://caijiao.org/posts/168
Source: docs/posts/168.md
Description: 结构化数据不改变排名，改变的是搜索结果的呈现形态。工具站用到的是 SoftwareApplication、BreadcrumbList 等少数几种，规模化站点应该在构建期和标题共用同一套变量注入，而不是事后补。

先把一件事说清楚，因为它决定了你该投入多少精力：结构化数据不是排名因素。加了一组 JSON-LD，不会让页面从第二页跳到第一页。

它做的是另外两件事——让 Google 更准确地理解这个页面是什么，以及让页面有资格获得更丰富的展示形态。理解这个定位之后，才谈得上"怎么用"。

## 它改的是呈现，不是排序

同一条搜索结果，带面包屑路径、带评分星级、带 FAQ 折叠，和不带任何增强的纯标题加摘要，点击率可以差出不少。结构化数据争取的是这个位置上的差异。

Omni Calculator 的 /finance/annual-income 页面，主词月搜索量 81000，页面月访问 50825。这个量级下，搜索结果页上每一点展示差异都会被放大成可观的访问差。这也是为什么计算器类站点普遍把结构化数据当作标配。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页写着 3925 个免费计算器，Finance 一个分类就占 616 个。*

但差异的前提是标记必须准确。标错或者标了页面上看不到的内容，轻则该富媒体结果不显示，重则该站点的这类增强结果整体失效。

结构化数据还有一层作用常被忽略：它给 Google 提供了一种不依赖自然语言理解的确认方式。页面正文里写了很多，Google 需要从中判断这是什么；JSON-LD 里直接声明了 applicationCategory 和 featureList，判断就明确得多。对程序化站点来说，这一层的价值可能比富媒体展示本身更大。

## 工具站实际用到的只有三四种

schema.org 里有几百种类型，工具站真正用得上的很有限。

SoftwareApplication 或 WebApplication 是主体，声明名称、功能描述、是否免费、运行环境（浏览器）、是否需要注册。工具页用这一组就够，不必再套 Organization 和 Product。

BreadcrumbList 用来交代层级：首页 > 财务计算 > 时薪转年薪。它对程序化站点特别有用，因为几千个页面的层级关系靠 URL 只能猜，靠标记是明确的。

FAQPage 用在有真实问答的页面上。HowTo 用在有明确步骤的任务上，比如"如何把 PNG 转成 JPG"。这两类不是必选项，加了也不保证显示。

判断该用哪种类型的依据很直接：看这个页面本质上是什么。一个能用的工具是 WebApplication，一篇讲步骤的文章是 Article 或 HowTo，一个纯参数组合的落地页可能哪种都不合适——那就别硬套。

类型选错的代价不是"没效果"，是给 Google 传了一个错误的页面定位。把工具页标成 Product 并给它塞价格和库存字段，页面既不会获得商品展示，也让自己的定位变得模糊。

## 最常见的错：标记了页面上没有的内容

这是结构化数据最快失效的方式。

页面正文里没有 FAQ 区块，却在 JSON-LD 里塞了五个问答；页面没有用户评分，却标记了 aggregateRating 给 4.8 分；页面没有作者信息，却编了一个作者。

这些做法在短期内可能拿到富媒体展示，但它属于典型的"标记与页面不符"，一旦被识别，失去的是整个站点的增强结果资格，而不是单个页面。

一条可以写进 CI 的规则：JSON-LD 里出现的每一段文本，都要能在页面的 HTML 里找到对应内容。这条校验不难写，把 JSON-LD 里的 description、name、text 字段取出来，去 HTML 里做一次子串匹配即可。

另一类常见错误是字段为空或填了占位符。批量生成时某个页面的配置漏填，模板把空字符串渲染进了 required 字段，JSON-LD 依然能通过语法校验，但语义上是不完整的。构建期对必填字段做一次非空检查，比上线后靠报告发现快得多。

## 规模化站点应该在构建期注入，不能事后补

几千个页面的站点，手写 JSON-LD 不现实，也不必要。

正确做法是把它当成模板的一部分：结构化数据和标题、描述读同一份页面配置，构建时一起生成。这样加一个字段，三处同步更新；某个页面的配置漏填，构建期的校验会直接报出来。

具体字段的组织方式和常见坑，[JSON-LD](/json-ld/) 里有更完整的说明。核心原则只有一条：结构化数据不是独立于页面的另一份内容，它是页面已有内容的另一种表达。

实现上有个细节值得注意：JSON-LD 用 script 标签放在 head 或 body 末尾都可以，但不要放在会被 JS 动态替换的容器里。模板引擎渲染时如果把它当成了普通字符串做了转义，引号会被破坏，标记就废了。

## 上线后看什么，不看什么

不看"有没有生效"——很多结构化数据即使完全正确，Google 也不会展示富媒体结果，这是它的选择，不是你的错误。

要看的是 [Search Console 的增强报告](/google-search-central/02-search-console-setup)里有没有报错。报错说明标记本身有问题，是必须修的；没报错但没展示，属于正常。

更完整的排查思路可以顺着 [Google Search Central](/google-search-central/) 的文档走，其中包含各类结构化数据的展示条件说明。

## 别把结构化数据当成内容的替代品

最后一点值得单独说。有些程序化页面正文很薄，靠 JSON-LD 把内容撑起来——这是把工具用反了。

结构化数据的前提是页面本身有内容，标记只是把内容标注清楚。页面空空如也，标记写得再完整，也拿不到任何增强，反而给站点增加了一层"内容和标记不匹配"的风险。

判断标准很简单：把 JSON-LD 整段删掉，页面还能不能独立回答用户的问题。能，标记才有意义；不能，该补的是正文，不是标记。

---

*Omni Calculator 单页数据来自 Ahrefs（2026 年 6 月）。*