很多站点的問题不是“蜘蛛不来”，而是来了之後走不遠。首頁有抓取记錄，栏目頁偶尔出現，再往里的詳情頁几乎没有動静。這種时候繼續加大提交量、堆 Sitemap，效果通常有限——路径中間已经断了，蜘蛛到不了後面。

先分清是“抓不到”還是“抓得慢”

在服務器日誌里按天筛一遍，把被抓的 URL 按目錄层級归類。如果某一层級的 URL 從头到尾都是零，那更像是路径断点；如果每一层都有，只是數量偏少，那更像抓取频次和速率的問题，两者的處理方向完全不同，別混在一起改。

断点常出現在四個位置

1. 入口頁自己能抓，但入口本身没被連結

新目錄、新专题頁如果只出現在首頁某個轮播位，或者靠 JavaScript 動態插入，蜘蛛第一跳未必能碰到。更稳妥的做法是在静態 HTML 里留一條普通的 a 标簽，位置不必顯眼，但要長期稳定存在。

2. 内鏈只在模板的邊角出現

• 相關推荐模块由前端請求填充，抓到的 HTML 里是空的；
• 列表頁只渲染前十條，其余靠“加载更多”按钮；
• 面包屑存在，但指向的是搜尋頁或带參地址，不是静態路径。

這些结构在用戶侧体驗不差，但對抓取路径来说等于把中間一段挖掉了。可以把一部分連結直接寫進首屏 HTML，哪怕只放十几條，也比全靠异步加载更容易被繼續跟進。

3. Sitemap 里的 URL 和站内實际情况對不上

Sitemap 是补充通道，不是替代品。如果里面混着大量 404、長跳轉鏈、noindex 頁面，蜘蛛按图索骥走一遍，收获的是一串無效地址，反而消耗了這次訪問的余量。定期把 Sitemap 與真實返回 200 的 URL 做比對，清理已经下线的條目，比新增條目更划算。

4. 爬到一半站点自己顶不住

抓取正在展開时，如果服務器開始返回 5xx、响應時間從几百毫秒跳到几秒，蜘蛛通常會主動降速甚至暫停。日誌上看起来就是“抓取量突然掉了一截”。這时候與其去調站点地图，不如先看這段時間的负载、慢查询和回源情况。

层級變深之後，路径需要重新设計

当站点從几百個 URL 涨到几萬個，原来“首頁—栏目—詳情”的三层结构往往撑不住。可以按主题或地域再补一层聚合頁，让每個詳情頁距离首頁不超過四跳；同时给聚合頁留稳定的内鏈入口，避免它們只靠 Sitemap 被發現，一旦 Sitemap 出問题就整体失联。

一個可以照着走的自查顺序

1. 取最近七天的日誌，按目錄层級統計被抓 URL 數量，找出断层的那一层；
2. 在浏览器禁用 JavaScript，訪問断层上一层的頁面，看能否看到指向下一层的連結；
3. 抽查断层层的 URL，確認返回碼、canonical、robots 元标簽是否正常；
4. 把 Sitemap 與這批 URL 對照，去掉返回非 200 的條目；
5. 观察改動之後两三周的日誌，看是否出現了新的被抓层級。

路径顺畅之後，再谈节奏

路径打通只是让蜘蛛“能走到”，走得多快取决于站点還能给出多少余量。長期在线的站点，抓取深度自然會往下延伸；经常超时的站点，即使連結结构再規整，蜘蛛也會在某一层停住。

把内鏈、Sitemap 和服務器狀態当作同一條鏈路上的三段来看：任何一段断開，後面做得再细也發挥不出来。