很多人看蜘蛛，只看它来了几次、抓了几个页面。但从服务器那一侧看，蜘蛛更像一阵阵的流量：某个时刻只有一两个请求，下一分钟可能同时进来几十个。抓取并发和站点承载能不能配合好，直接决定了蜘蛛走得多顺、新 URL 被发现得有多快。
抓取并发从哪里来
搜索引擎抓取器通常会对同一个站点维持一定数量的并发连接，而不是一个一个排队。触发并发的常见原因有几类：
- 列表页、聚合页一次展开大量内链，蜘蛛顺着链接批量请求；
- Sitemap 或站内目录被读取后，一批 URL 同时进入待抓队列；
- 页面里的静态资源在渲染阶段被一起拉取；
- 同一份内容存在多个 URL 变体，蜘蛛把每个变体都当成独立目标。
并发本身不是问题，问题是这些请求是否落在同一台机器、同一个接口、同一条动态查询上。
服务器扛不住时会发生什么
当并发超过承载能力，最直接的表现是响应时间上升。接着可能出现 5xx、连接被重置、图片或脚本加载失败。搜索引擎会记录这些信号，并据此调整对整站的抓取节奏——通常是降速，而不是加速。
降速之后，URL 被发现和更新的间隔会拉长。你看到的“蜘蛛来得少了”，往往不是它不想来，而是服务器在告诉它慢一点。
从日志里看并发，重点看三件事
- 每秒请求数的峰值：按分钟甚至按秒统计蜘蛛请求，找出尖峰出现在哪些时段、对应哪些页面。
- 状态码分布：5xx 的比例、超时类中断的数量，比单看 200 更有信息量。
- 按目录或接口拆分：把响应慢的路径单独拎出来，看是数据库查询、搜索接口还是分页参数造成的。
如果某个目录的平均响应时间明显高于其他目录，通常说明：不是蜘蛛抓得太猛，而是这部分逻辑本身太重。
给抓取留出通道的几种做法
- 把重逻辑挡在抓取路径之外：搜索、筛选、排序类参数页尽量不暴露给蜘蛛，或返回可缓存的静态结果。
- 静态化与缓存：内容页、列表页命中缓存后，蜘蛛并发带来的边际成本会低很多。
- CDN 与回源控制：静态资源走 CDN，回源只保留必要请求，避免蜘蛛一来就压到源站。
- 限流但别误伤：对异常流量做限流时，注意校验搜索引擎的官方 IP 或反向解析，别把正常抓取一起挡掉。
- 控制链接密度：列表页一次铺几百条内链，会把并发瞬间拉高，可以考虑分页或分批呈现。
抓取降速的代价
抓取速度下降，影响的不只是“抓得少”。新 URL 进入队列后要等更久，改版后的旧链接要过更长时间才被重新访问，Sitemap 里的更新也可能被延后处理。对内容更新频繁的站点来说，这种延迟比抓取总量更值得关注。
一个可以照着做的小清单
- 按天统计蜘蛛请求的峰值时段，确认是否与站点高峰重合。
- 找出平均响应时间最长的前十个目录或接口。
- 检查这些路径是否通过内链或 Sitemap 被大量暴露。
- 给慢路径加缓存或做降级，再观察一周日志中的 5xx 与超时变化。
- 确认限流、WAF、CDN 规则没有把正常抓取误判成攻击。
抓取并发和服务器承载是一组需要反复调整的平衡。目标不是让蜘蛛抓得越多越好，而是让它在你的站点上走得稳、少断点，新链接能比较及时地进入发现流程。