响應時間為什么會被纳入抓取考量
蜘蛛一次来訪能做的事，说到底是“發出請求、拿到响應、解析頁面里的連結”。這個過程里，請求到响應的耗时直接决定了它在單位時間内能處理多少條 URL。服務器响應慢，不是被扣分，而是可用的抓取次數被自然消耗掉了：同样的時間内，它只能完成更少的訪問。慢到一定程度，訪問就會落到队列後面。
超时、5xx 與连接失敗的差別
抓取程序一般會给請求设一個超时阈值。超過阈值還没返回内容，這次訪問就按失敗處理。失敗之後的行為並不完全相同：
- 响應超时：請求已经發出，但服務器長時間没有返回响應，常见于慢查询、後端接口阻塞、資料库鎖等待。
- 5xx 狀態碼：服務器明确表示自己出了問题。這類信号通常會被记錄下来，並在稍後重试。
- 连接被拒绝或重置：可能是服務進程挂了、连接數打满、防火墙誤拦。這個信号比較重，容易触發一段時間内的退避。
三者的共同点是：都消耗了一次抓取机會，却没有換来任何新内容。
服務器變慢时的几種典型场景
- 全站整体變慢：可能是資料库、缓存层或带宽的問题，所有頁面一起變慢，影响最直接。
- 個別頁面慢：列表頁翻到深處、含大量评论或關联查询的詳情頁，往往比首頁慢好几倍。蜘蛛按頁面逐個抓取，慢的那一類會拖住整体進度。
- 間歇性 5xx：高峰期偶發，平时正常。這種最难排查，但對抓取的影响是持續累积的。
抓取調度會跟着發生什么變化
訪問节奏被压低之後，连带影响通常体現在几個方面：
- 單位時間内的抓取量下降，站点可用的抓取額度實际上被浪費在重试上。
- 抓取重心更容易回到已经確認有效的頁面上，新發現的 URL 排队時間變長。
- 需要多跳進入的深层頁面，本来机會就少，延迟會更明顯。
- 站点地图和列表頁里提交的新 URL，可能迟迟轮不到第一次来訪。
換句话说，URL 發現的瓶颈有时不在入口寫得好不好，而在于入口指向的頁面能不能稳定、快速地响應。
可以動手检查和完善的地方
- 把服務器日誌里的响應時間按 URL 归類，找出最慢的一批頁面，看看它們是否有共同特征，比如查询复杂、模板過重、第三方脚本同步加载。
- 統計 5xx 與超时的比例和时段，判断是偶發還是集中出現。集中出現的时段，往往和业務高峰或定时任務重合。
- 對确實很慢但重要的頁面，考虑做静態化或缓存，让蜘蛛拿到的是缓存後的快速响應。
- 把大頁面拆小，减少單次請求需要传輸和處理的資料量。
- 設定合理的超时與重试策略，避免自己的服務在压力下连鎖失敗。
- 確認抓取入口（robots.txt、站点地图、内鏈）指向的頁面本身是健康的，不要把新 URL 引向一個响應不稳的地址。
一個容易被忽略的顺序問题
很多讨论抓取的内容都在讲入口和结构，但入口之後還有一個前提：頁面得能稳定返回。响應時間長期偏高时，站点地图提交得再全、内鏈铺得再密，實际轉化成的抓取次數也會打折。反過来，服務器稳定、响應快，相同的入口结构往往能带出更多的 URL 被訪問。
所以排查抓取量下降时，除了看 robots、站点地图、内鏈，也值得先看一眼服務器最近的响應時間曲线和错誤率。這两項資料往往比想象中更能解释問题。