抓取日誌里通常有两類记錄：成功的 200，以及超时、5xx、连接被重置這類失敗。多數人只盯前者，其實後者同样會影响 URL 發現的速度——蜘蛛按批抓取，一次失敗意味着這條 URL 要排队等下一轮，等待期間它與内鏈、更新节奏全都错開。搞清楚失敗之後會發生什么，比單纯數“抓了多少”更有用。
抓取失敗之後，蜘蛛會做哪些動作
不同失敗類型，處理方式並不一样，粗略分三档：
- 临时连接問题：超时、连接重置、DNS 抖動。這類通常被当成“没抓到”而不是“頁面没了”，蜘蛛倾向重试，而不是立刻放弃這條 URL。
- 服務器主動报错：500、502、503，以及偶發的 429。這些會被记成抓取受阻，直接推高站点维度的失敗率。
- 明确的内容狀態：404、410、401、403。這類不算失敗，而是结果，蜘蛛按狀態碼處理對應的 URL，和超时是两回事。
關键在于：临时失敗會让 URL 留在待抓队列里，但排序會往後退。如果同一條 URL 反复失敗，重试間隔會越拉越長，從小时級變成天級，最後可能需要外部連結或 Sitemap 重新把它唤回来。
服務器抖動怎样传導到 URL 發現
假设站点平时响應 200ms，某天開始偶尔 1-2 秒才返回。表面看只是慢，實际效果是：同一批抓取任務里部分請求超时，那部分 URL 這一轮白跑；下一轮再来时，優先級已经被其它任務挤到後面。站点越大，這種延迟累积越明顯——列表頁、分頁、詳情頁本就串成一條鏈，鏈上某一环慢，後面的 URL 就晚被發現。
更麻烦的是失敗率統計。蜘蛛一般按站点维度评估抓取表現，如果一段時間里 5xx 占比偏高，它會降低整站的抓取安排，而不只是那几個慢接口。也就是说，几個不稳定的動態接口，可能拖累全站的 URL 發現進度。
抓取频率更像一種信任額度：稳定就多给，抖動就回收。恢复稳定後額度會慢慢回来，但通常是渐進的，不會一次到位。
让失敗 URL 尽快回到队列的几件事
- 先分清是“慢”還是“挂”：在服務器日誌里按狀態碼和响應时長分组，看失敗集中在哪些路径、哪個时段，是資料库超时，還是某個接口被掃描拖死。
- 把 5xx 当作可用性問题處理：排查代碼报错、连接池耗尽、磁盘 IO 打满，別让蜘蛛替你做压力測試。
- 合理使用 503 與 Retry-After：計划内维護时，返回 503 並给出 Retry-After，比直接断開连接清晰得多，蜘蛛知道這是暂时狀態。
- 谨慎使用 429：只有确實需要限速时才用，並確認被限的是異常流量，而不是正常搜尋蜘蛛。用错了會把抓取路径掐断。
- 给重要 URL 留可重新發現的入口：Sitemap 的 lastmod、首頁或栏目頁的内鏈，都能在失敗之後提供一次新的發現机會，不必只等蜘蛛自己想起来。
- 观察恢复曲线：修好之後別急着下结论，看两到四周的抓取量與失敗率變化，確認队列确實在回补。
頁面侧可以做的小調整
- 减少首屏不必要的同步請求，让 HTML 能在超时之前吐出来。
- 把關键 URL 放在稳定的静態入口里，別都塞進需要复杂查询的動態列表。
- 检查图片、脚本是否挂在阻塞位置，资源加载失敗不應拖住主文档。
- 日誌里区分蜘蛛訪問和用戶訪問，否則限速策略很容易誤伤。
复盘时看什么
建议每周固定看三组數：按狀態碼拆分的失敗率、平均响應時間的分位值、新 URL 從發現到被抓取的間隔變化。三者一起看，才能判断問题出在服務器、内鏈结构，還是更新节奏。單獨看抓取總量，很容易把“抓得少”誤判成“蜘蛛不来了”。
抓取失敗本身不可怕，可怕的是失敗之後没有留下可重新發現的路径。把服務器稳定性、内鏈入口和 Sitemap 维護当成同一件事来做，URL 發現才不至于被一次抖動打断太久。