要取得可复查的 robotstxt 状态证据,核心是让每次结论都能对应到一个具体 URL、一次请求、一份带时间的原始响应,而不是只留下“我看过了,没问题”的口头记录。可复查意味着:换一个人、换一台机器,按记录重做一次,能得到相同或可解释的结果。下面按检查项给出要查什么、怎么查、结果说明什么。
要查的是哪个主机、哪个协议、哪个路径下的 robots.txt,必须先写清楚。同一域名下 http:// 与 https://、带 www 与不带 www,在抓取方看来可能是不同来源,各自需要单独取证。
https://example.com/robots.txt,以及取证时间(精确到分钟,注明时区)。浏览器打开 robots.txt 时看到的内容,可能来自缓存、可能被跳转、可能被中间层改写。可复查的证据应当包含状态码、响应头和正文原文。
curl -i https://example.com/robots.txt,把完整输出保存为文本文件。200 表示正常返回;404 表示该路径不存在;301 或 302 表示发生了跳转,需要继续追到最终地址。Content-Type 与缓存相关字段,判断拿到的正文是否为纯文本、是否可能来自缓存。.txt,文件名带上日期,例如 robots-20250101-https.txt。结果说明什么:拿到 200 加正文,说明该地址当前确实返回了一份规则文件;拿到跳转,说明真实生效的规则在另一个地址,原地址的结论不能直接沿用;拿到 404,说明该来源没有规则文件,这本身也是一种需要记录的状态。
证据不只是“文件能打开”,还要能说明文件里的规则表达了什么意图。多人协作时,规则由谁改、改了什么,必须能从记录里还原。
User-agent 分组是否写全、Disallow 与 Allow 的路径是否指向真正想控制的目录、是否误写了整站屏蔽。Disallow: / 这类写法,它表示屏蔽整站抓取,一旦误加,影响范围极大。Disallow: / 出现在本该开放的分组下,说明这是需要立即确认的配置问题,而不是“文件存在即正常”。这里要分清一个常见误解:robots.txt 的抓取限制不等于可靠的索引移除。即使某条路径被 Disallow,该 URL 仍可能因为外部链接等原因出现在结果中。若目标是让页面从索引中消失,需要另外的移除手段,不能只靠 robots.txt 取证。
同一份 robots.txt,在不同抓取方眼中的解释可能不同。可复查的做法是分别记录,而不是合并成一句“已检查”。
User-agent 分组是否命中。结果说明什么:如果原始响应显示允许,而测试工具显示被拦,说明两者命中的分组或地址不同,需要先对齐对象再下结论,不能直接判定某一方错误。
多人协作减少返工的关键,是交付物能被独立复核。可以按下面几项自检:
判断标准很简单:把交付目录交给另一位同事,对方不问你任何问题,就能复现你的请求、看到同样的响应、理解你的结论依据。做不到,就说明证据还不可复查。
下一步:选一个当前需要确认的 robots.txt 地址,按上面的顺序做一次完整取证,把原始响应、逐条核对表和测试记录放进同一个目录,再让同事独立复核一遍。