robots：日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /08c45b3691d2.html
📄
robots：日志中应该核对哪些字段
核对 robots 相关日志时，最该看的不是“有没有抓到”，而是请求的 URL 路径、User-Agent、响应状态码、抓取时间、来源 IP 和 Referer 这几类字段。因为 robots.txt 只表达“是否允许抓取”，它本身不等于索引移除；日志里真正能帮你判断的，是某个爬虫有没有来请求、请求的是不是 robots.txt、拿到的是 200 还是 403/404、以及它随后有没有继续请求页面。
先确认日志里哪些行属于 robots 相关请求
打开原始访问日志后，先按 URL 路径筛选，而不是先看总数。你需要找的是路径等于 /robots.txt 的请求行。常见的组合日志格式里，一行通常包含：来源 IP、时间、请求方法、请求路径、状态码、响应字节数、Referer、User-Agent。过滤时优先用路径和 User-Agent 两个字段交叉定位。
- 请求路径：确认是
/robots.txt本身，还是被误当成 robots 的页面 URL。 - User-Agent：区分是搜索引擎爬虫、普通浏览器，还是第三方工具。不同搜索引擎的爬虫标识不同，需要分别核查。
- 响应状态码：200 表示正常返回；403 可能被防火墙或权限拦截；404 表示文件不存在；5xx 表示服务器错误。状态码不同，后续处理方向完全不同。
- 抓取时间：看请求是否集中在你修改 robots.txt 之后，判断改动有没有被重新读取。
用状态码和抓取频率判断问题出在哪一层
如果日志里 /robots.txt 大量返回 404，说明爬虫拿不到规则文件，它可能按默认策略继续抓取，也可能降低抓取节奏，具体行为取决于搜索引擎。此时应先检查文件是否部署到了正确目录，而不是直接去改页面内容。
如果返回 403，可能是 WAF、CDN 或服务器权限规则拦截了爬虫。要核对拦截规则里是否误伤了目标 User-Agent。注意，403 和“robots.txt 禁止抓取”是两回事：前者是服务器拒绝响应，后者是规则文件明确表达不允许。
如果返回 200，但日志中某个 User-Agent 只请求 robots.txt、几乎不请求页面，可能原因是该爬虫在读取规则后判断不允许抓取，或者抓取预算被其他因素占用。这时应回到 robots.txt 内容，逐条核对 Disallow 和 Allow 的路径是否写错、是否误屏蔽了整站。
把日志字段和 robots.txt 规则逐条对照
假设日志显示某爬虫请求了 /robots.txt 并得到 200，但之后没有请求 /product/ 下的页面。你可以做一次对照检查：
- 从日志中提取该爬虫的 User-Agent 字符串。
- 在 robots.txt 中找到对应 User-Agent 分组，确认分组名称是否匹配。
- 检查该分组下的
Disallow是否包含/product/或更宽泛的/。 - 检查是否存在语法错误，例如缺少冒号、路径大小写不一致、通配符使用不当。
- 确认没有其他规则组意外覆盖了目标爬虫。
如果日志里同一路径被不同爬虫分别请求，要分开统计。一个爬虫被屏蔽，不代表另一个爬虫也被屏蔽；不同搜索引擎对 robots.txt 的支持细节需要分别核查。
验收信号：改完之后看什么
调整 robots.txt 或服务器规则后，不要只看“文件能打开”。更实际的验收信号是：目标爬虫再次请求 /robots.txt 时返回 200，并且在随后一段时间内开始请求之前被屏蔽的页面路径。如果日志中仍然只有 robots.txt 请求、没有页面请求，说明问题可能不在规则文件，而在页面可访问性、内链结构或抓取预算。
另外要记住：robots.txt 的抓取限制不等于可靠的索引移除。即使你在 robots.txt 里禁止抓取某个 URL，该 URL 仍可能因为外部链接等原因出现在搜索结果中。要移除索引，应使用对应的 noindex 机制或搜索平台提供的移除工具，并分别核查不同搜索引擎的支持情况。
下一步建议：从最近 7 天日志中导出所有 /robots.txt 请求行，按 User-Agent 和状态码分组统计，再与当前 robots.txt 内容逐条比对。先解决 403 和 404，再检查 Disallow 路径是否误伤，最后观察目标爬虫是否恢复页面抓取。
