robots.txt

1. robots.txt 是什么

robots.txt 是站点根目录下（/robots.txt）的一份纯文本文件，用来告诉爬虫不要抓取哪些路径。背后的协议 Robots Exclusion Protocol 比现代互联网还要早，1994 年由 Martijn Koster 提出，作为事实约定运行了大约 25 年，直到 2022 年 9 月 IETF 把它正式定为标准 RFC 9309。

GEO Wiki 工作定义：robots.txt 是放在 /robots.txt 的一份 UTF-8 纯文本文件，按 user-agent 寻址爬虫，并以非强制的方式请求它们跳过特定路径。它是爬虫访问意图的标准化表达，不是访问控制。

RFC 9309 自己就先把话讲清楚，不必等到本文谈及 AI：规则「不是一种访问授权」，协议「不能替代内容安全方面的有效措施」（RFC 9309 §1）。声明的意图与真正的执行之间，存在一道结构性的缝隙。

对 GEO 来说，变的不是这份文件本身，是这份文件要面对的爬虫群体。AI 爬虫出现之前，关于这份文件的策略讨论几乎只有一道选择题：「Googlebot 拦不拦」，一个决策，一个 bot。AI 爬虫出现之后，同一份文件要面对约 30 个公开身份的代理，并且分成三类、访问后果彼此相反（训练、检索、用户触发；具体的分类模型见 AI 爬虫 §2）。协议没变，要面对的对象变了，新的写错方式也随之出现。

2. 协议如何工作

robots.txt 文件由若干分组构成，每个分组把一组规则绑定到一个或多个 user-agent，文件本身放在站点根目录，路径匹配的语法很简单。

文件本身：UTF-8 纯文本，按主机隔离，必须以 /robots.txt 这一固定路径并以 2xx 状态码提供。4xx 响应被视为「没声明任何规则」，爬虫可以自由抓取所有路径（RFC 9309 §2.3.1.3）。5xx 的处理偏向保守：根据各家爬虫的策略不同，可能选择重试，也可能在故障期间把整站当作完全禁止抓取。

记录格式：一个分组由若干 User-agent: 行后接一行或多行 Allow: / Disallow: 规则构成。分组之间用空行分隔。注释以 # 开头。

分组选择是写错最多的关键规则：每个爬虫只读取与自己产品名相符且最具体的那一个分组（RFC 9309 §2.2.1）。其它分组里的规则不会被合并进来。即使文件里有 * 通用分组，只要该 bot 在文件别处出现了具名分组，那条 * 分组对它就没有任何作用。

路径匹配采用最长匹配优先。当一个 Allow 和一个 Disallow 路径长度相等但相互矛盾时，Google 的官方约定是「限制更少的规则胜出」，也就是同等长度时 Allow 压过 Disallow（How Google Interprets the robots.txt Specification）。RFC 9309 把这一平手判定留给各家爬虫自己决定，但大多数主流爬虫都跟随 Google 的约定。

通配符：* 匹配零个或多个任意字符，$ 锚定到 URL 的结尾。这两个通配符在 Google、Bing、OpenAI、Anthropic、Perplexity 的爬虫里都受支持，按规则逐条匹配，而不是把整套规则拼成一个大正则去算。

Sitemap 指令：Sitemap: https://... 不绑定任何分组，它在整份文件里全局生效。sitemap 本身的机制见 Sitemap 与 IndexNow。

下面一段最小的优先级演示用例：

User-agent: GPTBot
Disallow: /
Allow: /blog/

User-agent: *
Disallow: /private/

逐句读法：GPTBot 命中 GPTBot 这一分组，看到 Disallow: / 加上 Allow: /blog/，结论是「除了 /blog/，其它路径都不抓」。其它所有 bot 命中 * 这一分组，结论只是「/private/ 不抓」。* 分组里的规则永远不会传到 GPTBot，哪怕它看起来像一条「合理的默认」：GPTBot 已经有自己的分组，就只会读自己那一组。这条机制是后续三段策略写法的同一条主线，也是反模式里最常见的那一类失误的成因。

3. 用 robots.txt 语法表达 AI 爬虫的访问策略

