搜尋引擎蜘蛛每天来几次、抓了哪些 URL、哪些請求是白跑一趟，答案通常就躺在服務器的訪問日誌里。相比在站長平台看匯總資料，日誌能落到具体的 URL 和具体的時間点，排查問题时更直接。這篇文章讲的是怎么把日誌讀成一份能用的抓取报告。
日誌里必须先记全的字段
不少服務器的預設日誌格式只保留 IP、時間、方法、URL、狀態碼這五項，用来复盘抓取是不够的。建议至少补齐下面這些：
- User-Agent，用来切分来源
- 响應時間
- 返回字节數
- Referer，多數蜘蛛請求為空，可作為辅助判断
- 如果有 CDN，把邊缘處理時間和回源時間分開记錄
响應時間和字节數决定了你能不能看出“這個頁面被抓了但没有内容”或者“服務器是從哪一刻開始變慢的”。缺了這两項，很多结论只能靠猜。
把搜尋蜘蛛的請求單獨切出来
第一步是按 UA 過滤，把常见的搜尋蜘蛛單獨導成一份。要注意 UA 是可以伪造的，如果要做嚴谨判断，還得拿 IP 段和反向 DNS 做交叉核對。這一步可以定期做一次，不必每次分析都重跑。
過滤之後，手上就有一份只有蜘蛛的請求列表了。接下来關注的是分布，而不是總數。
五個值得看的分布
- 狀態碼分布：200、304、301/302、404、5xx 各占多少。5xx 一旦抬头，通常意味着服務器在抓取时段扛不住。
- 抓取频次的時間分布：蜘蛛的活動时段相對固定，如果某天開始明顯偏移，往往是抓取队列調整，或者站点响應變慢導致的。
- URL 目錄分布：抓取量集中在哪些路径，深层目錄是不是長期為零。
- 按小时統計的平均响應時間：超過某個阈值之後，抓取量一般會跟着往下走。
- 重复抓取的 URL：同一個地址在短時間内被反复請求，常见原因是内容频繁變動、重定向或者參數带来的多地址問题。
三種典型的日誌形態
狀態碼 200，但字节數很小
這多半是空列表、占位頁，或者模板渲染失敗後返回了一個空壳。蜘蛛認為抓到了内容，實际上没有可用的東西。找到那几個 URL 對照一下，判断是分頁取空、接口超时，還是渲染组件没加载出来。
大量 404 集中在同一個模板
如果 404 的 URL 有共同的前缀或者參數结构，通常是連結生成逻辑出了問题，比如列表里輸出了已经下线的 ID。修复之後 404 會在几天内回落，但要留意蜘蛛不會立刻停止訪問老地址，短期内看到残留是正常的。
5xx 突發，随後抓取量下降
顺序一般是：服務器先报错，蜘蛛识別到错誤後降低抓取频率，之後一段時間抓取量都偏低，即使服務恢复了也要等一等才回到原来的水平。所以發現 5xx 的第一件事是止血，先把错誤返回压下去，而不是接着观察曲线。
從日誌回到站内動作
日誌本身不解决問题，它只是把問题指出来。常见的對應動作可以這样排：
- 目錄長期零抓取：检查内鏈是否可達、Sitemap 是否覆盖、有没有 noindex 或 robots 拦截。
- 抓取量只集中在浅层：检查分頁的下一頁是否可点，深层内容有没有別的入口。
- 响應時間上升：分辨是資料库查询、图片资源還是第三方脚本，優先處理拖慢首字节的部分。
- 重复抓取：確認是否存在參數造成的多個地址指向同一内容，用 canonical 归一。
- 狀態碼異常：先修服務端返回，再考虑重定向和清理死鏈。
日誌的價值在于把“蜘蛛抓得不理想”這種模糊感受，變成一個能定位到 URL 和時間的具体問题。建议保留至少 30 天的原始日誌，並在每次改動上线後，對比前後两周的抓取分布，看看改動到底带来了什么變化。