前面几篇聊过抓取失败、重定向和抓取预算，这一篇把镜头对准服务器本身的响应速度。蜘蛛不会因为一次慢就放弃站点，但持续的慢会实实在在改变它来你站点的频率和深度。
蜘蛛为什么在意响应时间
抓取是一个排队的过程，蜘蛛在单位时间内能取回的页面数是有限的。当你的服务器处理一个请求需要 2 秒而不是 200 毫秒，同样的并发下，它在这段时间里能拿到的页面就变少了。通常会出现两种结果：降低对你站点的抓取速率，或者把资源挪给响应更快的站点。前者让你更新被发现的节奏变慢，后者更难受。
慢在哪一段，日志里能看到
不是所有“慢”都是同一回事。服务器日志往往只记总耗时，需要配合其他数据才能分清：
- 连接阶段慢：DNS 解析、TCP 握手、TLS 握手耗时偏高，常见于线路或证书配置问题。
- 首字节慢（TTFB）：请求到了，应用迟迟不返回。通常是数据库查询、外部接口调用、页面生成阻塞。
- 传输阶段慢：首字节很快，但页面体积大、带宽打满，整体下载时间被拉长。压缩和资源体积在这里起作用。
三类问题的处理方式完全不同：线路问题要查节点和配置，TTFB 问题要查后端，传输问题要从体积入手。混在一起判断，容易改错地方。
超时阈值之外的后果
蜘蛛一般会给自己设一个等待上限。超过这个上限，它记录下来的就不是“慢”，而是失败。失败一次不致命，但如果同一批 URL 反复超时，这些地址在你站点里的可抓取印象会变差，后续回访会更谨慎。更麻烦的是，超时往往发生在动态、需要计算的页面上，也就是你最希望被收录的那部分。
抓取速率会自己下调
很多站长会观察到类似现象：某段时间服务器压力大，日志里蜘蛛请求数明显下降，之后即使页面恢复正常，抓取量也要过一段时间才回到原来的水平。这是抓取速率被调低的典型表现。它不会立刻恢复，通常需要一段稳定的快速响应期。
可以做的几件事
- 把稳定内容放到缓存前面：不常变的内容走缓存或静态化，让蜘蛛拿到的是几毫秒的响应。
- 给动态页面设上限：数据库慢查询加超时保护，宁可返回简化内容，也不要让请求一直挂着。
- 压缩与懒加载分清主次：首屏文字优先送达，图片和非关键脚本不必拖慢首字节。
- 别让防护策略误伤：限流和验证页面如果作用在蜘蛛身上，通常表现为状态码异常，而不是单纯的变慢。
观测方式
把服务器日志按小时聚合，盯住三组数字：蜘蛛请求总数、平均响应时间、超时或非 2xx 占比。三者一起看，才能判断是“来得少了”，还是“来得不少但拿到的东西变差了”。如果只是响应时间上升而请求数没变，问题多半还在你这边；如果请求数先掉，说明蜘蛛已经调整了节奏。
响应速度是抓取表现里少数你能直接控制的因素之一。它不保证排名结果，但会明显影响蜘蛛愿意花多少时间在你的站点上。
最后提醒一点：不要为了让蜘蛛看到快页面，而给它返回和普通用户不同的内容。更稳妥的做法是把整站变快，或者至少让需要被抓取的关键页面保持稳定响应。