面向 AI 引用的写作
速览要点
- 难度
- 进阶
- 预计耗时
- 新写一页约 2 到 6 小时;改写更快
- 前置条件
- 可引用性、E-E-A-T
- 这是什么
- 可引用性的七项信号,每一项都配一条具体的改写动作:要怎么写、要删什么、什么不要碰,目的是让每一段都能被 AI 答案原样取用
- 配方主线
- 七条配方对应七项信号,逐条匹配;每条都按同一套五要素模板来写:产出、机制、步骤、前后对照、易踩的坑
- 产出
- 一份能让每一段都被单独取用、说清楚的草稿或改写稿,外加一份可复用的章节模板和一份发布前自检清单
- 投入
- 新写一页大约 2 到 6 小时;改写要快一些,因为审计手册已经把需要修的地方标出来了
- 必要而非充分
- 结构决定一段内容能不能被取用,可信度决定这个来源会不会被采纳。每条配方都要与 E-E-A-T 同步推进
1. 这份手册解决什么问题
这份手册把七项可引用性信号逐条转成具体的改写动作:要怎么写、要删什么、什么不要碰,让一份草稿能通过 可引用性审计 用到的那项内容块抽取测试。每项信号的定义见 可引用性 §4。审计在某项信号上给出 ⚠️ 或 ❌ 时,§4 里对应编号的配方就是该执行的那一条改写动作。
微软在 2026 年 2 月把结构这一面说得很直白:「清晰的标题、表格和 FAQ 段落有助于让关键信息浮现出来,AI 系统也更容易准确引用」(Bing AI Performance in Webmaster Tools)。实证见 Aggarwal 等人 2024:在内容上做实质性改写(引用来源、加入统计数据、加入引述),AI 答案中的可见度有可测量的提升,单纯堆关键词则没有效果。这个方向可以作为主结论;论文给出的具体倍数则应视为上限估计,竞争压力会稀释单一站点的提升幅度(C-SEO Bench)。
动手改写之前,两道上游关卡先要过:页面能被抓取(见 AI 爬虫;完整闭环见 生成式引擎优化),以及可信度足以被选中(E-E-A-T)。结构没有实质内容支撑,会被识别为低质内容并被降权(AI 垃圾内容识别);在权威度薄弱的域名上密集堆砌引用,照样会卡在可信度这一关。七条配方真正发挥作用的环节是第三关,也就是采信。
2. 动笔前:先定下来的四个决定
下面四个决定,决定了 §4 每条配方落到当前这页上时具体意味着什么。在写第一句之前先把它们确定下来,这与 可引用性审计 和 AI 引用追踪 两份手册强调的「先决策再测量」是同一个原则。
| 决定 | 选项 | 经验做法 |
|---|---|---|
| 写作对象 | 一页 / 一种模板 / 一组内容集群 / 一个语种 | 集中力量把一个对象写到位;多种对象混在一起,§4 的配方无论用在哪一段都难以落地 |
| 查询意图 | 定义类 / 操作类 / 对比类 / 列表类 / 参考类 | 形态跟着意图走:操作类用步骤列表,对比类用自标注表格,定义类用倒金字塔起句 |
| 写作模式 | 新写草稿 / 改写陈旧页面 / 回应一条可引用性审计结论 | 三种模式起手要做的核心内容不同;§5 的 MDX 骨架默认面向新写场景,但每条配方在回应审计的模式下也可以单独使用 |
| 读者层 | 仅从业者 / 决策者 / 混合 | 影响段落密度,也影响 §4.7 中可引述句的措辞分量;纯从业者页面可以承载更紧凑、术语更密的句子 |
从哪里开始。手上有一条审计结论时,直接跳到对应的 §4.N 配方,按 §6 走一遍发布前清单即可推送。新写一稿时,按 §3 → §4 → §5 → §6 的顺序逐节进行。如果改写是由内容过期触发的(某条事实已经不准、引擎更换了呈现方式、对手的一页在这条查询上排到了你前面),就把触发原因填到「写作对象」一格里,对出问题的章节走一遍新写流程即可。复看节奏的模型见 内容时效性。
3. 七项信号的改写主线
每条配方对应一行;§4 各有一节展开。常见的失败形态来自 可引用性审计 那份手册的逐项症状;定义来自 可引用性 §4。
| # | 配方 | 它能写出什么 | 针对哪种失败 | 定义 |
|---|---|---|---|---|
| 1 | 自包含的内容块 | 段落能被单独取出而不丢失意思;主语和代词都在本段内部解决 | 代词链、「如上所述」、悬空的「前文」指代 | 可引用性 §4.1 |
| 2 | 倒金字塔章节 | 每个 H2/H3 开头第一句就是结论,论证放在后面 | 在写出论点之前先铺两三段背景 | 可引用性 §4.2 |
| 3 | 问答型标题 | H2/H3 与真实用户查询对齐;只在确实是问答型的页面上使用 | 没有人会输入的话题型标题,或者凭空编造的 FAQ | 可引用性 §4.3 |
| 4 | 步骤列表 | 编号、祈使、一步一个动作,整段可被一次取走 | 把步骤埋在散文里(「首先你应该考虑……」) | 可引用性 §4.4 |
| 5 | 自标注表格 | 带标题句的表格,每一行都能独立读懂,表头是完整名词短语 | 离开正文就什么也讲不清的表格 | 可引用性 §4.5 |
| 6 | 标题层级规范 | 一份 H1,H2 → H3 干净嵌套,不跳级 | 装饰性标题、跳级(H2 → H4)、重复的 H1 | 可引用性 §4.6 |
| 7 | 可整段引述的句子 | 每个 H2 至少有一句简洁、能独立被取走的论断 | 含糊、多重从句、什么也提不出来的填充句 | 可引用性 §4.7 |
第 1、2、7 项的杠杆最大:它们决定一页内容里是否存在任何一个可以被取走的单元,所以每一页都应当具备。第 3 项和第 4 项要看页面形态,没有问答内容也没有过程描述的页面就不要硬造。第 5 项视表格密度而定。第 6 项成本低、收益稳定。
七条配方在各家呈现端都同样适用,差别只在哪一两项的权重被抬得更高,逐家细节见 §8。微软的一句话给整条主线提供了一个判定基准:「价值的最小单位正在从文档转向可采信的信息:离散、可佐证、有清晰出处的事实」(Bing:索引角色的演变,2026 年 5 月)。要写的最小单位是一段,不是一页。
4. 七条改写配方
每个 H3 都按同一套五要素模板来写:产出 / 机制 / 步骤(编号)/ 改写前后对照 / 易踩的坑,让七条配方彼此可比。
4.1 自包含的内容块
产出。 段落可以干净地从上下文里取出来:主语已经重新点明、代词在本段内部可解、没有指向相邻段落的悬空指代。
机制。 采信的最小单位是一段可被取走的内容;引擎在内容块层面做检索与挑选,不是在页面层面。一段如果必须依赖上一段才讲得通,被单独取出的那一刻就违反了 可引用性 §4.1 的要求。
改写步骤。
- 每一段开头都用一个自带主语的句子;把这一节讲的那个名词再点一次,不要用代词回指上一段。
- 每一个代词都要能在同一段内找到先行词;如果指向的是三句之前的内容,就换回原来的名词短语。
- 把「如上所述」、「如前文所言」、「前面提到」之类的指针,替换为内容本身,而不是指向内容的箭头。
- 跨章节的引用要在括号里补一句具体内容:「依据上面那条优先级规则(长路径胜出)」,而不是「依据 §2 的优先级规则」。
改写前。 「如上所述,是适用的;但正如我们在 §2 提到的,优先级规则可能会覆盖。」
改写后。 「robots.txt 的 Disallow 指令对该 user-agent 块下列出的每一个 URL 都生效。两条规则冲突时,路径较长的那条胜出;完整的优先级走查见 §2。」
易踩的坑。 过度切碎:为了凑第 1 项,把每一段都切成只有一句话的碎片。Google 2026 年 5 月的立场很直接:「并没有要把内容切成小碎片以让 AI 更好理解的要求」(AI 优化指南)。第 1 项考察的是完整意思之下的自包含,不是碎片化;一句一段在第 1 项上的失败程度与代词链相当。规模化操作时过度切碎为什么读起来像低质内容,见 AI 垃圾内容识别。
4.2 倒金字塔章节
产出。 每一个 H2 和 H3 都以本节的结论开头;铺垫、论证、附加条件全部放在结论之后。
机制。 实时抓取型引擎(典型如 ChatGPT search)更看重位于页面或章节开头的那一段直接答案。采信这一步在挑选时会倾向于开头就直接回答的段落,因为检索能看到的只有章节前部那一窗内容,模型就要在其中决定引用哪一段。
改写步骤。
- 把答案写成每个 H2 和 H3 的第一句。
- 把铺垫和论证全部放到结论之后。如果不先写两段铺垫就写不出那句结论,说明结论本身还没有打磨到位。
- 如果一节开头出现「让我们来想想……」「有几个因素需要考虑……」「首先,重要的是要理解……」,就是该改写的信号。
- 第一句本身就要能被原样引述;§4.7 会把它复用为本节的「可整段引述的句子」。
改写前。 「在思考 robots.txt 时有几个因素需要考虑。许多从业者讨论应当由路径长度还是具体程度来决定优先级。最终,权衡两者之后,路径较长的那条胜出。」
改写后。 「robots.txt 里两条 Disallow 指令冲突时,路径较长的那条胜出。本节其余部分会走一遍优先级模型,以及它不成立的两个边界情况。」
易踩的坑。 同一节内容写两遍:一句「TL;DR」只是把 H2 标题换一种说法、并不提供任何新论点,然后下面又把同样的内容重写一遍。开头句应当让这一页继续推进,不是宣告这一页要讲什么。整页层级的 TL;DR 已经在 frontmatter 里、由模板自动渲染,正文里不要再用引用块复述一次。
4.3 问答型标题
产出。 把 H2 和 H3 写成问句;仅在页面本身属于问答形态时这样做(FAQ、故障排查、「我什么时候应该……」、「为什么 X……」),并且要对齐真实查询。
机制。 问答型标题对齐的是查询展开后形成的若干子查询(见 Answer Loop §3.1)。Google AI Overviews 和 Gemini 的网页采信流程尤其偏好「标题与查询对齐」,因为标题在基于索引的引擎上是检索阶段最强的信号之一。
改写步骤。
- 只在页面属于问答形态时把 H3 写成问句。一份定义型参考页不会因为把每节都改成问句就变成问答页,反而更难浏览。
- 对齐真实查询:素材可以来自 Search Console、客服工单、销售通话记录,或者引擎自己的「相关问题」面板。凭空编造的问题会归入 §7 列出的反模式。
- 答案的第一句(第 2 项)即使把标题去掉也要能独立成立;引擎有时会在没有标题的情况下引述这一句。
- 一个标题对应一个问题;除非答案确实能用一句结论同时覆盖两者,不要把「X 和 Y,选哪个?」塞进一个 H3。
改写前。 「### 关于爬虫优先级规则的若干考虑」
改写后。 「### 两条 robots.txt 规则冲突时,哪一条胜出?」
易踩的坑。 滥造 FAQ:为了凑第 3 项,每一页底部都挂上十几个凭空捏造的问句标题。这种内容会被识别为模板套话、按低质内容降权,规模化使用还会被 AI 垃圾内容识别 命中。一页上问答型标题的正确数量,等于这一页确实能回答的真实用户查询的数量:有时是五个,有时是零个。
4.4 步骤列表
产出。 用编号、祈使语气描述的过程:一步一个动作,单步可以被取走,不需要靠周围的散文来解读其中某一步。
机制。 一个有序过程可以作为一个干净的单位被取走;当用户查询本身是过程型的(「我怎么……」、「……的步骤是什么」),引擎倾向于引述编号祈使列表。同样的内容写成把步骤嵌入散文的形式,在每一家引擎上都不如写成显式步骤列表的版本。
改写步骤。
- 任何过程都用编号列表,绝不要把步骤埋在散文里。
- 一步一个动作,用祈使语气:「执行 X」,不是*「你应当执行 X」,也不是「X 需要被执行」*。
- 每一步都要能被单独取走;不要写「这一步取决于上一步」却不把上一步的结果再写一次。
- 过程出现分支时,拆成两个子过程。不要在一份列表里嵌入条件分支;「若 X 则跳到第 5 步」正是第 4 项要识别的失败形态。
改写前。 「首先你应该考虑文件是否已经存在,然后可能值得拉一份当前版本下来,之后再编辑相关的指令,最后重新部署并核验。」
改写后。
1. 拉一份当前的 robots.txt: curl https://example.com/robots.txt
2. 找到 User-agent: * 块。
3. 在该块内单独一行加上 Disallow: /private/ 。
4. 重新部署到站点根目录。
5. 重新请求该 URL,确认新指令已生效。
易踩的坑。 给本来不分先后的内容编上号(「1. 重要背景 2. 另一个考虑点 3. 一条小贴士」),目的只是想借第 4 项「整段一次取走」的便利。编号意味着执行顺序,把它当作视觉强调反而会让这个信号失效。本来不分先后的若干项,用无序列表,或者写成散文。
4.5 自标注表格
产出。 带标题句的表格,每一行都能被单独引用:表头是完整的名词短语,单元格写成完整子句,表格上方有一句完整的话说明比较的对象。
机制。 表头本身已经说明含义时,每一行都能被单独引用;引擎可以只取一行,不必依赖周围的段落补全意思。微软说得很直接:「清晰的标题、表格和 FAQ 段落有助于让关键信息浮现出来,AI 系统也更容易准确引用」(Bing AI Performance)。
改写步骤。
- 每个表格上方都要有一句完整的句子说明比较的对象(「robots.txt 中两条 Disallow 规则冲突时,路径较长的那条胜出。」);不是标签,而是一个完整句。
- 表头是完整名词短语(「胜出的那条规则」,不是*「胜?」*),让每个单元格不必回头看表头就能被理解。
- 每个单元格写成完整子句,不要用一个字作答。单写一个*「是」无法被引用;「依 RFC 9309 §2.2.2,路径较长的那条胜出」*才可以。
- 随机抽取一行做提取测试:把这一行单独贴进一次新的引擎会话,问*「这一行在讲什么?」*。如果引擎回答得含糊,说明这一行依赖了相邻行,需要重写。
改写前。
| 规则 | 胜? | 备注 |
|---|---|---|
| 长 | 是 | 见上 |
改写后。
两条 robots.txt 的 Disallow 规则冲突时,匹配路径更长的那一条胜出。
| 冲突情形 | 胜出的规则 | 为什么 |
|---|---|---|
同一 user-agent 下 /private/ 与 /private/docs/ | /private/docs/ | 依 RFC 9309 §2.2.2,匹配路径最长的胜出 |
| 路径长度相同、声明顺序不同 | 先声明的那条 | 在同一 user-agent 块内,按声明顺序决出胜负 |
易踩的坑。 把表格当成装饰:本来一句话能说清的事,硬塞进一个两列的表。第 5 项考察的是可被引用的结构化对比,不是视觉版式。一张两行两列、内容只有「A:是 / B:否」的表,本质就是一句中文;做成表格反而损害第 1 项,也对第 5 项毫无贡献。
4.6 标题层级规范
产出。 H2 → H3 干净嵌套,不跳级,没有装饰性标题,每页只有一个 H1(来自 frontmatter 的标题)。
机制。 干净的嵌套让段落可以被定位:引擎按节进行检索与引述,标题是一段内容能拿到的最强隐式描述。跳级和装饰性标题会破坏第 6 项所要求的「可检索的章节边界」。
改写步骤。
- 一页只有一个 H1(来自 frontmatter 的
title字段,由模板渲染为 H1)。正文里不要再重复它。 - 只使用 H2 → H3,不跳级(不要为了拿到更小的字号而直接跳到 H4)。
- 每个标题都要命名一个真实存在的内容单元。如果一节内容没法用一句话总结,这个标题就是装饰性的,应当删除或与上一层合并。
- 标题文字界定了本节要交代的内容;下面的第一句话必须正面讲到这件事(第 2 项 + 第 7 项,通常落在同一句上)。
改写前。 H2 → H4 → H3(跳级);装饰性 H3 例如*「### 切入正题!」、「### 一起来看」、「### 顺便一提」*。
改写后。 全文 H2 → H3 → H3 干净嵌套;标题直接写主题(「### 两条规则冲突时」、「### 优先级模型的隐含前提」)。
易踩的坑。 只为视觉节奏而使用 H3:一段一句话也单独挂一个 H3,理由是「让页面看上去更舒服」。如果一个 H3 下面只有一句话,应把它并入上一层。只有一句话的标题,本身就是装饰性的。
4.7 可整段引述的句子
产出。 每个 H2 至少有一句简洁、能独立被引述、归属信息完整的论断;通常就是 §4.2 倒金字塔配方放在最前面的那一句。
机制。 可引用性的最小单元是一句被单独取走时仍然成立的论断。模型倾向于引用利落、能独立成立的句子;采信这一步会过滤掉含糊、从句叠加、提取不出任何要点的句子。
改写步骤。
- 每个 H2 都写一句可被原样取走的句子,动词或主语放在前面,不要把论点压在从句下面。
- 砍掉一切含糊语气。*「在某些情况下,X 可能并不总是会 Y,这或许可以加以论证」在第 7 项上每次都输;「X 确实会 Y」*每次都赢。
- 归属信息要嵌入句子本身:把来源直接写进这一句(「依 RFC 9309 §2.2.2」、「Aggarwal 等人提出」),不要放在脚注里,检索过程中脚注会丢失。
- 即便把 H2 标题去掉,这一句也要能独立成立;引擎有时会在没有标题的情况下引用这一句。
改写前。 「在某些情况下,检索可能并不总是会导向真正的使用,这或许可以加以论证。」
改写后。 「检索让你成为候选;采信决定你会不会被用上。」
易踩的坑。 编造统计:为了让某句话看起来像「可整段引述」,写出*「47% 的从业者表示……」却没有出处。没有出处的数字过不了可信度筛选(E-E-A-T),还会触发 AI 垃圾内容识别。一句带着虚构数字的引述句比含糊句更糟*,因为这一页等于带着一个外形像引用的陷阱发布出去。每一处统计都要把出处 URL 写进同一句里;这样一句既能被引用,也站得住脚。
5. 一份可复用的章节模板
下面是一份带注释的 MDX 骨架,示范一节写到位之后应有的样子。把它套进一个新的章节、按位置填入内容,这一节就同时覆盖了第 1、2、5、6、7 项。
## H2 — 主题型标题(第 6 项;如果写成问句也会承担第 3 项)
一句可被引述的论断句,回答 H2 的提问或断言本节最关键的事实。
(第 2 项 + 第 7 项,通常是同一句。)
两到三句有实质内容的铺陈支撑这条论断;每一句开头自带主语,代词
在本段内解决。(第 1 项。)
表格上方一句完整句,说明在比较什么;是句子,不是标签。
| A 列(完整名词短语) | B 列(完整名词短语) | C 列(完整名词短语) |
|---|---|---|
| 自包含的单元格子句 | 自包含的单元格子句 | 自包含的单元格子句 |
| 自包含的单元格子句 | 自包含的单元格子句 | 自包含的单元格子句 |
(第 5 项。)
一句收尾:*推动*本节往下,不是总结本节;指向下一个 H2,或在
读者需要更深内容的位置放一条交叉引用。(第 1 项 + 读者交接。)
填这份模板有三条要点。第一句必须能独立被引用:单独读一遍这一句,遮住标题,看它本身是否仍在做一个论断。每一段都要通过抽取测试:单独贴进一次 ChatGPT search 或 Perplexity 会话,问*「这一段在讲什么?」。表格上方的那句话是一个完整句,不是标签;「robots.txt 优先级规则对比」不合格,「robots.txt 中两条规则冲突时,路径较长的那条胜出」*才合格。
这份模板不是僵硬的填空表。没有对比对象的章节不要为了凑第 5 项强行加入表格;信号要根据页面的真实形态来选用。中文页面在段落长度的容忍度和章节起句的约定上与英文不同,语言层面的差异见 多语种 GEO。
6. 发布前自检清单
在草稿发布之前过一遍这份清单:它相当于 可引用性审计 中的内容块抽取测试在写作过程中的对应版本,应当一边写一边检查,而不是发布之后再做。清单按信号分组,任何一项不达标都可以直接回到 §4 找到对应的配方。
第 1 项|自包含的内容块
[ ] 每一段开头都自带主语(代词在本段内有先行词)。
[ ] 没有「如上所述 / 如前文所言 / 见 §X」之类、未把名词短语再点一次的指代。
[ ] 随机抽三段单独取出,都通过内容块抽取测试。
第 2 项|倒金字塔章节
[ ] 每个 H2 的第一句就是本节的论断。
[ ] 没有任何一节用「让我们来想想……」「有几个因素……」开头。
第 3 项|问答型标题(仅在页面就是问答形态时检查)
[ ] 每个问句标题都对应一条真实用户查询(Search Console、工单、销售通话)。
[ ] 没有为了凑第 3 项而编造的「常见问题」。
第 4 项|步骤列表(仅在页面包含过程描述时检查)
[ ] 每个过程都写成编号列表,祈使语气,一步一动作。
[ ] 没有把编号用在不分先后的内容上。
第 5 项|自标注表格
[ ] 每个表格上方都有一句完整句的标题句。
[ ] 每个表头是完整名词短语;每个单元格是完整子句。
第 6 项|标题层级规范
[ ] H2 → H3 干净嵌套;不跳级;没有装饰性标题。
[ ] 每页一个 H1(frontmatter 标题);正文里不再出现 H1。
第 7 项|可整段引述的句子
[ ] 每个 H2 都有一句利落、不含糊、归属信息完整的论断。
[ ] 每个统计数字都和它的出处 URL 在同一句话里。
可信度(E-E-A-T 的交叠区,不属于可引用性,但足以让一个可引用的页面失去采信)
[ ] 作者身份与资历在页面上可见。
[ ] 没有编造的统计;每一个数字要么有出处,要么删掉。
清单全部通过是必要条件,不是充分条件。E-E-A-T 仍然承担采信中的「可信度」一面;没有实质内容支撑的结构会被识别为低质(AI 垃圾内容识别)。清单从上往下走,顺序也对应优先级:多数页面上,第 1 项的失败代价高于第 5 项;而可信度一组里只要有任何一条不达标,就比任何信号项都更优先要处理。
7. 改写时要避开的几种做法
这是 可引用性 §6 与 可引用性审计 §7 在写作侧的对应版本:从动笔写稿的角度出发,而不是从评审审稿的角度。
| 不要这样做 | 看上去像是在修哪一项 | 为什么反而会失败 | 正确做法 |
|---|---|---|---|
| 把每一段都切成一句话 | 第 1 项(自包含) | 碎片丢掉了完整意思,没有任何一段是连贯、可被取走的答案;Google 也明确说不必这样做 | 一段写一个完整且自包含的想法,通常三到五句合适 |
| 编造没有人会问的 FAQ | 第 3 项(问答) | 会被识别为模板套话、按低质内容降权,规模化使用还会触发 AI 垃圾内容识别 | 只在 Search Console、工单或「相关问题」里有真实查询时,才写成问句标题 |
| 用编造的统计(「47% 的从业者……」)让句子看起来可被引用 | 第 7 项(可引述论断) | 没有出处的数字过不了可信度筛选;外形像引用的陷阱比含糊句更糟糕 | 使用真实出处,并把 URL 写进同一句;做不到就直接删掉这一句 |
| 在同类页面之间复制同一段模板文字 | 规模化下的第 1 项 | 近重复检测能识别出来:共用同一段散文的同类页面会被一并降权 | 每一页单独写;同类页面共用结构(§5 的模板),不共用具体句子 |
| 把 LLM 的初稿原样发布 | 看似已被「优化」的措辞 | 会被识别为低成本批量内容;即便外形合规,内容仍然是空的 | 让 LLM 扩写,由人来精修。流程是「人写内核 → LLM 扩写 → 人精修」,不是反过来 |
| 加一段「完美」的 TL;DR,但内容只是把 H2 标题换种说法 | 第 2 项(直接答案块) | 没有让页面继续推进;引擎遇到冗余会直接跳过这一节 | TL;DR 应是一个论断,而不是标题的复述;前后对照见 §4.2 |
关于 AI 辅助写作还需要把规律讲透一点。Aggarwal 等人测量的是实质内容,不是套用模板本身;外形合规、内容空洞的稿件,恰好会触发它本想绕开的那道过滤器。可行的方向是人写内核 → LLM 扩写 → 人精修,不能是LLM 先写 → 轻改一遍 → 发布出去。LLM 先写所引发的失败形态在 AI 垃圾内容识别 中也有展开;Aggarwal 那篇的读法是「方向可信,但具体倍数应作为上限估计」,原文与解读见 论文条目。
Google 在 2026 年 5 月的一段总结说得很清楚:「想出现在 AI Overviews 或 AI Mode 里,没有额外的要求,也不需要做什么特别的优化」(AI Features and Your Website)。§4 的七条配方并不是什么特殊技巧;它们是「写得清楚、有据可查的内容」自然呈现出的结构形态,而每一份关于这件事的一手资料,给出的建议归根到底也是同一件事。
8. 配方在不同呈现端的差异
七项信号在各家呈现端都同样适用,但各家会把其中一两项的权重抬得最高。写作时要回答的问题因此变成:如果一定要在某一项上重点投入,针对某家引擎该挑哪一项?
| 呈现端 | 应当重点投入的信号 | 为什么 | 优先做的配方 |
|---|---|---|---|
| Perplexity | 1、5、7 | 设计上引用密度很高;最看重紧凑、可被取走的内容块和利落的可引述句 | §4.1、§4.5、§4.7 |
| ChatGPT search | 2 | 实时抓取 URL;最看重位于本节顶端的那一段直接答案 | §4.2 |
| Google AI Overviews | 3、6 | 基于索引;最看重标题层级以及与展开后子查询对齐的问句标题 | §4.3、§4.6 |
语言是另一个维度。在中文里,内容块和直接答案块的可引用性与英文略有差异:段落长度的容忍度、标点节奏、章节起句的约定都不一样。中文页面在落地细节,以及在中文引擎上与英文有差异的那部分可引用性,见 多语种 GEO。
竞争环境下,单一站点的提升幅度会被稀释。这套配方在每个呈现端都能让一页内容比未优化的版本更容易被取用,但单站基准上读到的那些倍数并不是保证;一旦对手也用了同样的配方,整体的平均提升会被压缩(C-SEO Bench,NeurIPS ‘25 D&B)。读一条配方时正确的角度是*「用了它,我这一页是不是比不用更容易被取用」,而不是「能不能拿到绝对值 +40% 的提升」*。
9. 发布之后:把闭环跑完
发布之后有三件事要做。
第一件,在线上页面上再做一遍内容块抽取测试。随机抽取三段(TL;DR、某个 H2 下的第一段、表格里的某一行),原样复制出来,分别贴进一次新的 ChatGPT search 或 Perplexity 会话,问*「这一段在讲什么?」*。只要任何一段被引擎回答得含糊、引擎要求补充上下文,或者引擎补错了内容,就构成一条可引用性结论;用 可引用性审计 做完整诊断,再回到这份手册做对应信号的改写。
第二件,把这一页接入追踪集。把目标查询加入 AI 引用追踪 §3 定义的那份固定提示词集,等两个采集周期再看趋势:单周的变化都是噪声。重点观察引用率与平均位置(定义见 GEO 指标),而不是流量层面的表面指标。改写后的第一个周期常常出现一次短暂的回落,因为引擎需要重新抓取和嵌入;真正有意义的是趋势。
第三件,报告中要把引用与提及分开。同一页内容可能被带链接地引用,也可能被不带链接地复述(提及);两者都重要,但解决方法分属不同环节,见 引用 vs 提及。被提及但没被引用,通常说明可信度过得去而归属链条断了,这属于 E-E-A-T 或归属层面的问题,超出了可引用性的范围。归属层面的上限来自 Liu 等人的实证:「合成句中能够被引用完全支撑的比例为 51.5%」(Liu et al., EMNLP ‘23)。
什么时候要重写。触发条件就是 §2 开头列出的几种:某条事实已经不准、引擎更换了呈现方式、对手的一页在这条查询上排到了你前面。复看节奏的模型见 内容时效性;操作上的循环就是在出问题的那一节上重新走一遍 §2 → §4 → §6。
10. 延伸阅读
- 概念层:可引用性(七项信号的定义)、E-E-A-T(结构要真正落地必须依赖的可信度一面)、Answer Loop(这些配方赢的是其中的第 3 步)
- 相邻手册:可引用性审计(这份手册要回应的就是它给出的结论)、完整 GEO 审计(更上层的衔接对象)、AI 引用追踪(发布之后的度量闭环)
- 逐家呈现端:Perplexity、ChatGPT search
- 学术锚点:Aggarwal et al. 2024 — GEO: Generative Engine Optimization(实质胜于技巧的机制);倍数应作为上限估计来读,见 C-SEO Bench;归属层面的上限见 Liu et al. 2023
- 可信度与识别:AI 垃圾内容识别(为何过度优化反而通不过识别)、多语种 GEO(语言是另一个维度)
参考资料
学术:
- Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K. & Deshpande, A. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · ACM DL · 站内 论文条目
- Puerto, H., Gubri, M., Green, C., Oh, S. J. & Yun, S. (2025). C-SEO Bench: Does Conversational SEO Work? NeurIPS ‘25 Datasets & Benchmarks. arXiv:2506.11097
- Liu, N. F., Zhang, T. & Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP 2023. arXiv:2304.09848
官方平台文档(截至 2026-05):
- Google Search Central — Google’s Guide to Optimizing for Generative AI Features on Google Search · A new resource for optimizing for generative AI in Google Search · AI Features and Your Website · Top ways to ensure your content performs well in Google’s AI experiences on Search
- Microsoft Bing — Evolving role of the index: From ranking pages to supporting answers · Introducing AI Performance in Bing Webmaster Tools (Public Preview)
- OpenAI — ChatGPT search Help Center
- Perplexity — What is an answer engine, and how does Perplexity work as one?
常见问题
这份手册和「可引用性」概念条目、可引用性审计是什么关系?
七条配方是不是每一页都要全部用上?
能不能直接把草稿交给 LLM,让它「按可引用性优化」一遍?
每一段应该写多长?
改写发布之后,要看哪个指标?
相关手册与百科
参考来源
一手来源
- GEO: Generative Engine Optimization (Aggarwal et al., KDD 2024) · arXiv / KDD '24 · 2024-08-25
- GEO: Generative Engine Optimization (KDD '24 Proceedings) · ACM SIGKDD · 2024-08-25
- Google's Guide to Optimizing for Generative AI Features on Google Search · Google Search Central · 2026-05-15
- A new resource for optimizing for generative AI in Google Search · Google Search Central · 2026-05-15
- AI Features and Your Website · Google Search Central · 2025-12-10
- Top ways to ensure your content performs well in Google's AI experiences on Search · Google Search Central · 2025-05-01
- Introducing AI Performance in Bing Webmaster Tools (Public Preview) · Microsoft Bing · 2026-02-10
- Evolving role of the index: From ranking pages to supporting answers · Microsoft Bing · 2026-05-06
- ChatGPT search — OpenAI Help Center · OpenAI
- What is an answer engine, and how does Perplexity work as one? · Perplexity AI
二手来源
- C-SEO Bench: Does Conversational SEO Work? (Puerto et al., NeurIPS '25 D&B) · arXiv / NeurIPS '25 D&B
- Evaluating Verifiability in Generative Search Engines (Liu et al., EMNLP '23 Findings) · arXiv / EMNLP '23 Findings