很多站点运营者盯着 404 排查，却忽略了另一類更麻烦的响應：服務器错誤和限流。前者让蜘蛛以為頁面暂时不可用，後者让蜘蛛以為你在拒绝它。两者共同的结果，都是抓取時間被反复消耗在拿不到内容的請求上。
先看清常见狀態碼各自的含义
- 200：正常返回，内容完整。
- 301 / 302：跳轉，前者表示永久，後者是临时，两者不要混用。
- 304：内容没變，直接用缓存即可，這是省流量的好狀態。
- 404 / 410：頁面不存在，410 表示永久刪除，语义更明确。
- 429：請求太多被限流，通常由並發或频率触發。
- 500：程序内部错誤，多與代碼、資料库或依赖服務有關。
- 502 / 504：網關拿不到上游响應，常见于後端超时或進程異常登出。
- 503：服務暂不可用，一般用于维護窗口。
5xx 為什么比 404 更值得警惕
404 至少說明服務器是活的，只是這個地址没有内容；5xx 說明你的站点在這一刻整体不可用。蜘蛛遇到 5xx 通常會稍後重试，如果连續多次都失敗，就可能降低對整站的抓取频率，已经收錄的頁面也可能因為無法驗證而出現表現波動。
更隐蔽的是「部分 5xx」：列表頁正常、詳情頁报 500，或者只有带參數的地址出错。這類問题在浏览器里不容易發現，因為它們往往由特定資料、特定缓存狀態或特定用戶路径触發。
429 與防護策略的誤伤
有些站点為了让蜘蛛少来一点，會在 WAF 或防火墙里按 IP、UA 做限速，结果把正常抓取也拦掉了，返回 429 甚至 403。初衷是减轻压力，實际却让蜘蛛無法確認内容是否更新。
合理的做法是区分「服務器扛不住」和「不想被抓」。如果是前者，應该先優化慢查询、加缓存、拆分热点接口；如果确實要控制频率，用 robots.txt 的 crawl-delay 或服務端识別常见蜘蛛 UA 的方式，比一刀切限速更可控。限速規則改動後，最好用命令行工具模拟一次抓取請求，確認返回碼和响應時間都正常。
503 與维護窗口
短時間维護可以返回 503，並带上 Retry-After 头，告诉蜘蛛多久之後再来。這比直接關站、返回 200 的空頁面或者让請求一直挂起都要好。注意维護窗口不要開得太久，也不要在维護期間让首頁跳到一個临时提示頁上。
自查步骤
- 在服務器日誌里按狀態碼分组，統計最近 7 天各狀態碼的請求量與占比，重点看 5xx 和 429 的曲线。
- 找出 5xx 的地址分布：是集中在某個栏目、某個接口，還是随机出現。
- 用真實浏览器和命令行工具各請求一次，判断错誤是源站返回還是缓存、CDN 层返回。
- 查看後端错誤日誌，定位是超时、内存、连接池還是第三方依赖導致的失敗。
- 检查 WAF、防火墙、CDN 的限速規則，確認没有把常用蜘蛛的 UA 一並拦掉。
- 修复後观察一周，確認 5xx 占比下降、抓取請求恢复稳定节奏。
常见誤区
- 把 500 当成偶發，不做統計。偶發多了就是趋势。
- 用 200 返回「系統繁忙」頁面，蜘蛛會把它当作正常内容處理。
- 超时時間设得過長，慢請求不断堆积，最终拖垮整站响應。
- 维護时不設定 Retry-After，蜘蛛只能按自己的节奏反复来试。
- 只盯首頁，忽略接口、搜尋頁、站内结果頁這類動態地址。
狀態碼是站点健康状况最直接的表達。把 5xx 和 429 压到低位，比反复調整 Sitemap 和提交方式更有效。