robots.txt优化：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7ee04d0c50c.html
📄
robots.txt优化：日志中应该核对哪些字段
在robots.txt优化过程中，日志里最该核对的字段是：请求URL、User-Agent、HTTP状态码、请求时间、来源IP，以及响应体大小。这几项能帮你判断搜索引擎抓取器是否按你写的规则访问、哪些目录被误拦、哪些规则根本没生效。核对时不要只看“有没有抓到”，而要看“抓的是谁、抓了什么、结果如何”。
先分清两种处理方案：改规则前核对与改规则后复核
日志核对通常有两种场景，适用条件不同。第一种是改robots.txt之前，用于发现当前是否已有重要目录被拦、抓取预算是否浪费在无关路径上。第二种是改robots.txt之后，用于确认新规则是否被目标抓取器实际读取并执行。前者重点看历史请求分布，后者重点看时间戳之后的行为变化。若你无法区分这两种场景，容易把“规则已写”误判为“规则已生效”。
可执行清单：逐项查什么、怎么查、结果说明什么
- 请求URL：在日志中过滤出被请求的完整路径。看是否包含你已在robots.txt中禁止的目录。若禁止后仍大量出现该路径请求，说明抓取器可能尚未重新读取规则，或该请求来自其他User-Agent。结果判断：禁止目录请求量应随时间下降，而非立即归零。
- User-Agent：按抓取器名称分组统计。核对是否与你robots.txt中针对的User-Agent匹配。若你只禁止了某一种抓取器，却看到其他抓取器仍在抓取，属于正常现象。结果判断：只有对应User-Agent的请求变化才能证明你的规则对该抓取器起作用。
- HTTP状态码：统计200、301、302、403、404、429、503的占比。若被禁止目录返回403，说明服务器层面也做了拦截；若返回200，说明robots.txt只是建议，并未阻止服务器返回内容。结果判断：robots.txt限制的是抓取，不等于索引移除，也不等于服务器拒绝响应。
- 请求时间：按小时或按天聚合。对比修改robots.txt的时间点，看目标抓取器是否在之后重新请求了
/robots.txt。结果判断：若日志中没有修改后的robots.txt请求记录，就不能断言新规则已被读取。 - 来源IP与反向解析：记录请求来源IP，并做反向DNS核对。用于区分真实抓取器与伪装抓取器。结果判断：若User-Agent声称是某抓取器但IP不属于该抓取器，该请求不能作为规则生效的证据。
- 响应体大小：观察被禁止路径的响应体字节数。若状态码为200且响应体较大，说明内容仍被完整返回。结果判断：这通常意味着robots.txt未阻止服务器输出，需要检查服务器配置或改用其他控制手段。
核对时容易误判的三种情况
第一，把抓取限制当成索引移除。robots.txt禁止抓取后，页面仍可能因外部链接出现在搜索结果中。第二，把站点地图提交当成收录保证。站点地图只帮助发现URL，不保证被抓取或收录。第三，把HTTPS当成安全与排名保证。HTTPS不保证无漏洞，也不单独决定排名。核对日志时，这三项要分开判断，不能互相替代。
假设示例：一次规则调整后的日志对比
假设你在某日10:00把/tmp/加入Disallow，目标抓取器为ExampleBot。改前日志显示ExampleBot每小时请求/tmp/约50次，状态码200。改后24小时内，若日志中ExampleBot对/tmp/的请求降至0，且出现对/robots.txt的200请求，说明规则可能已生效。若请求仍为200且数量不变，则需检查：robots.txt是否可公开访问、是否写错路径、是否有其他抓取器在访问。这个例子只用于说明判断逻辑，不代表任何真实站点数据。
下一步：把核对结果落成一条可复查的记录
完成上述字段核对后，建议在同一张表里记录：核对日期、robots.txt修改时间、目标User-Agent、禁止路径、修改前后请求量、状态码分布。下次调整规则时，用同一张表对比。若发现某抓取器未按预期变化，优先检查它是否重新读取了robots.txt，再检查服务器是否对禁止路径返回了200。不要仅凭“规则已写”就认定优化完成。
