站点出問题的时候，很多人第一反應是去後台看抓取統計，但那些數字是匯總過的，看不出具体路径。真正能回答“蜘蛛走過哪些 URL、在哪儿停住”的，通常是服務器自己的訪問日誌。它不讨好任何人，记錄的是一次次真實請求。
先確認日誌里有哪些列
不同环境導出的字段不一样，但排查 URL 發現和抓取路径，至少要能拿到這几項：
- 請求時間，最好精确到秒，注意时区；
- 請求方法與完整 URL，含查询參數；
- 狀態碼和响應字节數；
- User-Agent，用来区分不同搜尋蜘蛛與普通訪問；
- Referer，有的话可以還原它是從哪個頁面走到這里的。
如果站点前面挂了 CDN 或 WAF，日誌里的 UA 和 IP 可能已经被改寫，先確認拿到的是不是原始记錄，否則後面的判断都會偏。
狀態碼分布比抓取總量更有信息量
總量只說明蜘蛛来得多不多，狀態碼分布才說明它有没有走通。
几個值得單獨拉出来的信号
- 404 / 410：說明某些 URL 還在被別的頁面引用，但目标已经不存在，這條路径等于白走；
- 301 / 302：看跳轉层數，一层是正常的，三层以上會让蜘蛛在队列里多绕一圈；
- 5xx 與超时：属于服務器侧的問题，出現集中时段时，蜘蛛往往會主動压低该目錄的抓取频率；
- 304：属于正常复查，内容没變时的回應，不用当成異常。
把日誌和 Sitemap、内鏈交叉對照
最直接的做法是做两次差集。先把 Sitemap 里声明的 URL 拿出来，和日誌中出現過的 URL 比對：只存在于 Sitemap、日誌里几乎没出現過的，多半是站内没有入口的孤岛頁；反過来，日誌里被频繁抓取但不在 Sitemap 里的，往往是參數组合或歷史遗留地址，属于抓取预算的消耗項。
再把主要列表頁、栏目頁的内鏈導出，看看日誌里的抓取是否沿着這些連結往下走。如果某一层之後几乎没有請求，問题通常不在内容质量，而在連結本身没被解析出来。
几種反复出現的漏抓形態
- 分頁很深的列表頁之後的 URL，蜘蛛爬到第几頁就停了；
- 只有执行脚本後才出現在 DOM 里的連結，未被解析时等于不存在；
- 篩選、排序、追踪參數生成的 URL 汪洋，真正的詳情頁被稀释在中間；
- 只能通過站内搜尋或表單到達的頁面，没有任何可跟的連結；
- 服務器抖動期間反复超时的目錄，恢复後抓取节奏也需要一段時間才回来。
反推之後怎么驗證
根據日誌定位到問题，調整时尽量一次只改一處：补一條内鏈、收敛一類參數、修掉一批 5xx。改動之後繼續按周對比日誌，观察對應目錄的請求量、狀態碼和出現過的 URL 數量有没有變化。
這個過程没有捷径，也不需要每天翻。每周固定看一次，把差异记下来，几周之後路径的形状自然會清楚。
日誌是观察工具，它只能告诉你過去發生過什么，不能保證某條 URL 一定在某個時間被抓到。把它当成排查线索，而不是结果指标。