很多收录问题追到最后，并不是页面质量差或者内容重复，而是蜘蛛根本没能把页面完整拿回去。抓取是收录的前一步，这一步失败，后面的索引、选页、排序都无从谈起。当你在日志里看到大量 5xx、超时或者连接中断，先把注意力放回服务器本身。
先分清三种情况
- 抓取失败：请求没拿到正常响应，页面连“被看见”都算不上；
- 抓取成功但未收录：内容已经拿到，卡在索引阶段的判断或排队；
- 收录后消失：曾经进过索引，后来被移除。
三者的处理方向完全不同。日志里的状态码，是区分它们最直接的依据，比反复刷新后台的收录状态有用得多。
服务器端常见的失败信号
- 5xx（500、502、503、504）：程序异常、后端超时、网关配置问题；
- 连接超时：服务器响应太慢，蜘蛛等不到结果就断开；
- 连接被拒绝或重置：防火墙、WAF、限流规则把请求挡掉了；
- 429：访问频率被限制，等于明确告诉蜘蛛降速；
- 返回不完整：状态码是 200，但 HTML 被截断，正文缺失。
最后一种最容易被忽略，因为日志看上去是“成功”的，实际抓到的却是个残缺页面。
一个可执行的排查顺序
- 拉取一段时间段的访问日志，按状态码分类统计，看 5xx 占比和集中出现的 URL 段；
- 观察失败的时间分布，是全天均匀，还是集中在备份、定时任务、流量高峰；
- 单独测几个失败 URL 的响应时间，区分是“慢”还是“直接报错”；
- 检查 CDN、WAF、安全插件是否存在误拦截，尤其是新出现的爬虫 IP 段；
- 看数据库、缓存、外部接口的耗时，很多时候慢的是页面依赖的下游服务；
- 确认服务器资源（CPU、内存、连接数）是否在抓取时段被打满。
挡爬虫要挡得精细
有些站点为了减轻压力，直接对整个 IP 段返回 403，结果把正常的抓取也一起挡掉了。更稳妥的做法是：对高频请求做限速而不是拒绝，给静态资源加缓存，把动态页面的查询结果缓存起来，必要时在 robots.txt 里调整抓取节奏，而不是用错误状态码回应。
用 403 或 503 大面积回应爬虫，短期省了流量，长期可能让整站的抓取节奏被拖慢。
抓取恢复之后
服务器稳定下来之后，抓取会逐步恢复，但收录不会同步回来。需要给蜘蛛重新访问的机会：保持内链可达、站点地图正常、重要页面不要压在很深的层级。曾经被标记为失败的 URL，往往要等下一轮抓取才会重新评估，这段时间里持续观察日志中的状态码变化就够了，不必频繁改动页面。
几个容易走偏的做法
- 一看到抓取失败就怀疑被惩罚，先排除服务器问题；
- 把 5xx 页面直接 301 到首页，制造新的跳转与内容不对应问题；
- 频繁更换服务器或 IP，让抓取节奏反复重新适应；
- 只盯首页状态，忽略列表页和详情页的失败率。
抓取失败本质上是服务器问题，不是内容问题。把状态码分布、响应时间、拦截规则这三件事查清楚，收录才有继续往下走的基础。