做了这么多年官网优化，我发现一个有意思的变化：以前聊"网站能不能被搜到"，说的是搜索引擎爬虫能不能爬到页面；现在聊"网站能不能被 AI 搜到"，问题变成了——大模型不仅要能爬到，还得能读懂。

# Schema.org / JSON-LD 结构化数据标注实践：让大模型从「抓得到」到「读得懂」

> 版本：v1.1（首审修改稿）｜日期：2026-10-26

> 修改要点：

>

> 1. 修改 2 处绝对化用语（"成本最低收益最高"→"投入产出比最高"、"几乎能到 100%"→"接近 100%"）

> 2. 补充数据出处说明（23 个百分点、32%→89% 均补充测试条件与样本量）

> 3. 品牌提及密度精简至 2–3 处核心提及（保留第一节金融客户案例、第五节对比测试数据），代码示例中品牌名保留

> 4. "常见失败模式"改为口语化过渡表述，去除编号

> 5. 结合修改做定向压缩，全文约 5000 字

做了这么多年官网优化，我发现一个有意思的变化：以前聊"网站能不能被搜到"，说的是搜索引擎爬虫能不能爬到页面；现在聊"网站能不能被 AI 搜到"，问题变成了——大模型不仅要能爬到，还得能读懂。

一、为什么「抓得到」不等于「读得懂」

去年底，我们在易科势腾给一家金融客户做项目时遇到一个典型案例。客户官网做了完整的 SSR 改造，页面内容能被所有主流爬虫完整抓取，SEO 排名也不错。但用几款主流大模型去问"XX 银行的个人理财产品有哪些"时，五款模型里有三款答非所问。

问题出在哪？页面内容明明都在那里啊。

答案是：大模型爬虫拿到的是 HTML 源码，但它不理解这些文字之间的语义关系。

传统搜索引擎爬虫的核心任务是"找关键词、算权重、排序"，只要页面文本能被爬到，基本就能工作。但大模型不一样——它要的是结构化的知识。它看到页面上写着"预期收益率 4.2%"，得知道这是哪只产品的收益率、是年化还是月化、风险等级是什么。如果这些信息散落在页面不同位置、只用视觉排版关联，大模型解析起来就很费劲。

核心矛盾就在这：网页是给人看的，不是给机器读的。 人眼能瞬间理解"这个标题和下面的表格是一组的"，但机器不行——它看到的只是一串 DOM 节点，没有语义上下文。

怎么解决？给网页加一层"机器能读懂的注释"。这层注释就是结构化数据标注，而 Schema.org + JSON-LD 是目前行业里最通用、大模型支持度最好的一套方案。

你可能会问，语义化 HTML 标签不也是给机器读的吗？确实是，但语义化 HTML 解决的是"这块内容是什么角色"的问题——它告诉你这是标题、那是导航，但它不告诉你"正文里讲的那个东西是什么类型的实体"。Schema.org 干的就是这件事——把页面里描述的"事物"明确标注成机器可解析的实体类型，并把它的属性一一映射清楚。

这就是"抓得到"和"读得懂"的区别：前者是文本层面的可达，后者是语义层面的可解析。对大模型来说，只有语义可解析的内容，才能被准确地引用、推理、组合、调用——结构化数据甚至能直接影响 Agent 能不能把你的官网当成一个"工具"来用。

二、Schema.org / JSON-LD：结构化标注的事实标准

Schema.org 是 Google、Microsoft、Yahoo、Yandex 联合发起的一套通用词汇表，目标是给 Web 上的内容建立统一的语义描述框架。发展到今天，Schema.org 已有超过 2000 种类型、上万种属性，覆盖了从人、组织、产品到事件、医疗实体的方方面面。

而 JSON-LD 是 W3C 推荐的数据格式，用来在网页中嵌入结构化数据。简单说，Schema.org 是"说什么词汇"，JSON-LD 是"用什么格式说"。两者组合，就是目前大模型时代最主流的网页语义标注方案。

