各類站長後台给出的都是匯總資料：抓取總次數、平均响應時間、错誤比例。匯總适合看趋势，但很难回答更具体的問题，比如哪一類 URL 在反复触發 5xx，蜘蛛是不是把大半時間花在了篩選參數頁上。服務器訪問日誌儲存的是每條請求的原始行，粒度最细，配合简單的命令行篩選或日誌工具就能查。不用指望一次翻日誌解决所有問题，更實际的做法是固定周期，只盯几個指标，長期對比變化。
先確認日誌里有哪些字段
- 訪問時間與时区，確認統計口径一致；
- 客戶端 IP，用来区分不同来源的抓取；
- User-Agent，识別蜘蛛與普通訪客；
- 請求方法與完整 URL，包含路径與查询串；
- 狀態碼與响應字节數；
- 响應時間，前提是服務器配置里记錄了這項；
- Referer，偶尔能看出異常外鏈来源。
如果日誌里没有响應時間字段，可以先在 Web 服務器配置中补上，後續排查慢响應會方便很多。
按狀態碼分组，先看異常的部分
5xx
任何 5xx 都值得追。把出現 5xx 的 URL 單獨拉出来，看是集中在某個栏目、某個接口，還是随机分布。集中的通常是代碼或資料库問题，分散的可能是超时或资源不足。同时留意时段分布，是否有規律地出現在某個時間点。
404 與软 404
404 分两類：本来就该消失的舊地址，以及因為連結寫错、模板漏參而新产生的死鏈。前者可以放着，後者要及时修。還有一類頁面返回 200 但内容為空，日誌里看不出来，需要抽样訪問確認，也就是常说的软 404。
301 與 302
大量 301 集中指向同一個目标，通常說明站内連結没有直接更新，仍然在走舊地址。鏈路越長，跳轉次數越多，趁早把内鏈改到最终地址更省事。
按目錄和 URL 分组，看抓取落在哪
把日誌里的 URL 去掉查询串後按一級目錄聚合，能得到一張抓取分布表。重点看两件事：核心内容目錄是否拿到了足够多的抓取，參數頁、搜尋结果頁、無限翻頁是否占用了過大比例。
如果某類低價值地址反复被抓，可以考虑收敛入口、清理站内連結，或者在 robots.txt 里做更细的限制，而不是直接屏蔽整個目錄。
抓取频次與时段
統計每天来自各搜尋引擎的抓取次數，能看出大致节奏。突然放量，可能是站内新增了大量連結，也可能是頁面结构變化導致蜘蛛反复回訪。突然掉到接近零，除了站点本身的問题，也可能是服務器返回了大量错誤，先去核對狀態碼分布。
时段分布也有參考價值。如果抓取集中在深夜而白天几乎没有，同时白天站点响應明顯變慢，說明响應速度可能已经影响到抓取安排。
几個容易被忽略的细节
- 同一個 URL 被不同的 User-Agent 反复請求，可能有采集或镜像行為；
- Referer 是自己站点的域名，属于正常内鏈跳轉；
- 大量請求集中在登入、提交、搜尋這類動態入口，需要评估是否值得；
- HEAD 請求和图片請求也會計入日誌，統計时最好分開看。
把检查落成固定動作
- 確認日誌按天切分並有足够保留期，至少覆盖一個完整對比周期；
- 每周導出一次蜘蛛請求，按狀態碼、目錄两個维度各出一張表；
- 记錄当期 5xx 數量、新增失效地址、核心目錄抓取占比；
- 對比上一期，只處理變化明顯的項，避免為了數字好看做無意义的改動；
- 處理過的問题寫進简單记錄，下次遇到相似現象可以直接對照。
日誌是現象，不是结论。看到異常先確認是不是統計口径或采集方式造成的，再動手改站点。
日誌分析不需要复杂工具，一行命令加一張表格就能開始。它的價值不在某一次排查，而在于長期坚持之後，你對站点被抓取的方式有了稳定的判断依據。