搜索蜘蛛的抓取不是一条一条排队来的，它会在同一时间发起多个尚未返回的请求。站点能承接多少这样的并发，会直接影响抓取队列推进的快慢，也间接影响一条新 URL 从被内链或 Sitemap 暴露，到真正被抓取之间的间隔。这篇把重点放在并发和限速这一层，讲怎么观察、怎么判断、怎么设置。
并发指的是什么
同一时刻，来自同一只搜索蜘蛛的、还没有返回结果的请求数量，就是当下的并发。抓取线程数、请求间隔、单次抓取的响应耗时，都会影响它。
日志里看到的是一串时间戳。按秒把同一 User-Agent 的请求聚合起来，就能粗略看出某一秒内同时有多少条请求在跑；按分钟看，则能得到一个更平稳的峰值曲线。
并发不是越高越好
静态页面加缓存，几十并发的压力通常可以轻松消化；如果每个页面都要查数据库、渲染模板、调用外部接口，并发升高会先把数据库连接占满，响应时间被拉长，接着开始出现 5xx 或超时。
搜索蜘蛛遇到明显的慢响应和错误，一般会降低抓取速率，把这条 URL 放回队列稍后再试。表面上看是站点保护了自己，代价是这条 URL 的抓取被往后推，新页面的曝光也会跟着延后。
从日志里看三件事
- 每秒请求数峰值：按分钟聚合同一 User-Agent 的请求数，看峰值落在什么时段，是否和站点自身的流量高峰撞在一起。
- 响应时长分布：把 200 响应按耗时分成几段，关注慢请求占多大比例。慢请求多，往往说明瓶颈在后端接口或数据库，而不是带宽。
- 状态码构成：5xx、429、499 以及超时占比如果持续偏高，基本可以判断站点在抓取并发上已经吃紧。
限速的几种做法
- 服务器层限速：Nginx 的 limit_req、limit_conn 可以按 IP 或 User-Agent 限制速率与并发连接数，超出的请求返回 429 或 503。
- CDN 与 WAF：多数 CDN 支持按 UA、路径配置速率规则，可以在边缘挡掉异常高频请求，减少回源。
- 缓存优先：把不常变动的页面放进反向代理或 CDN 缓存，让蜘蛛拿到的大多是缓存命中，回源压力自然下降。
- 临时降速：做数据迁移、批量任务时可以短时间收紧限速，但要留一个明确的恢复时间，不要长期挂着 503。
需要提醒的一点是，robots.txt 里的 crawl-delay 各家支持情况并不统一，Google 已经明确不采用这一指令。真正可控的限速点，还是在服务器和 CDN 这一层。
如果日志里 429 和 503 的比例长期偏高，先别急着调低限速值，先确认是站点本身变慢了，还是确实有异常高频请求在挤占配额。
限速过严会拖慢什么
限速过严时，日志里会出现大量 429、503，搜索蜘蛛会拉长重试间隔。新 URL 即使已经被 Sitemap 或内链暴露，也只能在队列里排队等待。表现就是：Sitemap 提交了、内链也加了，但在抓取记录里迟迟看不到这条 URL 出现。
并发有限时，让重要 URL 先走
- Sitemap 只放规范 URL 和确实需要被发现的页面，减少无效排队。
- 把重要页面放在较浅的内链层级里，让它们更早进入抓取队列。
- 用 robots 规则或参数规范化挡掉筛选、排序类低价值 URL，别让它们占用抓取名额。
每周复核一次
- 抓取峰值时段是否和站点自身流量高峰错开。
- 同一秒内来自搜索蜘蛛的请求数，是否明显超过当日平均。
- 5xx、429 的比例有没有抬升。
- Sitemap 里的 URL 在日志中的出现比例是否稳定。
并发和限速不是设置一次就不用再管的事情。站点在改版、缓存策略在调整、抓取量本身也会波动，隔一段时间用日志复核一遍，比长期套用一个固定数值更可靠。