📍 WDQWDWQD987AAAAA:216.73.217.162
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /82633b29ce76.html
📄

robots.txt写法日志中应该核对哪些字段：定位抓取限制是否生效

当你想确认某条 robots.txt 规则是否真的阻止了抓取，日志里最该核对的字段是：请求时间、请求方法、请求 URL（尤其是路径与查询串）、HTTP 状态码、User-Agent、来源 IP，以及响应体大小。其中状态码和 URL 路径是判断“是否命中规则”的核心，User-Agent 决定规则对谁生效，来源 IP 用来区分真实搜索引擎抓取与普通访问。只看到某个 URL 没被抓取，并不能证明是 robots.txt 起的作用，必须结合这些字段交叉判断。

为什么单看“某 URL 没出现”不能下结论

抓取日志里缺少某个 URL，可能有多种解释：它从未被链接到、被其他页面挤出了抓取预算、服务器返回了错误、robots.txt 阻止了抓取，或者被抓取但记录在别的日志文件里。因此核对字段的目的是把“可能原因”缩小为“已经定位的原因”。

适用前提是：你拥有服务器访问日志或 CDN 日志，并且能按时间范围过滤。如果只有一份聚合统计，没有逐条请求记录，就无法完成下列核对。

逐项核对的字段与判断依据

• 请求 URL 与路径：确认被测试的路径是否以 / 开头、是否带查询串。robots.txt 的 Disallow 匹配的是路径前缀，/private 与 /private/ 在部分实现下效果不同，日志里要看清实际请求的是哪一个。
• HTTP 状态码：200 表示正常返回内容；403、404、5xx 各有不同含义。被 robots.txt 阻止的抓取，通常表现为该 URL 根本没有请求记录，而不是返回某个特定码。
• User-Agent：robots.txt 规则按 UA 分组。日志中要确认发出请求的 UA 是否匹配你写的 User-agent 行，否则规则可能对另一个爬虫生效。
• 来源 IP：用反向解析或官方 IP 段核对，判断是真实搜索引擎还是仿冒 UA 的普通访问。仿冒请求不能作为规则生效的证据。
• 请求时间：与 robots.txt 文件修改时间对齐。规则改动前的日志不能用来判断改动后的效果。
• 响应体大小：200 但响应体为 0 或极小，可能意味着返回了空内容，需要进一步看是否被中间层拦截。

可执行核对步骤

1. 确定要验证的 URL 路径和对应规则，记下修改 robots.txt 的时间点。
2. 在日志中按该时间点之后过滤，先搜该路径，再搜该路径的父目录。
3. 若完全没有记录，检查同时段其他 URL 是否正常被抓取，用以排除日志中断。
4. 若有记录，核对 UA 与来源 IP 是否为真实爬虫，再看状态码和响应体大小。
5. 把结果与 robots.txt 中对应 UA 分组的规则逐条比对，确认匹配的是哪一行。

验收信号：修改规则后，被禁止的路径在日志中不再出现真实爬虫请求，而允许的路径仍有正常 200 记录。若被禁止路径仍被抓取，先确认是否是缓存、旧规则或另一个 UA 分组导致。

容易混淆的边界

robots.txt 的抓取限制不等于可靠的索引移除。即使日志显示爬虫不再请求某 URL，该 URL 仍可能因外部链接或历史记录出现在搜索结果中。站点地图也不保证收录，提交只表示告知，不代表一定被抓取。HTTPS 不保证安全无漏洞或排名，它只是传输层加密。不同搜索引擎对 robots.txt 的支持细节须分别核查，不能把一种爬虫的日志结论直接套用到另一种。

下一步：挑一条你最近修改过的规则，按上面的字段在日志里跑一遍，确认“没被抓取”到底是规则生效，还是从未被链接或返回了错误。