蜘蛛池跑起来之后，很多人只盯着后台那个抓取数字看，却很少打开服务器上那份原始访问日志。实际上，日志才是判断蜘蛛有没有认真抓、抓得对不对的第一手材料。第三方统计工具大多做了聚合和过滤，而 access log 保留了每一次请求的原始记录，很多异常只有在这里才看得出来。

日志里先看哪些字段

一份标准的 Nginx 或 Apache 访问日志，通常包含下列内容。建议在配置中把响应时间和完整 User-Agent 都打开，否则后面的分析会缺一半信息：

• 远端 IP：蜘蛛来源，也是做反向 DNS 校验的起点
• 时间戳：判断抓取是集中在某个时段还是全天分散
• 请求方法与 URL：看蜘蛛抓的是入口页、列表页，还是误抓的接口和资源
• 状态码：200、301、404、5xx 各自的占比
• 响应体大小与响应时间：判断哪些页面在拖慢整体响应
• User-Agent 与 Referer：辅助判断请求来源和跳转链路

先分辨真蜘蛛和伪装请求

日志里的 UA 可以随便伪造，所以不能只看字符串。比较稳妥的做法是做反向 DNS 校验：把 IP 反解成域名，再正向解析回 IP，确认两边一致，并且域名属于对应搜索引擎。IP 段也可以对照官方公布的列表定期核对。

如果发现大量 UA 写着蜘蛛、但反查没有结果、请求频率极高、只盯着少数 URL 的 IP，多半是采集器或扫描器。这类请求不会带来任何价值，反而持续占用带宽和连接数。

从日志看抓取结构是否合理

把日志按 URL 路径归类，可以大致看出蜘蛛的行为偏好：

• 入口页被抓很多次，但列表页几乎没有记录，说明链接层级太深，蜘蛛没有顺着往下走
• 大量带参 URL 被反复抓取，属于典型的重复入口，需要考虑归一化或屏蔽
• 图片、CSS、JS 等静态资源占了大头，说明抓取预算被无关内容消耗
• 抓取时间高度集中在某几分钟，可能是触发了限速，或并发被服务端压制

这些现象不直接等于收录会变差，但至少说明蜘蛛的访问效率不高，值得回头调整入口页的链接结构。

状态码与响应时间的异常信号

状态码分布是最容易被忽略的部分。5xx 比例偏高，通常意味着服务端在蜘蛛压力下不稳定；大量 404 说明入口页里存在失效链接；301 数量异常，往往是跳转链路拉得太长。响应时间方面，如果同一批 URL 的慢请求比例明显高于日常水平，就要检查是否有慢查询或外部接口在拖后腿。

另外，蜘蛛常用 HEAD 请求探测页面是否更新，这类请求不应算作完整抓取，统计时最好单独分开。

日志本身的配置注意点

• 开启 $request_time 与 $upstream_response_time，区分网络耗时和后端耗时
• 完整记录 User-Agent，不要截断，否则无法核对蜘蛛身份
• 设置按天轮转和保留周期，避免日志写满磁盘导致服务异常
• 如果流量较大，可以只对蜘蛛 UA 单独写一份日志，便于分析

几个常见的误判

1. 把请求量等同于抓取量：日志记录的是请求，蜘蛛可能只取头部就断开
2. 只看总请求数：几千次请求集中在少数 URL 上，实际覆盖的页面可能只有几十个
3. 忽略 HEAD 请求：用探测请求判断抓取效率，结论会偏乐观
4. 把日志当成收录证据：抓取和收录是两件事，日志只能说明蜘蛛来过

可落地的使用建议

1. 保留至少 30 天原始日志，按天切分，方便对比趋势变化
2. 把日志导入本地分析工具，按 UA、状态码、路径做交叉统计
3. 每周固定看一次蜘蛛抓取 TOP URL 与状态码分布，形成自己的基线
4. 发现 5xx 或响应时间突增，先排查服务端，再考虑调整入口页结构
5. 对疑似伪装的 IP 优先限速，而不是直接封禁，避免误伤真实蜘蛛

日志只是观测手段，它能告诉你蜘蛛来了、抓了什么、拿到了什么响应，但不能保证某个页面一定被收录。把它当作排查工具，而不是效果承诺。