不少站点把力气花在“怎么让搜尋蜘蛛發現新 URL”，却忽略了另一個环节：蜘蛛来了之後，服務器能不能在這几秒内把頁面交付出去。一次超时或一個 5xx 未必立刻带来變化，但如果這種狀態反复出現，抓取节奏會被整体拖慢，新 URL 從被發現到真正被抓的等待時間也會跟着拉長。
搜尋蜘蛛對响應有容忍度，但這個容忍度不是無限的
搜尋引擎通常不會因為一次失敗就放弃某個 URL，一般會安排後續重试。問题在于，重试的間隔和频次是動態調整的：同一路径下失敗率越高、响應越慢，這個目錄甚至整個域名获得的抓取机會就可能越少。常见的几類表現是：
- 连接或响應超时：頁面本身能打開，但首字节時間長期偏大，抓取請求在等待中結束。
- 間歇性 5xx：資料库短时不可用、後端扩容、發布過程都可能造成成片的 500 或 502。
- 限速與誤拦截：CDN、WAF 或自建防護把正常的抓取請求当作異常流量，返回 429、403 或驗證頁面。
這三類問题的共同点是：從用戶视角看，站点可能“只是偶尔慢一下”；從抓取视角看，它們會被记錄成失敗或異常响應，並影响後續的抓取安排。
不稳定是怎样影响 URL 發現的
URL 發現和抓取完成是两件事。Sitemap 或内鏈把地址交出去，只是让蜘蛛知道了這個 URL 的存在；抓取完成後，才有後續處理。服務器不稳定主要作用在後半段：
- 抓取速度下降，抓取队列里的 URL 积压，新提交的地址排队更久。
- 失敗較多的目錄可能被降低抓取频率，恢复起来需要一段時間。
- 如果重定向、分頁、篩選參數在故障期表現異常，還可能让蜘蛛走到一些本不该走的地址上。
換句话说，服務器响應不稳不會直接“阻止發現”，但會让發現之後的鏈路變長，更新频繁、URL 數量多的站点感受會更明顯。
怎么確認是服務器問题，而不是抓取本身的問题
- 在服務器訪問日誌里按時間段統計搜尋蜘蛛的响應碼分布，重点看 5xx 和 429 是否集中在某些时段或某些目錄。
- 對比同一天的响應時間：如果爬虫請求的首字节時間明顯高于真實用戶請求，可能是缓存或防護策略對爬虫没有生效。
- 用工具模拟抓取，检查是否存在重定向鏈過長、證书異常、连接被重置等情况。
- 把日誌里的抓取波動和發布、扩容、資料库维護的時間点對齐，看是否重合。
可以着手處理的几件事
- 让爬虫請求尽量走缓存层，静態资源與不常變動的頁面不必每次都查資料库。
- 發布时避免整站同时返回 5xx，可考虑分批上线或保留舊版本一段時間。
- 核對防護規則，確認已驗證的搜尋蜘蛛不會被誤拦，不要只凭 User-Agent 放行。
- 限速阈值不要压得太低，長期大量 429 對抓取並不友好。
- 故障期間尽量不改動内鏈结构和 Sitemap，少给抓取增加額外變數。
URL 發現解决的是“蜘蛛知不知道该来”，服務器稳定性解决的是“来了之後能不能顺利走完”。两者缺一個，抓取效果都會打折。
實际操作中不必追求零失敗，重点是让失敗可控、可定位。把响應時間、狀態碼和抓取频次放在一起看，往往比單獨盯某一項更容易找到症结。