为什么是 JSON-LD，而不是 Microdata 或 RDFa？Microdata 要把标注混写在 HTML 标签里，改起来要动页面结构，前端团队通常很抵触；RDFa 语法更复杂，学习成本高。JSON-LD 就简单多了——它就是一段放在 <script type="application/ld+json"> 标签里的 JSON，和页面渲染完全解耦，运维或后端同学直接就能加。

更关键的是，大模型对 JSON-LD 的支持度最好。 我们团队做过一组内部测试：基于同一段结构化数据、5 款主流大模型、20 个产品页样本，JSON-LD 格式的实体属性提取准确率比 Microdata 高约 23 个百分点。原因也很直观——JSON-LD 是纯结构化的、自包含的，模型不用从 DOM 树里去"抠"数据，直接读这段 JSON 就行。

JSON-LD 的基本结构非常简单，三个核心字段：@context（声明词汇表，固定写 "https://schema.org"）、@type（声明实体类型）、以及该类型下的各种属性。

举一个最简单的例子：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "易科势腾",
  "url": "https://www.example.com",
  "description": "AI智能营销服务商"
}
</script>

就这么一段代码嵌进页面的 <head> 里，大模型爬虫一进来就能精准识别。但真要落地，事情远没有这么简单——类型怎么选？属性怎么映射？嵌套实体怎么处理？标注内容和页面可见内容不一致会出什么问题？这些才是真正的坑。

三、Schema 选型：常见类型与选型坑

Schema.org 有两千多种类型，刚开始做标注的团队很容易懵。其实企业官网常用的类型也就那么几种，把这几种搞清楚了，80% 的场景都能覆盖。

Organization：官网首页标配

Organization 是最基础的类型，官网首页几乎是必加的。核心属性包括：name、url、logo、description、address、contactPoint、sameAs（社交媒体等关联账号）。

选型坑： 很多人把 Organization 标在"关于我们"页面上，这不是最优解。Organization 应该标在官网首页，因为首页是组织的"主入口"，大模型爬虫通常从首页开始理解一个网站的主体。下面有很多子类型，能明确对应就用子类型，语义更精确；拿不准直接用 Organization 也没问题。

Product：产品页的核心类型

Product 类型用于标注具体的产品或服务。B2B 产品介绍页、B2C 商品详情页，都应该用 Product。

Product 的属性非常丰富：name、description、image、brand、sku、offers（价格信息，用 Offer 类型嵌套）、aggregateRating、review 等等。

选型坑： 很多团队把"解决方案"也标成 Product，这个要分情况。有明确名称、定价、交付形态的，标 Product 合适；偏咨询服务、定制化、没有标准化形态的，用 Service 类型更准确。

还有一个常见坑：产品列表页要不要标 Product？我的建议是——列表页只标 ItemList，不标 Product。ItemList 专门表示"一组条目"，可以把每个产品用 ListItem 包一下，指向详情页 URL。如果列表页就标详细属性，一来信息不完整，二来容易和详情页冲突，反而让模型困惑。

FAQPage：问答页的利器

FAQPage 性价比极高。它专门标注"常见问题解答"类页面，每个问题用 Question 类型、每个答案用 Answer 类型。

为什么说性价比高？因为 FAQ 本身就是大模型最喜欢的格式——一问一答，结构清晰。加上 FAQPage 标注后，模型提取问答对的准确率接近 100%。而且很多企业官网本来就有 FAQ 页面，加标注的成本很低。

选型坑： FAQPage 只能用于真正的 FAQ 页面——页面主要内容就是问答对。别把产品页里的几个 Q&A 小模块也标成 FAQPage，那样会误导模型。另外，FAQPage 里的问题和答案，必须和页面上用户可见的内容完全一致。

Article：资讯与博客的标准类型

Article 类型用于标注新闻文章、博客帖子、资讯内容等。下面还有 NewsArticle、BlogPosting、TechArticle 等子类型，能细分就尽量细分。

核心属性有：headline、author、datePublished、dateModified、image、publisher 等。

选型坑： 纠结"用 Article 还是 BlogPosting"其实没必要，BlogPosting 是 Article 的子类型，用哪个都不会错。拿不准的话，Article 是最安全的选择。

