搜尋蜘蛛的抓取不是一條一條排队来的，它會在同一時間發起多個尚未返回的請求。站点能承接多少這样的並發，會直接影响抓取队列推進的快慢，也間接影响一條新 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 在日誌中的出現比例是否稳定。
並發和限速不是設定一次就不用再管的事情。站点在改版、缓存策略在調整、抓取量本身也會波動，隔一段時間用日誌复核一遍，比長期套用一個固定數值更可靠。