结构化数据与 Schema.org：面向搜索中的 AI 概览

结构化数据是页面上的标记，用来向搜索引擎和 AI 系统说明：你是谁、产品是什么、价格如何、FAQ 怎么答、哪些内容可作为事实。Schema.org 词表与 JSON-LD 格式早已服务于经典 SEO；到 2026 年，它们也能提高进入 AI 概览（Google AI Overviews 及同类模块）并被助手正确引用的机会。下面说明哪些标记类型对业务真正有用、如何落地（不靠「魔法」），以及 Schema.org 与 llms.txt 的区别。

• Schema.org - 共享实体词表：Organization、Product、FAQPage、Article、HowTo 等
• JSON-LD - 推荐以 <script type="application/ld+json"> 交付标记
• 面向 AI 概览的目标 - 给模型可核验的事实：名称、价格、库存、步骤、答案
• 没有保证 - 标记买不到 AI Overview 席位；没有强内容与索引，效果很弱
• 协同 - Schema.org + 清晰文案 + GEO + 爬虫可访问
• 校验 - 发布前后用 Rich Results Test / Schema Markup Validator

用白话解释结构化数据

搜索与 AI 摘要会读 HTML，但 HTML 往往很嘈杂：菜单、脚本、广告、好看却没有明确事实的区块。结构化数据是单独一层语义：你明确标注「这是组织」「这是带价格的产品」「这是一问一答」。

这不是「又一个冲排名的 meta」。它是机器可读的页面护照 - 经典搜索与生成式搜索在决定能否安全采用你 URL 上的事实时，都会倚赖它。

为什么 Schema.org 对 AI 概览特别重要

搜索中的 AI 概览（AI Overview / AI Mode 等）会在结果之上生成短答：对比、定义、操作步骤、价格、联系方式。模型更偏好事实易抽取、可核验的来源。

标记在三个层面有帮助：

1. 抽取 - JSON-LD 比随意 DOM 更好解析。
2. 实体信任 - 一致的 Organization / Product / Brand，降低把你和同名竞品弄混的风险。
3. 答案形态 - FAQ、HowTo、Product 天然贴合展示给用户的「现成答案」。

对 GEO 策略而言，Schema.org 不是可选装饰，而是与 answer-first 内容、索引并列的技术层。关于 ChatGPT 与 Google AI 渠道，见 AI 可见性与 llms.txt 一文。

业务应优先落地的 Schema.org 类型

不必「全部都标」。从匹配客户问题与 AI 摘要格式的类型开始：

Organization（有线下点则加 LocalBusiness）

你是谁：正式名称、Logo、联系方式、URL、sameAs 中的资料页。没有它，品牌容易在镜像站与第三方目录间被稀释。

Product / Offer / AggregateRating

产品或服务：价格、货币、库存、SKU。评分仅在有真实评价且符合 Google 政策时使用（虚假星级有被人工处罚的风险）。

FAQPage

含真实客户问题的页面。每一对必须在 HTML 中可见，不能只在 JSON 里 - 否则是隐藏内容。

Article / BlogPosting

博客与指南：标题、日期、作者、图片。有助于摘要中的归属与新鲜度。

HowTo

分步说明 - AI Overview 常见形态（「如何配置」「如何申请」）。

SoftwareApplication / Service

面向 SaaS 与代理商：产品做什么、服务谁、支持哪些平台 - 须与页面正文一致。

JSON-LD：实战长什么样

Google 长期推荐 JSON-LD。FAQ 页的典型片段：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "实施费用是多少？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "试点通常需要 2-4 周。确切价格取决于集成范围。"
    }
  }]
}
</script>

组织的最小示例：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "示例公司",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://t.me/example"
  ]
}

没有这些规则，标记反而有害：

• JSON-LD 中的事实与页面可见文案一致；
• 不要伪造价格、评分或「凭空评论」；
• 每个实体一个规范 URL，避免镜像重复；
• 价格与 FAQ 变更时同步更新标记 - 否则 AI 会引用过期信息。

如何落地：一个 sprint 检查清单

1. 页面盘点。 首页、关于我们、价格/目录、3-5 个 FAQ/服务页、关键文章。
2. 选定类型。 按页面语义使用 Organization + FAQ/Product/Article - 不要「以防万一」混入无关类型。
3. 生成 JSON-LD。 在 CMS/SSG 模板或插件中实现（WordPress、Tilda 模块、自建生成器）。
4. 与 HTML 对齐。 答案与价格必须对人可读地出现在页面上。
5. 校验。 Google Rich Results Test、Schema Markup Validator；修复必填字段错误。
6. 索引。 在 robots.txt 中允许抓取，把 URL 放入 sitemap；无索引则标记几乎无用。
7. 监控。 Search Console（增强功能 / 富结果），每 2-4 周抽查品牌词与商业词上的 AI 摘要。

常见错误

• 页面没有真实评价却加 AggregateRating。
• FAQ 只在 JSON-LD 里，屏幕上没有问题。
• 每个页面的 Organization 用不同的 name 与电话。
• 把 Schema.org 与 llms.txt 搞混：前者是面向搜索/富结果的实体标记；后者是给 LLM 的策展地图。两层都需要 - 任务不同。
• 向客户承诺「加了 Schema 就会进 AI Overview」 - 那是卖预期，不是算法。
• 照抄他人带别的品牌与价格的 JSON。

与 SEO、GEO 的关系

结构化数据是放大器，不是替代品：

• 没有技术 SEO 与索引，没人读标记；
• 没有 answer-first 内容与 GEO，模型没有扎实材料填概览；
• 没有品牌与页面间的 事实核验，AI 会放大错误；
• llms.txt 有助于助手，但不能替代搜索中的 JSON-LD。

2026 务实顺序：索引 → 强答疑页 → Schema.org → llms.txt → 在搜索与对话中定期做 事实核验。

小结

Schema.org 与 JSON-LD 让公司、产品与 FAQ 事实可被机器读取 - 这对经典摘要与搜索中的 AI 概览都很重要。只标记匹配客户问题的内容；与 HTML 保持一致；校验并持续更新。这样能提高被正确引用的机会 - 而不承诺 AI Overview「保位」。

常见问题

进入 AI 概览必须要有 Schema.org 吗？

不是必须，但很有用。AI 概览依赖索引、相关性与来源质量。Schema.org 加快事实抽取、减少歧义 - 尤其对 Product、FAQ、Organization。没有标记，若内容强且已收录，仍可能出现。

JSON-LD、Microdata、RDFa 哪个更好？

多数站点选 JSON-LD：模板与 CMS 更好维护，且 Google 推荐。Microdata 与 RDFa 可用，但改版时更容易坏。正确性、与可见内容一致，比「奇特语法」更重要。

每个页面都要标记吗？

不必。 标记有稳定实体与商业意义的页面：首页/组织、产品与服务、FAQ、文章、操作指南。没有事实的工具型落地页与目录筛选重复页，通常不必塞空 JSON-LD。

Schema.org 能提升经典 Google 排名吗？

没有「加了 Schema 就涨位」的直接因子。标记可开启富结果（FAQ、产品、评分等），并改善实体理解 - 间接影响点击与感知。排名仍主要看内容、外链与技术；Schema 是澄清层，不是一键冲量。

WordPress / Tilda / 自建栈从哪开始？

WordPress：成熟 SEO 插件的 Schema，再人工核对关键模板。Tilda：自带或第三方 JSON-LD 区块，或在设置里插入 head。自建栈：用与页面模板相同的数据生成 JSON-LD（价格、FAQ、名称），避免不同步。发布后跑 Rich Results Test，并确认重要 URL 对索引开放。