很多人看蜘蛛，只看它来了几次、抓了几個頁面。但從服務器那一侧看，蜘蛛更像一阵阵的流量：某個时刻只有一两個請求，下一分钟可能同时進来几十個。抓取並發和站点承载能不能配合好，直接决定了蜘蛛走得多顺、新 URL 被發現得有多快。
抓取並發從哪里来
搜尋引擎抓取器通常會對同一個站点维持一定數量的並發连接，而不是一個一個排队。触發並發的常见原因有几類：
- 列表頁、聚合頁一次展開大量内鏈，蜘蛛顺着連結批量請求；
- Sitemap 或站内目錄被讀取後，一批 URL 同时進入待抓队列；
- 頁面里的静態资源在渲染阶段被一起拉取；
- 同一份内容存在多個 URL 變体，蜘蛛把每個變体都当成獨立目标。
並發本身不是問题，問题是這些請求是否落在同一台机器、同一個接口、同一條動態查询上。
服務器扛不住时會發生什么
当並發超過承载能力，最直接的表現是响應時間上升。接着可能出現 5xx、连接被重置、图片或脚本加载失敗。搜尋引擎會记錄這些信号，並據此調整對整站的抓取节奏——通常是降速，而不是加速。
降速之後，URL 被發現和更新的間隔會拉長。你看到的“蜘蛛来得少了”，往往不是它不想来，而是服務器在告诉它慢一点。
從日誌里看並發，重点看三件事
- 每秒請求數的峰值：按分钟甚至按秒統計蜘蛛請求，找出尖峰出現在哪些时段、對應哪些頁面。
- 狀態碼分布：5xx 的比例、超时類中断的數量，比單看 200 更有信息量。
- 按目錄或接口拆分：把响應慢的路径單獨拎出来，看是資料库查询、搜尋接口還是分頁參數造成的。
如果某個目錄的平均响應時間明顯高于其他目錄，通常說明：不是蜘蛛抓得太猛，而是這部分逻辑本身太重。
给抓取留出通道的几種做法
- 把重逻辑挡在抓取路径之外：搜尋、篩選、排序類參數頁尽量不暴露给蜘蛛，或返回可缓存的静態结果。
- 静態化與缓存：内容頁、列表頁命中缓存後，蜘蛛並發带来的邊际成本會低很多。
- CDN 與回源控制：静態资源走 CDN，回源只保留必要請求，避免蜘蛛一来就压到源站。
- 限流但別誤伤：對異常流量做限流时，注意校驗搜尋引擎的官方 IP 或反向解析，別把正常抓取一起挡掉。
- 控制連結密度：列表頁一次铺几百條内鏈，會把並發瞬間拉高，可以考虑分頁或分批呈現。
抓取降速的代價
抓取速度下降，影响的不只是“抓得少”。新 URL 進入队列後要等更久，改版後的舊連結要過更長時間才被重新訪問，Sitemap 里的更新也可能被延後處理。對内容更新频繁的站点来说，這種延迟比抓取總量更值得關注。
一個可以照着做的小清單
- 按天統計蜘蛛請求的峰值时段，確認是否與站点高峰重合。
- 找出平均响應時間最長的前十個目錄或接口。
- 检查這些路径是否通過内鏈或 Sitemap 被大量暴露。
- 给慢路径加缓存或做降級，再观察一周日誌中的 5xx 與超时變化。
- 確認限流、WAF、CDN 規則没有把正常抓取誤判成攻击。
抓取並發和服務器承载是一组需要反复調整的平衡。目标不是让蜘蛛抓得越多越好，而是让它在你的站点上走得稳、少断点，新連結能比較及时地進入發現流程。