蜘蛛抓取一个 URL 的过程，本质上是一次 HTTP 请求。站点响应得快，它就能在同样的时间里多走几个页面；响应得慢、频繁报错，它会自然地把抓取节奏降下来。很多“抓取量突然掉了一半”的情况，最后追到的不是 robots 或 Sitemap，而是服务器在那几天变慢或开始大量返回 5xx。
慢和错，蜘蛛的处理方式不一样
响应慢（比如 3 秒以上）通常不会让蜘蛛立刻放弃，但它会降低对整站的抓取频率，因为单位时间内能完成的请求变少了。持续超时才会中断连接，这类请求在日志里往往看不到完整的状态码，只留下中止的记录。
而 5xx 是另一个信号。蜘蛛会把服务端错误理解为“这台服务器现在不适合被打扰”，于是缩短抓取间隔、减少并发。如果整站大面积 500，抓取量可能在几天内明显下滑；恢复稳定后，通常需要一段时间才会回到原来的水平。
- 连接中断：多为超时，检查慢查询、慢接口和外部依赖。
- 500 / 502 / 503：服务端或网关错误，优先看应用日志与回源情况。
- 429：主动限流的返回值，用过头反而会被当作持续拒绝。
- 200 但内容为空：蜘蛛拿到了页面，却读不到有效内容，同样浪费一次抓取。
抓取窗口与业务高峰撞在一起
很多站点的慢不是全天候的慢，而是集中在几个时段：早上发布、白天促销、夜间跑批量任务。蜘蛛的抓取分布也有起伏，如果两者重叠，日志里就会出现一批响应时间偏高的抓取记录。
判断标准可以很简单：把日志按小时切分，看每个时段蜘蛛请求的 P95 响应时间和 5xx 比例。哪几个小时明显变差，问题就在那几个小时。
常见的处理思路是错峰，而不是硬抗：把全站重建、数据同步、图片压缩这类重任务挪到抓取低谷；对蜘蛛频繁访问的列表页、分类页做缓存或静态化；把动态查询的落地页尽量提前生成。
让慢接口不拖累整站
蜘蛛抓取的是 URL，一个慢接口可能被包装成很多个 URL。如果详情页要实时调用库存、推荐、评论三个外部服务，任何一个抖动都会让整批页面变慢。把它们从首屏渲染路径里挪出去，或者降级为兜底内容，对抓取稳定性的帮助往往比调服务器配置更直接。
CDN 和反向代理在这里能分担一部分：静态资源、图片、已经生成好的 HTML 交给边缘节点，回源请求就会少很多。但要注意边缘节点缓存了旧版本或者错误页时，蜘蛛看到的就是那份内容，必要时通过刷新缓存来处理。
一份可执行的检查顺序
- 从日志里筛出蜘蛛 UA 的请求，统计状态码分布、响应时间分布。
- 把 5xx 按 URL 归类，看是集中在少数接口还是全站。
- 核对 robots.txt 返回是否正常——robots 本身报错也可能影响抓取。
- 检查最近的发布、配置变更、证书更新是否与异常时间点重合。
- 确认恢复稳定后，观察日志里的抓取量而非后台指标，给它几天时间。
服务器稳定性不是“越快越好”的问题，而是“别让蜘蛛白跑”的问题。响应稳定、错误少、内容能一次读全，抓取节奏自然会保持在合理的水平。