响应时间为什么会被纳入抓取考量
蜘蛛一次来访能做的事，说到底是“发出请求、拿到响应、解析页面里的链接”。这个过程里，请求到响应的耗时直接决定了它在单位时间内能处理多少条 URL。服务器响应慢，不是被扣分，而是可用的抓取次数被自然消耗掉了：同样的时间内，它只能完成更少的访问。慢到一定程度，访问就会落到队列后面。
超时、5xx 与连接失败的差别
抓取程序一般会给请求设一个超时阈值。超过阈值还没返回内容，这次访问就按失败处理。失败之后的行为并不完全相同：
- 响应超时：请求已经发出，但服务器长时间没有返回响应，常见于慢查询、后端接口阻塞、数据库锁等待。
- 5xx 状态码：服务器明确表示自己出了问题。这类信号通常会被记录下来，并在稍后重试。
- 连接被拒绝或重置：可能是服务进程挂了、连接数打满、防火墙误拦。这个信号比较重，容易触发一段时间内的退避。
三者的共同点是：都消耗了一次抓取机会，却没有换来任何新内容。
服务器变慢时的几种典型场景
- 全站整体变慢：可能是数据库、缓存层或带宽的问题，所有页面一起变慢，影响最直接。
- 个别页面慢：列表页翻到深处、含大量评论或关联查询的详情页，往往比首页慢好几倍。蜘蛛按页面逐个抓取，慢的那一类会拖住整体进度。
- 间歇性 5xx：高峰期偶发，平时正常。这种最难排查，但对抓取的影响是持续累积的。
抓取调度会跟着发生什么变化
访问节奏被压低之后，连带影响通常体现在几个方面：
- 单位时间内的抓取量下降，站点可用的抓取额度实际上被浪费在重试上。
- 抓取重心更容易回到已经确认有效的页面上，新发现的 URL 排队时间变长。
- 需要多跳进入的深层页面，本来机会就少，延迟会更明显。
- 站点地图和列表页里提交的新 URL，可能迟迟轮不到第一次来访。
换句话说，URL 发现的瓶颈有时不在入口写得好不好，而在于入口指向的页面能不能稳定、快速地响应。
可以动手检查和完善的地方
- 把服务器日志里的响应时间按 URL 归类，找出最慢的一批页面，看看它们是否有共同特征，比如查询复杂、模板过重、第三方脚本同步加载。
- 统计 5xx 与超时的比例和时段，判断是偶发还是集中出现。集中出现的时段，往往和业务高峰或定时任务重合。
- 对确实很慢但重要的页面，考虑做静态化或缓存，让蜘蛛拿到的是缓存后的快速响应。
- 把大页面拆小，减少单次请求需要传输和处理的数据量。
- 设置合理的超时与重试策略，避免自己的服务在压力下连锁失败。
- 确认抓取入口（robots.txt、站点地图、内链）指向的页面本身是健康的，不要把新 URL 引向一个响应不稳的地址。
一个容易被忽略的顺序问题
很多讨论抓取的内容都在讲入口和结构，但入口之后还有一个前提：页面得能稳定返回。响应时间长期偏高时，站点地图提交得再全、内链铺得再密，实际转化成的抓取次数也会打折。反过来，服务器稳定、响应快，相同的入口结构往往能带出更多的 URL 被访问。
所以排查抓取量下降时，除了看 robots、站点地图、内链，也值得先看一眼服务器最近的响应时间曲线和错误率。这两项数据往往比想象中更能解释问题。