很多站長把抓取频次理解成“蜘蛛来得越多越好”，實际上频次是双向的：一邊是搜尋引擎愿意花多少预算来抓，另一邊是你的服務器能不能在高峰时段稳住。只看任何一邊都容易判断失誤——蜘蛛来得少，未必是被冷落；蜘蛛来得猛，也未必是受宠。
先把三種“频次”分開看
日常讨论里说的抓取频次，其實混杂了三件事，混着看就會互相打架。
- 搜尋引擎的抓取調度：由平台根據站点歷史响應质量、更新频率等信号决定，你只能間接影响，不能直接设定。
- robots.txt 里的 Crawl-delay：只有部分爬虫會讀，而且是建议值不是硬限制，寫得太長會连带压掉新頁面的發現速度。
- 服務器侧的並發與限流：真正由你完全掌控的部分，也是出問题时最该先動手的地方。
服務器侧的自查清單
- 統計每分钟請求數峰值，区分是蜘蛛造成的還是真實用戶造成的。
- 確認應用层有没有並發上限，超限时是排队、拒绝，還是直接拖死。
- 检查資料库连接池是否够用，抓取高峰常常在這里先崩。
- 静態资源與動態頁面是否走同一套進程，图片被抓爆會不會拖累頁面本身。
- 超时阈值是否合理，太長的超时會把连接一直占着不放。
限流要做，但別做成一堵墙
带宽被打满时，最省事的做法是全站加一层嚴格的频率限制，结果往往是蜘蛛進不来、新内容迟迟不被發現。更稳的思路是分层：對已知的搜尋引擎爬虫给一個宽松但有限的上限，對来源不明的請求收紧，對登入、站内搜尋、篩選參數這類動態入口單獨设限。
如果确實需要临时降速，返回 503 或 429 並带上 Retry-After，比直接返回错誤頁或長時間挂起要好得多。前者蜘蛛會在约定時間後重试，後者容易被判定為服務器不稳定，抓取频次反而被压低。
限流的目的不是把請求挡在门外，而是让重要頁面在被抓的时候，服務器還答得出来。
日誌里值得長期盯的几個指标
- 每小时抓取請求數，看趋势而不是绝對值。
- 平均响應時間與 P95 响應時間，平均值正常不代表没有拖尾。
- 5xx 與 429 的比例，超過一個小比例就该查原因。
- 被抓取 URL 的分布，判断带宽是不是被低價值頁面消耗掉了。
- 出站带宽峰值，以及它與蜘蛛来訪峰值的重合程度。
几個容易走偏的做法
一是把 Crawl-delay 设成几十秒，以為這样能省资源。對抓取预算本就不多的站点，這等于主動放慢内容發現。二是只在 robots.txt 里寫規則，却不在服務器日誌里驗證效果，規則寫了没人遵守也無從得知。三是只顾着给蜘蛛限速，忽略真實用戶的並發，结果高峰期两邊一起卡。
抓取频次這件事没有一劳永逸的配置。内容規模、訪問量、服務器規格都在變，隔一段時間用日誌回看一次，比一次性把參數調到极端要實用得多。