抓取频率这件事，很多站长是在服务器开始卡之后才认真看的。平时只关注蜘蛛来过没有，一旦搜索蜘蛛的请求量翻了几倍，带宽、数据库连接、CPU 会被慢慢吃满，最先受影响的其实是真实访客的打开速度。抓取和体验之间需要一个可持续的平衡点，而不是一味放大。
先确认压力是不是真的来自抓取
服务器变慢的原因有很多，先别急着改 robots.txt 或上防火墙。用一两天的数据做个简单归因，方向会清楚很多。
日志里看四个数字
- 爬虫请求占比：按 User-Agent 和 IP 段统计，看爬虫请求占总请求的比例。这个比例长期偏高，说明抓取预算和带宽都被大量非访客请求占据。
- 时间分布：把请求按小时画一条线，看看是全天均匀，还是集中在一两个时段形成尖峰。尖峰更容易触发超时和 5xx。
- 状态码结构：如果 5xx、超时、499 的比例在上升，说明后端已经扛不住当前并发，这比抓了多少页更值得关注。
- 请求集中度：同一批地址被反复请求，往往意味着列表页、筛选页或参数组合产生了大量近似 URL。
带宽与负载监控
日志之外，再看一眼监控面板：带宽曲线的峰值时段是否和抓取高峰重合，入站流量与出站流量的比例是否异常，数据库连接数有没有被打满。如果这几条曲线对得上，基本可以确认抓取压力是主因。
常见的几个放大因素
- 列表页、筛选页、排序参数没有做归一化，同一批内容生成出大量不同地址；
- 动态页面没有缓存，每次抓取都走一遍完整查询；
- 图片和静态资源体积偏大，抓取时消耗的带宽比 HTML 高得多；
- 站点地图里的更新时间频繁变动，让蜘蛛误以为整站天天在更新；
- 站内搜索、日历、打印页这类低价值地址可以被批量抓取，却没有做任何限制。
一份可执行的自查清单
- 导出最近 7 天的日志，按小时统计爬虫请求量与访客请求量的比值。
- 找出被请求次数最高的 50 个地址，判断里面有多少是参数页面或重复内容。
- 检查服务器返回码分布，确认 5xx 与超时是否集中在抓取高峰。
- 查看带宽峰值是否与抓取高峰重合，必要时给静态资源加缓存与压缩。
- 确认 robots.txt 与站点地图没有互相矛盾，避免蜘蛛反复试探无效地址。
- 对列表页的分页、筛选参数设置合理的规范方式，减少近似 URL。
- 给动态页面加一层缓存，哪怕只有几十秒，也能明显削平尖峰。
- 在服务器层面设置合理的并发上限与超时时间，保证访客请求优先。
处理顺序：先止血，再优化
遇到明显压力时，先做能立刻见效的动作：限制单 IP 并发、给动态页加短缓存、把明显的低价值地址挡在门外。这些改动不涉及内容调整，风险小、见效快。等站点稳下来，再做结构层面的优化，比如收敛参数、合并重复列表、精简站点地图。顺序反了，容易在站点还不稳定的时候大改结构，反而让蜘蛛和访客一起迷路。
抓取量本身不是运营指标。真正需要盯的是：在保证访客体验的前提下，新内容能不能被稳定发现。如果访客开始抱怨打不开，抓取量再高也没有意义。
小结
抓取频率和服务器压力这笔账，最好在出问题之前就算清楚。定期看一眼日志里的爬虫占比、状态码结构和带宽曲线，比等到报警响起来再排查要从容得多。把资源留给真实访客，抓取这件事才谈得上可持续。