搜索引擎爬虫控制日志中应该核对哪些字段：先分清“谁来过”和“拿走了什么”
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bff569ec652f.html
📄
搜索引擎爬虫控制日志中应该核对哪些字段：先分清“谁来过”和“拿走了什么”
核对爬虫日志时，最该先看的不是访问总量，而是能回答三个问题的字段：谁来的（IP 与反向解析）、它自称是谁（User-Agent）、它要了什么、结果如何（URL、状态码、响应大小、时间）。只统计总请求数，很容易把正常抓取、恶意扫描和 CDN 回源混在一起，得出错误结论。
常见误解：日志里请求多，就说明抓取多
请求数只代表服务器收到过这些连接，不等于搜索引擎真的抓取并处理了页面。同一 IP 可能来自代理、监控探针、安全扫描器或预取服务；同一个 User-Agent 也可能被伪造。反过来，真实爬虫的请求可能因为 CDN、WAF 或负载均衡只留下回源记录，来源 IP 已被改写。所以日志核对的目标不是“数请求”，而是建立一条可验证的证据链：某条记录能否对应到某个已知爬虫身份，以及它访问的 URL 是否返回了可索引的内容。
必须优先核对的字段清单
- IP 地址：用于反向 DNS 查询和网段比对。不要只看 IP 归属地，要看能否解析回官方域名，并且正向解析能回到同一 IP。
- User-Agent：记录爬虫自我声明的名称和版本。它是线索，不是证据，必须与 IP 验证配合。
- 请求方法与协议：GET、HEAD、POST 的含义不同。大量 HEAD 或非 GET 请求往往不是正常内容抓取。
- 完整 URL 与查询串：包含路径、参数、分页和跟踪参数。只看路径会漏掉参数导致的重复抓取或错误页面。
- 状态码：200、301、302、304、403、404、429、5xx 要分开统计。403 和 429 尤其重要，它们直接说明抓取被拒绝或限流。
- 响应大小：状态码 200 但响应体极小，可能是空模板、验证页或软 404。
- 响应时间：用于判断抓取是否因超时失败，以及服务器是否在爬虫压力下变慢。
- Referer：可辅助判断请求来源，但对多数爬虫来说常为空，不能作为主要依据。
- 时间戳与时区：排查突发抓取、限流窗口和日志轮转问题时必须统一时区。
先验证身份，再判断行为
以 Googlebot 为例，正确顺序是：先从日志取出声称是 Googlebot 的 IP，做反向 DNS 查询，确认域名属于官方网段，再做正向解析确认回到同一 IP。只有两步都通过，才能把它当作可信的 Googlebot 记录。Bingbot 等其他爬虫有各自的验证方式，需要分别核查，不能拿一套规则套用所有搜索引擎。
验证之后，再按 URL 分组看状态码分布。假设某目录下 80% 的抓取返回 403，而其他目录正常，那么问题更可能出在该目录的访问规则、WAF 策略或权限配置，而不是全站抓取故障。这个比例是举例说明判断方法，不是真实项目数据。
可执行的最小核对步骤
- 从日志中筛出目标爬虫的 User-Agent，导出 IP、URL、状态码、响应大小、时间五列。
- 对出现频率最高的前若干 IP 做反向与正向 DNS 验证，标记可信、可疑、未知三类。
- 按状态码分组统计，重点看 403、429、5xx 和 200 但响应体过小的记录。
- 按 URL 目录聚合，找出抓取集中但返回异常的部分。
- 把结果与 robots.txt、站点地图、CDN/WAF 规则对照，确认限制是否被正确执行。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 也不保证安全无漏洞或排名提升。日志只能告诉你服务器收到了什么、返回了什么，不能单独证明页面是否被索引。
核对结果如何落到判断上
如果可信爬虫的请求大量返回 200，但响应体很小，优先检查模板渲染和软 404；如果大量返回 403 或 429，优先检查访问控制与限流；如果可信爬虫请求很少而未知 IP 很多，优先检查是否有伪装抓取或安全扫描；如果日志中几乎看不到目标爬虫，再考虑 robots.txt、站点地图提交和外部链接发现路径，而不是直接断定“没有被抓取”。
下一步，选取一个具体目录，按上述字段导出最近一段时间的日志，先完成 IP 身份验证和状态码分组，再决定是调整抓取规则、修复返回内容，还是继续收集更多证据。
