结论先行：结构化数据对 AI引用有用，但只有实体层有用。 我们 62 个中文站点三个月的监测显示，Organization + sameAs + @id 带来引用率中位 +3.1pp，LocalBusiness +4.7pp；Article 的日期与作者字段是弱正；FAQPage +0.2pp、BreadcrumbList 0.0pp、HowTo −0.1pp，均与零无异。
把 Schema 当整体去问"有没有用"，只能得到模糊答案；拆到类型层面问，答案立刻可执行。
这篇给四样东西：外部证据的真实边界、中文 AI 平台为什么不能照搬、我们分类型的监测结果、一套你能在自己站上跑的实测协议。
外部证据的真实边界：三条确定的，一条被误读的
公开证据里只有三条是硬的。
第一条，Ahrefs 的准实验。 追踪 1,885 个新增 JSON-LD 的页面，用 4,000 个引用水平相近的跨域页面做匹配对照，结果是 AI Overviews 引用量 −4.6%、AI Mode +2.4%、ChatGPT +2.2%——除第一项外均与零无异。
第二条，Google 官方口径。 Search Central 的 AI 功能文档写明：没有需要为 AI 功能额外添加的 schema.org 结构化数据。
第三条，微软的正面表态。 Bing 的 Fabrice Canel 在 SMX Munich 上确认 Schema 帮助微软的大模型理解内容。这是目前唯一一条来自 AI 平台方的明确肯定。
被误读的是那条相关性数据。 Ahrefs 在大规模 URL 横截面里发现，被 AI 引用的页面带 JSON-LD 的概率约为未被引用页面的三倍。这个 3 倍差被大量文章当成因果结论转述，但同一份研究的因果部分把它归因于站点整体质量与权威度——能把 Schema 铺完整的站，通常内容、外链、更新频率也都在线。相关不等于因果，这是全网关于结构化数据 AI引用最常见的一处误读。
中文 AI 平台为什么不能照搬这些结论
上述证据全部产自 Google 与 ChatGPT 生态。中文 AI 平台的检索架构不同，结论不能平移。核心差异：国内主流模型的引用来源高度集中在各自的内容生态，而不是开放网页索引。
从公开的引用来源统计与我们面板的抓取记录看：
- 豆包：引用大量来自抖音、今日头条等字节系内容，站外内容资产的权重远高于站内标记（详见抖音内容能进豆包和 AI 搜索吗）
- Kimi：UGC 占比高，知乎权重突出
- 通义千问 / 夸克：偏向新闻媒体号与已收录资讯源
- DeepSeek：缺乏自有内容生态，引用集中在百科、电商与门户
关键推论：你的 JSON-LD 是否被解析，取决于喂给该模型的那层索引是否解析它，而不是取决于模型本身。 一个站点即使 Schema 完美，如果不在豆包的召回池里，标记再全也不会产生引用。
对品牌方的实际影响是，站内结构化数据的天花板明显低于英文语境。想系统性提高中文 AI 可见度，站外证据网络的权重更高——这一层的排布逻辑在AI 引用来源优化：来源类型与证据链建设里单独拆过。
我们怎么测的：62 个站点、4 个平台、三个月
面板构成：62 个中文站点，消费品牌 24 个、B2B 与 SaaS 21 个、本地服务 17 个。观测窗口 2026 年 3 月至 6 月。其中 44 个站点在窗口内新增或补全了至少一类 Schema，18 个未改动结构化数据，作为基线漂移对照组。
Prompt 集与指标：每站配置 30–50 条问题，覆盖品类推荐（"XX 类产品有哪些靠谱品牌"）、品牌直问（"XX 这个牌子怎么样"）、对比类（"A 和 B 哪个更适合……"）三种意图，每周在 DeepSeek、豆包、Kimi、通义千问各跑两次。核心指标是引用率：域名出现在该条答案引用来源列表中的答案占比。提及率单独统计，不混入下表。
方法论边界必须说清楚：这是观测数据，不是随机对照实验。站点在打标同期往往还做了别的改动，无法完全隔离。对照组三个月的引用率中位漂移为 +0.4pp，下表数值均已减去该漂移。部分类型样本量偏小，只支撑方向判断，不支撑精确效应量。
分类型结论：哪些有可观测增益，哪些是无效投入
"为正站点比例"比中位数更能说明问题——比例接近 50% 意味着结果与随机波动无法区分。
| Schema 类型 | 打标站点数 | 引用率中位变化 | 为正站点比例 | 判断 |
|---|---|---|---|---|
| LocalBusiness（本地服务子集） | 12 | +4.7pp | 9/12 | 增益最强 |
| Organization + sameAs / @id | 38 | +3.1pp | 26/38 | 有可观测增益 |
| Person（作者实体） | 19 | +1.8pp | 12/19 | 中等，依赖跨平台一致 |
| Article / BlogPosting | 41 | +1.4pp | 25/41 | 弱正，集中在时效类问题 |
| Product / SoftwareApplication | 23 | +0.6pp | 12/23 | 仅参数类问题兑现 |
| FAQPage | 34 | +0.2pp | 17/34 | 与零无异 |
| BreadcrumbList | 29 | 0.0pp | 14/29 | 对 AI 无作用 |
| HowTo | 11 | −0.1pp | 5/11 | 无 |
站点数之和大于 44，因为多数站点同时补了多个类型。
实体层：唯一稳定为正的一类
Organization 与 LocalBusiness 的增益不来自"被排名奖励"，来自消歧。
中文品牌名同名率极高，"星辰""云图""智联"这类词在不同行业各有数家公司。当 sameAs 把官网、百科词条、企业信用信息、主流社媒账号串成一组，模型判断"用户问的是哪个星辰"的错误率明显下降。百科词条在这条链里权重最高，百科词条怎么建 AI 才当权威信源那篇拆过建站与送审流程。
@id 的作用是给实体一个跨页面稳定的锚点，让首页、产品页、文章页指向同一个 Organization，而不是三个孤立对象。具体标哪些字段、发布后怎么验证，可对照用 Schema 让 AI 看懂品牌和产品的字段清单逐项过。
本地服务的 +4.7pp 是全表最高，原因是 LocalBusiness 里的地址、营业时间、服务区域是事实型字段，AI 在回答"XX 区哪家……"这类问题时需要直接抽取，标记与页面可见信息一致时抽取成功率显著更高。前提是 NAP（名称、地址、电话）在站内、地图、平台三处完全一致，任一处不一致，增益就消失。
内容层：值钱的只有作者和时间两个字段
Article 的 41 个站点里，增益几乎全部集中在"2026 年最新""现在""目前"这类带时效限定的问题上。拆开看，起作用的字段是 datePublished、dateModified、author；其余字段（wordCount、articleSection、keywords）没有任何可辨识的差异。
dateModified 必须配合真实更新。只改日期不改内容，在我们面板里没有产生任何正向变化——部分平台会比对正文指纹，日期与内容不一致反而降低信任。
author 要与页面上可见的作者信息、以及该作者在站外的身份一致。孤立的 Person 标记价值很低：一个只出现在 JSON-LD 里、站外查无此人的作者名，模型无法用它做权威度判断。
对象层：Product 只在参数问答里兑现
Product 与 SoftwareApplication 的整体数值很难看（+0.6pp，52% 为正），但拆意图后有明确结构：
- 事实抽取型问题（"XX 型号参数是多少""XX 多少钱起"）：标了
offers、brand、model、规格属性的页面被准确引用的比例明显更高 - 生成型问题（"推荐几个品牌"）：没有差异
结论是按问题类型投。如果你的品类在 AI 里主要被问参数和型号，Product 值得做全；如果主要被问"哪家好"，这部分工时应该挪到实体层和站外证据。
aggregateRating 单独提醒：只在有真实、可核验的评价数据时才标。造假评分违反 Google 结构化数据政策，可能导致富结果资格被整站移除，风险远大于潜在收益。
FAQPage 与 HowTo：可以停手了
这两类是当前最大的无效投入来源。Google 早在 2023 年就收缩了 HowTo 与 FAQ 富结果的展示范围，FAQ 富结果仅保留给权威政府与健康站点，HowTo 富结果后续进一步下线。标记本身仍然合法，但原本的展示价值已经消失。
我们面板里 FAQPage 的 34 个站点为正比例正好 50%——这是"完全没有效应"的典型形态。
真正有效的是 FAQ 这种内容形式本身：一问一答、答案先行、每块自包含，这些特征让段落更容易被抽取。把内容写成问答结构有价值，把它包进 FAQPage 标记里没有额外价值。区分这两件事，能省掉一个季度的无效工时。
最反直觉的发现：增益来自打标时被迫做的事实对齐
这是整份数据里最值得单独说的一条。
在 Organization 类引用率上升的 26 个站点中，有 21 个在打标同期修改了正文事实——统一了品牌全称写法、修正了成立时间、重命名了不一致的产品线、补齐了缺失的资质信息。
把这 21 个站点剔除后，剩下 5 个"只改标记、没动正文"的站点，引用率中位增益从 +3.1pp 跌到 +0.7pp。
换句话说，Schema 在这个环节的主要身份是一致性审计工具，不是排名杠杆：
- 填
foundingDate，逼你确认成立时间到底写哪一年 - 填
sameAs，逼你清点品牌在站外还有哪些活跃阵地、哪些是废弃账号 - 填
legalName，逼你面对官网上三处品牌名写法不同的事实
修掉这些不一致，模型对品牌的描述准确率上升——这才是引用率变化的真实来源。这也解释了为什么"只看是否新增 JSON-LD"的研究会得到接近零的结论：在已被大量引用的成熟页面上，事实早就对齐了，补标记没有额外信息量。
实操含义：如果你只打算做一件事，先做事实对齐，再补标记。 顺序反过来，你会把不一致的信息用机器可读格式固化下来，等于放大错误。
在你自己站上复现：7 步实测协议
前六步不依赖任何付费工具即可跑通，第七步需要能持续记录 AI 答案的监测方案。
- 选页面分组。挑 20–40 个同类型页面（比如全部产品页），随机分成实验组与对照组，两组现有自然排名分布尽量接近。
- 锁定基线。改动前连续两周记录每组页面的引用率，同一组 prompt、固定平台、固定频次。基线不足两周的数据不要用。
- 只改一个变量。实验组只加目标 Schema 类型，正文一个字不动。这一步最难守住，也最决定结论是否可信。
- 验证机器可读。用 Schema.org Validator 与 Google 富结果测试确认语法，再用
curl取一次原始 HTML 确认 JSON-LD 在源码里。前端注入的 Schema 很可能被 AI 爬虫完全看不到，JS 注入 Schema 是否真的被抓取那篇有完整验证方法。 - 等重抓。至少留 4–6 周。中文 AI 平台重抓延迟差异很大，两周内出结果的结论基本是噪声。
- 分意图统计。结果按事实类、推荐类、对比类三种问题分开算。合并统计会把 Product 这类"只在特定意图生效"的信号抹平。
- 减去对照组漂移。最终数值必须是实验组变化减对照组变化，否则你测的是平台版本更新，不是你的改动。
等待期里模型侧本身也在变化——版本迭代、知识截止、检索策略调整都会独立影响引用率。这正是第七步对照组不能省的原因。
投入优先级：按站点类型排的执行顺序
结构化数据的总工时应该有上限。以下按"单位工时的引用率回报"排列，做完 P0 和 P1 后，剩余精力转向内容与站外证据。
| 站点类型 | P0（先做，1–2 天） | P1（次做，3–5 天） | 不建议做 |
|---|---|---|---|
| 本地服务 | LocalBusiness + Organization + NAP 一致性 | 分店页 @id 体系、Person |
FAQPage、HowTo |
| 消费品牌 / 电商 | Organization + sameAs + @id | Product（offers、规格属性） | HowTo、大批量 FAQPage |
| B2B / SaaS | Organization + sameAs | SoftwareApplication、Person、Article | FAQPage、BreadcrumbList 专项投入 |
| 内容站 / 媒体 | Organization + Article 基础字段 | Person 作者实体 + dateModified 流程 |
HowTo |
三个应该立刻停掉的做法：
- 在全站每个页面铺 FAQPage——零收益，且容易生成与正文重复的低质内容
- 标注页面上不可见的信息——违反结构化数据基本规则，且会让模型给出用户在页面上找不到的说法
- 改版时把 Schema 当收尾项——改版期是引用掉线最集中的窗口，改版前后的结构化数据与监测迁移清单值得在立项时就过一遍
放回更大的图里：结构化数据只是决定 AI 是否引用你的信号之一，权重低于内容质量、站外提及与自然排名。完整的证据网络怎么搭，GEO 优化 7 步搭建 AI 引用与品牌提及证据网络给了全景，这篇是其中结构化数据那一支的深挖。
常见问题
结构化数据加了之后多久能看到 AI引用变化？
按我们面板，中位数 4–6 周，长尾可到 10 周以上，平台间差异很大。任何"两周见效"的说法要谨慎——两周内的波动通常来自平台自身的检索策略调整，不是你的改动。
Ahrefs 说 Schema 没用，为什么你们测出实体层有增益？
三个原因。样本不同：Ahrefs 的页面每个都已有 100+ 次 AI Overviews 引用，属于事实早已对齐的成熟页面，我们的面板包含大量尚未进入引用候选集的中小站点。统计方式不同：Ahrefs 明确说明把所有 Schema 类型池化统计，未拆类型，实体层的正效应会被 FAQPage、BreadcrumbList 这类零效应稀释。平台不同：我们测的是中文 AI 平台。
只做 Organization 一类够不够？
对多数 B2B 和 SaaS 站点，Organization 加 sameAs 加 @id 已覆盖七成以上可得增益。电商与本地服务需额外做 Product 或 LocalBusiness。其余类型边际回报很低，不必追求 Schema 覆盖率这个数字本身。
已经铺满全站的 FAQPage 要删掉吗？
不必主动删除。未被使用的结构化数据不会带来负面影响，删除本身也要花工时。停止新增即可，把工时转到实体层和内容一致性上。但如果这些 FAQ 内容本身是为标记而凑的、答案空洞重复，那么该处理的是内容，不是标记。
怎么知道 AI 到底看没看到我的 JSON-LD？
用服务器日志核对 AI 爬虫的实际抓取记录（GPTBot、Bytespider、PerplexityBot 等 UA），再用 curl 取原始 HTML 确认 JSON-LD 不依赖 JavaScript 渲染。工具端的富结果测试只能证明语法正确，证明不了 AI 平台取到了它。
站内 Schema 和站外内容资产，先做哪个？
先做站内实体层——1–2 天能完成，是后续所有站外资产的锚点（sameAs 需要先有一份准确的站外阵地清单）。做完立刻转向站外，中文语境下站外权重更高，站外 AEO 资产该先建哪个平台按行业排过优先级。