本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

如果只看一段就走，请记住这几个结论：

• 流量入口正在迁移——越来越多人不再点蓝色链接,而是直接让 AI 把答案"端到嘴边",这意味着传统 SEO 那套堆关键词、换友链的玩法,正在被 AI 引用机制取代。
• 新打法叫做 GEO(Generative Engine Optimization,生成式引擎优化),目标不再是"排在搜索结果第一页",而是"让 AI 在回答用户问题时把你当成首选引用源"。
• 核心抓手有四块:一是内容可引用性(段落自包含、信息密度高、长度在 134–167 词之间);二是 robots.txt 对 AI 爬虫的精细化放行;三是 Schema/JSON-LD 结构化数据 + llms.txt 文件;四是品牌在第三方平台的提及度——研究显示品牌提及度与 AI 可见性的相关性是传统外链的 3 倍。
• 工具层面,开源项目 geo-seo-claude 提供了从可引用性评分、爬虫审计、Schema 生成、llms.txt 自动产出到 PDF 报告的完整工作流,可以作为入门 GEO 的趁手扳手。

想看完整拆解,往下翻——下面会把每一块原理、操作步骤、代码示例和我自己折腾出来的经验全都摊开讲清楚。

一、AI 搜索正在悄悄改写流量入口

打开后台看流量来源的时候,有一个变化越来越明显:从传统搜索引擎进来的访问量在缓慢下滑,而带有 chat.openai.com、perplexity.ai、gemini.google.com、yuanbao.tencent.com 这类来源的访问反而在悄悄抬头。这不是错觉。

1.1 用户的搜索行为正在迁移

以前要查一个技术问题,大部分人会先打开搜索引擎,然后在十几条蓝色链接里挨个点开,从中拼凑出答案。这是过去二十年我们都熟悉的"找信息"动作。

而现在更常见的场景是这样的:打开 AI 助手,直接问"帮我用 Python 实现一个 LRU 缓存,带过期时间";想吃饭的时候问"我在上海徐家汇,推荐三家口碑不错的本帮菜";想做技术选型的时候问"对比一下 Vue 3 和 React 18 在大型项目里的差异"。AI 直接吐出一段整合后的答案,里面顺带带上几条引用来源——这才是新一代用户的"搜索"。

公开数据里能看到一些印证:ChatGPT 的月度活跃用户已经突破亿级,Perplexity 的搜索量过去一年同比增长接近九倍。截至 2025 年 8 月,生成式 AI 搜索已经占据全球搜索市场约 43% 的份额,业内普遍预期两年内这个数字会冲过 70%。 流量在搬家,只是大部分网站主还没察觉。

1.2 传统 SEO 的根基正在被动摇

我以前做 SEO 时琢磨的几件事:关键词布局、TDK、外链交换、内链结构、移动端适配。这些东西在搜索引擎是"链接列表"的时代非常好用——你想办法排上第一页,用户自然就会点进来。

但 AI 搜索改写了这个流程:

graph LR
A[用户提问] --> B[AI搜索引擎]
B --> C[索引/RAG检索]
C --> D[筛选高质量内容]
D --> E[生成整合答案]
E --> F[附带引用来源]
F --> G[用户看完答案就走]

注意最后那一步——用户看完答案就走。如果你的内容只是被 AI 用来"喂"答案,而没有被列在引用来源里,你的网站在用户眼前根本就没出现过。即便被列在引用,大多数用户也不会点进去深读;真正能带来访问的,只有那些信息密度极高、被 AI 反复优先引用的页面。

这就是 AI 时代流量分发逻辑的根本变化。从前你只需要"被搜到",现在你必须"被引用",而且要被引用得足够频繁、足够前置,才能在新的入口里抢到一个位置。

1.3 GEO 这个概念是怎么冒出来的

