站長常把注意力放在“蜘蛛来了没有”，却容易忽略另一面：抓取本身就是一串真實的 HTTP 請求，它和你自己的用戶共用同一份 CPU、带宽、資料库连接和磁盘 IO。当頁面變重、模板里多了几個實时查询，抓取压力就會和真實流量叠加，表現為响應變慢、连接超时，甚至零星 5xx。要判断抓取是否顺畅，先要看服務器還有没有余量，而不是只盯着日誌條數。
蜘蛛請求的负载画像
不同類型的 URL，抓取成本差別很大。同样是“一次請求”，静態頁和带篩選的列表頁對後端的压力可能差一個數量級。
- 静態頁與缓存命中的頁面：成本最低，通常只消耗带宽和连接數。
- 列表頁翻頁與篩選參數頁：容易触發多次資料库查询，是负载的主要来源。
- 搜尋頁、價格比較頁、日歷類頁面：如果允许被抓，可能产生大量组合 URL，压力會放大。
- 静態资源：單次開销小，但數量多，带宽占用不容忽视。
把這几類分開看，才知道限速该限在哪儿。對高成本路径收紧，比對全站统一降速更有效。
先量化：日誌里要看的几個數
不量化就只能凭感觉調。按小时切分服務器日誌，統計下面几項，通常两三天就能看出規律。
- 單位時間的蜘蛛請求數，以及它占全部請求的比例。
- 抓取高峰出現的时段，是否和业務高峰重叠。
- 被請求最多的前 20 條路径，看有没有無意义的參數组合。
- 蜘蛛請求的 5xx 比例與平均响應時間，和普通用戶對比。
- 响應時間的分位數，而不只是平均值——平均 200 毫秒背後可能藏着大量 3 秒以上的請求。
能調的旋钮有哪些
robots.txt 里的 crawl-delay
需要說明的是，主流引擎中明确支持 crawl-delay 的以 Bing 等為主，Google 並不依赖這條指令来調度抓取。把它当作兜底手段可以，但不要指望它解决全部問题。對不支持的引擎，服務器侧的限制更實际。
WAF 與速率限制
不少“蜘蛛被挡”的情况，其實来自 CDN 或云 WAF 的通用反爬規則：短時間高频訪問、缺少常见浏览器指纹、命中某條频率阈值，都會被拦下来。處理方式不是简單放宽阈值，而是先核對来源——反向解析、UA 與官方公布的 IP 段三者比對後再放行，誤伤會少很多。
頁面本身的成本
抓取慢，多數时候不是蜘蛛慢，而是頁面本来就慢。给列表頁加缓存、减少同步的外部調用、把實时統計改成定时任務，往往比調限速更省事。
抓取时段與發布节奏
大規模生成新 URL、上线新目錄、批量推送 Sitemap，這些動作會让蜘蛛在短時間内集中来訪。如果又恰好压在业務高峰，服務器很容易吃不消。
- 批量發布安排在訪問低谷，给抓取留出缓冲。
- 新目錄上线时先放出部分入口，让蜘蛛分批發現，而不是一次性挂上几萬條連結。
- 大促、秒杀等确定性高峰前，提前检查缓存命中率和 5xx 比例。
蜘蛛的抓取請求是可以用日誌预测的流量。既然能预测，就不该让它成為压垮服務器的意外。
不建议一路限到底
另一個极端是把速率压得极低。抓取被過度限制後，新頁面和更新的 URL 被發現的速度會明顯變慢，問题排查时也更难拿到足够的抓取样本。限速的目标是让抓取有节奏地發生，而不是让它停下来。判断标准可以很简單：蜘蛛的 5xx 比例接近零、响應時間在可接受区間、业務高峰时段服務器仍有明顯余量。三條都满足，就不必再往下压。