robots.txt:抓取规则与边界

robots.txt:抓取规则与边界

robots.txt 是互联网基础设施中最基础也最常被误解的文件之一。在 AI 爬虫大规模涌现之前,它的角色相对简单:向 Googlebot 等少数爬虫声明站点的抓取偏好。然而,随着 AI 生态中爬虫数量的激增和用途的分化,robots.txt 的重要性与复杂性都显著提升。理解它的机制、局限和正确用法,是制定有效 GEO 策略的技术基础。

robots.txt 遵循 RFC 9309,用于向爬虫声明站点的抓取规则,由爬虫自行选择是否遵守,不能作为访问控制措施。遵守协议的 AI 爬虫会依照各自文档跳过站点声明不希望抓取的路径;不遵守协议或伪造身份的爬虫则不会。应按训练、检索、用户触发三类制定策略,并通过网络层核实策略是否真正生效。

关键洞察:robots.txt 的核心价值在于「声明」而非「强制」。它向遵守协议的爬虫清晰表达站点的访问偏好,但无法阻止不遵守协议或伪造身份的爬虫。真正的访问控制必须依靠网络层措施(WAF、IP 白名单)来实现。

robots.txt 的本质:一份声明,不是访问控制

robots.txt 是站点根目录下(/robots.txt)的一份纯文本文件,用于声明哪些路径不希望爬虫抓取。它采用的机器人排除协议(Robots Exclusion Protocol)诞生于现代互联网形成之前,由 Martijn Koster 于 1994 年提出,随后作为业界约定沿用了大约 25 年,直到 2022 年 9 月才由 IETF 正式制定为标准 RFC 9309。

GEO Wiki 工作定义:robots.txt 是放在 /robots.txt 的一份 UTF-8 纯文本文件,根据用户代理标识区分爬虫,请求它们跳过特定路径,所列规则不具强制性。它以标准格式声明站点希望爬虫如何访问内容,不是访问控制措施。

RFC 9309 在讨论 AI 之前就已明确说明:规则「不是一种访问授权」,协议「不能替代内容安全方面的有效措施」(RFC 9309 §1)。因此,站点通过 robots.txt 声明访问规则,并不等于已经实施访问限制。

对 GEO 而言,robots.txt 本身没有改变,变化的是需要处理的爬虫群体。AI 爬虫出现之前,制定策略时通常只需决定是否屏蔽 Googlebot。如今,同一份文件要面对约 30 个有公开标识的爬虫,它们分为训练、检索、用户触发三类,屏蔽后产生的后果彼此相反(具体分类见 AI 爬虫 §2)。协议没有改变,但适用对象变多,也带来了新的配置错误。

协议如何工作

robots.txt 文件由若干分组构成,每个分组都针对一个或多个用户代理设置一组规则。文件位于站点根目录,路径匹配语法也很简单。

文件本身:它是 UTF-8 纯文本,独立适用于每个主机,必须放在固定路径 /robots.txt,并返回 2xx 状态码。如果该文件返回 4xx 响应,爬虫会认为站点「没有声明任何规则」,因而可以抓取所有路径(RFC 9309 §2.3.1.3)。对于 5xx 响应,各家爬虫通常处理得更保守:可能选择重试,也可能在故障期间将整站视为完全禁止抓取。

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

分组选择最容易出错:每个爬虫只读取与自己产品标识相符且最具体的分组(RFC 9309 §2.2.1),其它分组的规则不会与之合并。即使文件中存在 * 通用分组,只要该爬虫另有具名分组,* 分组就不会对它生效。