正因为搜索逻辑变了,行业里开始出现一个新词——GEO,Generative Engine Optimization,生成式引擎优化。这个词最早是斯坦福大学的研究团队在论文里提出来的,后来被 Perplexity、Anthropic 等头部 AI 公司的实践推到了风口浪尖。

我个人的理解很朴素:GEO 就是把网站"调成 AI 喜欢的样子"。它不取代 SEO,而是站在 SEO 之上多走一步。SEO 解决的是"被收录、被排名",GEO 解决的是"被理解、被引用、被推荐"。

在这一波变化里,谁先把 GEO 跑通,谁就能在 AI 流量的红利期里抢到第一波席位。我自己经营 无忆研习社(www.wuyi.wiki) 的这段时间,最直接的感受是:写一篇 GEO 友好的长文,带来的复利远高于写十篇关键词堆砌的水文。

二、GEO 到底是啥,跟 SEO 哪里不一样

很多人第一次听到 GEO 都会下意识反问:这不就是 SEO 换个马甲吗?其实不是。两者的底层差异,需要展开聊聊。

2.1 一句话定义 GEO

GEO(生成式引擎优化)指的是面向 ChatGPT、Claude、Perplexity、Gemini、文心一言、豆包、夸克等以 AI 大模型驱动的搜索/问答平台,通过优化内容结构、语义逻辑、可验证性、权威信号,让你的网站内容被 AI 模型识别、理解、并优先作为引用源出现在用户得到的答案里。

这一段话有点长,但它包含了三个关键动作:理解 → 引用 → 推荐。SEO 要的是"被收录、被排名",而 GEO 要的是"被引用、被推荐"。一个面向蓝色链接列表,一个面向整合后的自然语言答案,目标完全不同。

2.2 SEO 与 GEO 的本质差异

直接上一张对比表会更直观:

可以看到,两者的差异不是表层的"优化技巧不一样",而是从目标 → 算法 → 落地动作这条链路上整体的范式切换。

2.3 一个直观的例子

来举个例子。假设有人问"近视手术风险有哪些?"

传统 SEO 时代,你只要让"近视手术"这个关键词在页面里出现的次数够多、外链够硬、TDK 够标准,就有机会排上首页。曾经有医疗网站把"近视手术"这个词在一篇文章里塞进 127 次,排名稳如老狗。

到了 GEO 时代,AI 不再吃这一套。它会拆解用户意图,把问题展开成"手术原理是什么 → 主流术式有哪些 → 各自的风险点 → 术后注意事项 → 适应人群与禁忌"等多个子问题,然后从不同站点抓最优答案拼成一个回答。哪个网站的某个段落最清晰、最自包含、最像一段可以直接抄进答案的"标准答案",哪个段落就会被引用。关键词堆砌在这个语义匹配机制里几乎没有任何加成。

2.4 GEO 不是要废掉 SEO,而是站在它上面

我必须强调一点,也是我作为 莫潇羽@无忆研习社 站长这段时间最大的体会:GEO 不取代 SEO,它是 SEO 的延伸。

理由很简单:几乎所有主流 AI 搜索引擎,后端依然依赖传统搜索引擎的索引数据。ChatGPT、Claude、Gemini、Perplexity 在做实时检索的时候,大量调用的还是 Bing、Google 的搜索能力,从结果里筛选候选内容。如果你的页面连 Google、百度都没收录,AI 根本不知道你存在,谈何引用。

所以正确的姿势是:先把 SEO 的地基打牢(收录、可访问性、内链、移动端),再在地基上加盖 GEO 的二层(可引用段落、Schema、llms.txt、品牌信号)。如果跳过 SEO 直接搞 GEO,等于盖楼不打地基,看起来花哨但风一吹就倒。

2.5 顺手澄清几个容易混的概念

最近行业里还冒出了一堆缩写,容易把人绕晕。我顺手拉一张对照表帮你区分清楚:

实际工作里,GEO 和 AEO 经常被混着说,边界并不严格。我自己的判断是:这些概念都在描述同一件事的不同侧面——让你的内容被新一代搜索范式认可。纠结术语没意义,把动作做实在就行。

