抓取是收錄鏈路的入口。当服務器在蜘蛛訪問时返回 5xx、429 或 503，這個入口就會出現波動。而這類波動的處理方式，和你直觉里“报错就等于頁面被删掉”並不一样。

先分清：哪些狀態碼是暂时，哪些是永久

• 200：正常返回，蜘蛛按計划處理頁面内容。
• 301 / 302：跳轉，蜘蛛會跟着跳到目标 URL。
• 404 / 410：资源不存在，相当于站点在明确表態。
• 5xx（500、502、503、504 等）：服務器端出問题，通常被视為暂时性故障。
• 429：請求過多，服務器在限流。

關键差异在于：4xx 系列常被理解為“這個 URL 不用再来了”，5xx 系列則被理解為“現在不行，過會儿再试”。两者對索引的影响路径並不相同。

5xx：短期波動和長期不可用是两件事

偶尔出現的 500 或 502 在正常运维里很难完全避免，搜尋引擎對短時間、低比例的失敗通常有一定容忍度，會稍後重试。真正需要警惕的，是持續時間長、比例高的 5xx。

如果某個栏目或整站在几天内持續返回 503，可能出現几種连鎖反應：抓取频率被下調；已经索引的頁面在搜尋结果中的展示逐渐發生變化；若持續時間足够長，部分 URL 可能從索引里被移除。

429 與 503：主動限流的正确用法

有些站点因為资源有限，會主動對蜘蛛限流。這时相對規范的做法是返回 429 或 503，並带上 Retry-After 响應头，告诉對方多久之後可以再来。比起直接断開连接或让請求超时，這样的回應信息更清晰。

但限流只是權宜之計。如果長期让蜘蛛吃閉门羹，抓取资源自然會向其他站点轉移，你自己的新 URL 被發現的节奏就會變慢。

抓取失敗會影响已经收錄的頁面吗

會有影响，但通常不是立刻發生的。搜尋引擎手里保留着上一次抓取到的内容，短期内會繼續使用舊版本。只有在多次抓取都失敗之後，它才可能降低该 URL 的抓取優先級，或調整這個頁面在索引中的狀態。

這也解释了一個常见現象：服務器出問题的那几天，搜尋结果的摘要看上去還是舊的，像是“没變化”。真正的變化，往往發生在故障持續一段時間之後。

几個容易踩的坑

1. 用 200 返回“網站维護中”的提示頁。這會让蜘蛛把维護頁当成正常内容處理，比返回 503 更麻烦。
2. 把 5xx 当成 404 處理。有些框架在报错时直接輸出 404 頁面，等于主動告诉搜尋引擎這個 URL 不存在。
3. 批量重定向到首頁。跳轉能解决用戶訪問問题，但把大量 URL 都指向首頁，通常不會被当作有效替代。
4. 日誌里只看總請求量，不看狀態碼分布。抓取量没下降，但 5xx 比例在上升，問题其實已经存在。

站点侧可以做的自查

• 在服務器日誌里按狀態碼分组，观察 5xx、429 的占比和趋势，而不是只看總量。
• 確認 5xx 是集中在某個接口、某個時間段，還是全局性出現。
• 检查安全防護策略是否把搜尋引擎的請求也一並拦掉了。
• 有計划维護时，尽量安排在訪問低谷，並返回 503 加 Retry-After。
• 故障恢复後，观察几天抓取日誌是否回到正常水平，再看索引狀態的變化。

服務端稳定是所有收錄工作的地基。地基出問题时，先修地基，再谈站点地图、内鏈和内容優化。

最後提醒一点：解决 5xx 只是让頁面重新具备被抓取的條件。頁面是否被收錄、以什么形式展示，還取决于内容质量、重复情况和站点整体的抓取分配。把服務端問题定位清楚，是排查收錄異常时成本相對較低的一步。