很多站長第一次在服務器日誌里看到蜘蛛时，會發現它並不是一條一條慢慢来的。同一秒里可能出現好几個請求，分布在不同目錄或不同頁面上。這並不是蜘蛛“乱抓”，而是抓取端在按自己的並發和速率安排工作。

理解蜘蛛的並發连接和抓取速率，有助于判断服務器该以什么狀態回應。如果服務器長期响應慢、频繁超时，蜘蛛通常會降低抓取频率；如果服務器稳定，蜘蛛在预算允许时會更顺畅地走完内鏈和 Sitemap 里的地址。

日誌里能看到哪些並發线索

最直接的观察方法是看訪問日誌的時間戳。按秒統計蜘蛛的請求數量，如果某一秒出現 3 到 10 個請求，說明抓取端在並行打開连接。不同搜尋引擎的並發策略不同，同一個搜尋引擎在不同站点上的表現也可能變化。

• 同秒請求數：反映瞬时並發，不等于長期抓取速率。
• 請求間隔：同一 URL 或同一目錄的两次抓取之間隔了多久。
• 响應時間：服務器從收到請求到返回首字节的耗时。
• 狀態碼分布：200、301、404、429、503 的比例變化。

把這些資料放在一起看，比只看總請求數更有意义。比如並發不高但响應時間持續超過一两秒，蜘蛛可能會主動放缓；反過来，响應很快、狀態碼稳定，蜘蛛在同一時間段内的抓取量往往會更接近站点可承受的上限。

服務器限流與狀態碼的配合

如果服務器承载有限，不建议直接封禁蜘蛛 IP。更常见的做法是通過狀態碼表達“現在忙，稍後再来”。

429 與 503 的区別

429 通常表示請求過多，503 表示服務暂时不可用。蜘蛛對這两類狀態碼一般會做退避處理，也就是降低後續請求频率，過一段時間再尝试。關键在于不要長期返回 429 或 503，否則抓取端可能認為站点持續不稳定，减少来訪。

限流的目标是保護服務器，而不是把蜘蛛赶走。短暂、有規律的退避，比長時間無响應更容易让抓取恢复正常。

如果使用 CDN 或反向代理，還要確認限流規則没有把蜘蛛請求誤判為攻击流量。有的防護策略會拦截高频 UA 或空 Referer 請求，而蜘蛛請求恰好可能缺少 Referer。检查拦截日誌时，可以先把蜘蛛 IP 段和 UA 加入观察名單，再决定是否放行。

robots.txt 里的抓取設定

robots.txt 中的 crawl-delay 並不是所有搜尋引擎都支持。Google 明确不遵循该指令，Bing 等部分抓取端會參考。因此，寫 crawl-delay 只能作為辅助手段，不能替代服務器端的稳定性和合理的响應速度。

• 如果站点規模小、服務器弱，可以設定一個較大的 crawl-delay，但不要指望所有蜘蛛都遵守。
• 更可靠的方式是让頁面快速返回，减少動態渲染和阻塞资源带来的等待。
• 把重要目錄的内鏈和 Sitemap 维護好，让蜘蛛在有限訪問次數里優先走到有效頁面。

抓取速率與站点结构的關系

蜘蛛愿意抓多少，除了看服務器，也看它發現地址的效率。内鏈清晰、Sitemap 更新及时、URL 不重复，蜘蛛就不容易把訪問次數浪費在重定向鏈、參數頁或空頁面上。抓取速率並不是越高越好，而是與站点能稳定提供的有效頁面數量匹配。

定期從日誌里抽样一周或一個月的蜘蛛請求，记錄响應時間的中位數、5xx 占比和 429 出現次數。如果這些指标稳定，抓取节奏通常也會比較平稳。若某段時間蜘蛛来訪明顯减少，可以先查服務器是否出現過長時間超时或大面积错誤，再回头检查内鏈和 Sitemap 有没有断档。

简單说，蜘蛛的並發和速率是抓取端根據站点反馈動態調整的结果。服務器稳定、响應快速、狀態碼清楚，蜘蛛就更容易按正常节奏完成 URL 發現和抓取；反之，過载、誤封或長期错誤會让抓取變慢，甚至让一部分地址迟迟等不到訪問。