本文统一用 GEO 这个词来涵盖这一整套打法,因为它在英文社区里最通用,也是 Stanford 那篇奠基论文最早提出的标准说法。后面如果偶尔混用 AEO,你知道说的是同一件事就行。

三、AI 是怎么决定引用谁的

这一节是底层原理,理解了它,后面所有的操作动作才有逻辑可循。先抛一个核心结论:AI 的引用决策,本质上是在最小化信息熵的前提下挑选最具信息增量和可验证性的内容片段。听起来抽象,慢慢拆开看。

3.1 AI 搜索的两套架构

主流 AI 搜索引擎大致是两种工作模式。

第一种是 RAG 模式(Retrieval-Augmented Generation,检索增强生成)。流程是这样:

flowchart TD
A[用户输入问题] --> B[查询改写/拆解]
B --> C[在搜索索引/向量库中检索候选文档]
C --> D[文档分块 chunking]
D --> E[相关性排序]
E --> F[把 Top-K 片段塞进 prompt]
F --> G[LLM 基于片段生成答案]
G --> H[抽取引用源 citations]
H --> I[返回给用户]

注意 D 这一步——"文档分块"。AI 不是把你整个页面一口吞下去,而是按段落、按语义把网页切成一个个"知识块",然后挑出最相关、信息密度最高的若干块塞进上下文。所以真正在 AI 眼里被引用的,不是"你的网站",而是"你网页里的某一段"。 这个细节非常关键,我后面会反复用到。

第二种是直接生成模式,模型完全依赖训练时记住的语料,不做实时检索。这种模式下,GEO 优化的关键就变成了"如何让你的内容尽可能多地出现在训练语料里"——主要是 robots.txt 是否放行训练爬虫(GPTBot、ClaudeBot、CCBot 等),以及内容在第三方权威平台的镜像与提及。

实操里,这两种模式经常混用。我个人的工作流是:对实时性要求高的内容(资讯、教程、对比),主攻 RAG 模式优化;对常识性、品牌认知类的内容,顺带让训练爬虫读到。

3.2 影响引用的几个关键信号

AI 在挑选候选片段时,会综合多个信号打分。结合我读到的几篇研究(包括 Stanford 那篇《Generative AI for Search: Challenges and Opportunities》)和实操体感,大致是这几条:

• 信息增量(Information Gain):这一段内容相比已经检索到的其他候选,带来了多少新知识。如果你的段落只是把别人的话换个说法,信息增量是零,基本不会被引用。
• 可验证性(Verifiability):段落里有没有具体数据、来源、可追溯的事实。AI 偏好那些可以"对照得上"的内容,空话套话会被直接降权。
• 自包含性(Self-containment):一段话能不能独立成立,不需要看上下文就能读懂。AI 切片之后,被切下来的那一段如果离开原文就读不懂,几乎一定会被丢弃。
• 实体清晰度(Entity Clarity):段落里有没有清晰的实体(人、地点、产品、概念、数字),这些是 AI 抓取的"锚点"。
• 逻辑自洽(Logical Coherence):句与句之间是不是有清晰的因果或递进关系。乱序、跳脱、自相矛盾的段落会被直接淘汰。
• 权威信号(Authority Signals):作者署名、网站权威性、第三方提及度、引用链。
• 新鲜度(Freshness):发布或更新时间是不是足够近,尤其是问题本身具有时效性时。

3.3 一个真实的对照实验

有一份相对靠谱的行业研究做过类似的对照测试:同样一个营销博客原本通篇用长段落描述 SEO 工具,在 Perplexity 上的引用率只有 12%;调整成清晰的 H2/H3 标题层级 + 列表 + 数据后,引用率升到 68%。差异接近 5 倍。这是真实可复现的数据。

