聚合报表替代不了原始日誌
後台的抓取統計看起来方便，但它是加工過的结果：有延迟、有采样，還會把不同来源混在一起。当你需要判断某個具体目錄是不是被反复抓取，或者某一類頁面是不是長期返回異常，最後還是得回到服務器日誌。日誌本身不做判断，它只是把事情按原样记下来，判断的部分要自己来。
做法上不用一開始就追求复杂。把日誌按三個层次過一遍：抓取频次、狀態碼、URL 落点。這三层看完，日常大部分疑問都能有個方向。
分析之前先统一前提
不同服務器、不同 CDN 輸出的日誌字段顺序並不一致，直接拿两份日誌對比很容易得出错誤结论。動手前先確認几件事：時間用的是哪個时区、有没有開啟压缩或采样、反向代理有没有改寫真實 IP。前提弄错，後面所有结论都要打折扣。
至少要留下的字段
- 訪問時間
- 客戶端 IP 與 User-Agent
- 請求方法與完整 URL，包含查询串
- 狀態碼與响應体大小
- 响應耗时
第一层：抓取频次，看趋势也看集中度
把蜘蛛的請求單獨筛出来，按天統計總量，先看曲线是否平稳。忽然翻倍或腰斩，通常對應着站点這邊有動作：改過 robots.txt、上過新栏目，或者服務器出過一段時間的異常。把日誌和操作记錄放在一起對，因果關系會清楚很多。
總量之外還要看集中度。如果八成的抓取都落在少數几個列表頁和參數頁上，說明注意力被這些頁面吃掉了，詳情頁和正文頁拿到的份額並不多。這时候要考虑的是入口的分配問题，而不是單纯想办法让蜘蛛来得更勤。
频次下降不一定是坏事，可能只是把重复入口收掉了；频次上升也不一定是好事，要看新增的抓取到底落在了哪里。
第二层：狀態碼，先分清正常與異常
按狀態碼分组統計，把 2xx、3xx、4xx、5xx 的占比列出来，再看各自的走向。
- 5xx：優先處理，服務端在蜘蛛面前出错，比什么都伤。
- 404：看是否集中在一批已经下线的舊地址上。如果集中，考虑做一次批量清理或统一改跳。
- 3xx：留意同一條跳轉是不是被反复走，一條鏈跳三次以上就该想办法收成一步。
- 2xx：注意响應体很小、耗时却很長的 200，這類頁面未必真的有效。
第三层：落点分布，看蜘蛛實际走到了哪
把請求 URL 按目錄聚合，對照站点结构看一遍。哪些栏目被爬得勤，哪些栏目几乎没人来。差异明顯的时候先怀疑入口：那個栏目在導航里是不是太深，内鏈是不是只靠一個總入口，栏目頁自身有没有值得繼續往下走的連結。
同时看新 URL 的首次出現時間。新頁面從發布到第一次被抓，這個間隔能反映站点被關注的程度。間隔變長，就回头检查連結通路和 Sitemap 提交通道，而不是急着改内容。
几個常见的誤讀
- 把正常訪客的請求当成蜘蛛，或者反過来，把伪装 UA 的采集当成搜尋引擎。
- 只看一天的資料就下结论。抓取本身有波動，看一周更稳。
- 忽略时区，把两天的資料拼成一天，曲线自然對不上。
- 只看 CDN 邊缘节点的日誌，没看回源记錄，两者對不上时先查缓存命中。
把日誌结论轉成待办
日誌分析的價值在于落到動作上。建议每次看完只留三到五條具体待办，比如某個目錄的错誤比例要降下来、某條重定向鏈要收短、新栏目要补两個内鏈入口。寫清负责人和复查時間，下次看日誌时先核對上一轮待办有没有生效。
频率上，粗看一周一次就够，每月做一次完整的分层統計。不必追求把日誌讀得多精细，能把频次、狀態碼、落点這三层看明白，日常問题基本就有方向了。