不少站点运营判断抓取情况，主要看搜索资源平台后台的抓取统计和第三方工具。这些数据有参考价值，但都有延迟和聚合，遇到具体问题——某个栏目突然没人来、某类页面抓取量掉下去——很难定位到原因。服务器日志是原始请求记录，能回答一个更具体的问题：谁在什么时间、用什么方式、访问了哪个地址、返回了什么。
日志里值得看的几类字段
一行访问日志通常包含时间、来源 IP、User-Agent（里面含蜘蛛标识）、请求方法、URL（含查询参数）、状态码、响应时间、返回字节数、Referer。不需要逐条阅读，先按维度聚合再看。
- 状态码：200、3xx、4xx、5xx 各占多少，集中在哪些路径。
- URL 结构：抓取最多的是列表页、详情页，还是带一堆参数的地址。
- 响应时间：哪些地址明显偏慢，是否集中在某个接口或某个时段。
- 来访节奏：同一类页面多久被访问一次，新页面多久后出现。
先看状态码分布，再看具体页面
状态码分布突然变化，往往比绝对值更有意义。比如 404 的数量突然翻倍，可能是改版后某批地址失效；5xx 集中在某个时段，可能是数据库或外部接口在拖后腿。
- 404 集中在哪几个路径，是否被反复抓取，而不是抓一次就放弃。
- 301 和 302 是否过多，是否存在跳转链。
- 200 的页面里，有多少是重复地址（大小写、参数、结尾斜杠不同）。
先看趋势，再看单条记录。只看某一天的绝对值，很容易被一次异常流量带偏。
看 Spider 的抓取深度
如果蜘蛛长期只在首页和几个主要列表页打转，很少深入栏目下的详情页，通常说明站内链接路径有问题，或者入口太深。可以在日志里统计：
- 被抓取的页面总数量，以及其中属于深层目录的比例。
- 同一批参数地址是否被反复抓取，占用了多少请求。
- 新发布的内容，从上线到第一次被抓取间隔多久。
这些数字不需要非常精确，横向对比几周就能看出变化。
响应时间与超时
抓取程序也有等待上限。一个地址长期响应很慢，或者偶尔直接超时，被抓取的频率往往会下降。把日志里响应时间最长的一批地址挑出来，看看是数据库查询慢、调用了外部接口，还是页面引用了体积过大的资源。这类问题通常在服务器侧解决，比在内容侧反复调整更有效。
参数与重复地址的干扰
带跟踪参数、带 session id、大小写不一致的地址，经常在日志里反复出现。这类抓取不会带来新内容，却会分散抓取额度。把相同路径、不同参数的访问量聚合一下，如果某个参数组合的访问量明显偏高，就值得考虑统一处理，例如规范链接、限制参数入口。
日志和统计工具对不上很正常
统计工具依赖页面脚本执行，会被广告拦截、脚本加载失败影响；日志记录的是服务器实际收到的请求。两者数量对不上是常态，不用急着下结论。可以先比较同一时间段的量级差异，再看某一类页面是否异常。
把日志分析变成固定动作
- 日志至少保留一个月，并配置轮转，避免磁盘被写满。
- 每周导出一次聚合结果，记录状态码分布、抓取量、抓取最多的地址。
- 每月和上月对比一次，重点看趋势而不是某一天的峰值。
- 发现问题时，把具体 URL 单独拿出来验证，而不是只看汇总数字。
几个容易踩的坑
- 只看抓取总量，不看被抓的是哪些页面。
- 看到 4xx 就紧张，其实有一部分是正常的探测请求。
- User-Agent 可以伪造，日志里标着蜘蛛的不一定真是蜘蛛，必要时结合 IP 段核对，但不要图省事整段封禁。
- 日志太大就放弃分析。其实按小时抽样，或者只聚合状态码和路径，已经能看出大部分问题。
日志分析不需要复杂工具，一条命令或一个小脚本的聚合结果就能说明不少事。真正有价值的是把它变成每周固定的动作，而不是等到排名波动了才回头翻文件。