我自己在 无忆研习社 也跑过类似的对照——把一篇旧文按 GEO 思路重写后,被各家 AI 引用的频次明显抬升,搜索结果里也开始出现"来源:wuyi.wiki"的脚注。这部分体感是最直接的。

3.4 段落长度有个"甜区"

最后一个非常具体的发现,几乎所有做 GEO 评分的工具(包括开源的 geo-seo-claude)都指向同一个区间:最容易被 AI 引用的段落长度在 134–167 个英文词(对应中文约 250–340 字)之间。

为什么是这个区间?短了信息密度不够,信息增量太低;长了上下文窗口塞不下,容易被 chunking 算法切碎。这是一个"刚好能装得下一个完整论点,又不至于啰嗦"的甜区。在中文写作里,我自己的经验是按 5–8 个中文句子 来组织一个段落,既符合 AI 的偏好,也符合人类的阅读节奏。

四、内容可引用性:让 AI 一口吞下你的内容

理解了 AI 的引用机制,下一步就是把这套机制反推到写作动作里。这一节讲的是 GEO 最核心的内功——怎么写,AI 才更可能引用你。

4.1 段落自包含是第一原则

我把它列为第一原则,因为它是 AI 引用的"准入门槛"。一段话如果离开了上下文就读不懂,被切下来塞进 prompt 的时候就会丢失关键信息,AI 自然不会用它。

举个例子对比一下,下面是一段糟糕的写法:

如前所述,该方法的核心在于第三步。我们只需要把它替换成新的实现,就能解决之前提到的问题。

这段话里"如前所述""第三步""它""之前提到的问题"全是依赖上下文的指代——切片之后这段话直接报废。

改成自包含写法:

Schema 结构化数据的核心在于将网页中的人物、地点、产品、价格、评分等实体用 JSON-LD 格式显式标出。只要把传统 HTML 标签替换为带有 @type 和 @context 的 JSON-LD 脚本块,就能让搜索引擎和 AI 准确识别页面内容,而无需依赖语义推理。

这一段不依赖任何前文,实体清晰,论点完整,AI 一口就能吞下。

4.2 信息密度的具体衡量办法

什么叫"信息密度高"?可以用一个简单的自检公式:

[

\text{信息密度} = \frac{\text{段落中具体事实/数据/实体的数量}}{\text{段落总句数}}

]

理想值是 ≥ 0.6,也就是十句话里至少有六句包含可验证的事实或具体实体。

什么样的内容不算事实?"领先的""强大的""高效的""最佳的"这类形容词全都不算。它们是修辞,不是信息。 AI 不会因为你说自己"领先"就把你的内容写进答案。

什么样的内容算事实?具体的数字、人名、产品名、时间、地点、版本号、代码片段、引用源、对照表——这些都是"硬通货"。

4.3 一个"答案胶囊"的写法

业内有个挺好用的概念叫 Answer Capsule(答案胶囊),意思是把一段内容写成"问题 → 一句话答案 → 展开解释"的结构。研究显示,72% 被 ChatGPT 引用的页面都包含这种结构。

代码示意一下,在 Markdown 里它长这样:

## llms.txt 文件有什么用?

llms.txt 是一个放在网站根目录的纯 Markdown 文件,
作用是为 AI 爬虫提供一份"网站导览图",
帮助大模型在有限的上下文窗口内快速理解网站结构与核心内容。
它由 Answer.AI 联合创始人 Jeremy Howard 于 2024 年 9 月提出,
目前已有 5000+ 网站采用,包括 Anthropic、Cursor 等头部产品。

这种写法的好处:AI 只需要切下这一段,就能完整回答"llms.txt 是什么"这个问题。被引用的概率会显著高于把同样信息分散在五个段落里。

4.4 实体堆叠技巧

AI 在做 chunking 的时候,会优先保留实体密集的段落。所以一个非常实用的写法是:在段落里尽可能多地堆叠相关的实体名词。

不要写:"主流 AI 公司都推出了自己的爬虫工具,各家在策略上略有差异。"