按类别（训练 / 检索 / 用户触发）划分的访问策略，写进 robots.txt 文件就是给每一类各起一组命名的 user-agent 分组。下面是三段最小的写法，每段大约六行。

只退出训练：保留 AI 答案的引用，让训练那一侧不再增量取走：

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
Disallow: /

检索和用户触发的取回器不在这一组里，所以 ChatGPT、Claude、Perplexity 和 Google AI Overviews 的实时答案仍然可以引用你。

只退出检索：接受暂时不在 AI 答案里被引用的代价：

User-agent: OAI-SearchBot
User-agent: PerplexityBot
User-agent: Claude-SearchBot
User-agent: Bingbot
Disallow: /

这里有一处协议本身无法表达的细节：屏蔽 Googlebot 会同时把你从 Google 搜索和 AI Overviews 里一起拿走，Google 没有提供「只退 AI Overviews、留下搜索」的单独令牌。Google-Extended 控制的是抓到的内容是否被用于训练，并不控制是否被抓取，所以它属于上面那组「退出训练」，而不是这一组。

全部放行，但逐一具名声明：

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

这种写法在实际效果上和一个空的 robots.txt 完全一样，但显式声明仍然有两个用处：一是把意图明确写下来，方便内部评审和审计工具读取；二是即使下游配置层在某处误给 * 加上了 Disallow: /，按具名分组的优先级仍能保住放行。

合并陷阱值得先点明：每个具名 bot 只读自己那一组的规则，所以最常见的写错就是这一种：在 * 组里写了 Disallow: /，又在各 bot 的命名分组里加一行 Allow:。后者根本进不了前者的作用范围，等于没写。完整的纠正写法见反模式一节。

每家厂商公开的产品名标识、IP 段和核验流程都在各自的专条里：GPTBot、ClaudeBot、PerplexityBot、Google-Extended、Applebot-Extended、OAI-SearchBot、ChatGPT-User。要核实当下究竟是哪些爬虫真正访问了你的站点（包括从日志里直接 grep 出来的那一份名单），见 AI 爬虫访问审计。

4. 各家厂商关于 robots.txt 遵守程度的官方说明

各家厂商对外公开的「我家爬虫如何处理 robots.txt」差异分明。下面这张表给出主要 AI 爬虫运营方的合规姿态，以及它们各自为「用户触发的取回器」留下的例外口径。

厂商	涉及的产品名标识	公开的 robots.txt 合规姿态	备注
OpenAI	GPTBot · OAI-SearchBot · ChatGPT-User	GPTBot 和 OAI-SearchBot 按文档遵守 robots.txt。截至 2025 年底，OpenAI 的爬虫文档对 ChatGPT-User 改为：「因为这一类访问由用户触发，robots.txt 规则可能不适用」	用户触发的口子在 2025 年 12 月的文档改版里被明确写了出来（OpenAI bots）
Anthropic	ClaudeBot · Claude-SearchBot · Claude-User	三只全部按文档遵守 robots.txt。2025 年的文档把它们拆成了「训练 / 检索 / 用户触发」三种 bot 的细分框架，每只都给出可直接拿来用的 Disallow 写法	Anthropic 明确说明，除了标准的 Disallow: 规则之外，还遵守非标准的 Crawl-delay: 扩展（Anthropic 爬虫说明）
Perplexity	PerplexityBot · Perplexity-User	PerplexityBot 遵守 robots.txt，禁止它则页面正文不会被收录。Perplexity-User 由用户发起，按 Perplexity 自己的说法「robots.txt 的限制通常不适用」	用户触发的口子是该厂商自 2024 年起一直采用的官方说法（Perplexity Crawlers；How Perplexity follows robots.txt）
Google	Googlebot · Google-Extended	Googlebot 遵守 robots.txt。Google-Extended 是「专门用于训练数据退出」的令牌：它控制的是抓到的内容是否被用于训练 Google 的生成式 AI 模型，并不控制 Googlebot 自己抓不抓	屏蔽 Googlebot 会把你从搜索和 AI Overviews 里一起拿走，Google 并未提供单独的 AIO 退出令牌（Google’s common crawlers）
Apple	Applebot · Applebot-Extended	两只都遵守 robots.txt。Applebot-Extended 是 Apple Intelligence 等生成式 AI 的训练数据退出令牌；主 Applebot 继续服务 Spotlight、Siri 和 Safari	单独禁掉 Applebot-Extended、把 Applebot 留着放行，就能在 Spotlight 与 Siri 里保留可见度（About Applebot）
Microsoft（Bing）	Bingbot	遵守 robots.txt；同时为 Bing 搜索与 Bing Copilot 提供检索	截至 2026 年 5 月，未公开过单独的 AI 训练退出令牌，这一点与 Google、Apple 不同（Which crawlers does Bing use?）
Common Crawl	CCBot	遵守 robots.txt，并遵守非标准的 Crawl-delay: 扩展	Common Crawl 的数据集会被很多第三方 AI 训练语料间接引用，禁用 CCBot 等于把这一条间接通路也一并切断（CCBot）

