日誌里经常能见到這样的情况：一個站点前一周每天還有几千次蜘蛛請求，這周突然掉到几百次，頁面结构没動，内容也在正常更新，抓取却像踩了刹车。多數时候這並不是被惩罚，而是抓取調度端根據服務端的實际表現，下調了對這個站点的抓取速率。它和抓取预算是两個概念：预算决定愿意花多少，速率决定每次花多快，两者叠加起来，才决定了日誌里看到的請求量。
抓取速率不是固定值
搜尋引擎不會给每個站点寫死一個抓取频率，它更像一個實时协商的過程：先按相對保守的速率试探，观察响應時間、狀態碼分布、连接是否稳定，再决定加快還是放慢。同一個域名，在服務器狀態好的月份和狀態差的月份，抓取量可能相差好几倍。所以当你發現抓取量下滑，第一步不是去改内容，而是回头看服務端在那段時間里發生了什么。
影响速率的几類信号
响應時間與超时
响應變慢是最常见的诱因。当大量請求的响應時間從两三百毫秒涨到两三秒，調度端不會繼續用原来的並發去压，而是主動收敛。頁面本身的内容质量在這里几乎没有參與，纯粹是服務端给不给得出及时响應。值得注意的是，平均响應時間好看不代表没問题——一個被慢查询拖住几秒的接口頁，就足以让這批請求整体被降速。
5xx 與连接中断
如果说慢是劝退，那 5xx 和连接被重置就是劝停。短時間内集中的 500、502、503，會让調度端判断這個站暂时不适合抓取，把速率压到很低甚至临时暫停，過一段時間再回来试探。更麻烦的是這種信号會累积：一次資料库抖動、一次發布瞬間的過载，可能让之後的几天都處在低速抓取狀態。相比之下，返回 404 並不属于這類信号，它只是告诉蜘蛛這個 URL 不存在。
资源與並發
媒体文件、大体积 JS 和 CSS 同样占用抓取资源。如果一個頁面的渲染依赖几十個零散资源，且這些资源的响應都很慢，拉低的是整站的抓取体驗。把静態资源交给 CDN、给它們設定足够長的缓存头，往往比優化 HTML 本身的收益更直接。
先確認是不是速率被調低了
在動手改之前，先做一次简單的核對，避免把正常的抓取波動当成故障：
- 把日誌按天統計蜘蛛請求數、平均响應時間、5xx 占比，看三條曲线是否同时出現拐点；
- 检查下滑期間是否有過發布、扩容、CDN 切換、證书更新等操作；
- 区分路径：是整站所有路径都變少，還是只有某個目錄變少，後者更可能是结构問题而非速率問题；
- 確認服務器没有對蜘蛛做過激進限速或封禁，包括 WAF 規則和防火墙阈值。
如果統計下来是 5xx 上升、响應變慢、請求量下降同时出現，基本可以判断是速率被主動調低了。
恢复的先後顺序
不少人會在這时候去改 Sitemap、加内鏈、堆内容，希望把抓取量拉回来。顺序反了。抓取速率的恢复取决于服務端信号變好，内容层面的改動在這個阶段几乎不起作用。相對合理的顺序是：
- 先把错誤率压下去。找出报 5xx 的具体 URL 和触發條件，是超时、是内存、還是连接池打满。哪怕只修掉最主要的一類，效果也比到處優化明顯。
- 再把响應時間拉回稳定区間。加缓存、覆盖慢查询、把動態頁面静態化，目标是让大多數請求落在几百毫秒内，且波動小。
- 让稳定性维持一段時間。不要在刚修完的当天就期待請求量回来，調度端需要一段時間的正常样本才會重新提速。
- 最後才是内容层面的铺垫。等速率回升之後，用 Sitemap 和内鏈把重要頁面重新推到抓取路径上，效率才高。
两個容易被忽略的点
第一，速率下調往往不是针對你，而是調度端對整体表現的預設反應，不必去猜是不是被人工處理了。第二，恢复是渐進的，先回来的是首頁和列表頁這類高频路径，深层頁面會更晚，判断恢复情况时不要只盯着總請求數。
把抓取速率的波動当成一個服務端健康指标来看，很多疑問會變得清楚：它反映的通常不是内容好不好，而是服務器在那几天里，能不能稳定、快速地回應每一次抓取。