要写:"主流 AI 公司的爬虫工具包括 OpenAI 的 GPTBot 与 OAI-SearchBot、Anthropic 的 ClaudeBot 与 Claude-SearchBot、Perplexity 的 PerplexityBot、Google 的 Google-Extended、Apple 的 Applebot-Extended,以及 ByteDance 的 Bytespider。各家在 robots.txt 合规性上存在差异,其中 Bytespider 历史上多次被记录为不遵循 robots.txt 指令。"

第二种写法,实体密度高,信息量大,自包含,AI 几乎一定会优先引用。

4.5 标题层级要清晰

AI 在抓取页面的时候非常依赖 H1/H2/H3 的层级结构。一个混乱的标题层级会直接让模型"读不懂目录"。

我的标准做法是:

# 一级标题(文章主题,全篇唯一)
## 二级标题(主要章节)
### 三级标题(章节下的小节)
#### 四级标题(小节下的具体操作或对比,慎用)

不要跳级(从 # 直接到 ###),不要并列同级标题用一句话叙述,不要用加粗或字号"假装"标题。这些都是 GEO 大忌。

4.6 表格、列表、代码块是引用率最高的格式

行业里反复出现的一条经验:FAQ、编号列表、项目符号列表、表格、代码块,是 AI 引用率最高的几种格式。原因很简单——它们结构清晰,可以被精确切片,信息密度极高。

特别是表格。我自己写 GEO 文章时,只要遇到对比、参数、配置项,基本都会上表格。下面这种表就是 AI 最爱抓的:

数据是参考行业研究 + 个人观察,不绝对准确,但方向无误。

4.7 一个我反复用的自检清单

写完一段后,我会在心里过一遍下面这个清单:

• 这段是不是脱离上下文也读得通?
• 这段里有没有至少 3 个具体实体(产品名、人名、版本号、数字)?
• 这段开头能不能用一个清晰的"答案句"概括?
• 这段里有没有形容词废话("强大""领先")可以删掉?
• 这段的长度是不是控制在 250–340 字之间?

只要有一条不过关,立刻在当前段落改掉再继续往下写。这是 莫潇羽@无忆研习社 在写 GEO 长文时的标准流程,亲测有效。

4.8 一个反面案例:为什么 80–90% 的内容根本进不了 AI 答案

这一节最后讲一个让我印象很深的数据:业内研究显示,真正被 AI 引用的内容只占被抓取内容的 10% 左右,剩下 80–90% 即便被爬虫读到也基本无效。

为什么这么悬殊?把那些"无效内容"拉出来看一眼,问题特别集中:

• 信息密度过低:通篇是"领先""强大""高效""一站式解决方案"这种空话,几乎抽不出可验证的事实点。
• 结构混乱:长篇大论没有小标题、列表、表格,AI 在 chunking 时切下来的片段无法独立成立。
• 指代不清:"该方案""我们""我们的产品"这种代词满天飞,离开了上下文完全读不懂。
• 核心结论被埋在文末:用户和 AI 都需要先翻到第 1500 字才能看到关键信息,引用就更别提了。
• 缺乏权威信号:没有作者署名、没有发布时间、没有任何可验证的来源链接。

把这五条反过来,基本就是 GEO 友好写作的完整公式:信息密度要高、结构要清晰、表达要自包含、结论要前置、权威信号要完整。我自己写 无忆研习社 的文章时,前 200 字一定会把核心结论亮出来,中间用清晰的标题层级展开,文末再做一次小结——这套结构无论是给人读还是给 AI 抓,都是最高效的。

写到这里你可能已经发现,GEO 的内容写作其实和"好的技术文档"高度重合。真正能被 AI 高频引用的内容,本质上就是经得起推敲的优质长文。没有捷径,但也没那么玄学。

五、AI 爬虫家族与 robots.txt 精细化配置

写得再好,如果 AI 爬虫被你挡在门外,那一切都白搭。这一节专门讲技术侧的入口配置,也是最容易被忽略、却最致命的一环。

5.1 先认识一下 AI 爬虫家族

AI 爬虫和传统搜索引擎爬虫不是一回事。粗略分,AI 爬虫可以划成三类:

• 训练爬虫(Training Crawler):抓内容去训练大模型,典型代表是 GPTBot、ClaudeBot、Google-Extended、CCBot、Bytespider。
• 检索爬虫(Search/Retrieval Crawler):负责构建 AI 搜索的索引,典型代表是 OAI-SearchBot、Claude-SearchBot、PerplexityBot。
• 用户触发爬虫(User-Initiated Fetcher):当用户在 AI 助手里贴一个 URL 让模型读时被调用,典型代表是 ChatGPT-User、Claude-User、Perplexity-User。

下面这张表是我整理的主流 AI 爬虫一览,建议直接收藏:

重点提醒:OAI-SearchBot 和 GPTBot 是两个独立爬虫。如果你只放行了 GPTBot 却挡掉了 OAI-SearchBot,你的内容依然不会出现在 ChatGPT 的实时搜索结果里——OpenAI 官方文档明确说明,被 OAI-SearchBot 排除的站点不会出现在 ChatGPT 搜索答案中。

5.2 一份"对 GEO 友好"的 robots.txt 模板

直接给一份我自己在用的 robots.txt 模板,以 GEO 可见性为优先目标:

# ============================================
# GEO 友好的 robots.txt 配置
# 维护者: 莫潇羽@无忆研习社
# ============================================

# --- AI 检索爬虫(必须放行,影响 AI 引用)---
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

# --- AI 训练爬虫(按需放行)---
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

# --- 传统搜索引擎(必须放行)---
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: Baiduspider
Allow: /

# --- 通用爬虫规则 ---
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /private/
Disallow: /tmp/

Sitemap: https://www.wuyi.wiki/sitemap.xml

这是一个"开放优先"的配置。如果你出于版权或商业考虑,不希望内容被用于模型训练,可以把 GPTBot、ClaudeBot、Google-Extended、CCBot 改成 Disallow,但务必保留检索爬虫的 Allow,否则你就从 AI 搜索结果里彻底消失了。

5.3 一个非常容易踩的坑:CDN 层覆盖

我必须把这一点单独拎出来讲,因为业内的研究数据触目惊心:约 27% 的 B2B SaaS 与电商网站,在 CDN 层(尤其是 Cloudflare)悄悄挡掉了主流 AI 爬虫,而站长完全不知道。

Cloudflare 在 2024 年推出了一项名为"AI 爬虫管理"的功能,默认会拦截已知的 AI 训练爬虫。如果你在 Cloudflare 后台启用了这个开关,那么你在站点根目录精心编写的 robots.txt 完全没用——爬虫连 robots.txt 都读不到就被 403 了。

自检方法:登录 Cloudflare 控制台 → Security → Bots → AI Crawl Control,检查是否开启了"Block AI Bots"或类似选项;同时审计服务器访问日志,看有没有大量来自 GPTBot、ClaudeBot、PerplexityBot 的 403/CAPTCHA 响应。如果有,这是当前最高优先级要解决的问题,胜过任何内容优化。

国内的 CDN(腾讯云、阿里云、七牛、又拍等)也有类似的 Bot 管理功能,逻辑相同——记得查一遍。

5.4 服务器层的合规性

robots.txt 是一种"君子协议",大部分头部 AI 公司(OpenAI、Anthropic、Google、Perplexity)都公开承诺遵守,但少数爬虫(比如历史上的 Bytespider)曾被记录为不遵守。

如果你需要硬性拦截某些不合规爬虫,只能在服务器层做,常见手段:

• Nginx 层基于 User-Agent 做 if 规则返回 403
• WAF(Web Application Firewall)规则
• 反向代理层加 IP 黑名单(各家爬虫的 IP 段官方都有公开)

不过我个人建议:对绝大多数内容站,完全没必要硬拦。GEO 时代,曝光本身就是最大的资产。

六、给 AI 递张名片:Schema 结构化数据实战

如果说 robots.txt 是"门禁卡",那 Schema 结构化数据就是你递给 AI 的"名片"——告诉它你是谁、这个页面讲什么、内容里的实体怎么理解。这一节讲怎么写、写哪些。

6.1 为什么 AI 偏爱结构化数据

直接说结论:带结构化数据的页面,被 AI 引用的概率比纯 HTML 页面高约 40%。这是行业里多份研究的共识。

原因不复杂。AI 在处理网页时,要从 HTML 这个混杂着导航、广告、脚本的"乱炖"里提取有用信息,这个过程会消耗大量上下文窗口,且容易出错。而 Schema 结构化数据用一段独立的 JSON-LD 脚本,把"这个页面是一篇文章、作者是谁、发布于何时、属于哪个分类、关联了哪些产品"一次性、机器可读地说清楚——等于把网页关键信息打包成 AI 能直接消化的格式,省了它一道处理工序。

省工序就意味着优先级提升。

6.2 三种 Schema 实现格式

Schema.org 官方支持三种标记格式,但实操里基本只用一种——JSON-LD:

• JSON-LD(推荐):独立 <script type="application/ld+json"> 标签,不与可见内容混编,改起来不会动到页面 HTML。Google 与各家 AI 厂商都首推。
• Microdata:直接在 HTML 标签里加 itemscope/itemprop 属性,改维护起来都麻烦。
• RDFa:HTML5 扩展,语法繁琐,使用率很低。

无脑选 JSON-LD,放进 <head> 即可。

6.3 一个文章页的标准 JSON-LD 模板

下面这段是 无忆研习社 文章页用的 JSON-LD 模板,直接照抄改改就能用:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "网站想被 AI 主动引用?GEO 生成式引擎优化从原理到落地全景指南",
  "description": "面向 AI 搜索时代的网站优化完整指南,涵盖 GEO 原理、可引用性、AI 爬虫、Schema、llms.txt、品牌提及与工具实操",
  "image": "https://www.wuyi.wiki/static/cover/geo-guide.jpg",
  "datePublished": "2026-05-13T09:00:00+08:00",
  "dateModified": "2026-05-13T09:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "莫潇羽",
    "url": "https://www.wuyi.wiki/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "无忆研习社",
    "url": "https://www.wuyi.wiki",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.wuyi.wiki/static/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.wuyi.wiki/blog/geo-ai-search-optimization-guide"
  }
}
</script>