关于「用户触发取回器」有一处需要单独讲清楚：这是各家厂商公开的设计选择，不是缺陷。ChatGPT-User、Claude-User、Perplexity-User 都被各自的厂商描述为「由用户发起」、「robots.txt 限制通常不适用」。它们给出的理由一致：一次「某个真实用户问到某个具体 URL」的取回，本质上更像一次代为浏览，并不是自主的爬虫抓取。OpenAI 在 2025 年底的文档改版里把这层框架最明确地写了出来；Perplexity 的帮助页自 2024 年起就一直采用同样的口径。「robots.txt 覆盖所有 AI 访问」这种笼统说法，在这里就有一个最直接的反例。

各家爬虫的具体产品名标识、IP 段 JSON 列表，以及具体的 Disallow 写法，详见各爬虫的专条（表格里都已链好）。如果需要的是一份能随时复核、可直接作为审计依据的对照，见 AI 爬虫访问审计。

5. 声明的控制 vs 实际的执行

RFC 9309 自己并不把这份文件当成访问控制。标准开篇就把这道缝隙摆在了明处：声明的意图与真正的执行，本就不是同一件事。

RFC 9309 自己的免责声明。标准 §1 写得很直白：「robots.txt 文件里的规则不是一种访问授权」。后文又补一句：「本文档不能替代有效的内容安全措施，凡是不希望被访问的信息都应当被妥善保护」。两条话都出自这份正式标准（RFC 9309），是 IETF 自己写下的判断，不是事后的解读。

user-agent 字段只是爬虫自己声称的标识，并不构成可核验的身份。「我日志里看到了 GPTBot」并不等于「OpenAI 真的取走了这个页面」。伪造一个 user-agent 字段，任何按它写的规则都会被绕过；不遵守协议的爬虫连这份文件都不会去读。真正的身份核验依赖对外公开的 IP 段，再配合正向确认的反向 DNS（forward-confirmed rDNS）：所有主要的 AI 爬虫运营方都为此公开了 IP 列表。具体的核验流程见 AI 爬虫访问审计。

实际遵守程度的实测。公开口径与实测观察之间，往往存在差距，下面这张表把站得住的部分和它的边界并列开来：

站得住的事	边界
主要的一方 AI 爬虫都公开声明会按文档遵守 robots.txt	这是公开宣布的政策，不是技术保证：厂商可以随时修改文档（且确实修改过，参见 §4 关于 ChatGPT-User 的说明）
对任何遵守协议的代理来说，这份文件能毫无歧义地表达你的意图	意图不等于执行；不遵守协议或伪造身份的代理，无论文件写得多严谨都不会去读
关于「声明的策略」这件事，独立测量是存在的	Cloudflare 2025 年的扫描显示，被取样的域名中只有约 14% 的 robots.txt 文件里有针对 AI 爬虫的规则（Cloudflare, 2025-07-01）。也就是说，大多数站点根本没有就 AI 这件事表达过任何策略
主动声明合规的厂商，绝大多数都是一方运营方	第三方报道里也记录了大规模不遵守的案例：2024 年多家新闻媒体报道，某主要答案引擎从那些已经把它写进 Disallow 的站点上抓取内容（TechCrunch, 2024-07-02）；2025 年 Cloudflare 报告了另一只未公开身份的爬虫伪装成普通浏览器、轮换 IP 绕开 no-crawl 指令，影响范围覆盖数万个域名（Cloudflare, 2025-08-04）
真正的拦截在技术上是可行的	但那是网络层的事：WAF 规则、可验证 bot 白名单、请求签名等手段，不是 robots.txt 能办到的

