做蜘蛛池入口页时，服务端错误码经常被当成小事处理：先重启服务，或者干脆换个 IP 继续。但搜索蜘蛛对不同的错误码有不同解读，429、503 和 5xx 带来的后果差别很大，值得单独理一遍。

先分清三类错误码的含义

搜索蜘蛛拿到响应后，第一件事是判断这个页面现在能不能访问。同样是失败，信号强弱并不一样：

• 404 / 410：明确的“不存在”，长期返回会逐步把 URL 从索引里清掉，入口页尤其敏感。
• 403 / 401：访问被拒绝，抓取方通常不会反复硬闯，抓取频次会明显下降。
• 429：请求过多，属于限流信号，含义是“你在，但慢一点”。
• 500 / 502 / 503 / 504：服务端问题或临时不可用，一般被视为暂时状态，会安排重试。

对入口页来说，最忌讳的是把本该是 404 的页面返成 200 空内容，或者把限流返成 403。前者会让蜘蛛反复抓取无效页面，后者等于主动请对方少来。

429：抓取频次下降的起点

429 本身不是封禁，它是服务器主动告诉抓取方当前并发太高。常见触发原因有两个：一是入口页所在服务器资源有限，二是站内链接数量大、蜘蛛短时间内连续请求。

如果响应里带 Retry-After 头，抓取方一般会按这个时间等待；不带的话，就按自身经验做退避。问题在于，持续大量的 429 会让搜索蜘蛛对整站的抓取节奏做整体下调，恢复后也不会马上回到原来的水平。所以看到 429 就换 IP，往往只是把问题推迟到下一个 IP 上。

503 与 Retry-After 的正确配合

计划内的维护、灰度发布、压测，用 503 加 Retry-After 是合适的：既表达了暂时不可用，也给出了恢复时间，能减少被误判成长期故障的概率。但要注意两点：

• Retry-After 的时间要给真实值，不要统一写 86400，那相当于告诉对方一整天别来。
• 不要为了省事长期挂 503。持续时间过长，抓取方会按不可用处理，恢复后需要一段时间重新建立抓取节奏。

5xx 错误率与抓取频次的关系

搜索蜘蛛通常按域名或 IP 维度统计错误率。短时间内 5xx 占比升高，抓取并发和频次会被压低，这是保护自身资源的常规做法。关键要看清：

• 错误集中在某一台机器或某一个入口页，还是全站性的；
• 是后端超时导致的，还是反向代理直接返回的；
• 是否只在抓取高峰期出现，平时正常。

这三种情况对应的修法完全不同，只看总错误率容易误判。

排查顺序建议

1. 先从访问日志里按状态码分组，看 429、503、5xx 各占多少，是否集中。
2. 确认是否 CDN、WAF 或安全策略拦截了搜索蜘蛛，这类拦截常表现为 403 或 429。
3. 检查后端连接数、超时设置和慢查询，排除资源瓶颈。
4. 看入口页是否存在无意义的循环请求，比如页面上的链接反复指向自身。
5. 修复后观察一段时间内的回访情况，不要指望立刻恢复原频次。

几个常见误区

• 用 200 返回一个空白页掩盖错误，实际上会制造软 404 问题。
• 用 302 把错误流量转走，抓取方跟过去后仍然是错误页面，问题没解决。
• 看到 429 就断定被针对，忽略了自己入口页的并发设计。
• 忽略 Retry-After，让抓取方按默认策略退避，恢复时间被拉长。

状态码是入口页和搜索蜘蛛之间最直接的沟通方式。返回什么码，就等于告诉对方“现在是什么情况”，含糊不得。

把错误码当成信号而不是噪音，入口页的抓取稳定性会好很多。至于修复之后多久能恢复抓取频次、多久能重新发现目标 URL，取决于站点整体情况和抓取方的调度，没有人能给出确定时间。