把它贴在 HTML 的 <head> 里就行。@type 字段就是你告诉 AI 这个页面是什么——文章用 Article,产品页用 Product,组织主页用 Organization,常见问答页用 FAQPage,教程类用 HowTo,事件用 Event。

6.4 几个高价值的 Schema 类型

按优先级,我会把下面几个类型作为标配:

• Organization(放在首页 + 关于页):告诉 AI 你是个什么样的网站/品牌,包含官方名称、Logo、社媒账号链接(sameAs 数组),这是 AI 识别"主体"最关键的一块数据。
• Article / BlogPosting(每篇文章):标题、作者、发布时间、摘要,是被 AI 引用时显示来源的关键依据。
• Person(作者页 + 文章页的 author 字段):把作者作为一个清晰的实体,关联到对应的个人主页、社媒账号。
• FAQPage(任何 FAQ 内容):AI 极爱 FAQ,因为它本身就是"问题 → 答案"结构,被引用率极高。
• BreadcrumbList(面包屑导航):帮 AI 理解页面在网站结构里的位置。
• HowTo(教程类内容):分步骤明确,被 AI 抓取后可直接转化为答案。

6.5 一个 FAQ Schema 的实例

FAQ 类的页面强烈建议加 Schema,引用率会显著提升:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "GEO 和 SEO 的区别是什么?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO 面向传统搜索引擎,目标是让网页排在搜索结果前列;GEO 面向 AI 大模型驱动的问答平台,目标是让内容被 AI 引用进答案。两者并不互斥,GEO 是 SEO 之上的延伸。"
      }
    },
    {
      "@type": "Question",
      "name": "llms.txt 文件必须要有吗?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "目前 llms.txt 还是一个暂拟标准,主流大模型厂商并未官方采用,但已有 5000+ 网站部署。从前瞻布局的角度,建议加上;它对 AI 友好度有正向作用,且实现成本极低。"
      }
    }
  ]
}
</script>

