robots.txt 抓取：规则、禁止项与获取失败

页面返回 HTTP 200，并不能决定是否可以依据 robots.txt 抓取。服务器可能交付一份被其已发布爬虫规则禁止访问的文档。BotBrowser 支持浏览器自动化集成，但不能替代应用中的 robots.txt 规则评估器，也不会授予采集页面的许可。

摘要

• 发送目标请求前，先评估适用于已声明爬虫产品令牌的规则。
• 合并匹配的命名组；只有没有命名组匹配时才使用 User-agent: *。
• 在匹配路径中按具体程度解析规则，而不是采用排在最前的一条。
• 将 robots 规则、采集许可和实际 HTTP 响应视为彼此独立的判断。
• 策略文件获取结果未定时，停止新的任务派发；HTTP 错误不是更换身份的理由。

目录

• 策略、许可和交付彼此独立
• 先选择爬虫组，再选择 URL
• 有限的规则匹配示例
• 先获取 robots，再获取页面
• 将判断写入请求队列
• 实践结论

策略、许可和交付彼此独立

机器人排除协议 RFC 9309 定义了服务所有者发布爬虫规则的方式。这是一种协调机制：遵循协议的爬虫获取 /robots.txt，选择适用规则，并据此决定要请求什么。服务器不必在收到每个请求时都查询该文件。因此，即使规则禁止访问，浏览器仍可能从服务器收到 HTTP 200。这符合协议设计，并不表示规则已失效。

事件记录应区分三个问题。第一，适用的 robots 规则是否允许这个已声明爬虫访问该 URL？第二，团队是否已建立适当的采集依据，并考虑服务条款、授权、数据范围和相关义务？第三，服务器实际返回了什么？规则评估无法回答第二个问题，而成功响应也无法回答前两个问题。

观察结果	能说明什么	不能说明什么	安全的下一步
匹配 Disallow: /private/	适用的 REP 规则禁止匹配路径	服务器一定会拒绝手动请求	从爬取派发队列移除这些路径
没有匹配的路径规则	在所选组下，REP 未禁止该 URL	许可、采集授权或频率额度	应用单独批准的采集策略
目标返回 HTTP 200	目标返回了成功的 HTTP 响应	符合 robots 规则、数据完整或具有法律许可	分开保存策略与内容校验结果
目标返回 HTTP 403	服务器拒绝了该请求	哪条 robots 规则、身份信号或安全产品导致拒绝	停止，并使用获准的证据进行诊断

最后一行对应按层诊断爬虫被拦截：它区分 DNS 或连接故障、HTTP 响应和页面数据问题。robots 评估发生在请求之前，事件诊断则解释请求之后的结果。混淆阶段会产生“robots 阻止了浏览器”之类的误述，而手头证据可能只有 HTTP 403。

RFC 9309 还提醒，列出路径会让这些路径公开可发现。服务所有者必须用适当的访问控制保护机密资源；Disallow 不是身份验证。反过来，路径可见也不代表允许爬虫获取它。对于已获授权的店铺工作流，Shopify 采集边界可区分观察到的页面与采集实际需要的数据及访问范围。即使规则检查通过，这些范围仍然重要。

先选择爬虫组，再选择 URL

User-agent 记录标识的是爬虫产品令牌，不是完整指纹，也不一定是浏览器 User-Agent 请求头全文。RFC 9309 要求产品令牌匹配时忽略大小写。令牌应出现在爬虫标识字符串中，该字符串应说明其用途。为采集应用选择诚实且稳定的令牌；不要仅因搜索引擎组规则不同就改用其名称。

来看一个自有示例服务上的合成文件：

User-agent: *
Disallow: /catalog/

User-agent: ExampleBot
Disallow: /catalog/private/
Allow: /catalog/private/help/

User-agent: examplebot
Disallow: /exports/
Allow: /exports/public/