具体到 Perplexity 一连串事件的细节，见 PerplexityBot；这里抽取的是可推及一般情况的通用结论。更宽的访问决策视角，见 AI 爬虫 §5。

写好 robots.txt 这件事仍然值得做，因为遵守协议的爬虫会去读它，而绝大多数一方 AI 爬虫都属于这一类，效果是实打实存在的。但要核实策略是否真的生效，那是网络层的事。这两层不要混为一谈：一旦混在一起，站点就可能在自以为受保护的同时，悄无声息地把流量交给了无视这份文件的爬虫。

6. 常见反模式

针对 AI 爬虫的 robots.txt 写错，绝大多数都落在四类失误里：优先级错和分组合并错、机制误用（把这份文件当强制执行、当成 meta 标签、或当成限速工具）、位置错，以及失效错。下面表里每一行都是一种「看起来对、其实失效」的写法。

反模式	看起来为什么对	为什么实际上失效
* 通配组里写 Disallow: /，再在各 bot 的具名分组里写 Allow:	「先给一个默认规则，再单独放开我信任的 bot」	每个具名 bot 只读取自己那一个分组（RFC 9309 §2.2.1）。* 分组里的规则永远到不了具名 bot：GPTBot 分组里那行 Allow: 并不会推翻 * 分组里的 Disallow: /，因为 * 分组对 GPTBot 完全不可见。所谓「合并」从一开始就没有发生
「为了不出现在 ChatGPT 里」而屏蔽 GPTBot	GPTBot 是 OpenAI 的爬虫	GPTBot 只用于训练。ChatGPT 搜索实际由 OAI-SearchBot（建索引）和 ChatGPT-User（用户触发）负责。这是典型的类别错位，拦下的并不是真正影响 ChatGPT 引用的那一只 bot，分类详见 AI 爬虫 §3
把 robots.txt 当成对恶意行为方的强制拦截	「我已经 Disallow 了，它就不能抓」	协议本质上是自愿性的；RFC 9309 §1 写明规则「不是一种访问授权」。伪造身份或不遵守协议的代理完全无视这份文件。强制拦截属于 WAF 或可验证 bot 白名单的范畴（见 AI 爬虫访问审计）
用 Crawl-delay: 给 AI 爬虫限速	「限速也是 robots.txt 的功能之一」	Crawl-delay: 并未写进 RFC 9309。各家是否遵守并不统一：Common Crawl 的 CCBot、Anthropic 的 Claude 系列爬虫公开声明遵守它；Google 则明确表示 Googlebot 会忽略它。在整个 AI 爬虫的群体里，可靠的限速手段只能放在网络层
在 robots.txt 里写 Noindex: 指令	「这是用来控制页面索引的」	Noindex 从来不是任何标准里的 robots.txt 指令。Google 已经在 2019-09-01 停止支持这条非官方的 Noindex: 写法（A note on unsupported rules in robots.txt）。控制索引的正确方式是 <meta name="robots" content="noindex"> 或 X-Robots-Tag HTTP 头
robots.txt 放在 /foo/robots.txt，或者子域名没有自己单独的一份	「文件在那儿，放在哪儿无所谓」	RFC 9309 §2.3 规定文件必须放在每个 host 的固定路径 /robots.txt。每个子域名、每种协议（http 与 https）都各自需要一份；非根路径上的文件会被直接忽略
写了一份 AI 爬虫白名单，从此不再回看	「只让我信任的 bot 通过」	AI 爬虫的名单 2023 到 2026 年从约 3 个具名 bot 涨到约 30 个。静态白名单会按默认把所有后来上线的新 bot 一并拒在门外，其中也包括那些一旦拦了就立刻丢掉引用的检索类爬虫
页面已经上线之后才把训练爬虫加进 Disallow	「现在我的内容就退出训练集了」	robots.txt 只面向未来。它无法回收已经被吸收进上一轮训练语料的内容。能用来「事后退出」的渠道是各家厂商各自公开的政策（退出申请表单、下架渠道等），不在 robots.txt 这份文件的能力范围里

