不少站点把收录问题归到内容质量或外链上，但翻开服务器日志，最先暴露的往往是响应异常。蜘蛛每次来访，首先拿到的是状态码和响应时间，只有这一层稳定，后面的解析、渲染、入库才有意义。
响应层为什么排在收录流程前面
抓取是收录流程的第一步。页面返回 200 且内容是完整的 HTML，蜘蛛才有东西可解析；如果每次抓取都撞上超时、5xx，或者被限速挡回来，这个 URL 在抓取队列里的优先级会逐渐下降。这不是某种惩罚，而是抓取资源会被优先分配到能稳定拿到内容的地址上。
几类常见的异常响应
5xx：服务器侧报错
500、502、503、504 都表示服务器这边出了问题。偶发几次通常影响有限，但如果同一批 URL 反复出现 5xx，抓取频次会被主动调低。用 503 做临时维护本身没错，但最好配合 Retry-After，并且别长期挂着；长期 503 的效果接近于让这些页面停止被更新。
429：请求过多
429 常出现在 CDN 或 WAF 层。它和 5xx 不一样，含义是「能响应，但你现在来得太频繁」。蜘蛛被限速挡下后，既拿不到内容，也无法判断页面是否变化。需要排查防护规则是不是把已知的搜索蜘蛛一起拦了，或者站点自定义的限速阈值设得过低。
超时与连接中断
响应时间过长同样影响抓取。页面本身不复杂，但接口、第三方脚本或数据库查询让它经常几十秒才吐出内容，蜘蛛可能直接断开。这类情况在日志里往往表现为没有状态码，或者长时间卡在等待阶段。
名义 200，内容却不是页面
还有一种更隐蔽的情况：状态码是 200，返回的却是「服务器繁忙」「内容不存在」这类提示。对蜘蛛来说这是一个正常页面，但页面是空的，长期如此很难被当作有效页面处理。这类响应应当改成对应的错误状态码，让语义回到正确的位置。
排查顺序
- 取一段连续几天的日志，按状态码分布做统计，先看非 200 请求的比例和趋势。
- 把异常请求按 UA、IP 段、URL 目录分组，判断是全局问题还是集中在某个模块。
- 对比同目录下正常页面与异常页面的差异，看是否有共同的模板、接口或参数特征。
- 如果异常集中在固定时间段，检查是否与备份、跑批、批量发布撞在一起。
统计时别只看平均值。平均值容易被缓存命中的请求拉低，中位数和较高分位数更能反映内页的真实响应情况。
处理时容易忽略的几点
- 别只盯首页。首页通常是缓存命中最好的位置，问题多集中在内页和列表页。
- 区分限速与故障。429 需要放宽规则或加白名单，5xx 要去修代码、资源或配置，处理方式完全不同。
- 保持状态码语义正确。内容已删除就返回 404 或 410，不要用 200 兜底。
- 不给蜘蛛单独做一套内容。返回给蜘蛛和用户的内容不一致，会带来新的问题。
- 控制发布节奏。一次上线大量新 URL，容易在短时间内触发限速。
响应层修好之后，收录不会立刻跟着变。它只是把「能不能稳定拿到内容」这一步打通，页面是否进入索引，还要看内容质量、重复程度和站点整体情况。
修完怎么看有没有改善
不要只对比收录总数。更实用的做法是固定一批之前频繁出错的 URL，持续观察它们的状态码分布有没有变好、抓取次数有没有回升、页面内容有没有被重新更新。如果响应已经稳定两三周，抓取仍然不动，那问题多半已经转移到内容或结构层面，这时候再回过头查模板、内链和重复内容，方向会清楚很多。