GEO 审计

1. 一次完整 GEO 审计要做什么

一次完整的 GEO 审计，就是周期性检查全站内容：系统评估 AI 引擎能否访问、解析、采信并引用页面。具体检查方法分别见可引用性、爬虫访问审计、Schema 实施、llms.txt 部署、为 AI 引用而写和引用追踪。审计需要按照各项能力的依赖关系依次检查，为每项发现划分严重级别，最后形成报告。

六层依次是：访问 → 渲染 → 结构 → 内容 → 站外权威 → 结果。 检查顺序很重要：如果基础条件不成立，后续检查就失去意义（见 §3）。

审计与另外两项工作相互衔接：

• 持续监测：AI 引用追踪 持续记录引擎表现；审计以这些记录为依据，分析结果产生的原因；
• 改进规划：GEO 成熟度模型 根据诊断结果制定可执行的改进方案。

「GEO 审计」是行业通行的说法。本文使用的六层依赖框架由 GEO Wiki 整理，并非公认标准。之所以选择这一框架，是因为各项检查之间存在关键的先后依赖关系（见 §3），而不是因为它已经获得行业认可。

2. 开始审计前：范围、输入、触发条件

以下四项决定会直接影响后续发现的解释方式。任何一项设定错误，整份报告都无法正确解读。这与引用追踪手册强调的原则一致：先确定口径，再开始度量。

决策	选项	经验法则
范围	整个域名、某个语言版本、某个子目录或关键模板	每次只审计一个边界清楚的对象；混合不同范围会使结论失去可操作性
引擎集	明确列出受众使用的引擎，不要以笼统的「AI」代替	所选引擎会影响审计结果，必须在报告开头写清
竞品集	不设，或指定一组作为可选叠加项	竞品类发现是相对结论，绝不能和绝对结论混在一起。口径定义见 GEO 指标
基线	首次审计，或与上一次审计或追踪日志比较差值	没有基线，只能看到当前状态，无法判断变化趋势；报告必须注明基线类型

多久审一次。 建议每季度审计一次，并在特定事件发生后追加审计：站点迁移、改版或 SSR 与渲染方式调整、robots.txt 变更、大批内容上线，以及已知的引擎模型或检索机制更新。定期审计用于发现逐步积累的变化，事件触发的审计用于及时评估突发影响。

开始前先准备以下资料与工具： 生产环境的抓取权限、线上的 robots.txt、XML sitemap、能够抓取并渲染页面而不只是查看源代码的工具，以及最近一次引用追踪日志（如有）。没有追踪日志也可以开始审计，见 §4.6。

3. 审计阶梯：为什么顺序至关重要

GEO 就绪度有一组逐项成立的依赖条件，不能把所有检查当作彼此独立的清单项。前置条件不成立，后续检查就没有意义。

• 如果 AI 爬虫无法访问页面，再完善的 Schema 也无法发挥作用。
• 如果页面无法被抓取，再好的内容也不会被引擎处理。

因此，检查时要按照第 1 层到第 6 层的顺序，先确认必要条件是否成立；报告中的问题与行动优先级则要按严重级别排列，而不是按层级排列（见 §5 至 §6）：

#	层	它回答什么	判断与影响	详见
1	访问与可抓取性	AI 能否抓取页面？	未通过 → 第 2 至第 6 层无需再查	AI 爬虫访问审计
2	渲染与交付	抓取后能否取得主体内容？	未通过 → 后续只能针对缺少正文的页面检查	面向 AI 爬虫的 SSR · Sitemap 与 IndexNow
3	结构与机器可读性	机器能否解析已抓取的内容？	较弱 → 内容抽取难度显著增加，但不一定完全无法处理	Schema 实施 · llms.txt 部署
4	内容与可信度	内容是否值得引用？	较弱 → 内容可以读取，但难以获得引用	可引用性 · 为 AI 引用而写
5	站外权威	这个实体能否获得站外信息印证？	较弱 → 即使站内工作完善，引用表现仍可能受限	品牌提及追踪
6	结果核对	引擎实际如何处理页面？	不设中止条件，而是比较预期表现与实际结果	AI 引用追踪

各项发现都应简明完整，并能拆分成独立段落，以便阅读、引用和抽取。

4. 沿阶梯逐层审

按照第 1 层到第 6 层的顺序检查。每层都要回答四个问题：核心问题、继续或中止检查的条件、最关键的 2 到 3 项检查，以及操作说明。

4.1 第 1 层：访问与可抓取性

