作者為官網加入 3 套 JSON-LD，兩周後 AI 搜尋回答出現變化

2026-10-27 8

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文实证验证：AI搜索高度依赖结构化数据（Schema.org+JSON-LD）来理解网页实体与关系。作者为官网补充Organization、Service+AggregateOffer、FAQPage三类标记，两周后AI回答准确性显著提升——业务描述更准、价格分档可见、问答直引率提高。结论：结构化数据已成AI搜索时代的“入场券”，非万能，但对长期稳定内容至关重要。（239字）

前阵子给一个官网陆续补了三套结构化数据，想验证一件事：AI 搜索到底认不认机器可读的标记。先说结论——认，而且认得很具体。

结构化数据，就是用 schema.org 这套词汇表、配 JSON-LD 的格式，把你网页里的内容"翻译"成机器能直接读懂的实体和关系。AI 搜索在决定采不采信你之前，第一步是看它读不读得懂你，这一步就卡在结构化数据上。

为什么 AI 搜索比传统搜索更吃这一套

传统搜索是关键词匹配：输入"数字人口播怎么做"，引擎去倒排索引里找含这些词的页面。AI 搜索不一样，它不把页面原样吐给你，而是读完一批页面后自己组织一段答案。这个过程里它最缺的不是文字，而是"这段文字在说谁、这个东西属于哪类"——也就是实体和关系。

Google 官方 Search Central 对结构化数据的定位说得挺清楚：它不算直接的排名因子，但它是搜索引擎"理解你页面内容"的一种明确信号。到 AI 搜索这一代，"理解"的权重更高了，因为答案生成靠的是对内容的语义读懂，而不是命中关键词。

有一篇论文印证得比较实：Aggarwal 等人在 KDD 2024 发的 GEO 论文（arXiv:2311.09735），做的就是"生成式引擎里内容怎么被看见"的实验。结论里有一条值得记住——在生成式引擎里，内容的可见性不只是排序问题，还跟内容怎么被结构化、怎么被摘取有关。换句话说，AI 搜索时代，"让机器读懂"从加分项变成了入场券。

我加的是哪三套，代码大概这样

不是拍脑袋想的，是对着官网已有的内容，把三类信息补成机器可读版本。原则只有一条：机器声明的东西，正文里必须真实存在，不能图文两张皮。

第一套是 Organization，告诉引擎这个网页背后的主体是什么、主要做什么。核心是 name、url、description 三件套：

【代码片段一：Organization 主体标记】

{
"@context": "https://schema.org",
"@type": "Organization",
"name": "示例科技",
"url": "https://example.com",
"description": "为中小团队提供 AI 视频内容生产与多平台分发工具的公司"
}

为什么这么写：AI 回答"某某是做什么的"这类问题时，最容易引用的就是这种"主体 + 一句话业务描述"。你写不清楚，AI 要么答错，要么直接跳过。

第二套是 Service 配 AggregateOffer，把"提供什么服务、收费大概什么样"说清。服务费这块很多人只写一个"价格咨询客服"，机器读不到，AI 也就不会在回答里带出来：

【代码片段二：Service + AggregateOffer 服务与报价】

{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "AI 视频内容生产",
"provider": {
"@type": "Organization",
"name": "示例科技"
},
"offers": {
"@type": "AggregateOffer",
"priceCurrency": "CNY",
"lowPrice": "0",
"highPrice": "999",
"offerCount": "3"
}
}

为什么用 AggregateOffer 而不是 Offer：如果你的定价是分档的（免费起步、按量、分级这种），AggregateOffer 能一次说清"存在多个价格档"，AI 引用的口径就不容易漂。

第三套是 FAQPage，把用户最常问的问题提出来，一问一答结构化。我补了 8 个，覆盖"做什么、怎么收费、怎么上手、靠不靠谱"这类高频信任问：

【代码片段三：FAQPage 问答标记】

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "这家公司主要做什么？",
"acceptedAnswer": {
"@type": "Answer",
"text": "AI 内容生产、多平台分发、GEO 全网可见、AI 转化承接。"
}
}
]
}

FAQ 是最容易被 AI 搜索直接"摘句子"的一类：你问 A、它答 B，这种现成的问答对几乎不用改写就能进答案。前提还是那句——这些问答在正文里得真实存在，不能只在 JSON-LD 里声明。

两周后的变化，得拿数据说话

我没靠"感觉变了"下结论，用了笨办法：固定一批问题（围绕"是干什么的、怎么收费、靠不靠谱"），在 5 个 AI 平台各问 3 遍，记改动前后的差异。

结果是方向性的，不是玄学。改动前问"这家是做什么的"，AI 要么答不出，要么把两家业务混成一家；改动后，同一批问题里业务分类开始出现，"怎么收费"这种原本答不上的也开始能给出分档大意。一个更硬的信号是：回答里出现了近似那条 description 原文的改写——这基本坐实了 AI 引用了这份数据。

什么场景我劝你别折腾

结构化数据不是万能药。纯单页落地页，就一个表单一个按钮，没实体、没问答、没价格档，给它套 JSON-LD 基本是自嗨。还有一种是一个月一换的活动站，内容生命周期太短，引擎还没抓完就换了，投入产出算不过来。结构化数据真正的价值，是给长期、稳定、有实体属性的内容——官网、产品页、FAQ、作者主页这一类。

我的判断就一句：AI 搜索给结构化数据重新抬了身价，因为它只能靠能读懂的内容来生成答案。留个问题给你们——如果你的官网到现在还没有任何 JSON-LD，你会先补哪一套：主体、价格，还是 FAQ？