对于 ExampleBot，两个命名组匹配时不区分令牌大小写，因此规则会合并。通配组不会并入这些命名组。对于没有匹配命名组的其他已声明爬虫，User-agent: * 提供适用规则。如果命名组和通配组都不适用，则没有组规则适用。无论结果如何，都不能据此认定 REP 之外的采集许可。

这一区别会改变 /catalog/item 的判断：通配组禁止该路径，而合并后的 ExampleBot 规则没有匹配它。对同一命名爬虫，/catalog/private/item 匹配禁止规则，/catalog/private/help/start 则同时匹配禁止规则和更长的允许规则。简单合并所有组的解析器会对 /catalog/item 给出不同判断。只在第一个匹配命名组停止的解析器则会漏掉 /exports/。

不要把产品令牌等同于测试工具碰巧发送的浏览器字符串。浏览器进程可以加载 URL，却不一定承担完整爬虫调度器的职责。负责发现 URL、获取策略、解释规则并派发请求的应用，必须明确这些职责。BotBrowser 自动化参考介绍了浏览器集成层，但不能证明某个库已替你实现 REP 评估。

匹配服务，而非整个组织

规则文件位于服务顶层路径 /robots.txt。记录 URL 时要同时记录 scheme 和 authority：https://example.test/robots.txt 并非适用于该组织所有主机名、端口和协议的策略请求。不要把一个 origin 的允许判断复制到另一个 origin 的队列中。相对导航、子域名和重定向都可能改变服务上下文，即使屏幕上的品牌没有变化。

RFC 9309 指出，爬虫应跟随至少五次连续的 robots 重定向，包括跨 authority 的重定向。如果在这条链中找到文件，其规则适用于初始 authority 的上下文。记录已请求的策略 URL 和最终响应 URL。否则，只按最终托管位置建立的缓存可能会把一个站点的规则错误地附加到另一个站点的目标队列。

有限的规则匹配示例

路径匹配从目标路径的开头开始。RFC 9309 按八位组数衡量最具体的匹配规则；路径匹配应区分大小写。当等效的 allow 和 disallow 规则并列时，应采用 allow。因此，不能依赖规则行的先后顺序来作出判断。协议还定义了 *、结尾标记 $、注释和百分号编码行为，生产实现必须处理这些情况。

下面的 Node.js 示例只隔离组选择和 ASCII 字面前缀匹配。各组已从上面的合成文件解析出来。程序会主动拒绝通配符、结尾标记、编码路径和非 ASCII 路径，而不是假装实现了 RFC 9309 的其余部分。它不会发送网络请求，也不会测试任何真实网站的策略。将它粘贴到本地 .mjs 文件中，并用 node 运行该文件。

import assert from 'node:assert/strict';

const groups = [
  { agent: '*', rules: [['disallow', '/catalog/']] },
  {
    agent: 'ExampleBot',
    rules: [
      ['disallow', '/catalog/private/'],
      ['allow', '/catalog/private/help/'],
    ],
  },
  {
    agent: 'examplebot',
    rules: [
      ['disallow', '/exports/'],
      ['allow', '/exports/public/'],
    ],
  },
];

