用 JSON-LD 告诉大模型你是谁：结构化数据配置实战

AI 爬虫在解析一个普通 HTML 页面时需要做大量的"猜测"工作：哪段文字是导航栏，哪段是广告，哪段才是实际内容？这个清洗过程会引入噪音和误差。JSON-LD 则不同——它是一段藏在 <head> 里的机器可读代码，直接按照 Schema.org 国际语义标准描述"这个页面说的是什么"，大模型爬虫可以跳过清洗，直接读取。

article.media/1761b019-31fa-4b7a-9c3c-5193ef11f05a.png

这篇文章聚焦 GEO 场景下最常用的三种 Schema 类型，附完整可用的代码模板。

为什么 JSON-LD 对 AI 收录特别有效

结构化数据之所以对 AI 收录特别有效，逻辑很直接：当模型需要判断"这个页面的产品名是什么"、"价格是多少"时，从非结构化的正文段落里提取要靠语义推断，存在歧义与漏检，而从 JSON-LD 里可以直接读取、几乎不会出错。信源置信度越高，大模型越倾向于采信它。

Schema 类型一：Organization（品牌/组织）

这是企业官网的基础配置，用于向大模型声明：我是谁，我的官网在哪里，我关联哪些社交平台。缺少这个 Schema，大模型在处理"介绍一下 XX 公司"类问题时，只能依赖正文猜测，容易出现幻觉（如把另一家同名公司的信息张冠李戴）。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "工蜂云",
  "url": "https://geo.gongfengyun.com",
  "logo": "https://geo.gongfengyun.com/logo.png",
  "description": "工蜂云旗下 AI 品牌可见度监测与生成式引擎优化（GEO）评估平台",
  "foundingDate": "2025",
  "sameAs": [
    "https://www.gongfengyun.com"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "admin@zhileme.com"
  }
}
</script>

Schema 类型二：Product + Offer（产品与定价）

当用户通过 AI 问"有哪些 GEO 监测工具，大概多少钱"，大模型会扫描带有 Product Schema 的页面，直接提取定价数据进行对比。如果你的定价页面没有 Schema，大模型只能从段落正文里提取，漏检率很高。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "工蜂云 品牌可见度监测方案",
  "description": "实时监控豆包、DeepSeek、通义千问、腾讯元宝等主流大模型中品牌提及率的专业系统，支持情感分析与竞品对比",
  "brand": {
    "@type": "Brand",
    "name": "工蜂云"
  },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "CNY",
    "availability": "https://schema.org/InStock",
    "url": "https://geo.gongfengyun.com/pricing"
  }
}
</script>

注意 priceCurrency 务必填写正确的货币代码（人民币为 CNY，美元为 USD）。货币代码错误会导致大模型在引用价格时产生误导。

Schema 类型三：FAQPage（常见问题页）

FAQ 页面是 GEO 优化性价比最高的内容格式。大模型在 RAG 检索时偏好问答结构，因为这种格式与用户 Prompt 的"问题—答案"模式天然对齐，切片后每个 Q&A 对都可以作为一个独立语义单元被召回。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "GEO 和 SEO 有什么区别？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO 优化的目标是在传统搜索引擎的链接列表（如 Google 蓝色链接）中获得高排名；GEO 优化的目标是让品牌内容被大语言模型纳入生成答案的原始素材，从而出现在 ChatGPT、Perplexity 等 AI 的直接回答中。"
      }
    },
    {
      "@type": "Question",
      "name": "为什么我更新了官网，但 ChatGPT 的回答还是旧的？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "大模型的联网功能依赖底层搜索引擎（如 Bing）的缓存。如果搜索引擎尚未重新爬取你的页面，大模型拿到的仍然是旧版本。可以通过 Bing Webmaster Tools 主动提交 URL 加速索引更新。"
      }
    }
  ]
}
</script>

sameAs：让大模型确认「你就是你」

Organization Schema 里的 sameAs 字段常被忽略，但它对 AI 实体消歧至关重要。当大模型遇到「工蜂云」这个名字时，它需要确认这指的是哪一个实体——同名公司、同名产品并不少见。sameAs 的作用就是把你的官网，与维基数据、企查查、官方社交账号等权威实体库的页面显式关联起来，相当于给大模型一组交叉验证的身份证明。关联得越完整，大模型把不同来源的信息正确归并到同一个实体上的概率就越高，「张冠李戴」式的幻觉随之下降。

为什么是 JSON-LD，而不是 Microdata 或 RDFa

结构化数据有三种主流写法：Microdata、RDFa 和 JSON-LD。前两者把语义标签直接嵌进网页元素的属性里，和页面结构耦合，维护起来牵一发动全身，改个版式就可能破坏标注。JSON-LD 则是一整段独立的脚本，和页面渲染完全解耦——内容团队改正文、前端改样式，都不会动到它；要更新结构化数据，也只改这一段。Google 早已明确推荐 JSON-LD，主流大模型爬虫对它的解析支持也最成熟。新项目没有理由再用前两种。

结构化数据与 llms.txt 的分工

JSON-LD 和 llms.txt 经常被一起提到，但它们解决的是不同层次的问题。JSON-LD 是页面级的「字段精确声明」——告诉大模型这一页的产品名、价格、FAQ 各是什么；llms.txt 是站点级的「阅读优先级导航」——告诉大模型整站里最该读哪几页。两者叠加，才能既让爬虫找对页面、又让它在页面里读对字段。只做其一都是半成品。

三条不能违反的铁律

数据一致性：JSON-LD 中的价格、产品名、联系邮箱等必须与页面正文完全一致。不一致会被搜索引擎和大模型视为欺骗行为，可能降低整体信任度。
上线前校验语法：哪怕一个多余的逗号也会导致整个 JSON-LD 解析失败，等于什么都没配。上线前用 Google 的结构化数据测试工具（search.google.com/test/rich-results）验证一遍。
按页面类型配置：不要在所有页面放同一份 Schema。文章页配 Article，产品页配 Product，帮助中心配 FAQPage。千篇一律的全局 Schema 对 AI 爬虫没有额外帮助。