robots.txt：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7ec4a55ee9ab.html
📄
robots.txt：怎样取得可复查的状态证据
要取得 robots.txt 的可复查状态证据，核心是同时保存三样东西：抓取到的文件内容、抓取时的 HTTP 响应头、以及请求所用的完整 URL 和时间。只有文件内容而没有状态码，无法判断搜索引擎看到的是 200、404 还是 403；只有截图而没有原始响应，也无法复核。正确做法是用命令行或带响应头查看能力的工具发一次请求，把响应头与正文一起留存，再与线上文件逐行比对。
常见误解：文件内容对，就说明 robots.txt 生效
很多人打开浏览器看到 robots.txt 里的规则，就认为状态已经确认。但浏览器地址栏访问和爬虫抓取并不等价：浏览器可能命中缓存，可能跟随跳转，也不会把 404、403、5xx 明确区分给你看。对爬虫来说，这些状态的含义完全不同——404 通常意味着没有规则约束，403 可能被当作拒绝访问，5xx 则可能让爬虫暂时保留旧规则。因此“内容看起来对”只是必要条件，不是可复查的证据。
用一次请求同时拿到正文与响应头
可执行的起点是发一条带响应头输出的请求。假设站点是 https://example.com，可以执行：
curl -i https://example.com/robots.txt
-i 会把响应头和正文一起打印。你要留存的是：状态行（如 HTTP/1.1 200 OK）、Content-Type、Content-Length、可能的 Location 跳转头，以及正文全文。把输出重定向到文件，例如 curl -i https://example.com/robots.txt > robots-check.txt，就得到一份带时间戳可归档的原始记录。
适用条件是你能在本地或服务器上执行命令。如果只能通过浏览器操作，退而求其次的办法是打开开发者工具的 Network 面板，刷新 robots.txt，查看该请求的 Status、Response Headers 和 Response 正文，并导出 HAR 文件。判断结果时看两点：状态是否为 200，正文是否与预期规则一致。任一不符，证据就不成立。
检查项：哪些字段决定这份证据是否可信
- 请求 URL：必须是目标主机根目录下的
/robots.txt，子目录下的同名文件对爬虫无效。 - 协议与主机：
http与https、带www与不带，可能返回不同结果，要按你实际希望约束的主机分别抓取。 - 状态码：200 表示规则可用；301/302 要记录跳转终点；404 表示无规则；403、5xx 需要单独判断。
- 正文编码与字符：确认没有 BOM、没有因编码错误产生的乱码，规则行未被截断。
- 抓取时间：同一文件可能被改动，证据必须带时间，否则无法与后续状态对比。
把证据与“索引状态”分开看
robots.txt 的抓取限制不等于可靠的索引移除。即使规则写对了，已收录的页面也可能继续出现在结果中，因为抓取限制只约束爬虫访问，不保证已有索引被删除。所以这份证据只能证明“爬虫在某一时刻从该 URL 拿到了什么”，不能证明页面已从索引消失。若目标是移除索引，需要另找对应渠道，并单独留存那一步的操作记录。
同样，站点地图不保证收录，HTTPS 不保证安全无漏洞或排名提升，这些都与 robots.txt 的状态证据无关，不要混在同一份记录里当作同一结论的依据。不同搜索引擎对 robots.txt 的支持细节须分别核查，同一份文件在不同引擎下的实际行为可能不同。
下一步：建立可对比的复查记录
把这次抓取的输出按“主机 + 日期”命名存档，例如 example.com-robots-2025-01-15.txt。下次复查时用同样的命令再抓一次，对比两次的状态行与正文差异。如果状态码或规则发生变化，你就有了一份可追溯的变更记录，而不是只能凭印象说“以前是对的”。若发现状态异常，先确认是服务器配置、CDN 缓存还是重定向规则导致的，再决定是否修改，避免在原因未定位前反复改动文件。