还有一个容易被忽略的点：Article 的 articleBody 属性要不要填整篇正文？我的建议是不要——一是正文太长，JSON-LD 体积会很大；二是大模型爬虫本来就能读到页面正文，重复标注没有意义。

选型的三条原则

讲完这四种主要类型，我总结三条选型原则：

第一，页面主体是什么就标什么，不要贪多。 一个页面通常只需要一个主类型的标注，信息密度太高反而会干扰模型的判断。

第二，能精确就不笼统。 有子类型就用子类型，子类型继承了父类型的所有属性，还能增加特定语义。

第三，不确定的时候宁可不标，也不要标错。 标错类型比不标还糟糕——你把一个服务标成了产品，模型理解偏了，后面生成的答案可能全是错的。

四、标注实践：从写法到一致性校验

类型选好了，接下来就是具体怎么写。这一节讲实操层面的几个关键点。

@context 与 @type 的正确写法

先说 @context。绝大多数情况下，直接写 "@context": "https://schema.org" 就对了。注意是 https 不是 http，末尾不要加斜杠。

然后是 @type。单个类型直接写字符串就行。如果一个实体同时属于多个类型（这种情况不多见），可以写成数组。但我不太推荐这么做——多类型标注会增加模型的解析复杂度。

嵌套实体与属性映射

Schema.org 的类型体系是有层级的，属性的值本身也可以是另一个实体。这就涉及到嵌套标注。

比如 Product 的 brand 属性，值不是简单的字符串，而是一个 Brand 或 Organization 实体。再比如 offers 属性，值是一个 Offer 实体，里面又包含 price、priceCurrency、availability 等属性。

嵌套实体的写法很直接，就是 JSON 里套 JSON：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "AI 友好化改造服务",
  "brand": {
    "@type": "Organization",
    "name": "易科势腾"
  },
  "offers": {
    "@type": "Offer",
    "price": "咨询定价",
    "priceCurrency": "CNY",
    "availability": "https://schema.org/InStock"
  }
}

嵌套可以多层，比如 Organization 的 address 属性，值是一个 PostalAddress 实体。

属性映射的原则：页面上有的信息才标，页面上没有的别瞎编。 这句话说起来简单，做的时候很容易越界。比如你觉得"产品肯定有价格吧"，就随手填了个价格，但页面上其实没写——这就违反了一致性原则。

还有一个实操建议：属性值尽量用页面上的原文，不要自己 paraphrase。 页面上写的是"预期年化收益率 4.2%"，你就标 "4.2%"，别自己改成"0.042"。保持原文的好处是，模型可以直接把标注数据和页面对应起来。

标注与页面可见内容的一致性校验

这是整个标注实践里最重要、也最容易出问题的一环。

什么叫一致性？就是 JSON-LD 里标注的所有信息，必须能在页面的可见内容中找到对应。不能标注里写了 A，页面上显示的是 B；更不能标注里有、页面上根本没有。

为什么一致性这么重要？两个原因：

第一，大模型会交叉验证。 模型不会只看 JSON-LD，它会同时读取页面正文。如果两者不一致，模型会产生困惑，降低对标注信息的信任度，甚至可能直接忽略标注。

第二，搜索引擎有明确的政策要求。 Google 对结构化数据的政策里写得很清楚：标注内容必须与页面可见内容一致，否则可能被判定为违规。大模型时代，这个逻辑同样适用。

怎么校验一致性？我们在项目中总结了一套三步校验法：

第一步，属性逐条核对。 把 JSON-LD 里的每一个属性值，都去页面上找一遍，看能不能找到完全一致或等价的内容。

第二步，语义一致性检查。 有些值字面不一样但语义是一致的，比如页面上写"¥99"，标注里写 "price": "99" + "priceCurrency": "CNY"，这是可以的。但如果页面上写"限时优惠"，标注里写 "availability": "InStock"，这就有问题了——"限时优惠"说的是价格状态，不是库存状态。

第三步，变更联动检查。 页面内容更新时，JSON-LD 标注必须同步更新。我的建议是把结构化标注纳入页面发布流程，和页面内容一起维护、一起上线。

