蜘蛛抓取頁面时，服務器返回的第一個信息不是内容，而是狀態碼。很多站点在優化内鏈、Sitemap 和 URL 结构，却忽略了狀態碼對抓取节奏的影响——一個持續返回 5xx 的路径，可能让整站的新 URL 發現速度慢下来。
狀態碼是蜘蛛收到的第一句反馈
狀態碼决定了蜘蛛接下来做什么：200 會解析内容並沿着連結繼續發現 URL；301、302 會跟随到新地址；404 和 410 表示地址不可用，蜘蛛會逐步降低對该 URL 的訪問；而 5xx 系列則被理解為“服務器暂时出問题”，蜘蛛會保留這個 URL 並稍後重试。
關键在于“稍後重试”的代價。單次 5xx 影响不大，但如果一個目錄、一類模板頁或某個接口路径持續返回 5xx，抓取系統會整体調低對站点的抓取频次，而且調低容易，恢复慢。
5xx：最容易被低估的抓取减速器
5xx 不一定是整站宕机。常见的诱因有：
- 資料库连接池耗尽，動態頁面在高並發下間歇性报错；
- 缓存层失效，請求直接穿透到後端，超时後返回 500 或 502；
- 图片、字体等静態资源路径配置错誤，返回 500；
- 限流策略把蜘蛛的並發請求也一並拦下，返回 502 或 503。
這些問题在人工訪問时往往只表現為“偶尔刷新慢一点”，但在蜘蛛批量抓取时會被放大成成片的错誤，進而影响同一條抓取路径上的其他正常頁面。
429 和 503：主動限速时要说清楚
如果确實需要限制蜘蛛的請求量，用 429（Too Many Requests）或 503（Service Unavailable）比用 403、404 更合适，因為前者明确告诉蜘蛛“稍後再来”，後者可能被理解為地址失效。
更重要的是带上 Retry-After 响應头，给出一個具体的等待秒數或時間点。蜘蛛拿到這個值後，通常會按提示延後重试，而不是在错誤里反复试探。
與其让蜘蛛在 5xx 里自己猜恢复時間，不如用 Retry-After 给一個明确的等待窗口。含糊的报错換来的往往是更長時間的抓取空窗。
超时和空响應同样算失敗
還有一種情况不体現在狀態碼上：服務器處理時間過長，蜘蛛在等待中主動断開连接。這时蜘蛛既没拿到内容，也没拿到連結，URL 發現自然停在這一步。常见诱因包括慢查询、同步調用外部接口，以及首字节時間本来就很長的頁面。
建议把响應時間的目标定在“稳定”而不是“偶尔很快”：平均值好看、長尾很差的服務端，對蜘蛛来说依然是不稳定的抓取源。
排查與恢复的基本顺序
- 按蜘蛛 UA 聚合服務器日誌，統計各狀態碼的數量和占比，先看清 5xx 集中在哪些路径。
- 区分错誤来自源站、CDN 還是 WAF，不少 5xx 實际上是中間层拦截或回源超时。
- 核對限流規則、防火墙策略和 robots.txt，確認抓取請求不是被誤伤。
- 修复後持續观察一段時間，抓取频次通常不會立刻回到原来的水平，需要逐步恢复。
- 對已经修复的地址，可以通過 Sitemap 重新提交，帮助蜘蛛再次發現。
稳定的抓取通道，比一次性的提交更重要
URL 發現、内鏈传递和 Sitemap 提交，都建立在蜘蛛能稳定取回頁面這個前提上。服務器频繁抖動时，即使内鏈结构再清晰，蜘蛛也可能走不到深层頁面。把狀態碼、响應時間和重试提示處理好，抓取路径才會真正顺畅。