很多人排查抓取量的时候，习惯先看入口頁有没有被屏蔽、連結有没有寫對，却容易忽略一個更基础的問题：入口頁是不是能稳定、快速地返回。搜尋蜘蛛的每一次抓取都要占用時間和连接，如果入口頁响應慢、经常断在半路，抓取量往往不是慢慢减少，而是成片地掉。
搜尋蜘蛛遇到超时，會怎么處理
搜尋蜘蛛發起請求後不會無限等待。服務端迟迟不返回，請求就會被判定為超时或失敗。接下来大致會發生两件事：
- 它可能會重试，但重试次數有限，而且重试本身也要占用抓取配額。
- 如果某個入口頁或某個 IP 连續失敗，抓取频率會被主動压低，後續的抓取安排整体往後排。
所以“慢”带来的第一层损失，是這次没抓到；第二层损失，是本来可以分配给目标 URL 的抓取机會被消耗掉了。
入口頁常见的几類“慢”
- 首字节時間過高：入口頁是動態生成、每次都要查库或渲染，蜘蛛等的是服務端而不是網絡。
- 並發不够：服務器连接數偏小，蜘蛛和真實用戶抢资源，谁先来谁先卡。
- 被中間层拦住：CDN、防火墙或安全策略把搜尋蜘蛛的請求当成異常流量，返回驗證頁或直接断開。
- 頁面背了太重的资源：入口頁里塞了大量脚本和图片，服務端压力被拉高，返回變慢。
- 线路或解析不稳：DNS 解析慢、节点绕路，表現為忽快忽慢。
慢下来之後的连鎖反應
抓取量下降只是表面現象，往下看還有几個變化：
- 新 URL 的發現周期被拉長，入口頁里刚加的目标地址可能几天都等不到第一次訪問。
- 抓取日誌里超时和 5xx 的比例上升，有效抓取占比變小。
- 長尾入口頁長期排队，可能一直轮不到。
- 同一個目标 URL 被反复重试，反而挤掉了其他地址的机會。
排查时的大致顺序
建议從日誌開始，而不是先改代碼：
- 按小时統計搜尋蜘蛛的請求狀態碼，区分正常返回、跳轉、被拒和超时，先確認問题集中在哪個時間段。
- 從外部多次請求入口頁，记錄首字节時間和總耗时，看是稳定慢還是間歇性慢。
- 對照服務器侧的 CPU、内存、连接數和資料库慢查询，判断瓶颈在哪一层。
- 检查 CDN、WAF 規則是否誤伤了搜尋蜘蛛，尤其是刚調整過安全策略的時間点。
- 最後再看入口頁结构，確認是否過度依赖動態渲染。
可以優先做的几件事
- 给入口頁加頁面缓存或直接静態化，把目标 URL 列表用最简的 HTML 輸出。
- 减少入口頁自身承担的重资源，让它只负责“列出地址”這一件事。
- 给入口頁留出並發余量，不要让它和主站业務抢同一份资源。
- 谨慎使用 crawl-delay，它會主動压低抓取速度，通常只在服務器實在扛不住时才考虑。
- 把重要的入口頁放到响應更稳定的机器或节点上，避免和慢服務混在一起。
慢和超时本身不是收錄問题，但它會先把抓取机會吃掉。抓取量上不去的时候，先確認入口頁是不是“能打開，但打開得很慢”。