问题	主流 AI 用户代理（user-agent，UA）能否抓取页面？
判断条件	如果受到封禁或严格限流 → 第 2 至第 6 层不再检查。 这是最严格的中止条件。
重点检查	（1）robots.txt 针对各 AI UA 的规则，包括 Google-Extended；（2）服务器、CDN 或 WAF 是否封禁 UA，或返回机器人验证拦截页；（3）是否存在软封锁，即状态码为 200，但非浏览器客户端收到验证页
操作说明	见 AI 爬虫访问审计；UA 对照见 AI 爬虫

权威的 UA 清单和 robots.txt 令牌行为见 Google 常见爬虫文档。这一层只有两种判断：页面可以抓取，或不能抓取。不能抓取时，应记录为第 1 层的阻断级发现。没有中间状态。

4.2 第 2 层：渲染与交付

问题	抓取后是否仍能取得主体内容？
判断条件	如果主体内容依赖爬虫不会执行的客户端 JS 渲染 → 爬虫只能取得没有正文的页面。
重点检查	（1）主体内容采用 SSR/SSG 还是 CSR（检查抓取所得 HTML，而不是渲染后的 DOM）；（2）sitemap 覆盖度与 lastmod 时效性；（3）是否通过 IndexNow 或 ping 通知内容变更
操作说明	面向 AI 爬虫的 SSR · Sitemap 与 IndexNow

IndexNow 协议参考见 indexnow.org/documentation。如果页面返回 200，但禁用 JS 后抓取结果为空白，应记录为第 2 层问题，而不是第 4 层的内容问题。准确分类可以避免后续诊断偏离问题根源。

4.3 第 3 层：结构与机器可读性

问题	机器能否稳定解析抓取到的内容，并将其归入正确实体？
判断条件	如果结构化数据缺失或无效 → 实体解析和答案抽取的质量都会下降，但内容不会因此必然无法处理。
重点检查	（1）关键模板的 Schema.org 覆盖度与有效性；（2）llms.txt 是否存在且内容正确；（3）标题结构是否符合语义，内容块边界是否清晰
操作说明	Schema 实施 · llms.txt 部署；概念见 面向 AI 的 Schema.org

可用 Google 结构化数据入门、Rich Results Test 和 schema.org 的 Schema Markup Validator 校验；llms.txt 则应对照提案规范。Google 已明确说明，AI 功能不要求使用任何专门的 Schema。因此，结构化数据的作用是帮助机器识别实体，而不是作为进入 AI 功能的必要条件（见 AI features and your site）。

4.4 第 4 层：内容与可信度

问题	内容被读取后，是否可信并值得引用？
判断条件	如果内容无法清晰分块，或可信度信号不足 → 机器仍能读取页面，但页面难以获得引用。
重点检查	（1）论断是否便于抽取、能否独立成段，内容分块是否清晰（见 可引用性）；（2）E-E-A-T 信号；（3）时效性页面的更新状态与内容价值衰减
操作说明	可引用性 · 为 AI 引用而写；概念见 E-E-A-T · 内容新鲜度

在已有研究中，内容层的因果证据最多。Aggarwal et al. 2024 发现，通过增加引文、统计数据和引述来改写内容，最多可使内容在答案中的呈现度提升约 40%。这一结果只说明可能的改善方向，不能当作适用于所有场景的精确幅度（见 §8）。

4.5 第 5 层：站外权威

问题	这个实体在自有域名之外能否获得信息印证？
判断条件	如果站外信息不足 → 即使站内工作完善，引用表现仍会受到限制。
重点检查	（1）在引擎经常引用的来源类型中，品牌提及的数量与情感倾向；（2）实体是否存在于知识图谱中，以及能否与同名实体区分
操作说明	品牌提及追踪；概念见 品牌提及 · 知识图谱存在度 · 实体识别

这一层最容易被从业者忽略，却经常成为限制因素。即使站内已充分完善，引用表现仍会受到站外实体识别和信息印证程度的影响。

4.6 第 6 层：结果核对

问题	引擎是否引用了页面，引用结果是否符合第 1 到第 5 层的判断？
判断条件	本层不设置中止条件，而是对照第 1 到第 5 层得出的预期引用表现与引擎给出的引用。
重点检查	（1）针对报告中声明的每个引擎，分别取得最近一次引用追踪记录；（2）如果站内各项检查均无明显问题，引用仍然不足，这种差异可作为排查站外因素或引擎行为的线索
操作说明	以 AI 引用追踪 的最近一次记录为依据

追踪机制的建立方法见 AI 引用追踪 手册。如果没有追踪日志，第 6 层只能记录一项发现：先建立追踪机制。 不同引擎的行为应分别核对，包括 Perplexity AI、ChatGPT Search 和 Google AI Overviews。Google AI Overviews 没有提供逐条引用的 API，因此只能做较粗粒度的结果核对。

5. 评分：依据明确的严重级别模型