针对 AI 爬虫的 robots.txt，最常见的写错都不出在协议语法上，而是出在分类或优先级上。语法本身很宽容，后果并不宽容。

7. 三个根目录文件，三种职责

AI 时代的发布基建里，最常见的一类划分错位是把三份根目录文件混作一谈：robots.txt、sitemap.xml、llms.txt。这三者的职责彼此不重合。

文件	它控制什么	它不做的事
robots.txt	访问控制：爬虫能否抓取某个路径（标准化为 RFC 9309）	不做策展、渲染、排名或强制拦截。是一次请求，不是一次授权
sitemap.xml	发现与完备：把站点上的所有内容列出来供引擎索引（见 Sitemap 与 IndexNow）	不做策展，不做授权，也不是质量信号；不是「精选清单」
llms.txt	策展与可读性：让 AI 优先读这几页内容，并以精简的 markdown 形式提供（见 llms.txt）	不授予或禁止访问；不是排名信号；不是发现文件

三份文件，三种职责，谁也替代不了谁。robots.txt 不是「AI 访问控制」，正如它当年不是「Google 访问控制」一样。它仍然是同一份文件，做着同一件事，只是面对的爬虫群体比当年大了，并且这层群体内部有了类别上的分化。变的是听众，不是这份文件的角色。

8. 这件事对 GEO 意味着什么，以及该怎么做

做到「能被抓」是必要的，但并不充分：robots.txt 决定的只是爬虫层访问这一关，能否最终被引用还要再过一关。文件不写，多数遵守协议的 AI 爬虫会按「没有限制」对待；文件写错，代价就可能是悄无声息地从 AI 答案里消失。

你的需求	从这里开始
按类别（训练 / 检索 / 用户触发）先把策略定好	AI 爬虫 §2：分类模型
把 robots.txt 的具体规则写出来	本条目 §3
拿到每家爬虫的产品名标识、IP 段和核验流程	GPTBot · ClaudeBot · PerplexityBot · Google-Extended · Applebot-Extended · OAI-SearchBot · ChatGPT-User
核实「现在真正抓到我站点的是谁」	AI 爬虫访问审计
给 AI 指明应该优先读哪些页	llms.txt
取回之后，让那一段内容能被原样引用	可引用性
把以上几件事串起来的整体方法	生成式引擎优化

策略写在 robots.txt 里，因为遵守协议的爬虫会读它；真正的拦截放在网络层，因为不遵守的不会被它拦。也别把两件事看反：被抓到只是一道入口，并不等于已经拿到了引用；它给你的是「具备被引用资格」，至于最终能不能被引用，是后一关要回答的问题。

参考资料

标准与规范：

• IETF — RFC 9309: Robots Exclusion Protocol
• Google Search Central — How Google Interprets the robots.txt Specification
• Google Search Central — A note on unsupported rules in robots.txt（2019 年的 Noindex: 停用）

各家爬虫文档：

• OpenAI — Overview of OpenAI Crawlers · Publishers and Developers FAQ
• Anthropic — Does Anthropic crawl data from the web, and how can site owners block the crawler?
• Perplexity — Perplexity Crawlers · How does Perplexity follow robots.txt?
• Google Search Central — Google’s common crawlers（含 Google-Extended）
• Microsoft Bing — Which crawlers does Bing use?
• Apple — About Applebot
• Common Crawl — CCBot

独立测量与报道：

• Cloudflare — From Googlebot to GPTBot: who’s crawling your site in 2025
• Cloudflare — Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives
• TechCrunch — News outlets are accusing Perplexity of plagiarism and unethical web scraping
• Search Engine Land — Anthropic clarifies how Claude bots crawl sites and how to block them