很多站长把抓取频次理解成“蜘蛛来得越多越好”，实际上频次是双向的：一边是搜索引擎愿意花多少预算来抓，另一边是你的服务器能不能在高峰时段稳住。只看任何一边都容易判断失误——蜘蛛来得少，未必是被冷落；蜘蛛来得猛，也未必是受宠。
先把三种“频次”分开看
日常讨论里说的抓取频次，其实混杂了三件事，混着看就会互相打架。
- 搜索引擎的抓取调度：由平台根据站点历史响应质量、更新频率等信号决定，你只能间接影响，不能直接设定。
- robots.txt 里的 Crawl-delay：只有部分爬虫会读，而且是建议值不是硬限制，写得太长会连带压掉新页面的发现速度。
- 服务器侧的并发与限流：真正由你完全掌控的部分，也是出问题时最该先动手的地方。
服务器侧的自查清单
- 统计每分钟请求数峰值，区分是蜘蛛造成的还是真实用户造成的。
- 确认应用层有没有并发上限，超限时是排队、拒绝，还是直接拖死。
- 检查数据库连接池是否够用，抓取高峰常常在这里先崩。
- 静态资源与动态页面是否走同一套进程，图片被抓爆会不会拖累页面本身。
- 超时阈值是否合理，太长的超时会把连接一直占着不放。
限流要做，但别做成一堵墙
带宽被打满时，最省事的做法是全站加一层严格的频率限制，结果往往是蜘蛛进不来、新内容迟迟不被发现。更稳的思路是分层：对已知的搜索引擎爬虫给一个宽松但有限的上限，对来源不明的请求收紧，对登录、站内搜索、筛选参数这类动态入口单独设限。
如果确实需要临时降速，返回 503 或 429 并带上 Retry-After，比直接返回错误页或长时间挂起要好得多。前者蜘蛛会在约定时间后重试，后者容易被判定为服务器不稳定，抓取频次反而被压低。
限流的目的不是把请求挡在门外，而是让重要页面在被抓的时候，服务器还答得出来。
日志里值得长期盯的几个指标
- 每小时抓取请求数，看趋势而不是绝对值。
- 平均响应时间与 P95 响应时间，平均值正常不代表没有拖尾。
- 5xx 与 429 的比例，超过一个小比例就该查原因。
- 被抓取 URL 的分布，判断带宽是不是被低价值页面消耗掉了。
- 出站带宽峰值，以及它与蜘蛛来访峰值的重合程度。
几个容易走偏的做法
一是把 Crawl-delay 设成几十秒，以为这样能省资源。对抓取预算本就不多的站点，这等于主动放慢内容发现。二是只在 robots.txt 里写规则，却不在服务器日志里验证效果，规则写了没人遵守也无从得知。三是只顾着给蜘蛛限速，忽略真实用户的并发，结果高峰期两边一起卡。
抓取频次这件事没有一劳永逸的配置。内容规模、访问量、服务器规格都在变，隔一段时间用日志回看一次，比一次性把参数调到极端要实用得多。