很多人排查抓取量的时候，习惯先看入口页有没有被屏蔽、链接有没有写对，却容易忽略一个更基础的问题：入口页是不是能稳定、快速地返回。搜索蜘蛛的每一次抓取都要占用时间和连接，如果入口页响应慢、经常断在半路，抓取量往往不是慢慢减少，而是成片地掉。
搜索蜘蛛遇到超时，会怎么处理
搜索蜘蛛发起请求后不会无限等待。服务端迟迟不返回，请求就会被判定为超时或失败。接下来大致会发生两件事：
- 它可能会重试，但重试次数有限，而且重试本身也要占用抓取配额。
- 如果某个入口页或某个 IP 连续失败，抓取频率会被主动压低，后续的抓取安排整体往后排。
所以“慢”带来的第一层损失，是这次没抓到；第二层损失，是本来可以分配给目标 URL 的抓取机会被消耗掉了。
入口页常见的几类“慢”
- 首字节时间过高：入口页是动态生成、每次都要查库或渲染，蜘蛛等的是服务端而不是网络。
- 并发不够：服务器连接数偏小，蜘蛛和真实用户抢资源，谁先来谁先卡。
- 被中间层拦住：CDN、防火墙或安全策略把搜索蜘蛛的请求当成异常流量，返回验证页或直接断开。
- 页面背了太重的资源：入口页里塞了大量脚本和图片，服务端压力被拉高，返回变慢。
- 线路或解析不稳：DNS 解析慢、节点绕路，表现为忽快忽慢。
慢下来之后的连锁反应
抓取量下降只是表面现象，往下看还有几个变化：
- 新 URL 的发现周期被拉长，入口页里刚加的目标地址可能几天都等不到第一次访问。
- 抓取日志里超时和 5xx 的比例上升，有效抓取占比变小。
- 长尾入口页长期排队，可能一直轮不到。
- 同一个目标 URL 被反复重试，反而挤掉了其他地址的机会。
排查时的大致顺序
建议从日志开始，而不是先改代码：
- 按小时统计搜索蜘蛛的请求状态码，区分正常返回、跳转、被拒和超时，先确认问题集中在哪个时间段。
- 从外部多次请求入口页，记录首字节时间和总耗时，看是稳定慢还是间歇性慢。
- 对照服务器侧的 CPU、内存、连接数和数据库慢查询，判断瓶颈在哪一层。
- 检查 CDN、WAF 规则是否误伤了搜索蜘蛛，尤其是刚调整过安全策略的时间点。
- 最后再看入口页结构，确认是否过度依赖动态渲染。
可以优先做的几件事
- 给入口页加页面缓存或直接静态化，把目标 URL 列表用最简的 HTML 输出。
- 减少入口页自身承担的重资源，让它只负责“列出地址”这一件事。
- 给入口页留出并发余量，不要让它和主站业务抢同一份资源。
- 谨慎使用 crawl-delay，它会主动压低抓取速度，通常只在服务器实在扛不住时才考虑。
- 把重要的入口页放到响应更稳定的机器或节点上，避免和慢服务混在一起。
慢和超时本身不是收录问题，但它会先把抓取机会吃掉。抓取量上不去的时候，先确认入口页是不是“能打开，但打开得很慢”。