日志里经常能见到这样的情况：一个站点前一周每天还有几千次蜘蛛请求，这周突然掉到几百次，页面结构没动，内容也在正常更新，抓取却像踩了刹车。多数时候这并不是被惩罚，而是抓取调度端根据服务端的实际表现，下调了对这个站点的抓取速率。它和抓取预算是两个概念：预算决定愿意花多少，速率决定每次花多快，两者叠加起来，才决定了日志里看到的请求量。
抓取速率不是固定值
搜索引擎不会给每个站点写死一个抓取频率，它更像一个实时协商的过程：先按相对保守的速率试探，观察响应时间、状态码分布、连接是否稳定，再决定加快还是放慢。同一个域名，在服务器状态好的月份和状态差的月份，抓取量可能相差好几倍。所以当你发现抓取量下滑，第一步不是去改内容，而是回头看服务端在那段时间里发生了什么。
影响速率的几类信号
响应时间与超时
响应变慢是最常见的诱因。当大量请求的响应时间从两三百毫秒涨到两三秒，调度端不会继续用原来的并发去压，而是主动收敛。页面本身的内容质量在这里几乎没有参与，纯粹是服务端给不给得出及时响应。值得注意的是，平均响应时间好看不代表没问题——一个被慢查询拖住几秒的接口页，就足以让这批请求整体被降速。
5xx 与连接中断
如果说慢是劝退，那 5xx 和连接被重置就是劝停。短时间内集中的 500、502、503，会让调度端判断这个站暂时不适合抓取，把速率压到很低甚至临时暂停，过一段时间再回来试探。更麻烦的是这种信号会累积：一次数据库抖动、一次发布瞬间的过载，可能让之后的几天都处在低速抓取状态。相比之下，返回 404 并不属于这类信号，它只是告诉蜘蛛这个 URL 不存在。
资源与并发
媒体文件、大体积 JS 和 CSS 同样占用抓取资源。如果一个页面的渲染依赖几十个零散资源，且这些资源的响应都很慢，拉低的是整站的抓取体验。把静态资源交给 CDN、给它们设置足够长的缓存头，往往比优化 HTML 本身的收益更直接。
先确认是不是速率被调低了
在动手改之前，先做一次简单的核对，避免把正常的抓取波动当成故障：
- 把日志按天统计蜘蛛请求数、平均响应时间、5xx 占比，看三条曲线是否同时出现拐点；
- 检查下滑期间是否有过发布、扩容、CDN 切换、证书更新等操作；
- 区分路径：是整站所有路径都变少，还是只有某个目录变少，后者更可能是结构问题而非速率问题；
- 确认服务器没有对蜘蛛做过激进限速或封禁，包括 WAF 规则和防火墙阈值。
如果统计下来是 5xx 上升、响应变慢、请求量下降同时出现，基本可以判断是速率被主动调低了。
恢复的先后顺序
不少人会在这时候去改 Sitemap、加内链、堆内容，希望把抓取量拉回来。顺序反了。抓取速率的恢复取决于服务端信号变好，内容层面的改动在这个阶段几乎不起作用。相对合理的顺序是：
- 先把错误率压下去。找出报 5xx 的具体 URL 和触发条件，是超时、是内存、还是连接池打满。哪怕只修掉最主要的一类，效果也比到处优化明显。
- 再把响应时间拉回稳定区间。加缓存、覆盖慢查询、把动态页面静态化，目标是让大多数请求落在几百毫秒内，且波动小。
- 让稳定性维持一段时间。不要在刚修完的当天就期待请求量回来，调度端需要一段时间的正常样本才会重新提速。
- 最后才是内容层面的铺垫。等速率回升之后，用 Sitemap 和内链把重要页面重新推到抓取路径上，效率才高。
两个容易被忽略的点
第一，速率下调往往不是针对你，而是调度端对整体表现的默认反应，不必去猜是不是被人工处理了。第二，恢复是渐进的，先回来的是首页和列表页这类高频路径，深层页面会更晚，判断恢复情况时不要只盯着总请求数。
把抓取速率的波动当成一个服务端健康指标来看，很多疑问会变得清楚：它反映的通常不是内容好不好，而是服务器在那几天里，能不能稳定、快速地回应每一次抓取。