蜘蛛来抓頁面时，服務器這一端如果没有正常把 HTML 交出去，這次抓取就是失敗的。很多站長看到日誌里成片的 5xx 或超时，第一反應是頁面要掉收錄了，其實要先分清失敗的類型和持續時間，再判断影响范围。
抓取失敗和收錄失敗不是一回事
抓取是蜘蛛取回頁面的動作，收錄是搜尋引擎把頁面存進索引並允许它參與展現。抓取失敗时，蜘蛛手上拿不到新内容，但它不一定马上把已有的索引條目删掉。短暂故障期間，索引里往往還保留着上一次成功抓取的版本，只是不會更新。
真正需要警惕的是持續失敗。如果同一個 URL 连着几天、几周都抓不下来，蜘蛛會認為這個地址不稳定，先降低回訪频率，再考虑把它移出索引。
按狀態碼区分失敗的嚴重程度
- 5xx（500、502、503、504）：服務器侧問题，通常是程序报错、資料库连不上、網關超时。這属于临时性失敗，蜘蛛一般會稍後再来；但如果 5xx 连續出現，影响就會累积。
- 连接超时、無响應：蜘蛛等待一段時間没拿到資料就断開。頁面响應特別慢时，蜘蛛可能抓到一半就放弃，長期如此會明顯拉低抓取效率。
- 429 請求過多：服務器主動限流。這通常說明抓取速度超出了你的承受范围，需要检查限流規則是不是把蜘蛛一起挡了。
- 403、连接被拒：多為防護策略、UA 黑名單或 IP 封禁導致。蜘蛛看到的是拒绝訪問，處理方式和服務器故障並不相同。
哪些故障其實是誤伤
日誌里大量 403 或超时，未必是服務器坏了。常见原因有：CDN 或 WAF 把搜尋引擎的 UA 当成攻击流量拦掉；机房對某些 IP 段做了限制；站点在夜間跑全量备份或資料導出，把带宽占满，蜘蛛正好撞上。這些情况在服務器监控上看可能一切正常，只有從蜘蛛的视角看才是一片失敗。
排查抓取失敗，別只看服務器自己的监控面板。要按蜘蛛的 UA 和 IP 取一段日誌，看它實际收到的是什么响應。
一條可用的排查顺序
- 從日誌里筛出搜尋引擎 UA 的請求，統計 5xx、超时、403 各自的占比。
- 随机挑几個失敗的 URL，用普通浏览器和模拟蜘蛛两種方式各訪問一次，看结果是否一致。一致則偏服務器問题，不一致多半是防護侧拦截。
- 確認失敗是集中在某個目錄、某類頁面，還是全站都有。集中在局部，通常和那段代碼或那块資料有關。
- 看失敗的時間分布。如果集中在固定时段，優先怀疑定时任務、备份或流量高峰。
- 修复後观察回訪。蜘蛛不會立刻恢复原来的频率，通常需要一段時間才回到正常水平。
降低失敗率的几個動作
- 给動態頁面和查询接口加缓存，减少資料库压力，這是最直接的一步。
- 在防護規則里為已知的搜尋引擎 IP 段或已驗證的 UA 放行，別让 WAF 一刀切。
- 把重任務（备份、資料導出、全站重建）挪到抓取低谷时段。
- 頁面本身要能快速返回首字节，別把主要内容压在需要長時間計算的接口後面。
- 如果确實需要临时下线，用 503 配合 Retry-After 头，比直接返回 404 或 500 表達得更清楚。
總结一句：偶發的 5xx 和超时，多數情况下不會立刻撼動收錄，但它會消耗蜘蛛對你站点的信任。把失敗率压在一個較低的水平，比事後补救掉收錄要省事得多。