站点抓取出問题时，很多人的第一反應是改 Sitemap、加内鏈、提交一批 URL。這些動作本身没错，但它們都是在"猜蜘蛛會怎么走"。更稳的做法是先看資料：蜘蛛實际走了哪些路径，在哪個环节停下来。這篇文章讲一個可重复的排查流程——把日誌、狀態碼和内鏈整理成三張表，然後對着看。
第一步：取一段可比的日誌
日誌分析最容易犯的错，是拿一段不具代表性的資料下结论。几個基本要求：
- 時間窗要连續，通常取 7 天左右，避開大促、發版当天這類抓取行為異常的时段。
- 先核對身份，不要只看 UA 字符串。用反向 DNS 或已知 IP 段驗證，把模拟請求和真蜘蛛分開統計。
- 過滤静態资源，只保留 HTML 文档請求，否則 CDN 上的图片請求會把資料冲淡。
- URL 归一化，统一大小寫、末尾斜杠、跟踪參數，把 ?utm_source= 這類噪声去掉，否則同一個頁會被算成十几條记錄。
做完這四步，你手上才有一份能和上周、下個月對比的基础資料。
第二步：三張表分別看什么
日誌表
按目錄聚合，看三個指标：抓取總次數、该目錄下 URL 的首抓時間分布、以及抓取量在目錄之間的比例。重点不是绝對值，而是比例是否和目錄的重要程度匹配。
狀態碼表
統計每個目錄下 200、301、404、5xx 的占比。如果某個目錄的 5xx 集中在少數几個接口上，問题通常不在連結结构，而在服務端。301 比例過高則說明站内連結還没更新到最终地址，蜘蛛每次都要多走一步。
内鏈表
對重要 URL 记錄：入鏈數量、入鏈所在的层級（首頁、栏目頁、詳情頁）、以及最近一次被連結的時間。這張表反映的是"你希望蜘蛛走的路"，和日誌表對照才有意义。
第三步：交叉核對，识別常见堵点
- 内鏈多但日誌里几乎不出現：多半卡在 robots 規則、canonical 指向了別的地址，或者這些連結是 JS 渲染後才插入的，蜘蛛拿到的初始 HTML 里並没有。
- 日誌里只有列表頁前几頁：分頁被"加载更多"按钮取代，或者後頁 URL 带上篩選參數後被規則拦下，路径在第 3、4 頁就断了。
- 某目錄 5xx 集中出現：常见于缓存穿透或慢查询。蜘蛛遇到连續错誤會退避，恢复後也不會立刻回到原来的抓取节奏，所以日誌上會看到一段明顯的空白。
還有一類不容易發現的：抓取次數正常，但抓的都是同一批老 URL，新頁面的首抓時間一直往後拖。這通常是站点缺少让蜘蛛判断"有新内容"的信号，比如列表頁不更新、Sitemap 的 lastmod 長期不變。
第四步：調整时控制變量
找到堵点後，別一次性把 Sitemap、内鏈、跳轉全部改掉，那样最後無法判断是哪一步起了作用。建议：
- 一次只改一處，记錄改動日期。
- 固定同一批 URL 作為观察样本，比較改動前後的抓取次數與首抓時間。
- 给自己留一個抓取周期（通常一到两周）再下结论，中間不要频繁變動。
- 服務端問题優先修，連結结构問题其次——服務器一直报错时，改内鏈的效果會被完全掩盖。
蜘蛛的抓取路径是结果，不是原因。狀態碼、内鏈和清單文件，都只是它讀到的輸入。
小结
排查抓取問题，與其反复調整清單文件，不如先把日誌、狀態碼、内鏈三張表整理清楚，找出蜘蛛實际停下的那一段。定位准了，改動往往很小；定位不准，改動越多，越难判断效果。