6.6 校验与监测

写完 Schema 不要拍脑袋发布,一定要校验。常用的两个工具:

• Google 的 Rich Results Test:https://search.google.com/test/rich-results
• Schema.orgSchema.org 官方的 Schema Markup Validator:https://validator.schema.org

把页面 URL 或 JSON-LD 代码粘贴进去,几秒钟就能看到错误清单。常见的错误是字段拼写错误、必填项缺失、URL 不是绝对路径——这些都得改到 0 错误再发布。

6.7 一个新手最容易翻的车

最后提醒一个我自己踩过的坑:不要在每个页面都塞 Organization Schema。Google 明确说过,Organization 只需要在首页和"关于我们"页放一份,放到全站每个页面不会有负面影响,但也不会带来加成,反而会让 AI 在抓取时多做一次去重判断。

更不要做的是:为了在搜索结果里显示星级,把 Review/Rating Schema 塞进每个页面。这种操作会被 Google 直接判定为操纵,曾经有公司因此被全站降权。Schema 是用来描述事实的,不是用来"美化展示"的。

七、llms.txt:网站的新版"AI 说明书"

llms.txt 是 2024 年 9 月才提出的新标准,但发展速度极快。这一节单独讲它,因为它代表了 GEO 时代网站标配文件的下一个形态。

