聚合报表替代不了原始日志
后台的抓取统计看起来方便，但它是加工过的结果：有延迟、有采样，还会把不同来源混在一起。当你需要判断某个具体目录是不是被反复抓取，或者某一类页面是不是长期返回异常，最后还是得回到服务器日志。日志本身不做判断，它只是把事情按原样记下来，判断的部分要自己来。
做法上不用一开始就追求复杂。把日志按三个层次过一遍：抓取频次、状态码、URL 落点。这三层看完，日常大部分疑问都能有个方向。
分析之前先统一前提
不同服务器、不同 CDN 输出的日志字段顺序并不一致，直接拿两份日志对比很容易得出错误结论。动手前先确认几件事：时间用的是哪个时区、有没有开启压缩或采样、反向代理有没有改写真实 IP。前提弄错，后面所有结论都要打折扣。
至少要留下的字段
- 访问时间
- 客户端 IP 与 User-Agent
- 请求方法与完整 URL，包含查询串
- 状态码与响应体大小
- 响应耗时
第一层：抓取频次，看趋势也看集中度
把蜘蛛的请求单独筛出来，按天统计总量，先看曲线是否平稳。忽然翻倍或腰斩，通常对应着站点这边有动作：改过 robots.txt、上过新栏目，或者服务器出过一段时间的异常。把日志和操作记录放在一起对，因果关系会清楚很多。
总量之外还要看集中度。如果八成的抓取都落在少数几个列表页和参数页上，说明注意力被这些页面吃掉了，详情页和正文页拿到的份额并不多。这时候要考虑的是入口的分配问题，而不是单纯想办法让蜘蛛来得更勤。
频次下降不一定是坏事，可能只是把重复入口收掉了；频次上升也不一定是好事，要看新增的抓取到底落在了哪里。
第二层：状态码，先分清正常与异常
按状态码分组统计，把 2xx、3xx、4xx、5xx 的占比列出来，再看各自的走向。
- 5xx：优先处理，服务端在蜘蛛面前出错，比什么都伤。
- 404：看是否集中在一批已经下线的旧地址上。如果集中，考虑做一次批量清理或统一改跳。
- 3xx：留意同一条跳转是不是被反复走，一条链跳三次以上就该想办法收成一步。
- 2xx：注意响应体很小、耗时却很长的 200，这类页面未必真的有效。
第三层：落点分布，看蜘蛛实际走到了哪
把请求 URL 按目录聚合，对照站点结构看一遍。哪些栏目被爬得勤，哪些栏目几乎没人来。差异明显的时候先怀疑入口：那个栏目在导航里是不是太深，内链是不是只靠一个总入口，栏目页自身有没有值得继续往下走的链接。
同时看新 URL 的首次出现时间。新页面从发布到第一次被抓，这个间隔能反映站点被关注的程度。间隔变长，就回头检查链接通路和 Sitemap 提交通道，而不是急着改内容。
几个常见的误读
- 把正常访客的请求当成蜘蛛，或者反过来，把伪装 UA 的采集当成搜索引擎。
- 只看一天的数据就下结论。抓取本身有波动，看一周更稳。
- 忽略时区，把两天的数据拼成一天，曲线自然对不上。
- 只看 CDN 边缘节点的日志，没看回源记录，两者对不上时先查缓存命中。
把日志结论转成待办
日志分析的价值在于落到动作上。建议每次看完只留三到五条具体待办，比如某个目录的错误比例要降下来、某条重定向链要收短、新栏目要补两个内链入口。写清负责人和复查时间，下次看日志时先核对上一轮待办有没有生效。
频率上，粗看一周一次就够，每月做一次完整的分层统计。不必追求把日志读得多精细，能把频次、状态码、落点这三层看明白，日常问题基本就有方向了。