抓取路径出問题时，很多人第一反應是去看後台的抓取統計或收錄曲线，但這些資料通常已经過一层聚合，看不出具体断在哪一步。服務器訪問日誌是更原始的證據：每次請求的時間、URL、狀態碼、UA、响應字节數都记在里面。学會讀它，等于把蜘蛛在站点里的行走轨迹摊開来看。
先確認哪些請求真的来自搜尋引擎
UA 字符串可以随意伪造，一條寫着 Googlebot 的记錄並不代表真是它。判断依據至少有两個：做反向 DNS 解析確認 IP 归属，以及核對官方公布的 IP 段。做不到全量驗證时，也可以先按 IP 段過滤，再结合 UA 和請求行為看。
日誌里值得重点看的几列
- 時間：抓取是持續發生還是集中在某几分钟，是否跟發布节奏同步。
- URL 路径：带參數的、大小寫不同的、带與不带尾斜杠的，先分開統計，重复入口往往在這里露头。
- 狀態碼：200、301/302、304、404、5xx 各占多少，5xx 集中在哪些前缀下。
- 响應時間：慢的路径通常抓取频次會下滑，這是服務器侧對抓取路径最直接的影响。
- UA 與 IP：用来区分不同搜尋引擎，也用来识別伪装爬虫。
三類典型問题在日誌里的样子
路径走两步就断
入口頁有稳定的 200 抓取，但入口頁正文里指向下一层的 URL 在日誌里几乎没有记錄。多數情况不是蜘蛛不想走，而是那些連結在 HTML 里根本不存在——靠 JS 渲染、靠点击才插入，或者被属性挡住了。對照頁面源碼里的原始 HTML 核對一遍就能確認。
抓取集中在少數 URL
同一個列表頁一天被訪問几十次，深层内容頁一周只有一两次。這通常說明入口太窄：站点的内鏈资源压在首頁和少數几個栏目頁上，蜘蛛每次来都在原地打轉。日誌上表現為路径分布的头部极重、尾巴极長。
5xx 與超时增多
日誌里出現成片的 500、502、503，或者响應時間明顯拉長，接下来几天的抓取频次往往會下降。這更像抓取調度在做自我保護，而不是惩罚，服務恢复稳定後一般會回来。要留意 CDN 缓存：命中缓存的請求不一定落到源站日誌里，只看源站日誌容易低估實际抓取量，最好把邊缘节点日誌或负载均衡日誌一起看。
把日誌和 Sitemap、内鏈對照起来
Sitemap 里提交了几萬條 URL，日誌里只被請求過几百條，說明 Sitemap 更像一份备用清單，真正带路的還是内鏈结构。反過来，如果日誌里出現大量你既没提交、也不在任何内鏈上的 URL，那多半是參數拼接或歷史遗留入口在漏。
一個可执行的小流程
- 過滤出真實蜘蛛請求，按周導出日誌片段。
- 按狀態碼和路径前缀分组，找出占比異常的那一组。
- 抽 10 到 20 條被反复抓取的 URL，和實际頁面内容、内鏈位置對照。
- 抽 10 到 20 條從未被抓取的 URL，检查它們在 HTML 里是否真的可点、是否被属性挡住。
- 改完後保持同样的統計口径，观察两到四周的變化。
日誌反映的是已经發生的事。改動之後要给蜘蛛一個重新爬取的周期，短期資料波動不必急着下结论。
把日誌分析放進常規巡检：每周掃一次狀態碼分布和路径集中度，比等到收錄出問题再回头排查要省力得多。抓取路径的修复，往往是内鏈、Sitemap 和服務器响應三者一起調整的结果，只改其中一處，效果通常有限。