不少站点运营判断抓取情况，主要看搜尋资源平台後台的抓取統計和第三方工具。這些資料有參考價值，但都有延迟和聚合，遇到具体問题——某個栏目突然没人来、某類頁面抓取量掉下去——很难定位到原因。服務器日誌是原始請求记錄，能回答一個更具体的問题：谁在什么時間、用什么方式、訪問了哪個地址、返回了什么。
日誌里值得看的几類字段
一行訪問日誌通常包含時間、来源 IP、User-Agent（里面含蜘蛛标识）、請求方法、URL（含查询參數）、狀態碼、响應時間、返回字节數、Referer。不需要逐條阅讀，先按维度聚合再看。
- 狀態碼：200、3xx、4xx、5xx 各占多少，集中在哪些路径。
- URL 结构：抓取最多的是列表頁、詳情頁，還是带一堆參數的地址。
- 响應時間：哪些地址明顯偏慢，是否集中在某個接口或某個时段。
- 来訪节奏：同一類頁面多久被訪問一次，新頁面多久後出現。
先看狀態碼分布，再看具体頁面
狀態碼分布突然變化，往往比绝對值更有意义。比如 404 的數量突然翻倍，可能是改版後某批地址失效；5xx 集中在某個时段，可能是資料库或外部接口在拖後腿。
- 404 集中在哪几個路径，是否被反复抓取，而不是抓一次就放弃。
- 301 和 302 是否過多，是否存在跳轉鏈。
- 200 的頁面里，有多少是重复地址（大小寫、參數、结尾斜杠不同）。
先看趋势，再看單條记錄。只看某一天的绝對值，很容易被一次異常流量带偏。
看 Spider 的抓取深度
如果蜘蛛長期只在首頁和几個主要列表頁打轉，很少深入栏目下的詳情頁，通常說明站内連結路径有問题，或者入口太深。可以在日誌里統計：
- 被抓取的頁面總數量，以及其中属于深层目錄的比例。
- 同一批參數地址是否被反复抓取，占用了多少請求。
- 新發布的内容，從上线到第一次被抓取間隔多久。
這些數字不需要非常精确，横向對比几周就能看出變化。
响應時間與超时
抓取程序也有等待上限。一個地址長期响應很慢，或者偶尔直接超时，被抓取的频率往往會下降。把日誌里响應時間最長的一批地址挑出来，看看是資料库查询慢、調用了外部接口，還是頁面引用了体积過大的资源。這類問题通常在服務器侧解决，比在内容侧反复調整更有效。
參數與重复地址的干扰
带跟踪參數、带 session id、大小寫不一致的地址，经常在日誌里反复出現。這類抓取不會带来新内容，却會分散抓取額度。把相同路径、不同參數的訪問量聚合一下，如果某個參數组合的訪問量明顯偏高，就值得考虑统一處理，例如規范連結、限制參數入口。
日誌和統計工具對不上很正常
統計工具依赖頁面脚本执行，會被广告拦截、脚本加载失敗影响；日誌记錄的是服務器實际收到的請求。两者數量對不上是常態，不用急着下结论。可以先比較同一時間段的量級差异，再看某一類頁面是否異常。
把日誌分析變成固定動作
- 日誌至少保留一個月，並配置轮轉，避免磁盘被寫满。
- 每周導出一次聚合结果，记錄狀態碼分布、抓取量、抓取最多的地址。
- 每月和上月對比一次，重点看趋势而不是某一天的峰值。
- 發現問题时，把具体 URL 單獨拿出来驗證，而不是只看匯總數字。
几個容易踩的坑
- 只看抓取總量，不看被抓的是哪些頁面。
- 看到 4xx 就紧張，其實有一部分是正常的探测請求。
- User-Agent 可以伪造，日誌里标着蜘蛛的不一定真是蜘蛛，必要时结合 IP 段核對，但不要图省事整段封禁。
- 日誌太大就放弃分析。其實按小时抽样，或者只聚合狀態碼和路径，已经能看出大部分問题。
日誌分析不需要复杂工具，一條命令或一個小脚本的聚合结果就能說明不少事。真正有價值的是把它變成每周固定的動作，而不是等到排名波動了才回头翻文件。