抓取失敗這件事，很多站長只在日誌里看到一片 5xx 或超时才想起来。蜘蛛處理失敗的方式其實比較克制：它預設“先当临时問题”，而不是立刻把頁面判死刑。但這份耐心有次數和時間上的邊界，越早修好，頁面恢复得越快。
先分清失敗的類型
不同狀態碼在蜘蛛那里的分量不一样，後續動作也完全不同。
- 5xx（500、502、503、504）：一般被当作服務器端临时故障。蜘蛛會保留這條 URL，過一段時間再来试，而不是马上删掉。
- 连接超时、连接被重置：和 5xx 類似，属于“這一趟没拿到内容”，但不會因此判定頁面已经失效。
- 429 與带 Retry-After 的 503：属于明确的“現在別来”。蜘蛛通常會按你给出的時間窗口收敛抓取频率。
- 403、401：這類多半被理解為“不让抓”。如果只是防火墙誤伤，蜘蛛可能長期不再尝试。
- 404、410：這才是真正意义上的“不存在”，其中 410 的信号更明确，頁面會更快從索引中登出。
失敗之後，重试的节奏會怎么變
單條 URL 的失敗不會孤立存在。当同一個主机在短時間内持續超时或返回 5xx，蜘蛛會把這個域名整体标记為“暂时不稳定”，然後做两件事：降低對這個站点的抓取频率，把省下来的抓取能力分给其他站点；同时把已经排队的 URL 往後挪。表現出来就是：日誌里的抓取量突然掉下去，几小时甚至几天之後才慢慢恢复。
如果失敗集中在某几個目錄或某類頁面，影响通常只落在那一块；但如果是全站性的响應變慢、資料库抖動，整個站点的抓取节奏都會被牵连。
内鏈和 Sitemap 救不了服務端错誤
有個常见誤解：以為 Sitemap 里寫了、内鏈里挂着，蜘蛛就一定會反复来抓。連結解决的是“發現自己”，不是“拿得到内容”。如果某條 URL 每次訪問都返回 504，再多的内鏈也只能让它多失敗几次。反過来，只要服務恢复正常，之前已经發現過的 URL 依然在队列里，並不一定需要重新推送。
在日誌里確認“失敗—重试”的痕迹
- 按狀態碼聚合当天日誌，看 5xx 的數量和出現时段，是否集中在某個時間窗。
- 挑几個失敗 URL 單獨跟踪一段時間，看後面是否出現同样 User-Agent 的再次請求，間隔多長。
- 對比服務器错誤率和蜘蛛抓取量的两條曲线，两者通常一前一後。
- 留意抓取量下滑的起点，往往就是第一次大面积超时的时刻。
能做的几件事
- 先修故障，再看抓取。恢复稳定比任何提交動作都更有效。
- 主動限速时用 503 加 Retry-After，而不是直接断连，或者返回一堆 404。
- 临时维護頁面用 503，不要返回 200 的空壳頁面，也不要统一重定向到首頁。
- 確認是永久下线的頁面，直接给 404 或 410，让它干脆地登出队列。
- 把监控盯在服務器错誤率上，而不是等日誌里堆满失敗记錄才發現問题。
蜘蛛的耐心不是無限的：短期故障它會等，長期不稳定它會绕開。让服務器先稳住，抓取路径自然就顺了。