每一条发现都要标明严重级别，级别取决于问题所在的层级。第 1 层的访问失败比第 4 层的任何细节优化都更严重：只要访问问题没有解决，内容优化就无法体现效果。

严重级别	含义	通常出现在哪一层
阻断级	直接阻止引用；无法评估后续层级	第 1 层、第 2 层
重大级	明显降低抽取或引用表现；当前即可测量	第 3 层、第 4 层
次要级	确有影响但幅度有限；属于优化问题，不构成中止条件	第 4 层的细节优化、第 5 层影响较小的问题

0 到 100 的综合分，并非必需，重要性也低于严重级别清单。它只能反映大致方向，不能视为绝对值；只有同时说明加权算法，才能对外报告。这与 GEO 指标 对公开数据口径的要求一致：缺少加权算法的孤立分数不能构成有效结论。

6. 排优先级：从问题清单到排好序的行动计划

严重级别不等于行动优先级。如果一项重大级问题成本低、解决把握高，它可以排在需要半年迁移才能解决的阻断级问题之前。对已经划分严重级别的发现，应按影响 × 把握 × 难易（ICE）重新排序。报告最后应提供一份次序明确的行动清单，而不是未经整理的问题汇总。

发现	层	严重级别	影响	把握	难易	ICE	排名
robots.txt 中的 Google-Extended 被 Disallow 规则禁止抓取	1	阻断级	9	9	9	729	1
关键模板完全没有 Schema	3	重大级	7	8	6	336	2
定价页是纯 CSR	2	阻断级	8	7	3	168	3
作者信息与 E-E-A-T 信号不足	4	重大级	6	5	5	150	4

排序后的行动计划用于制定后续改进方案，但两者并不相同。审计负责说明当前状况；如何根据结果安排长期改进，见 GEO 成熟度模型。

7. 审计报告交付物

每一次都要交付的内容：

• 开头与口径：注明审计日期、范围、所选引擎，以及所用追踪日志的版本（见 §4.6）。缺少这些信息，报告就无法与后续审计比较。
• 六层检查结果：按第 1 层到第 6 层列出检查结论，并为每项通过或未通过的判断附上证据。
• 按严重级别排序的发现，随后提供按 ICE 确定优先级的行动计划。
• 基线差值：如果已有上一次审计，需说明发生了哪些变化，以及变化源于站点调整还是引擎本身。

关于复审。 对于未发生变化且不受触发事件影响的下层结论，复审可以继续沿用；受影响的部分则要重新检查（见 §2）。报告必须清楚区分两者，否则已经失效的「通过」结论可能连续三次审计都得不到复核。

8. 容易踩的坑

发布报告前，应逐项排除以下问题：

• 从上往下审：先检查内容，却忽略第 1、2 层的访问或渲染障碍；这是最常见且代价最高的错误。
• 孤立的综合分：一个不附加权算法的 0 到 100（GEO 指标）。
• 把过时的追踪日志当作现状：第 6 层核对的仍是上个季度的情况（AI 引用追踪）。
• 竞品相对发现和绝对发现混用：两者性质不同，绝不能放在一起加总（GEO 指标）。
• 把单语言审计的结论套用到所有语言：不同语言下的答案结果不能相互替代，审计结论也不能直接套用。
• 没有复审前后对比就说「修好了」：任何改动在通过复审验证前，都不能视为已经取得结果。
• 把可见度改善夸大为营收增长：审计只能证明某个可见度缺口得到改善，不能据此认定营收已经变化；评估可见度如何影响业务收益，需要另一套模型（GEO ROI 模型）。
• 把一家机构测得的提升扩大为普遍结论：一家机构单独测得的提升，在竞争对手也针对同一引擎进行优化后未必能够维持；Aggarwal et al. 2024 §6 也对此作了专门提醒。

9. 延伸阅读

• 六层检查方法：AI 爬虫访问审计 · 面向 AI 爬虫的 SSR · Sitemap 与 IndexNow · Schema 实施 · llms.txt 部署 · 可引用性 · 为 AI 引用而写 · 品牌提及追踪
• 持续监测与改进：AI 引用追踪 · GEO 成熟度模型
• 指标与定义：GEO 指标 · 生成式引擎优化
• 研究依据：Aggarwal et al. 2024 — GEO: Generative Engine Optimization

参考资料

学术：

1. Aggarwal, P. et al. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · ACM DL
2. Liu, N., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP ‘23. arXiv:2304.09848

平台与标准文档（2026-05 已核对）：

• Google Search Central — Overview of Google crawlers · Common crawlers list · AI features and your site · Structured data intro
• 校验工具 — Rich Results Test · Schema Markup Validator
• IndexNow — Protocol Documentation
• llms.txt — proposed standard
• Perplexity — Chat Completions API Reference · OpenAI — Web Search tool (Responses API)