robots.txt 的四个默认值：404 全开、5xx 全禁、最长匹配、合规靠自愿

直接答案

「我写了 robots.txt，所以那些内容不会被抓」这句话里藏了四件事，它们由四段不同的机制负责，任何一段出错都不会报错：

层	要回答的问题	靠什么	出错时的表现
① 声明	我允许谁抓哪些路径？	robots.txt 里的组与规则	规则写给了不存在的爬虫名
② 故障	文件取不到时怎么办？	HTTP 状态码	404 等于全开，5xx 等于全禁
③ 匹配	两条规则冲突时谁赢？	最长匹配（最多 octets）	以为先写的赢，实际相反
④ 执行	谁真的会停下来？	对方的自愿 + 你的边缘规则	只有守规矩的爬虫停，日志里看不出区别

最常见的错误是把 ① 当成全部：规则写得很细，却从没看过这份文件在故障时是「全开」还是「全禁」，也没确认过冲突规则的实际判定。robots.txt 是一份请求，不是一道门。 RFC 9309 在引言里把这句话写得很直接：

These rules are not a form of access authorization.

本文以 RFC 9309（IETF Standards Track，2022-09）为规范依据，以 Cloudflare AI Crawl Control 的公开文档为「观测与执行」的实现样本。它不是「怎么拦住 AI 爬虫」的产品评测，也不假设你用哪家 CDN；不同厂商的控制台口径不同，但要问的问题一样。

一、文件本身：顶层、全小写、UTF-8

规范对「文件放在哪」的要求是硬的，四条都可能被静态站点配置搞错：

