想搞清楚搜尋蜘蛛到底爬了哪些頁面、漏了哪些 URL，服務器日誌是最直接的一手资料。第三方工具能给出趋势，但具体到一條路径、一個目錄，只有日誌能回答。下面這套讀法适用于大多數 Nginx、Apache 或 CDN 回源日誌。
先確認日誌里的“蜘蛛”是不是真的
User-Agent 可以随意伪造，只按關鍵詞過滤，很容易把采集脚本当成搜尋蜘蛛。更稳妥的做法是组合判断：IP 反查確認归属，再叠加行為特征，比如是否請求過 robots.txt、請求频率是否稳定、是否几乎不携带 Cookie、是否只抓 HTML 和少量静態资源。
- 真蜘蛛一般會先讀 robots.txt，再按自己的顺序抓頁面；
- 請求节奏相對平稳，很少出現每秒數千次的突發；
- 對同一 URL 的重复請求有間隔，而不是连續轰炸。
一行日誌里值得看的字段
字段不用全看，抓住六七個就够：
- URL（含參數）：判断抓取覆盖面，也能發現參數被日誌系統截断的情况；
- 狀態碼：200 是正常抓取，301/302 說明走了跳轉，404/410 說明地址失效，429/503 說明被限流或服務器不稳；
- 响應体大小：長期偏小往往是空模板、软 404 的信号；
- 响應時間：和抓取频次放在一起看，能看出抓取节奏有没有被拖慢；
- 時間：用来還原請求顺序；
- User-Agent：只作參考，不作為唯一依據。
從日誌還原抓取路径
Referer 不是每台蜘蛛都會带，別把路径還原完全押在它上面。更實际的做法，是把同一 IP 在一段時間内的請求按時間排序，观察請求的前後關系：它先進的是列表頁還是詳情頁？是否從首頁一层层往下走？
再和另外两份材料交叉驗證：一是你提交過的 Sitemap，二是站内的連結结构图。三者對得上，說明路径是通的；對不上，問题通常出在内鏈或渲染环节。
路径還原是概率判断，不是精确追踪。同一個 IP 也可能對應多個抓取任務，结论要留有余地。
URL 發現：把日誌里的地址分成三類
- 被反复抓取的 URL：通常是首頁、栏目頁和更新频繁的詳情頁，說明它們在内鏈和 Sitemap 里的位置比較靠前；
- 只被抓過一次就消失的 URL：可能是内容更新少、狀態碼異常，或者被判定為低價值；
- 從未出現過的 URL：最值得排查，常见原因是被 robots.txt 拦截、只存在于 JS 渲染後的内容里、没有任何内鏈指向、被 noindex 或規范标簽指向了別的地址。
第三類不用一次全查，先挑业務上重要的目錄看，效率更高。
Sitemap 和内鏈到底有没有起作用
提交 Sitemap 後，日誌里通常會出現两條线索：蜘蛛對 Sitemap 文件本身的請求，以及随後對新 URL 的抓取。两者之間往往有間隔，不必因為当天没動静就反复改文件。
内鏈調整的效果更容易观察：改完連結位置或锚文本後，看目标 URL 的抓取频次和首次出現時間有没有變化。如果几天内毫無變化，再回头检查是不是被 JS 加载、被屏蔽，或者連結指向了跳轉地址。
三種容易讀错的日誌
- CDN 邊缘日誌：缓存命中不會产生回源记錄，源站日誌看起来“蜘蛛没来”，實际是邊缘节点响應了；
- 采样或压缩日誌：被抽样的日誌不能用来統計精确抓取量，只能看大致分布；
- 參數被截断：日誌系統為了省空間會砍掉查询串，看到“同一 URL 被反复抓”时先確認不是记錄問题。
一份可以照着做的排查流程
- 按 IP 段過滤出真實蜘蛛請求，導出最近 7 天資料；
- 按 URL 目錄分组，統計各目錄的抓取次數與狀態碼分布；
- 挑出“零抓取”的重要目錄，逐一检查 robots、内鏈、渲染方式和規范标簽；
- 對比 Sitemap 中的 URL 與日誌中出現的 URL，找出長時間未被抓取的部分；
- 查看抓取高峰时段是否與服務器压力、备份任務重叠；
- 记錄改動時間和内容，两周後再對比一次日誌，看變化是否稳定。
日誌不會直接告诉你该怎么改，但它能把“猜”變成“看”。坚持按目錄、按狀態碼定期過一遍，抓取問题通常會比想象中更容易定位。