做收录排查时，很多人第一反应是内容质量、内链、sitemap。但如果去翻服务器日志，会发现另一类问题：搜索蜘蛛确实来过，只是请求被挡回去了，或者响应太慢直接中断。这类失败不会在页面上留下痕迹，却会让收录一直上不去。
抓取失败和页面质量差，是两条不同的线
页面质量差，通常表现为已抓取但未编入索引；服务器端抓取失败，表现为抓到一半没下文，甚至 URL 长期停在“已发现”状态。两者的处理方式完全不同，先分清楚再动手。
判断依据其实很简单：看日志里同一批 URL 的状态码分布。如果大量返回 5xx、超时，或者请求根本没到达应用层（被 WAF、CDN 拦截），那就不是内容问题。
常见的几类服务器端抓取失败
5xx 状态码
- 500：应用报错，可能是某个查询、模板或第三方接口挂了。
- 502 / 504：反向代理拿不到后端响应，常见于后端超时或进程被打满。
- 503：服务暂不可用，短时间维护时可以用，但要配合 Retry-After，别长期挂着。
搜索引擎对 5xx 的处理是“稍后再来”，不会立刻删掉 URL，但如果持续几周都失败，抓取频率会明显下降，已有的收录也可能被降级。
超时和连接中断
服务器 TTFB 太高、响应体太大、或者连接被中途掐断，蜘蛛可能等不到完整内容。日志里往往看不到状态码，只有连接被重置或超时的记录。这类问题最容易被忽略，因为页面在浏览器里“能打开”。
429 和访问频率限制
一些站点用 WAF 或限流组件挡爬虫，规则设得太严会把正常搜索蜘蛛也一起挡掉。表现为特定 UA 或特定 IP 段大量 403、429，而普通用户访问正常。
为什么偶尔失败也会拖慢收录
- 蜘蛛会根据历史成功率调整抓取频率，失败率高的目录会被降频。
- 新 URL 的首次抓取如果失败，可能被放进重试队列，等待时间比正常发现长得多。
- 反复失败的 URL，即使后来恢复了，重新被信任也需要一段时间。
抓取失败不会直接等于不收录，但会持续消耗你在 URL 发现和内容建设上投入的效果。
一套可以照着做的排查顺序
- 拉一周的蜘蛛日志，按状态码分组统计，看 5xx、403、429、超时的占比。
- 把失败请求的时间段和服务器的 CPU、内存、慢查询日志对齐，找高峰点。
- 检查 CDN、WAF、防火墙规则，确认没有误伤搜索蜘蛛的 UA 和 IP 段。
- 检查 robots.txt 和页面 meta，排除“一边挡一边想收录”的配置冲突。
- 抽查几个失败 URL，用命令行带蜘蛛 UA 请求一次，尽量复现问题。
- 修复后观察状态码是否回到 200，以及抓取频率是否回升。
修复之后，怎么确认真的恢复了
别只看单次请求成功。更可靠的信号是：同一目录下多个 URL 在一段时间内稳定返回 200，且日志里出现持续、规律的抓取，而不是零星几次。必要时可以在 Search Console 里看抓取统计，或者手动请求重新抓取几个代表性 URL，但不要指望一次提交就立刻生效。
几个容易踩的坑
- 把 503 当成省事的挡箭牌，长期返回，收录会被慢慢清掉。
- 只在测试环境看页面正常，忽略了生产环境的超时和限流。
- 为了防采集把 UA 判断写死，结果误伤搜索蜘蛛。
- 服务器恢复后不做观察，以为状态码正常收录就会自动跟上。
服务器稳定不是收录的充分条件，但它是必要条件。把状态码、响应时间和拦截规则这几件事理顺，再回头看内容质量和 URL 规范，排查会顺很多。