• 只能在顶层：URI 是 scheme:[//authority]/robots.txt，规则「MUST be accessible in a file named “/robots.txt” (all lowercase) in the top-level path of the service」。/blog/robots.txt 不是给 /blog/ 用的，爬虫不会去读。
• 文件名全小写：Robots.txt 与 robots.txt 在多数服务器上是两个路径。
• UTF-8 + text/plain：两条都是 MUST。
• 按主机算：规则的作用域是 authority（HTTP 里就是主机名）。www.example.com 与 blog.example.com 各要一份；把主域的文件当成子域的，是常见误判。

这里有一个反直觉的推论：robots.txt 只对「同主机的路径」说话，对「内容被搬到别处」没有约束力。别人把你的文章转载到自己的域名下，你的文件管不到他那边——这是协议的作用域，不是配置问题（编辑判断）。

二、404 与 5xx：两个方向相反的默认值

这是本文最有价值的一张表。文件取不到时，爬虫不是「当作没写」，而是按状态码分成两类完全相反的行为：

取文件的结果	规范用词	爬虫的行为	对你的实际含义
200 且可解析	Successful Access	MUST 遵守可解析的规则	你写的规则生效
400–499（含 404）	Unavailable	MAY access any resources	等于全开：什么都没挡
500–599 或网络错误	Unreachable	MUST assume complete disallow	等于全禁：连首页都别抓
连续重定向超过 5 跳	视为 unavailable	MAY 当作不可用	等于全开

原文对这两类的措辞差别值得逐字读：

If a server status code indicates that the robots.txt file is unavailable to the crawler, then the crawler MAY access any resources on the server.

If the robots.txt file is unreachable due to server or network errors, this means the robots.txt file is undefined and the crawler MUST assume complete disallow.

由此得到三个容易踩的坑：

坑一：用 WAF 拦掉 /robots.txt，等于把门全开。 如果你的边缘规则对「可疑请求」一律返回 403，而这条规则恰好也命中了 /robots.txt，爬虫拿到的就是 4xx——按规范它可以抓全站。「拦得更严」在这里反而变成「许可更宽」。

坑二：把 500 当临时挡板。 有人把 robots.txt 换成 500，想「先全禁几天」。规范给了两个反向的时间条款：不可达持续「a reasonably long period of time (for example, 30 days)」后，爬虫 MAY 改按「不可用」处理（也就是全开），或继续用缓存；而缓存的常规上限是：「SHOULD NOT use the cached version for more than 24 hours, unless the robots.txt file is unreachable.」——注意这个 unless：恰恰在不可达时，旧缓存可以继续生效。于是你看到的是一个 500，爬虫看到的是几天前那份「全开」的旧文件。

坑三：把重定向当无事。 规范要求「SHOULD follow at least five consecutive redirects, even across authorities」，5 跳之内必须取到、解析，并按最初的主机名应用规则；超过 5 跳，爬虫 MAY 认定不可用。http→https、加 www、末尾斜杠，任何一条链只要套娃超过 5 次，你的规则就作废。

解析出错的处理是另一条：「Crawlers MUST try to parse each line」——不是「有一行错就整份作废」，而是逐行能解析的都算。所以一份半坏的文件的危险在于：你以为全禁，实际只有一部分生效。

三、匹配：最长匹配赢，不是先写先赢

规则冲突时的判定，规范只有一句，但它推翻了大多数人的直觉：

The most specific match found MUST be used. The most specific match is the match that has the most octets.

「最具体」＝匹配到的字节数最多，与文件里的先后顺序无关。RFC 第 5.2 节的示例正是这个结构：Allow: /example/page/ 写在前面，Disallow: /example/page/disallowed.gif 写在后面，对 example.com/example/page/… 这个 URI，规范写明后者「MUST be used」——因为 28 octets 比 14 octets 更长。（该例的 URI 在原文里写作 disallow.gif、规则写作 disallowed.gif，显系原文笔误，不影响「最长者胜」的结论。）

下面这张表是我按同一套规则做的推演（规则集是示例，不是原文）：

User-agent: *
Disallow: /private/
Allow: /private/blog/
Disallow: /private/blog/draft-

请求路径	命中的规则	判定	为什么
/private/	Disallow: /private/	禁止	唯一匹配
/private/blog/	Allow: /private/blog/（更长）	允许	14 > 9 octets
/private/blog/draft-1	Disallow: /private/blog/draft-（更长）	禁止	20 > 14 octets，与 Allow 写在前无关
/public/	无	允许	无匹配即允许

同一节里还有几条常被忽略的细则，每一条都能让「看起来对」的规则失效：

• 组外规则被忽略：「The crawler SHOULD ignore “disallow” and “allow” rules that are not in any group (for example, any rule that precedes the first user-agent line).」文件开头直接写 Disallow: /admin/，等于没写。
• 空组等于全允许：「The last group may have no rules, which means it implicitly allows everything.」只写一行 User-agent: GPTBot 而不给规则，不是「禁掉它」，是「对它全开」。
• 同名组要合并：多个组匹配同一个 product token 时，「the matching groups’ rules MUST be combined into one group」，不是取第一个。
• 兜底看 *：没有匹配组时 MUST 遵守 User-agent: *；连 * 都没有，「no rules apply」（即全允许）。
• 等价时 allow 胜：「If an “allow” rule and a “disallow” rule are equivalent, then the “allow” rule SHOULD be used.」——Allow: /x 与 Disallow: /x 同时存在，结果是允许。
• /robots.txt 自身隐式允许：你没法用 robots.txt 挡住 robots.txt。
• 大小写不对称：找组时 MUST 大小写不敏感（gptbot 与 GPTBot 同组）；匹配路径时 SHOULD 大小写敏感。Disallow: /Private/ 挡不住 /private/。
• 非 ASCII 要百分号编码：URI 与规则里超出 ASCII 的字节「MUST be percent-encoded … prior to comparison」。中文路径直接写汉字，多数实现比对的是编码后的形式，等于没匹配上。
• 特殊字符只有三个是 MUST：#（注释）、$（匹配到结尾）、*（0 个或多个任意字符）。把 ? 或正则当通配符用，不在规范保证范围内。

四、500 KiB 是解析下限，不是文件上限

这条被误读得最彻底：

The parsing limit MUST be at least 500 kibibytes [KiB].

它是下限：爬虫至少要能解析 500 KiB，不能更少。它不是「文件不能超过 500 KiB」的上限，规范也没承诺超过这个量的部分一定被读到。对一人公司的实际含义很朴素：文件越大，越可能有一部分只有部分实现读得到。一个内容站正常只需要几十行，如果长到几百 KB，通常是规则生成脚本失控，而不是「写得更细」。

五、谁来执行：合规是自愿的

规范的定性在第一句就写完了，Cloudflare 的术语表也用同一句话解释 robots.txt：「Compliance is voluntary.」 一家边缘厂商的概览页把能力写成三条可核对的事——看「which AI services are accessing your content」、按爬虫设置 allow／block、以及「Monitor robots.txt compliance - Track which crawlers follow your directives and create enforcement rules」。

把它当「观测 + 执行」的实现样本时，有四个细节决定你看到的东西是否可信：

1. 识别方式决定覆盖率。免费版是按 user agent 字符串识别 AI 爬虫，官方措辞是「identifies AI crawlers based on their user agent strings. This enables AI Crawl Control to detect well-known, self-identifying AI crawlers.」；更彻底的识别要用付费版的 Bot Management 检测字段。也就是说：免费档看到的是「愿意报名字的爬虫」（推论：伪装 UA 即可绕过，属编辑判断）。
2. 拦截是另一套规则。在控制台里 block 一个爬虫，系统会在你的 zone 上创建或更新一条 WAF 自定义规则来执行；想加路径例外得直接去改 WAF。robots.txt 与 WAF 是两条独立的线：前者是声明，后者才是执行。
3. 响应码是你选出来的信号。付费版可自定义拦截响应：403 Forbidden（不想让你访问）或 402 Payment Required（要付费才能访问），还能写响应体。注意官方的一个约束：如果 WAF 规则被手工改成 403／402 以外的码，控制台会无法执行你所选的响应（下拉框会显示为空）。
4. 「违规」是按当前规则回算的。违规表比对的是「你现在的 robots.txt」与「过去抓取请求」：新增一条 Disallow 后，过去对该路径的合法请求会全部显示成违规。所以这个数字不能当「对方一直在违反」的证据，它衡量的是「现在的规则与历史请求的差集」。

还有一条与「公开」有关的事实，来自规范的安全考虑一节，值得每个写规则的人读一遍：

Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable.

把 /internal-2027-roadmap/ 写进 Disallow，等于给所有人和所有爬虫一份「这里可能有东西」的目录。对真的不能公开的路径，正确做法是访问控制（HTTP 认证之类），不是写进这份公开文件。

顺带一个监控口径的坑：Cloudflare 的 robots.txt 可用性表把 400 以上全部算作 unsuccessful。这个口径把 404（全开）与 500（全禁）合并成一列，所以面板上「不成功」不等于「已挡住」——两者对爬虫的含义正好相反。

六、上线前的 11 项检查

#	检查项	怎么验	不合格的后果
1	/robots.txt 返回 200	curl -sSI https://<域名>/robots.txt	4xx 全开
2	没有被 WAF／鉴权拦成 403	同上，看状态码与响应体	4xx 全开，且你以为拦住了
3	Content-Type 是 text/plain、编码 UTF-8	curl -sSI 看头	解析可能失败
4	文件名与路径全小写、在顶层	直接访问确认	规则不适用
5	每个子域各有一份	逐个 curl	子域裸奔
6	没有组外规则（首行就是 user-agent）	读文件	规则被忽略
7	User-agent: * 兜底组存在且有规则	读文件	未命中时全允许
8	冲突规则按最长匹配复核过	按上表逐条推演	该禁的没禁、该放的没放
9	非 ASCII 路径写成百分号编码、大小写与真实 URL 一致	抓一条真实 URL 对照	静默不匹配
10	Sitemap: 指向的文件真的 200	curl 那一行里的 URL	提交了死链
11	改完规则后有观测手段	看边缘日志／违规表	改没改对全靠猜

第 10 项值得单独说：Sitemap 属于规范的「Other Records」——爬虫 MAY 解释，且「Parsing of other records MUST NOT interfere with the parsing of explicitly defined records」。它是附注，不是许可；能提交不等于会被收录。本站当前的 robots.txt 就是三行结构（User-agent: *、Allow: /、Sitemap: https://aopc.ai/sitemap-index.xml），实测文件本身 200、所指向的 sitemap 索引也是 200——这是第 1 项与第 10 项同时通过的样子。

七、四种常见误读

误读一：「写了 Disallow，就等于挡住了。」 规范原文是「not a form of access authorization」，合规自愿。robots.txt 只能约束愿意守规矩的爬虫；要真拦，得靠边缘规则或访问控制，而那是另一套配置、另一套日志。

误读二：「robots.txt 挂了，最坏也就是没规则。」 没有「没规则」这个状态。404 是全开，5xx 是全禁，两个方向相反；而 5xx 持续约 30 天后还可能被改判为「不可用」（全开），缓存条款在不可达时反而放宽。故障不是中性的。

误读三：「规则从上往下匹配，先写的优先。」 是「最多 octets 的那条赢」。而且等价时 allow 胜、无匹配即允许、/robots.txt 隐式允许——四条合起来，与「白名单／黑名单顺序执行」的直觉完全不同。

误读四：「500 KiB 是文件大小上限。」 它是解析能力的下限，不是上限。规范只承诺「至少能读 500 KiB」，没承诺超过的部分会被读；把文件写大不会让规则更强。

八、本周就能做的五件事

1. 把 /robots.txt 的状态码抄下来：200、4xx 还是 5xx。4xx 与 5xx 分别对应「全开」和「全禁」，先知道自己在哪一边。
2. 检查边缘规则有没有误伤这份文件：任何对全站生效的 403／挑战页，都应该给 /robots.txt 留例外。
3. 把文件读一遍，找组外规则：第一个 user-agent 之前的所有行都不生效；只有一个 User-agent: GPTBot 而没有规则，等于对它全开。
4. 拿三条真实 URL 手工推演一次最长匹配：一条该禁、一条该放、一条边界。推演结果与预期不符的，就是现在正在漏的地方。
5. 给「改规则」定一个观测动作：改完 24 小时内不要假设所有爬虫都看到了新版本（缓存上限是 24 小时，不可达时还可能更久），并且记住违规表是按当前规则回算的。

如果只能记住一件事：规则决定「你请求什么」，状态码决定「对方默认怎么做」，匹配规则决定「两条冲突时谁赢」——三者任一错，另外两个都白写。

---

边界说明：本文的规范性陈述全部来自 RFC 9309（2026-10-28 访问，HTTP 200，25 265 B），实现侧样本全部来自 Cloudflare AI Crawl Control 的三个公开页面（同日访问，均 HTTP 200）。不写「写了 robots.txt 就挡住了」、「按顺序匹配／Disallow 优先」、「文件不能超过 500 KiB」、「开了某个产品就能拦住所有 AI 爬虫」，也不写任何「AI 爬虫占比」「拦住了多少」的数字。文中三处为编辑判断并已就地标注：转载不受本站文件约束；免费版按 UA 识别意味着伪装可绕过；「面板不成功 ≠ 已挡住」。第三节目录下的示例规则集与四行判定表是按规范推演的示例，不是 RFC 原文；第五节的 402／403 与 WAF 关系仅描述 Cloudflare 的实现，不代表其它厂商。本站 robots.txt 的两条实测（文件 200、sitemap 索引 200）为 2026-10-28 当日结果。

来源

以下页面均于 2026-10-28 逐条访问并验证为 HTTP 200；字节数为当日抓取的实际大小。

1. RFC 9309: Robots Exclusion Protocol核查于 2026/10/28（200，25 265 B，纯文本；IETF Standards Track，2022-09，作者含 M. Koster、G. Illyes、H. Zeller、L. Sassman）：规则「are not a form of access authorization」；URI 为 scheme:[//authority]/robots.txt、文件必须全小写、位于顶层、UTF-8、text/plain；400–499 属 Unavailable、爬虫 MAY 访问任意资源，500–599 与网络错误属 Unreachable、MUST 假定全禁，持续约 30 天 MAY 改判为不可用或继续用缓存；缓存 SHOULD NOT 超过 24 小时「unless the robots.txt file is unreachable」；重定向 SHOULD 至少跟 5 跳、5 跳内 MUST 按最初 authority 解析、超过可视为不可用；解析错误须逐行尽力解析；解析上限 MUST 至少 500 KiB；匹配 MUST 从路径第一个 octet 开始、最具体者胜且「most specific … has the most octets」、等价时 allow SHOULD 胜、无匹配即允许、/robots.txt 隐式允许、路径 SHOULD 大小写敏感；组外规则 SHOULD 被忽略、同名组 MUST 合并、无匹配组用 *、都没有则不适用规则、最后一个空组隐式全允许；特殊字符 #／$／* 为 MUST 支持；非 ASCII 与保留字符 MUST 先百分号编码；安全考虑写明它不是内容安全措施的替代、且「Listing paths in the robots.txt file exposes them publicly」；Sitemap 属 Other Records，解析不得干扰显式记录。
2. AI Crawl Control · Overview核查于 2026/10/28（200，116 004 B；页面标注 Last updated Aug 14, 2026）：原名 AI Audit、「Available on all plans」；能力为看清哪些 AI 服务在访问、按爬虫设 allow／block、Monitor robots.txt compliance - Track which crawlers follow your directives and create enforcement rules、按次收费（页面标注 private beta）、零配置部署。
3. Directives（Track robots.txt）核查于 2026/10/28（200，114 731 B；Last updated Apr 23, 2026）：术语表把 robots.txt 定义为「Compliance is voluntary」；可用性表把「Successful」定义为状态码低于 400（含 200 与重定向）、「Unsuccessful」为 400 及以上；违规表比对的是当前指令与过去请求，新增 Disallow 会让过去对该路径的请求显示为违规；可开启 Managed robots.txt 由厂商代管并写入 Content Signals Policy；另提供 Agent Readiness 扫描（含 robots.txt 配置项）。
4. Manage AI crawlers核查于 2026/10/28（200，127 871 B；Last updated Jul 28, 2026）：免费版按 user agent 字符串识别 AI 爬虫、付费版可用 Bot Management 检测字段；拦截会在 zone 上创建或更新 WAF 自定义规则，路径例外需直接改 WAF；付费版可自定义拦截响应为 403 Forbidden 或 402 Payment Required 并可写响应体，若 WAF 规则被改成其它码则无法执行所选响应；表格含 Robots.txt violations 列。