排查收录时，多数人从标题、正文、内链查起，但有一类情况常被忽略：内容本身没问题，sitemap 也提交过，蜘蛛却始终没能把页面完整取回去。这时候问题往往不在页面里，而在服务器对抓取请求给出的回应上。回应不稳定，后面的索引判断就缺少可用的输入。
三类常见的回应异常
超时与连接中断
服务器响应慢、首字节时间过长，或者抓取中途连接被掐断，爬虫通常拿不到完整的 HTML。偶尔一次影响有限，但如果同一批 URL 反复如此，抓取频次会逐步下调，URL 的排队位置也会往后挪。
5xx 状态码
500、502、503、504 表示服务端当前无法正常交付页面。短时间内的 5xx 一般会被当作临时故障，爬虫过一阵再来；若持续多天，已收录页面就可能被重新评估，严重时从索引中拿掉。计划内维护更适合用 503 并附上 Retry-After，明确告诉爬虫什么时候再来，而不是让页面直接报 200 却交不出正文。
429 与限流、拦截
429 表示请求过多，通常由站点侧的频控、CDN 或 WAF 触发。另一种是返回 403，或者干脆给出验证页面，常见于把爬虫 UA 一并挡掉的规则。这类回应不是“页面内容有问题”，而是爬虫根本没被允许读到页面，排查方向完全不同。
回应异常会带来哪些连锁后果
- 抓取频次下调，新 URL 的发现和抓取都变慢；
- 已发现、待抓取的 URL 排队时间被拉长；
- 已收录页面在多次抓取失败后，索引状态可能发生变化；
- 日志里的抓取记录看着不少，实际能成功解析的比例却很低。
按这个顺序排查更快
- 从服务器访问日志里按状态码分组统计，先看 5xx、429、403 和超时各自占比，而不是先看总请求量；
- 对照应用日志、CDN 与 WAF 日志，确认异常是源站产生还是边缘节点产生；
- 区分“只对爬虫异常”和“对所有访客异常”。只有爬虫 UA 才报错，多半是拦截规则；全站都慢，问题通常出在源站；
- 用命令行工具或抓取测试复核同一条 URL，确认回应能否稳定复现；
- 修复后继续观察一段时间的抓取频次与成功比例，不要只看单日数据。
让回应稳定下来的几件基础事
- 盯住可用率，而不是只看平均值。少量长时间的 5xx，影响往往大于整体平均响应时间的小幅波动；
- 频控按来源细分，给搜索引擎留出独立配额，避免按 IP 一刀切；同时控制站内并发，减少自己把自己拖慢的情况；
- WAF 与 CDN 规则上线前，先确认不会误伤正常爬虫，必要时做验证或白名单；
- 减少不必要的跳转链，缩短首字节时间，让一次抓取能拿完核心内容；
- 维护窗口使用 503 加 Retry-After，而不是把错误页以 200 返回。
抓取阶段的稳定性属于基础项：它做不好，内容、结构和内链上的优化都很难被完整看到。
还要提醒一点，修好回应不等于页面立刻回到索引。抓取频次和索引状态都需要一段观察窗口，建议以周为单位对比抓取成功率、状态码分布和索引数量的变化，再判断是否需要继续往内容与结构层面排查。