7.1 llms.txt 是什么

一句话定义:llms.txt 是一个放在网站根目录的纯 Markdown 文件(路径为 /llms.txt),为大语言模型提供一份精简、专业、易解析的"网站导览图",帮助 AI 在有限的上下文窗口内快速理解你的网站结构与核心内容。

它由 Answer.AI 联合创始人 Jeremy Howard 在 2024 年 9 月正式提出,2024 年 11 月被开发者文档平台 Mintlify 内置支持后,几乎一夜之间被 Anthropic、Cursor、FastHTML、Apifox 等数千个文档网站采纳,截至 2025 年 7 月已有 5000+ 网站部署。

7.2 它和 robots.txt / sitemap.xml 的差异

很多人会把这三者搞混,我专门做了一张对比表:

关键区别:robots.txt 解决"能不能抓",sitemap.xml 解决"能找到啥",llms.txt 解决"重点是啥"。 三者互补,不冲突。

7.3 llms.txt 的标准格式

llms.txt 的格式由 llmstxt.org 维护,要求按下面的顺序写:

# 网站名称(H1,唯一必填项)

> 一句话描述网站做什么,包含理解全文所需的关键信息(blockquote 格式)

可选的若干段补充说明...

## 二级分区名称(比如"核心内容")

- [页面标题](https://example.com/page-a): 简要说明
- [页面标题](https://example.com/page-b): 简要说明

## Optional(可选,放低优先级内容)

- [页面标题](https://example.com/page-c)

实际写一份 无忆研习社 的 llms.txt 大概长这样:

# 无忆研习社

> 由站长莫潇羽运营的中文知识型博客,聚焦 AI 工具、网站建设、GEO/SEO 优化、独立开发等技术实操内容,提供详细的原理拆解与工程化方法。

无忆研习社的内容定位是"实操优先 + 原理清晰",所有文章均为站长基于个人学习实践撰写,语言风