爬虫日志分析 - 如何取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9f12c20c7f04.html
📄
爬虫日志分析 - 如何取得可复查的状态证据
可复查的状态证据，是指任何第三方拿到你的原始日志、处理脚本和中间结果后，能独立重算出同一结论。对爬虫日志分析来说，这意味着不能只保存一张汇总截图或一句“某搜索引擎抓取变少了”，而要保留从原始行到判断结论的完整链条。
从一条假设日志开始走完整流程
假设你拿到一台服务器 2024 年 3 月 1 日至 3 月 7 日的访问日志，想确认某搜索引擎爬虫的抓取是否异常。下面是一条假设的日志行（真实日志字段以你的服务器配置为准）：
203.0.113.10 - - [01/Mar/2024:09:12:03 +0800] "GET /guide/seo HTTP/1.1" 200 15320 "-" "Mozilla/5.0 (compatible; ExampleBot/1.0; +http://example.com/bot)"
假设你按 User-Agent 中含 ExampleBot 筛选，得到 7 天内 1200 条请求，其中 3 月 3 日只有 40 条，明显低于其他日期的 180 至 220 条。这个“下降”就是待验证的状态，不是结论。可复查的第一步，是把筛选条件写成固定命令或脚本，而不是手工在界面里点选。
需要固定下来的四类证据
- 原始文件：日志文件本身，记录文件名、大小、时间范围、获取方式。
- 筛选规则：匹配哪个字段、用什么字符串、是否区分大小写、是否排除已知伪造 UA。
- 处理过程：脚本或命令原文，以及运行环境（如 Python 版本、grep 版本）。
- 输出结果：按天或按小时的计数表，保留可重新生成的中间文件。
这四类齐了，别人才可能复现你的数字。缺任何一项，结论都只能算个人观察。
常见错误与检查项
第一类错误是只看 User-Agent。UA 可以被伪造，所以更稳的做法是同时记录来源 IP 段、反向 DNS 或官方公布的 IP 列表，并说明你用了哪一种校验。如果只凭 UA 下结论，要在证据里明确标注这一限制。
第二类错误是时间口径不一致。日志时间可能是服务器本地时间，也可能是 UTC，而你的统计按自然日切分。复查时要写明时区，以及跨天请求如何归属。
第三类错误是拿汇总数当原始证据。比如只保留“3 月 3 日 40 条”，却删掉了按小时分布。实际可能是抓取集中在凌晨某两小时，而不是全天均匀减少，两者的处理方向完全不同。
可以按下面的清单逐项检查：
- 原始日志是否完整覆盖声称的时间段，有没有轮转丢失。
- 筛选命令能否在另一台机器上跑出相同计数。
- 是否区分了成功响应（如 200）与其他状态码。
- 是否排除了你自己或监控工具的请求。
- 结论中的每个数字，是否都能指回某条命令或某个中间文件。
状态证据能支持什么、不能支持什么
可复查的证据能支持“在这份日志覆盖范围内，符合该筛选规则的请求数量如何变化”。它不能单独证明索引状态、排名变化或抓取配额调整。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些都需要另外的核查渠道。
如果要把日志结论和索引情况对照，应分别记录两边各自的证据来源和获取时间，不要用一边的数据替代另一边。不同搜索引擎的爬虫标识、IP 公布方式和验证方法需要分别核查，不能套用同一份规则。
下一步：选一段 7 天的日志，把筛选命令、时区和计数脚本写成一份可运行的记录，然后让另一个人按记录重跑一次，看数字是否一致。不一致的地方，就是你的证据链还需要补强的位置。
