蜘蛛抓取的本质是一次资源交换：它花时间请求你的页面，你花带宽和 CPU 返回内容。当响应变慢时，蜘蛛并不是简单地“等一等”，而是会调整对整站的抓取安排。很多站点抱怨抓取量下降，最后查下来问题不在 robots、不在内链，而在服务器响应时间。
响应时间是抓取的第一道门槛
蜘蛛请求一个 URL 时，最先等待的是第一个字节返回的时间，也就是 TTFB。这个时间长期偏高，会连带出现几种情况：
- 单次请求占用连接的时间变长，单位时间内能抓的 URL 变少；
- 超过蜘蛛自身的超时阈值后，请求被放弃，页面被记为抓取失败；
- 失败率升高后，蜘蛛会主动降低对该目录甚至整站的抓取频率。
换句话说，慢不会立刻表现为“不抓”，而是表现为“抓得少、抓得浅、间隔变长”。这些变化在服务器日志里往往先出现在响应时间那一列，而不是状态码那一列。
蜘蛛会做哪些调整
从日志和抓取报告里，可以观察到几种常见反应：
- 抓取频次下降：同一批 URL 的回访间隔从几天拉长到一两周；
- 抓取深度变浅：蜘蛛更愿意停留在列表页和热门页，不再往下翻；
- 新 URL 发现变慢：Sitemap 里的新链接要更久才会被访问；
- 重试增多：同一 URL 在短时间内出现多次请求，多数是超时后的重试。
这些现象叠加起来，效果和“抓取预算被压缩”很像。区别在于，预算问题是分配策略，响应时间问题是硬约束。
哪些“慢”其实不归蜘蛛管
不是所有拖慢页面的因素都会影响抓取，需要区分开：
- 服务器端慢：数据库查询、模板渲染、同步调用第三方接口，这些直接影响 TTFB，蜘蛛能感知；
- 浏览器端慢：图片体积、前端脚本执行、字体加载，影响的是用户，对只取 HTML 的抓取影响有限，但渲染阶段的资源消耗仍值得留意；
- 网络链路慢：跨境线路、CDN 回源异常，可能让部分位置的蜘蛛拿到的是超时结果或旧版本。
排查时先把这三类分开，避免在无关的地方反复改动。
用日志判断响应时间是不是瓶颈
只看平均值容易误判。更实用的做法是：
- 按蜘蛛 UA 过滤出抓取请求；
- 看响应时间的分布，重点看 P95 和最大值；
- 统计超时和 5xx 的占比，而不是只看 200 的数量；
- 对比抓取量下降的时间点与响应时间上升的时间点是否吻合。
如果 P95 长期处于偏高水平，且超时零星出现，基本可以判断响应时间已经在影响抓取节奏。
优化顺序
优先级大致可以这样排：
- 先解决超时和 5xx：这类请求对蜘蛛最不友好，也会让重试挤占正常抓取；
- 加缓存：对不常变的列表页、详情页做页面级或对象级缓存，收益通常最直接；
- 减少同步外部调用：评论、统计、推荐接口能异步就异步，别让它们挡在 HTML 前面；
- 保护性限流：给蜘蛛留出足够配额，避免高峰时被正常用户流量挤到超时；
- 稳定发布节奏：维护窗口、批量改版尽量避开抓取高峰，减少集中失败。
和 URL 发现配合起来看
Sitemap、内链和站内搜索负责“告诉蜘蛛有哪些 URL”，服务器稳定性负责“让蜘蛛拿得到”。前者做得再细，如果响应时间不稳，URL 发现依然会滞后。比较稳妥的做法是：新内容发布后先确认关键路径上的页面响应正常，再通过内链和 Sitemap 引导抓取，而不是一次性推入大量 URL。
抓取量下滑时，先看响应时间的分布和超时比例，再谈内链与 Sitemap，往往能少走弯路。