robots.txt编写 日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /07fee9e64f18.html
📄
robots.txt编写 日志中应该核对哪些字段
排查robots.txt相关问题时，日志里最该先核对的是请求路径、状态码、User-Agent、请求时间和来源IP这几类字段。它们能帮你判断搜索引擎抓取器是否请求了robots.txt、是否被允许抓取，以及限制规则是否真的生效。下面是一份可执行清单，每项都说明查什么、怎么查、结果说明什么。
先确认robots.txt本身有没有被抓取
查什么：日志中路径为/robots.txt的请求记录，以及对应的状态码。
怎么查：在服务器访问日志里筛选包含GET /robots.txt的行，统计出现次数和状态码分布。
结果说明什么：如果长期没有该路径的请求，说明抓取器可能还没请求，或日志被轮转、被CDN/代理层截留；如果状态码是404或403，robots.txt等于不存在或被拒绝访问，后续规则自然不生效。状态码200只说明文件被成功返回，不代表规则一定被正确解析。
核对User-Agent字段，区分抓取器身份
查什么：请求robots.txt以及被限制路径的User-Agent字符串。
怎么查：按User-Agent分组统计，观察哪些UA在请求robots.txt，哪些UA在请求你打算禁止的目录。
结果说明什么：如果robots.txt只对某个UA段写了规则，就要确认该UA字符串是否与日志中的实际值匹配。UA可以被伪造，所以日志中的UA只能作为线索，不能单独作为“这就是官方抓取器”的证据。不同搜索引擎的抓取器名称和支持的robots.txt指令可能不同，需要分别核对。
核对状态码，判断规则是否被真正执行
查什么：被Disallow的路径在日志中返回的状态码。
怎么查：筛选目标路径，统计200、301、302、403、404、429、5xx各自占比。
结果说明什么：robots.txt的Disallow只是“请求不要抓取”，并不等于服务器会拒绝访问。如果被禁止路径仍大量返回200，说明抓取器没有遵守规则，或者请求来自其他来源；如果返回403或429，可能是服务器或防护层在拦截，与robots.txt是两回事。要区分“规则没生效”和“规则生效但日志里仍有其他请求”。
核对请求时间与频率，识别异常抓取
查什么：同一IP或同一UA在单位时间内请求robots.txt和被禁路径的时间戳。
怎么查：按分钟或小时聚合请求数，观察是否存在短时间高频访问。
结果说明什么：如果robots.txt被高频重复请求，可能是抓取器在反复确认规则，也可能是异常扫描。如果被禁路径的请求集中在某个时间段，要结合该时段的发布、改版或跳转操作判断。频率异常本身不是robots.txt写错的直接证据，但能提示你需要进一步查来源IP和referer。
核对来源IP与反解，避免误判
查什么：发起请求的IP，以及该IP是否属于已知抓取器网段。
怎么查：提取IP后做反向解析或与官方公布的抓取器IP段比对，注意比对时要看官方最新文档，不要凭记忆。
结果说明什么：如果IP不属于目标抓取器，那么即使UA写着相同名称，也不能据此判断robots.txt对该抓取器生效。来源IP能帮你把“规则问题”和“他人抓取或扫描”分开。
一个可执行的最小核对流程
- 筛出所有
/robots.txt请求，记录状态码和UA。 - 筛出被Disallow的路径，按状态码分组。
- 把两组记录的UA和IP交叉比对，看是否来自同一抓取器。
- 对可疑IP做反解，确认身份。
- 如果robots.txt返回非200，先修文件可访问性，再谈规则。
这套流程适用于“怀疑robots.txt没起作用”的场景。如果日志里根本没有robots.txt请求，重点应放在文件是否可访问、是否被CDN缓存或拦截；如果有请求但被禁路径仍被大量抓取，重点应放在规则语法、UA匹配和抓取器是否遵守规则上。robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点不要混进同一个判断。
下一步：拿一份最近24小时的访问日志，按上面的顺序跑一遍，先确认robots.txt是否被请求、返回什么状态码，再决定是改规则还是查拦截层。