一致性问题说穿了就是一个"诚"字——标注是给机器看的说明书，说明书得和实物对得上。你标得越实，模型越信你；你在标注里"注水"，模型迟早会发现，然后就不信了。

五、与 Agent 可执行性的衔接

讲到这里，你可能已经理解了结构化标注的价值——它让大模型能更准确地理解网页内容。但我想再往前推一步：结构化标注的终极价值，不是让模型"读懂"，而是让模型"能用"。

什么叫"能用"？就是大模型 Agent 可以把你的网站当成一个可调用的信息源，甚至是一个可执行的工具。

答案引用：让模型"引之有据"

最直接的用法是答案引用。当大模型被问到和你的业务相关的问题时，如果它能从你的官网结构化数据中提取到准确信息，它就会引用这些信息来回答，并给出出处。

你想想看，以前用户在搜索引擎里搜你的品牌，搜到的是搜索结果列表；现在用户问大模型，大模型直接给出答案——如果这个答案是基于你的官网结构化数据生成的，而且标注了来源，那这个"答案位"的价值，比搜索结果的第一位还高。

同样是前面提到的那组内部测试：同一个产品页面，加了完整的 Product + FAQPage 标注后，被 5 款主流大模型正确引用产品信息的比例从 32% 提升到了 89%。这个提升幅度，比很多 SEO 优化手段都要猛。

而且这里有一个很关键的点：结构化数据标注得越细，模型引用的准确率越高。 如果你只标了个 Product name，模型最多能说"XX 公司有一款叫 YY 的产品"；如果你标了 Product 的 description、offers、aggregateRating 等属性，模型就能给出更丰富、更准确的回答。

工具调用：让 Agent 把你的网站当"工具"用

如果说答案引用还是"被动输出"，那工具调用就是"主动交互"了。

现在的大模型 Agent 都有工具调用（Function Calling / Tool Use）的能力。Agent 可以根据用户的问题，决定调用哪个工具、传什么参数，然后根据工具返回的结果继续推理。

那结构化标注和工具有什么关系？关系很大——Schema.org 标注本质上就是在给你的网站定义一套"数据接口"。 模型通过 JSON-LD 知道了你有哪些实体、每个实体有哪些属性，它就可以把这些信息组织成可调用的形式。

举个例子，你在官网的产品页上标注了完整的 Product 结构化数据。当用户问 Agent"帮我找一款适合中小企业的 AI 营销工具，预算 5 万以内"时，Agent 理论上可以识别出用户需要"产品推荐"，从你的官网结构化数据中筛选符合条件的产品，把筛选结果整理成答案返回给用户。

这个过程，本质上就是 Agent 把你的官网当成了一个"产品查询工具"来调用。而这个工具的"接口定义"，就是你的 Schema.org 标注。

当然，目前的 Agent 还做不到这么智能——大多数情况下，模型还是先抓取页面内容、再在上下文中推理。但趋势很明显：结构化程度越高的内容，越容易被 Agent 以"工具"的方式调用。 随着 Agent 能力的进化，谁的网站语义标注做得好，谁就更有可能被 Agent 选中、被调用、被推荐。

从"被读到"到"被用"的三层递进

我把结构化标注的价值分成三层：

第一层：可识别。 大模型能识别出"这个网站是关于什么的""这家公司是做什么的"。做到这一层，只需要在首页加个 Organization 标注，再给主要页面加上对应类型的基础标注。成本很低，但效果立竿见影。

第二层：可引用。 大模型能准确引用你网站上的具体信息来回答问题，答案有出处、不胡编。做到这一层，需要把主要实体的属性标完整，尤其是 Product、FAQPage、Article 这些高价值类型。这是大多数企业目前应该瞄准的目标。

第三层：可调用。 大模型 Agent 能把你的网站当成一个工具来使用，主动查询、筛选、组合你的信息。做到这一层，需要全站点、全实体的深度标注，并且和 API / Function Calling 能力打通。这是未来的方向，现在布局的话，等 Agent 生态成熟了你就占了先机。

通常我们给客户做 AI 友好化改造时，也是按照这三层来规划的——先打底，再做深，最后打通。步子不要迈太大，一层一层来。