路径匹配采用最长匹配优先。当 AllowDisallow 的路径长度相同且规则冲突时,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/ 外不会抓取其它路径。其它所有爬虫读取 * 分组,因此只跳过 /private/* 分组的规则不会用于 GPTBot,即使它看起来像一条合理的默认规则;GPTBot 已经有具名分组,只会读取该分组。下文的三种策略配置都遵循这项规则,常见的错误配置也由此产生。

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

若要在 robots.txt 中表达按训练、检索、用户触发三类划分的访问策略,需要为每一类设置具名用户代理分组。以下是三种最简配置,每段大约六行。

只退出训练:保留 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 控制的是已抓取内容是否可用于训练,不控制 Googlebot 是否抓取,因此它属于上面的「退出训练」组,而不是本组。

全部放行,但逐一具名声明

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

这种配置的实际效果与空的 robots.txt 完全相同,但明确声明仍有两个作用:一是记录访问规则,便于内部评审和审计工具读取;二是即使后续配置中误在 * 分组加入 Disallow: /,具名分组仍会优先适用,确保相应爬虫可以访问。

分组不会合并这一点需要特别注意:每个具名爬虫只读取自己的分组。最常见的错误是在 * 分组中写入 Disallow: /,同时又在各爬虫的具名分组中加入一行 Allow:。爬虫不会同时计算两组规则,因此这种配置不能产生预期效果。完整的纠正配置见反模式一节。

各厂商公开的用户代理标识、IP 段和核验流程可查阅以下条目:GPTBot、ClaudeBot、PerplexityBot、Google-Extended、Applebot-Extended、OAI-SearchBot、ChatGPT-User。如需核实当前有哪些爬虫真正访问了站点,包括直接从日志中提取爬虫名单,见 AI 爬虫访问审计

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

厂商 涉及的用户代理标识 公开的 robots.txt 遵守政策 备注
OpenAI GPTBot · OAI-SearchBot · ChatGPT-User GPTBot 和 OAI-SearchBot 按文档遵守 robots.txt。截至 2025 年底,OpenAI 的爬虫文档将 ChatGPT-User 的说明调整为:「因为这一类访问由用户触发,robots.txt 规则可能不适用」 2025 年 12 月改版的文档明确写出了用户触发类访问的例外
Anthropic ClaudeBot · Claude-SearchBot · Claude-User 三个爬虫都按文档遵守 robots.txt。2025 年的文档将它们分为训练、检索、用户触发三类,并为每个爬虫提供了可直接使用的 Disallow 配置 Anthropic 明确说明,除了标准的 Disallow: 规则,还会遵守非标准的 Crawl-delay: 扩展
Perplexity PerplexityBot · Perplexity-User PerplexityBot 遵守 robots.txt;如果禁止它抓取,页面正文就不会被收录。Perplexity-User 由用户发起,Perplexity 对此说明为「robots.txt 的限制通常不适用」 自 2024 年起,该厂商一直在官方说明中保留用户触发类访问的例外
Google Googlebot · Google-Extended Googlebot 遵守 robots.txt。Google-Extended 是专用于将内容排除在训练数据之外的标识:它控制已抓取内容能否用于训练 Google 的生成式 AI 模型,不控制 Googlebot 是否抓取 屏蔽 Googlebot 会使内容同时退出搜索和 AI Overviews;Google 尚未提供独立的 AIO 退出标识
Apple Applebot · Applebot-Extended 两个爬虫都遵守 robots.txt。Applebot-Extended 是用于退出 Apple Intelligence 等生成式 AI 训练数据的标识;Applebot 则继续服务 Spotlight、Siri 和 Safari 单独禁止 Applebot-Extended,同时允许 Applebot 访问,可以保留内容在 Spotlight 与 Siri 中的可见度
Microsoft(Bing) Bingbot 遵守 robots.txt;同时为 Bing 搜索与 Bing Copilot 提供检索 截至 2026 年 5 月,未公开过单独的 AI 训练退出令牌,这一点与 Google、Apple 不同
Common Crawl CCBot 遵守 robots.txt,也遵守非标准的 Crawl-delay: 扩展 Common Crawl 的数据集会间接用于许多第三方 AI 训练语料;禁止 CCBot 也会切断这一间接来源

需要说明的是,「用户触发类爬虫」属于各厂商公开的设计选择,并非缺陷。ChatGPT-User、Claude-User、Perplexity-User 都被各自厂商描述为「由用户发起」,且「robots.txt 限制通常不适用」。它们给出的理由一致:真实用户针对某个具体 URL 发起的获取请求,更接近受用户委托访问页面,而不是爬虫自主抓取。OpenAI 在 2025 年底改版的文档中对这种设计说明得最明确;Perplexity 的帮助页自 2024 年起也一直采用相同说法。因此,声称「robots.txt 覆盖所有 AI 访问」并不准确,用户触发的获取请求就是直接反例。

robots.txt 的声明与网络层的实际拦截

RFC 9309 并未将 robots.txt 视为访问控制。标准开篇就明确区分了站点声明的规则与实际实施访问限制的技术措施。

RFC 9309 的免责声明。标准 §1 明确写道:「robots.txt 文件里的规则不是一种访问授权」。后文又补充:「本文档不能替代有效的内容安全措施,凡是不希望被访问的信息都应当被妥善保护」。这两项表述均来自 IETF 的正式标准(RFC 9309),并非事后解读。

用户代理字段只是爬虫自行报告的标识,不能用于核验身份。日志中出现 GPTBot 并不能证明 OpenAI 确实抓取了这个页面。任何爬虫都可以伪造用户代理字段,从而绕过依据该字段编写的规则;不遵守协议的爬虫甚至不会读取 robots.txt。要核验身份,需要依据运营方公开的 IP 段,再配合经正向确认的反向 DNS(forward-confirmed rDNS)。所有主要 AI 爬虫运营方都为此公开了 IP 列表。具体流程见 AI 爬虫访问审计

实际遵守程度的测量结果。公开政策与实测观察往往存在差异。下表分别列出已有证据支持的结论及其适用边界:

已有证据支持的结论 适用边界
主要厂商直接运营的 AI 爬虫大多公开声明会按文档遵守 robots.txt 这只是公开政策,并非技术保证:厂商可以随时修改文档,而且确实修改过,参见上文关于 ChatGPT-User 的说明
只要爬虫遵守协议,robots.txt 就能清楚声明站点的访问规则 声明规则不等于已经实施限制;无论文件写得多严谨,不遵守协议或伪造身份的爬虫都不会读取它
已有独立研究统计了站点针对 AI 爬虫设置规则的情况 Cloudflare 2025 年的扫描显示,抽样域名中只有约 14% 的 robots.txt 文件包含针对 AI 爬虫的规则(Cloudflare, 2025-07-01)。也就是说,大多数站点尚未针对 AI 访问声明任何策略

Perplexity 相关事件的详细经过见 PerplexityBot。这些事件反映出的普遍问题是,公开政策不能替代实际核验。关于更完整的访问决策,见 AI 爬虫 §5

正确配置 robots.txt 仍然有必要,因为遵守协议的爬虫会读取它,而绝大多数由厂商直接运营的 AI 爬虫都属于这一类。至于策略是否真正生效,则需要通过网络层核实。两者不可混淆,否则站点可能误以为访问已经受限,实际上仍有爬虫无视 robots.txt 并抓取内容。

常见反模式

反模式 看似合理的原因 实际失效的原因
* 通配组里写 Disallow: /,再在各爬虫的具名分组里写 Allow: 「先设置默认规则,再单独允许可信爬虫访问」 每个具名爬虫只读取自己的分组(RFC 9309 §2.2.1)。对于 GPTBot,* 分组根本不会被读取;GPTBot 分组中的 Allow: 也不会与 * 分组中的 Disallow: / 合并,因为爬虫不会合并这两个分组的规则
「为了不出现在 ChatGPT 里」而屏蔽 GPTBot GPTBot 是 OpenAI 的爬虫 GPTBot 只用于训练。ChatGPT 搜索实际由 OAI-SearchBot(建索引)和 ChatGPT-User(用户触发)负责。这是典型的爬虫分类错误,屏蔽的并非真正影响 ChatGPT 引用的爬虫,分类详见 AI 爬虫 §3
把 robots.txt 当作强制拦截恶意爬虫的措施 「我已经 Disallow 了,它就不能抓」 协议本质上是自愿性的;RFC 9309 §1 写明规则「不是一种访问授权」。伪造身份或不遵守协议的爬虫会完全无视这份文件。强制拦截需要使用 WAF 或可验证爬虫白名单(见 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 规定,每个主机都必须在固定路径 /robots.txt 提供这份文件。每个子域名、每种协议(http 与 https)都需要单独配置;非根路径中的文件会被直接忽略
配置一份 AI 爬虫白名单,此后不再更新 「只允许我信任的爬虫访问」 从 2023 年到 2026 年,AI 爬虫名单已从约 3 个具名爬虫增至约 30 个。静态白名单默认拒绝所有后来新增的爬虫,其中也包括一旦被屏蔽就会立即失去引用机会的检索类爬虫
页面上线后才将训练爬虫加入 Disallow 「现在我的内容就退出训练集了」 robots.txt 只约束未来的抓取,无法撤回已经纳入上一轮训练语料的内容。要在事后退出,只能使用各厂商公开的渠道,例如退出申请表单和下架渠道;robots.txt 无法处理

面向 AI 爬虫配置 robots.txt 时,最常见的问题不在协议语法,而在爬虫分类和分组优先级。协议语法的容错度较高,但配置错误会产生直接后果。

三个根目录文件,三种职责

文件 主要用途 不具备的功能
robots.txt 声明访问策略:说明哪些路径不希望爬虫抓取,遵循 RFC 9309 不负责内容筛选、渲染、排名或强制拦截。它只向爬虫声明规则,不授予访问权限
sitemap.xml 帮助发现并完整收录内容:列出站点内容供引擎索引(见 Sitemap 与 IndexNow 不筛选内容,不授予访问权限,也不构成质量信号;它不是精选清单
llms.txt 筛选内容并提高可读性:建议 AI 优先读取特定页面,并以精简的 markdown 形式提供内容(见 llms.txt 不授予或禁止访问,不构成排名信号,也不用于发现内容

三份文件职责不同,不能相互替代。robots.txt 不是强制性的「AI 访问控制」,正如它过去也不是强制性的「Google 访问控制」。文件的功能没有改变,但如今面对的爬虫数量更多,而且爬虫类型已有明显分化。

这件事对 GEO 意味着什么,以及该怎么做

网页能够被抓取是必要条件,但并不充分:robots.txt 只影响爬虫能否访问,内容最终是否被引用还取决于后续环节。未配置 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 中,因为遵守协议的爬虫会读取它;真正的拦截则应由网络层执行,因为不遵守协议的爬虫不会受 robots.txt 约束。还需注意,内容能被抓取只代表引擎可以读取并评估这份内容,并不意味着它必然获得引用;是否最终被引用,还取决于后续处理。

中国企业配置 robots.txt 的特别考量

对于面向中国市场的企业,robots.txt 的配置需要考虑以下几个额外因素:

首先,百度爬虫的政策相对明确。百度爬虫遵守 robots.txt,且与 Googlebot 类似,同时服务于搜索和 AI 回答功能。屏蔽百度爬虫会导致内容同时退出搜索和 AI 可见度,应谨慎操作。

其次,国内 AI 引擎如文心一言、通义千问、豆包等的爬虫政策透明度较低。建议通过服务器日志分析识别主要爬虫来源,并参考各厂商官方文档的最新说明。目前这些引擎大多使用标准的浏览器用户代理,难以通过 UA 字符串直接识别。

第三,微信搜一搜和小红书等平台的爬虫策略尚未公开。这些平台的 AI 功能可能使用不同的抓取机制,建议关注各平台的官方文档更新。

第四,国内企业应特别注意网络层防护。由于 robots.txt 的约束力有限,建议配合 CDN 或 WAF 实施爬虫访问控制,特别是针对高频抓取和可疑 IP 段的拦截。Cloudflare、阿里云 CDN、腾讯云 CDN 等国内可用的 CDN 服务都提供爬虫防护功能。

第五,跨国企业应注意 robots.txt 的多域名配置。如果企业在多个子域名或不同协议(http/https)下运营,每个主机都需要单独配置 robots.txt 文件。一份 robots.txt 不能跨域名共享。

常见问题解答

robots.txt 真的能拦住 AI 爬虫吗?

robots.txt 只是向爬虫声明规则,是否遵守由爬虫自行决定,本身不会强制执行。RFC 9309 已明确说明,文件里的规则「不是一种访问授权」。遵守协议的 AI 爬虫(GPTBot、ClaudeBot、PerplexityBot、Google-Extended、Applebot-Extended、CCBot)会依照各自公开的说明处理 robots.txt;不遵守协议或伪造身份的爬虫则不会。要真正拦截这些爬虫,需要使用网络层措施(WAF 规则、可验证爬虫白名单),robots.txt 无法做到。

屏蔽 GPTBot 会不会让我从 ChatGPT 搜索里消失?

不会。这是最常见的爬虫分类错误。GPTBot 只用于训练。ChatGPT 搜索的实时答案实际由 OAI-SearchBot(建索引)和 ChatGPT-User(用户触发获取)负责。屏蔽 GPTBot 只会阻止你的内容进入下一轮模型权重,不会影响 ChatGPT 搜索引用内容。各爬虫分别承担什么职能,以及为何屏蔽不同爬虫会产生完全相反的后果,详见 AI 爬虫

为什么 User-agent: * 加上各爬虫的 Allow:,什么都没放开?

因为 RFC 9309 §2.2.1 规定,每个爬虫只读取与自己产品标识最相符的那一个分组,其它分组的规则不会与之合并。所以在「User-agent: * Disallow: /」之后再写一个「User-agent: GPTBot Allow: /blog/」分组,GPTBot 只会读取自己的分组:它只能抓取 /blog/,无法抓取其它路径。* 分组的规则不会用于 GPTBot。这是 robots.txt 最常见的配置错误之一,而且文件本身不会报错。

Crawl-delay: 是 robots.txt 的标准指令吗?

不是标准指令。Crawl-delay: 并未被 RFC 9309 正式收录。各家是否遵守因厂商而异,并不统一:Common Crawl 的 CCBot 与 Anthropic 的 Claude 系列爬虫公开声明遵守它;Google 则明确表示 Googlebot 会忽略它。既然 AI 爬虫整体的遵守程度参差不齐,真正可靠的限速手段只能放在网络层,不能寄望于 Crawl-delay:

robots.txt 能把我的内容从已经训练过的模型里删掉吗?

做不到。robots.txt 只能约束未来的抓取请求,让爬虫今后访问时跳过某些路径;对于已被抓取并纳入上一轮训练语料的内容,robots.txt 无法将其撤回。如果某个页面在你将训练爬虫加入 Disallow 之前就已上线并被抓取,要从模型中移除相关内容,只能使用各厂商公开的退出渠道(例如退出申请表单)。这取决于各厂商的政策,robots.txt 无法处理。

延伸阅读

常见问题

如何开始GEO优化?

1) 审计现有内容可见度 2) 添加结构化标记 3) 优化品牌提及 4) 创建可引用内容 5) 监控AI推荐数据。建议从基础知识学习开始,逐步实施。

GEO优化的ROI如何衡量?

GEO效果可通过:AI推荐提及次数、零点击搜索份额、品牌搜索量增长、内容引用率等指标衡量。建议建立基线数据并定期追踪。

GEO优化的时间周期?

GEO效果通常需要3-6个月才能显著体现。结构化标记即时生效,但品牌提及和实体识别需要时间积累。建议持续优化并定期评估。

达摩

晓名 AI・GEO CTO & 创始人,专注生成式引擎优化实战

需要 GEO 优化?

立即联系我们,获取免费诊断报告。

获取免费诊断 →