摘要

  • 1994 年 6 月的 robots 共识选择 /robots.txt，是因为现有 Web 服务器便于提供它，爬虫只需一次 HTTP 请求便能找到规则。
  • 这项设计以网站级管理和自愿遵守换取共同、可预测的约定；1995 年的一场讨论表明，允许范围、爬虫身份和访问频率是三个不同问题。

爬虫可以让一个很小的网站承受意料之外的负载。1994 年的《A Standard for Robot Exclusion》在引言中回顾了 1993 至 1994 年的投诉：有的机器人请求过快，或反复抓取同一文件；有的沿链接深入虚拟目录树，进入重复、临时内容，甚至触发取回时会产生副作用的 CGI 脚本。问题不是 Web 缺少页面，而是爬虫跟随链接时可以越过服务器的运行边界，而站点运营者还没有一种大家都能识别的方式告诉它在哪里停下。

提案的回答是把规则放在固定位置的普通文本文件里。爬虫先取回站点本地 URL /robots.txt，再开始遍历。作者给出的理由很务实：既有 Web 服务器容易实现，而且爬虫只需获取一份文档就能发现策略。根目录还省去了让每个机器人逐站学习不同地址的麻烦。文件可以写出某个爬虫的名称，也可以使用通配符，再列出不应抓取的 URL 路径。一般规则和例外可以放进不同的记录中。

这种简化把控制面放到了站点边界。服务器管理员可以为整个主机发布一份规则。提案同时写明了代价：单一文件不能由每篇文档的维护者各自直接维护。站点可以通过本地流程把多份规则汇总成一个文件，但如何做不在提案范围内。只需一次请求的便利，因此伴随着组织内部的权限问题：谁有权替整个网站设定爬虫策略？

该约定的地位也被说得很清楚。原文称它体现了 1994 年 6 月 30 日多数爬虫作者和其他关注者形成的共识，并曾向 www-talk 邮件列表开放讨论；文件还基于更早的工作草案。但它不是由标准组织背书的正式标准，没有机构负责强制执行，也不保证现在或未来的所有爬虫都会使用。作者把它称作多数爬虫作者向 Web 社群提供的一项共同机制。这是一种协调提议，不是挡在文件前面的技术门禁。

1995 年 5 月 W3C 的 www-talk 邮件档案展现了另一个边界。Kee Hinckley 回复说，权限文件可以告诉爬虫避开哪些路径，却不能帮助服务器确认来访者是谁。他还指出，文件不会在每次访问时都被重新抓取，访问间隔较长是为了减少对单个系统的负担；普通读者也能取回这个文件。这只是一个参与者对当时做法的说明，不是所有爬虫行为的统计。不过，它把三个容易混为一谈的任务分开了：表达站点偏好、识别客户端，以及决定客户端多久再来一次。

此后，这套协议获得了不同的制度地位。RFC 9309 于 2022 年 9 月以 IETF Standards Track 文件发布，称其规范并扩展了 Martijn Koster 在 1994 年定义的方法，同时补充更明确的术语、错误处理和缓存指导。RFC 也明确了边界：爬虫应当遵守这些规则，但它们不构成访问授权。从社群约定到标准的过程，并没有把 robots.txt 变成认证或强制机制。

这段历史说明，一项共同规则可以放在哪里。唯一而固定的文件降低了网站运营者和爬虫作者参与协调的成本，代价是管理员成为默认的规则编辑者，而执行责任落在客户端。现有材料记录了设计取舍和后来的标准化路径；它们没有统计有多少站点采用该文件、它阻止了多少请求，也没有量化节省的服务器负载。

来源

  • Martijn Koster，《A Standard for Robot Exclusion》，1994 年 6 月 30 日共识文件，WebCrawler robots 项目存档副本：原文。
  • Kee Hinckley，《Re: Byte ranges (actually robots)》，W3C www-talk 邮件档案，1995 年 5 月 25 日：邮件。
  • IETF，RFC 9309《Robots Exclusion Protocol》，2022 年 9 月：RFC。