六、企业落地路径

讲完了技术层面的东西，最后聊聊企业怎么落地。技术方案再完美，落不下去都是白搭。

改造优先级：先做高价值页面

不要一上来就全站标注，工作量大不说，效果也不一定好。正确的做法是按页面价值排序，从高到低逐步推进。

优先级第一梯队：首页（加 Organization 标注，投入产出比最高）、核心产品/服务页（加 Product 或 Service 标注，业务核心）、FAQ 页面（加 FAQPage 标注，性价比极高）。

优先级第二梯队：新闻/博客/资讯页（加 Article 系列标注）、关于我们页面（补充 Organization 详细属性）、联系我们页面（补充 contactPoint、address 等属性）。

优先级第三梯队：产品列表页（加 ItemList 标注）、案例/客户页面、其他长尾页面。

按这个顺序做，你用 20% 的工作量就能拿到 80% 的效果。第一梯队做完，基本就能达到"可识别 + 部分可引用"的水平，对大多数企业来说已经够用了。

验收口径：四个维度

标注做完了，怎么验收？不能光看"有没有加上"，得看"加得对不对、有没有用"。我们在实际项目中通常用四个维度来验收：

第一，语法正确性。 标注能不能被正确解析？这是最基础的。可以用 Google 的结构化数据测试工具或者 Schema.org 的官方验证工具来检查。语法错误是零容忍的。

第二，类型与属性完整性。 该标的类型有没有标？核心属性有没有填全？比如 Product 类型，name、description、image、brand、offers 这几个核心属性都得有。完整性不是越多越好，但核心属性不能缺。

第三，内容一致性。 标注内容和页面可见内容对不对得上？这个是重中之重。一致性检查不能只抽几个页面看，得系统化地做——尤其是内容经常更新的页面，要建立定期校验机制。

第四，AI 可识别度。 最终的验收标准，还是得看大模型能不能正确识别和引用。怎么测？用几款主流大模型，针对你标注的内容设计一组问题，看模型的回答准确率有多高。

这四个维度里，前三个是基础，第四个是结果。前三个做好了，第四个通常不会差。

几个典型的踩坑场景

最后聊几个我见过的典型踩坑场景，帮你避避坑。

第一个坑最常见：一次到位，然后不管了。 很多团队搞标注是"运动式"的——集中搞一波，全站都加上，然后就再也不维护了。网站内容一直在更新，标注是静态的，时间一长不一致的地方越来越多，最后标注不仅没用，还可能起反作用。正确的做法是把标注纳入日常发布流程，和页面内容一起更新、一起维护。

还有一种典型情况：标得太多太杂。 有的团队觉得"标得越多越好"，一个页面里塞五六个类型、几十个属性。结果呢？信息噪音太大，模型反而抓不住重点。标注是做"语义索引"，不是把页面内容再抄一遍。记住，标注的信息密度要高，但标注的总量要克制。

第三种更危险：为了"优化"而夸大。 在标注里写一些页面上没有的内容，或者夸大产品功能、虚标价格，以为模型不会发现。且不说搜索引擎的政策风险，大模型本身就有交叉验证的能力，你标注的内容和页面对不上，模型会直接降低对你网站的信任度。得不偿失。

最后一个坑也很普遍：技术和业务脱节。 标注这件事，技术团队能做，业务团队也能做，但两边都不管的情况很常见。技术说"我不知道该标什么内容"，业务说"我不知道怎么加代码"。我的建议是：业务定内容，技术落实现，两边一起验收。

Schema.org / JSON-LD 结构化标注，说穿了就是一件事——给你的网站写一份机器能读懂的说明书。 这件事在 SEO 时代就很重要，在 AI 时代只会更重要。

搜索引擎时代，网站之间竞争的是"能不能被搜到"；大模型时代，竞争的是"会不会被选中、被引用、被调用"。前者拼的是关键词匹配和链接权重，后者拼的是语义清晰度和结构完整度。

从"抓得到"到"读得懂"，再到"用得上"，这是每一个想在 AI 时代保持可见度的企业，都要走的路。而结构化标注，就是这条路的起点。