很多站点运营者盯着 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 和提交方式更有效。