结构化数据怎么做才对 GEO 有用？四种最值得加的 JSON-LD

直接回答：对 GEO 来说，结构化数据的价值不在"加得越多越好"，而在让机器低成本地确认"这是什么内容、谁写的、什么时候更新的、回答了什么具体问题"。按投入产出比排序，最值得加的四种是 BlogPosting、BreadcrumbList、FAQPage 和 Person。

为什么结构化数据对 GEO 特别重要

回到检索链路：模型会把页面切成片段再做相似度匹配。片段一旦脱离上下文，"这段文字在讲什么"就变得模糊。

结构化数据在这里提供的是页面级的确定性：

• 这篇内容是什么类型（文章？问答？产品页？）
• 标题、摘要、发布时间、更新时间分别是多少
• 作者是谁，有什么身份背景
• 文中的问答对可以被拆成独立的问题与答案

对模型来说，这些字段是已经解析好的结构化输入，不需要从 HTML 里猜。同等内容质量下，解析成本更低的一方通常更容易被选中。

优先级排序

一、BlogPosting：最基础也最容易被做错

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "结构化数据怎么做才对 GEO 有用",
  "description": "按投入产出比排出四种最值得加的结构化数据。",
  "datePublished": "2026-08-11",
  "dateModified": "2026-08-11",
  "author": {
    "@type": "Person",
    "name": "张三",
    "url": "https://example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "示例站点"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/posts/structured-data-for-geo/"
  },
  "keywords": "结构化数据, JSON-LD, Schema.org",
  "inLanguage": "zh-CN"
}

最常见的三个错误：

1. dateModified 和 datePublished 永远相同。 文章更新过就应该改 dateModified，它是最直接的新鲜度信号。
2. author 只写一个字符串。 "author": "张三" 是合法但信息量极低的写法，用对象并带上 url 和 sameAs 才能建立实体。
3. mainEntityOfPage 与 canonical 不一致。 两个地址指向同一内容时，模型无法确定哪个才是原文。

二、BreadcrumbList：让模型知道你的内容归属

1
2
3
4
5
6
7
8
9

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "GEO 工具箱", "item": "https://example.com/categories/geo-tools/" },
    { "@type": "ListItem", "position": 3, "name": "结构化数据怎么做才对 GEO 有用", "item": "https://example.com/posts/structured-data-for-geo/" }
  ]
}

它的隐性价值是主题聚类。当模型看到十几篇文章都挂在同一个分类下，会更容易把它们识别成一个完整主题体系，这对建立领域权威很有帮助——而领域权威正是被优先引用的重要条件。

三、FAQPage：把问答对直接喂给模型

这是对 GEO 最"对症"的一种类型，因为 AI 搜索要回答的正是问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据会直接提升 AI 引用率吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不会立竿见影。它解决的是机器能不能准确理解这段内容是什么。"
      }
    }
  ]
}

两个实践建议：

• 问答必须真的出现在正文里。 只在 JSON-LD 里写、页面上看不到，属于垃圾标记，有被判定作弊的风险。
• 答案控制在 40 到 120 字。 太短没有信息量，太长会被截断，反而失去作为独立答案的价值。

四、Person：让"你是谁"变成可检索的实体

1
2
3
4
5
6
7
8
9
10
11
12

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "张三",
  "url": "https://example.com/about/",
  "jobTitle": "技术博主",
  "knowsAbout": ["生成式引擎优化", "AI 搜索", "结构化数据"],
  "sameAs": [
    "https://github.com/your-account",
    "https://x.com/your-account"
  ]
}

sameAs 的作用是跨平台身份对齐。当模型发现同一个名字在多个可信平台上指向同一个人，作者的可信度会显著上升。这直接服务于 GEO 的第三层——可信任。

怎么落地到静态博客

本站用 Hexo + Stellar，落地方式分两部分：

1. 文章级数据由主题生成：BlogPosting 由主题自动输出，包含标题、描述、时间、作者、标签。
2. 额外数据由构建脚本注入：scripts/geo.js 在页面渲染完成后，把 BreadcrumbList 和 FAQPage 插入 </head> 之前。FAQ 数据直接写在文章的 front matter 里：

1
2
3

faq:
  - q: 结构化数据会直接提升 AI 引用率吗？
    a: 不会立竿见影。它解决的是机器能不能准确理解这段内容是什么。

这样写作者只需要在文章的 front matter 里维护问答，JSON-LD 会自动生成，不会出现"页面改了但结构化数据忘了改"的情况。

自检清单

• 每篇文章都有 BlogPosting，且 dateModified 是真实更新时间
• mainEntityOfPage 的地址与 canonical 完全一致
• author 是对象而不是字符串，且指向可访问的作者页
• 有分类结构的站点输出 BreadcrumbList
• 有 FAQ 的文章输出 FAQPage，且问答在正文可见
• Person 的 sameAs 填的是真实存在的外部主页
• 用 Schema Markup Validator 校验过，没有报错

常见问题（FAQ）

结构化数据会直接提升 AI 引用率吗？

不会立竿见影。它解决的是机器能不能准确理解这段内容是什么，属于必要条件而不是充分条件。没有结构化数据，模型仍可能读懂；有了它，解析成本更低、出错更少，在同等内容质量下更容易被选中。

JSON-LD、Microdata、RDFa 该选哪个？

首选 JSON-LD。它写在 script 标签里，与页面视觉结构解耦，改动排版不会破坏数据，也是搜索引擎官方推荐的形式。

一篇技术文章需要加多少种结构化数据？

三种就够：BlogPosting 说明这是篇文章，BreadcrumbList 说明它在站点里的位置，FAQPage 在文中有问答时补充。作者信息作为 Person 挂在 BlogPosting 里即可。

下一篇：《GEO 内容写作模板：让 AI 一眼看懂你的文章》。

加完之后建议用 Google 的富结果测试工具自查一遍，最容易出错的是图片地址、作者信息和日期格式。结果对不上，欢迎到留言板贴出来一起看。

内容被转载或改写之后怎么让溯源更容易，见《内容被 AI 改写后传播，该如何处理》。