function literalDecision(agent, path) {
  const named = groups.filter(g => g.agent.toLowerCase() === agent.toLowerCase());
  const selected = named.length ? named : groups.filter(g => g.agent === '*');
  const rules = selected.flatMap(g => g.rules);
  for (const value of [path, ...rules.map(r => r[1])]) {
    if (!value.startsWith('/') || /[^\x20-\x7e]|[%*$?#]/.test(value)) {
      throw new Error('literal ASCII paths only');
    }
  }
  const matches = rules.filter(([, prefix]) => path.startsWith(prefix));
  matches.sort((a, b) => b[1].length - a[1].length || Number(b[0] === 'allow') - Number(a[0] === 'allow'));
  return !matches.length || matches[0][0] === 'allow';
}

const cases = [
  ['ExampleBot', '/catalog/item', true],
  ['OtherBot', '/catalog/item', false],
  ['ExampleBot', '/catalog/private/item', false],
  ['ExampleBot', '/catalog/private/help/start', true],
  ['ExampleBot', '/exports/file', false],
  ['EXAMPLEBOT', '/exports/public/file', true],
  ['ExampleBot', '/Catalog/private/item', true],
];
for (const [agent, path, allowed] of cases) {
  const actual = literalDecision(agent, path);
  assert.equal(actual, allowed, `${agent} ${path}`);
  console.log(`${agent} ${path} repAllowed=${actual}`);
}

输出使用 repAllowed 这一名称，避免结果被悄悄称作“已获授权”。前两个用例体现命名组与通配组的选择；两个私有目录用例体现最长前缀选择。exports 用例体现组的合并和令牌大小写不敏感。最后一个用例改变 URL 路径的大小写，没有改变爬虫令牌。若 URL 规范化步骤把所有路径都转成小写，就会抹去这一区别，并可能改变爬虫请求的资源。

该示例不会解析下载的文件内容、合并同一组中的多个产品令牌记录、规范化 URI 八位组、跟随重定向、校验 MIME 类型、管理缓存期限或选择网络重试策略。它只用于推理上面展示的输入。生产环境应选择维护中的 REP 实现，检查其支持的语法，并将这些用例与百分号编码和 */$ 用例一起测试。通过七个 ASCII 用例并不能证明符合协议。

空的 Disallow 值是另一个生产解析器需要处理的情况，不是全面禁止 / 的规则。根据 RFC 9309，路径模式字段可以为空；它不会产生覆盖整个站点的有效禁止前缀。配置规范化时不要把空行转换成 /。同样，未知指令不应终止有效组，也不应抹去其周围可解析的 allow/disallow 记录。

先获取 robots，再获取页面

目标请求和 robots 请求是不同事件。将 policyStatus 和 targetStatus 记在不同字段中。如果 /robots.txt 返回 HTTP 503，即使目标页面昨天返回 HTTP 200，爬虫仍面临未解决的策略获取问题。只保存主机名最近 HTTP 状态码的面板可能掩盖这一区别，并因错误原因重新启动任务。

策略获取结果	RFC 9309 基线	采集应用的决定
robots 下载成功	遵循可解析的规则	评估已声明令牌和目标 URL
HTTP 404，文件不可用	REP 可能允许访问资源	另行执行许可和采集策略检查
HTTP 401 或 403，同属 4xx	RFC 的“不可用”类别不等于授权	暂停并等待明确的策略决定；不要推断已获同意
HTTP 429	不要假定所有爬虫都把它当作普通的文件缺失	停止派发并遵循服务的限流指引
HTTP 5xx 或网络故障	文件无法访问期间假定全面禁止	暂停新任务并采用有界恢复策略
文件可用但部分记录格式错误	使用可解析规则	保留解析器诊断信息，不要丢弃整个文件

RFC 中“不可用”类别涵盖 HTTP 400-499，而“不可达”类别包括 HTTP 500-599 和网络错误。这一区别描述的是爬虫协议行为。右栏对 HTTP 401、403 和 429 作出更严格的停止决定，这是应用策略，不是虚构的 RFC 要求。Google 文档中的 robots 处理方式也会区别对待 HTTP 429 与多数其他 4xx 响应。Googlebot 的行为是有用的厂商文档，但不是你采集器通用的重试算法。

缓存也需要时间记录。RFC 9309 表示，除非文件无法访问，爬虫不应使用超过 24 小时的缓存副本。针对不可达情况的指引允许在经过合理长时间后作其他选择，并以 30 天 为例。这些限定并不支持在没有获取时间、响应历史或审核决定时无限期保留“上次允许”标志。如果一个批次在策略故障后恢复，在重新派发前应根据当前适用规则重新评估剩余 URL。

Crawl-delay 不是 RFC 9309 定义的 allow/disallow 规则之一。有些实现会解释额外记录，有些则不会。不支持延迟指令不代表自动拥有请求额度。应将应用的并发和速率决定与路径匹配器分开；服务发出限流信号时，降低或停止派发。宽松的路径规则无法保证工作负载频率可以接受。

将判断写入请求队列

有效的集成点是能够阻止 URL 进入浏览器任务的组件。导航之后才评估 robots，对该请求来说已经太迟。保存判断时应包含 origin、爬虫产品令牌、策略获取时间、选定组、相关匹配规则以及单独批准的采集范围。在保留规则允许的情况下，保存策略文本或内容摘要，以便之后的事件调查能识别作出判断时使用的版本。

简明的派发记录可以包含 origin、productToken、policyFetchedAt、policyStatus、matchedRule、repDecision 和 collectionDecision。即使 repDecision=allow，只要 collectionDecision=unresolved，任务仍须暂停。repDecision=disallow 会把任务移出可执行集合，即使浏览器此前能访问也一样。网络故障应产生 repDecision=unresolved，而不是伪造一个空 robots 文件。这些状态明确了停止条件，避免把所有获取失败当成同一事件。

队列执行还必须考虑浏览器生成的请求。打开获准文档时，可能同时加载图片、脚本、框架或后台 API 请求。仅检查顶层 URL，并不能证明所有自动子请求都符合采集策略。派发前应盘点所需资源的 origin 并定义获准范围；若工作流无法遵守该范围，就停止并选择已批准的接口或缩小采集任务。不要以获准页面为借口请求禁止的数据端点。

多工作进程采集时，应通过调度器为每个 origin 和已声明令牌发布一份策略判断，而不是让每个工作进程各自得出结果。相关策略版本变化时，使队列中的判断失效。如果当前文件开始禁止先前入队的路径，应移除尚未开始的任务；不要只因浏览器会话仍开着，就沿用昨天的判断。这是应用一致性要求，不是浏览器配置文件的属性。

BotBrowser 文档所述的自动化集成可以为已授权任务提供浏览器目标。它们不会把 REP 变成访问控制，不会替应用选择应该声明的爬虫名称，不会建立采集许可，也不保证目标站点接受请求。负责任使用政策和法律免责声明仍然是相关边界。浏览器设置和成功启动都不能代替上游尚未解决的策略判断。

常见问题

robots.txt 的 Allow 规则意味着我可以采集个人数据吗？

不能。Allow 规则只针对适用爬虫解决协议层面的路径判断。数据类别、用途、允许的访问、保留方式及相关义务，仍是负责团队需要单独处理的问题。REP 不授予数据使用许可；这一区分属于技术说明，不构成法律建议。

Disallow 能阻止 URL 出现在搜索结果中吗？

不一定。Google 的 robots 介绍区分了爬取和索引：被禁止爬取的 URL 仍可能通过链接被发现。保护机密文档需要访问保护。禁止爬虫不是身份验证或通用去索引指令的可靠替代品。

重定向后可以继续使用相同的 robots 判断吗？

分别记录来源和目标上下文。robots 文件重定向遵循 RFC 9309 所述的初始 authority 规则；目标页面重定向则可能引入另一个服务，其策略和授权范围仍需评估。不要推断重定向会把允许判断或采集许可转移到无关主机。

为什么普通浏览器可以打开禁止访问的路径？

REP 由参与的爬虫应用实现；协议并未要求每次浏览器导航都自动被拒绝。HTTP 服务器仍可能提供该路径。该响应只能证明这次请求收到交付，爬虫是否必须遵循适用规则仍是另一项判断。

来源

• RFC 9309：机器人排除协议，特别是 2.2-2.5 和 3 节
• Google Search Central：robots.txt 介绍
• Google Search Central：robots.txt 解释与 HTTP 处理
• BotBrowser 自动化一致性参考
• BotBrowser 负责任使用
• BotBrowser 法律免责声明

实践结论

开始下一项 robots.txt 抓取决策时，先明确一个爬虫令牌、一个服务 origin 和一个目标路径。解析适用规则，将采集许可单独处理，并阻止未解决或被禁止的任务进入浏览器队列。HTTP 响应成功只能说明服务器交付了文档，不能替代之前的判断。