抓取日志里出现 5xx、429 或者成片的连接超时，很多人的第一反应是“蜘蛛是不是不喜欢这个站了”，接着去改标题、改内容、重新提交 sitemap。方向可能没错，但顺序常常反了——服务端连稳定应答都做不到时，后面那些动作很难被正确评估。下面按“先看通道，再看内容”的思路，给出一份核对顺序。
抓取失败不等于收录出问题，但会拖慢收录
抓取是收录的前置条件之一。搜索引擎需要先拿到一份完整的 HTML，才能判断这个 URL 是否值得进入索引。如果同一个地址在一段时间里反复返回错误状态，抓取端会降低访问频率，甚至暂时把该目录移出高频抓取范围。这时候你看到的收录变慢、新页面迟迟不出现，往往不是内容质量问题，而是抓取通道被自己堵住了。
把服务器状态码分布当作第一优先级来核对，比反复调整页面文案更有效率。
先看日志里的状态码分布
从最近的抓取日志里按响应码做一次分组统计，重点看这几类：
- 200：正常。如果占比高但收录没动，问题就不在抓取通道，需要回到内容与 URL 规范上找原因。
- 301 / 302：跳转本身没问题，但要确认跳转链是否超过一跳、是否跳到了错误目标。
- 404 / 410：属于正常反馈，只要不是大面积存在，一般不影响整体抓取。
- 5xx：服务端自身的错误，这是最需要立刻处理的一类。
- 429 / 503：限速或维护状态，通常伴随 Retry-After 提示。
- 403 / 401：权限或拦截，常见于 CDN、WAF、地域策略误伤。
- 超时、连接重置：往往在日志里体现为没有状态码，容易被直接忽略。
三类高频问题的处理顺序
5xx：先看时间是否集中
如果 5xx 集中出现在某个时间段，多半和当时的发布、备份、数据库压力有关；如果全天分散出现，更可能是应用层的偶发错误或某个接口拖垮了整页渲染。处理顺序是：先确认是全局还是个别路径，再看是否与某个功能模块相关，最后才考虑是不是抓取频率过高导致的资源竞争。
429 与 503：区分限速和维护
429 一般说明访问频率超过了服务端设定的阈值。此时不要一味提高限速上限，先确认抓取是否集中在低价值 URL 上，比如参数组合生成的筛选页、站内搜索结果页。把这类地址先收口，再放核心页进来，往往比放宽限速更有效。503 要确认是计划维护还是被动降级，维护页如果长期挂着 503，抓取节奏会被明显压低。
超时与响应慢：比错误码更容易被忽略
日志里没有状态码的记录，通常就是超时或连接中断。排查时看两件事：一是首字节时间是否稳定，二是是否存在个别接口拖慢整页。图片、统计脚本、第三方组件都可能成为瓶颈，但它们未必影响正文抓取，需要结合渲染方式判断。
403 与 401：检查是否有误伤
这类状态常出现在上 CDN 或安全策略之后。核对时注意：是否对特定 User-Agent 做了拦截，是否对境外或特定网段做了限制，是否触发了频率型防护规则。误伤的特征是同一目录浏览器可以访问、抓取端却持续被拒。
一份可执行的核对顺序
- 按小时统计状态码占比，标出异常集中的时间段。
- 确认异常是否集中在个别目录或 URL 模板上。
- 对照服务端监控，检查是否为发布、备份或资源瓶颈导致。
- 检查 CDN 与 WAF 规则，排除对抓取端的误拦截。
- 收口低价值 URL，减少无效请求占用抓取额度。
- 观察一到两周，确认失败率回落到可接受区间。
服务端恢复之后，再看内容与 URL
抓取成功率回升，只说明通道顺畅了，不代表收录一定会跟着涨。此时再回到常规核对项：页面是否有独立价值、是否存在多个版本指向同一内容、canonical 与实际展示是否一致、内链是否给了入口。这些因素决定的是“抓到的页面值不值得进索引”，和服务端状态是两个层面的事。
把两者分开看，排查会更清楚：服务端问题解决的是能不能顺利拿到页面，内容与规范问题解决的是拿到之后留不留。顺序对了，很多看似无解的收录停滞，其实只是第一步没做完。