抓取是否顺畅、蜘蛛走了哪些路径，很多时候答案不在後台报告里，而在服務器的原始日誌中。报告會做聚合與抽样，日誌則是逐條請求，能看清某一分钟谁来過、看了什么、拿到什么结果。排查 URL 發現或抓取断层的問题时，先把日誌讀顺，往往比反复提交 URL 更實际。
先確認請求里哪些是蜘蛛的
日誌里混着真實用戶、监控探针、CDN 回源和蜘蛛。最常见做法是用 User-Agent 做初筛，但 UA 可以伪造，建议再结合来源 IP 段的反向解析做交叉驗證。初筛时把 UA 字段單獨抽出来，建一份固定清單，之後每天用同一套規則過滤，结果才有可比性。
值得單獨留存的几個字段
- 請求時間與时区，用来對齐抓取节奏；
- 請求方法與完整 URL，带上查询參數，否則看不到篩選路径；
- 狀態碼，区分正常返回、跳轉與错誤；
- 响應時間，判断哪些頁面拖慢了整体节奏；
- User-Agent 與来源 IP，確認訪問者身份；
- Referer，判断蜘蛛是從哪條内鏈走到這一頁的。
把原始請求整理成三條视图
日誌是流水，直接翻容易眼花。建议固定做三種聚合，形成习惯後每次只看增量。
按 URL 分组看重抓节奏
同一個 URL 在一段時間内被訪問的次數、間隔、狀態碼是否稳定，能反映它值不值得被频繁回訪。如果一個頁面長期没人抓，先看它有没有被發現過，再看它的内鏈入口是否還在。
按 Referer 分组看内鏈线索
把 Referer 归類，可以看出蜘蛛主要沿着哪些頁面往里走。如果某個栏目頁几乎没有 Referer 指向它的子頁面，多半意味着這個栏目頁的出鏈有問题，或者連結由脚本渲染，蜘蛛在 HTML 里看不到。
按小时看抓取分布
抓取請求在一天内的分布能反映站点响應状况。如果某几個小时請求明顯减少，先排查那段時間是否有發布、备份或批量任務。服務器压力和抓取节奏常常互相牵连，把两件事放在一起看更容易找到原因。
日誌里比較常见的三類問题
- URL 已被發現但没有後續抓取，日誌里只有 Sitemap 拉取记錄，没有對應的頁面請求；
- 抓取反复落在參數版本上，說明規范連結或連結收敛没有做到位；
- 某段路径請求量正常但狀態碼频繁跳轉，鏈路里可能夹着一层不必要的中間地址。
日誌要和覆盖率报告對照着看
日誌反映的是“来過”，覆盖率报告反映的是“收没收”。两者對不上时，通常有三種情况：抓到了但没被采用、被采用但没進索引、或者根本没抓到。定位到具体 URL 之後，再回日誌里查它当天的請求记錄，比凭感觉猜测更快。
讀日誌的目标不是把每次抓取都记下来，而是找到反复出現的模式，再把模式對應到一處可以改的地方。
把结论落到具体改動
- 补入口：给孤岛頁面加上可点击的普通連結，而不是只在脚本里拼出来；
- 收敛路径：同一内容保留一個主地址，其余用跳轉或規范标簽處理；
- 稳定响應：把慢查询、超大頁面、频繁超时的资源排在修复清單前面；
- 更新 Sitemap：只放需要被發現、且能返回正常狀態的地址。
日誌本身是消耗品，存一段時間就够，但讀日誌的方法可以沉淀成固定的几個视图。每次網站结构、模板或服務器配置有變動，都用同一套视图复核一遍，抓取路径上的問题通常會在數字明顯變化之前就露出迹象。