有些站点会遇到一种很难复现的情况：搜索里能搜到页面，隔几天再看又不见了，再过一阵子又出现。翻日志会发现，爬虫来的时候并不总是拿到正常响应，偶尔是 500、502，偶尔是连接超时。这类问题往往不是内容质量问题，而是服务器可用性把收录状态搅动了。
间歇性失败为什么会动摇收录状态
搜索引擎对页面的收录判断建立在多次抓取之上。一次成功抓取可能让页面进入索引，但如果后续几次抓取都失败，系统会认为页面当前不可访问，可能把它从索引里暂时撤下，或者降低后续抓取频率。等服务器恢复正常，页面又可能重新被抓到，于是形成收录状态反复的现象。
关键在于失败是间歇性的，而不是持续性的。持续性的 5xx 一般会被识别为服务器故障，处理方式相对明确；间歇性失败则容易被误判成页面本身有问题，排查时也更容易被忽略。
第一步：确认失败是偶发还是成片
先从服务器日志里筛出爬虫 UA 的请求，按状态码分组统计。重点看三个比例：
- 5xx 占全部爬虫请求的比例，超过 1% 就值得查
- 超时请求的占比，包括长时间无响应和响应时间异常拉长
- 失败请求是否集中在某个时间段
如果失败集中在几分钟内，多半是某个进程重启、缓存击穿或数据库抖动。如果全天零散分布，则更可能是资源长期吃紧，比如内存不足、连接数打满。
第二步：看失败发生在哪一层
同样是 5xx，来源可能完全不同。按下面的顺序往下查，能少走弯路：
- 反向代理或负载均衡层：连接被拒绝、上游超时
- 应用层：脚本报错、内存溢出、第三方接口拖慢整体响应
- 数据库或缓存层：连接池耗尽、慢查询堆积
- CDN 或 WAF：把爬虫请求误判为异常流量而拦截，返回 403 或 5xx
特别留意最后一项。有些站点开启防护策略后，正常用户访问没问题，但爬虫的请求特征触发规则，被间歇性拦截。这类失败在日志里看起来像服务端错误，实际是策略配置问题，改代码是解决不了的。
第三步：分清对已收录页和未收录页的不同影响
两种情况要分开看。已经收录的页面被抓取失败，风险是索引状态波动、展示信息变旧；还没有收录的新页面抓取失败，风险是发现被推迟，内链传递的权重也可能被浪费。
如果新页面的失败率明显更高，可以检查是不是这些页面的生成逻辑更重，比如需要实时聚合、调用外部接口。把这类页面的渲染成本降下来，往往比反复改内容更有效。
收录状态反复，先别急着改标题和正文。先确认爬虫每次来的时候，服务器是不是都正常回应了。
一个可执行的核对清单
- 导出近一周爬虫请求日志，按状态码和时间分布做统计
- 找出失败率最高的 URL 类型，判断是模板问题还是个别页面问题
- 检查 WAF、CDN、限流配置是否对爬虫请求生效
- 确认监控告警覆盖 5xx 与响应时间，而不只是端口探活
- 修复后观察两周，看收录状态是否趋于稳定，而不是只看单日数据
把稳定性纳入日常巡检
服务器稳定性属于基础设施问题，它不会直接带来收录，但会持续消耗已经取得的收录结果。把它放进日常巡检项里，比等到收录量下滑再回头逐项排查要省事得多。