百度抓取压力把服务器打满之后Crawl-delay 与压力反馈工具的排查复盘适用读者企业站运维、独立开发者、负责官网的 IT 兼职同学。你将看到一次真实的百度爬虫压垮服务器事故以及从日志到限流再到收录回升的完整排查过程。上个月 14 号下午两点多我们公司官网制造业 B2B 站大约四千个 URL突然打不开客服部电话被打爆。登上服务器一看CPU 长期 90% 以上带宽跑满 50Mbpsaccess.log里密密麻麻全是 Baiduspider。那一小时的并发请求数是平时的七倍多。做网站优化Search Engine Optimization, SEO这几年第一次被搜索引擎自己打到宕机。这篇就复盘整个过程包括我们中途一个错误决定差点让收录崩掉。TL;DR滞后反馈回路百度抓取频次调整滞后服务器几分钟就被打满。一刀切限流致命全站限流会压垮收录索引量从 3800 掉到 1100。正确做法资源平台压力反馈 Nginx 双 zone 精细限流。改版前预防提前调频次上限、分批提交链接、预配双 zone。事情怎么发生的先交代背景。站点是 2019 年上线的老站跑在一台 4 核 8G 的云服务器上Nginx 1.24 PHP-FPM内容以产品页和技术资料页为主平时日 PV 一万多不算重负载。出事前一周我们刚把全站 URL 从动态参数改成了伪静态并在百度搜索资源平台ziyuan.baidu.com提交了新版链接。改动后站点结构变了不少旧 URL 301 到新 URL。问题就出在这百度发现站点大面积变化后临时调高了抓取频次来更新它的索引库。伪静态规则又写得比较费 CPU——每条请求都要跑一遍正则匹配再转发给 PHP——爬虫一提速服务器直接顶不住。这里得说清楚百度抓取压力的机制不然后面的处理你看不明白。百度抓取压力的机制百度官方的说法是Baiduspider 会根据网站规模、更新频率、页面质量、服务器承受能力来动态调整抓取频次。它有一条压力基线理论上会「自动适配」站点的负载。但这个自动适配是滞后的——它感知到你的服务器变慢需要先观察到一段时间的超时、5xx 响应然后再往回调频次。回调窗口往往是小时级的而一台小服务器被打满只要几分钟。也就是说抓取频次和站点负载之间存在一个反馈回路但这个回路的响应速度跟不上突发调整。你在资源平台「抓取频次」工具里看到的曲线是百度已经执行的结果不是即将执行的预告。等你在曲线上看到尖峰服务器早就被压过了。另一个常被忽略的点URL 改版、大量新链接提交、301 跳转集中上线这些动作都会触发抓取频次上调。我们后来在站长社区看到不少人有类似经历改版后一两周是压力最大的窗口期。承受住承受不住站点改版/批量提交链接百度上调抓取频次请求量陡增服务器能否承受索引更新正常响应变慢/超时/5xx百度感知异常逐步下调频次站点恢复正常用户访问受阻业务受损排查从日志确认元凶服务器卡死的第一反应是被攻击先排除了这个。看日志的命令很简单依赖Linux 服务器Ubuntu 22.04、Nginx 1.24以下命令均在生产机上以 root 执行。# 统计最近一小时 UA 中含 Baiduspider 的请求数grepBaiduspider/var/log/nginx/access.log|grep$(date-d1 hour ago%d/%b/%Y:%H)|wc-l# 按分钟分组看爬虫请求的时间分布确认是持续高压还是脉冲式awk{print $4}/var/log/nginx/access.log|grepBaiduspider|cut-d: -f1-3|sort|uniq-c|sort-rn# 查看爬虫请求里状态码分布5xx 多说明服务器已经在硬扛grepBaiduspider/var/log/nginx/access.log|awk{print $9}|sort|uniq-c# 找出被请求最多的前 20 个 URL判断爬虫在抓什么grepBaiduspider/var/log/nginx/access.log|awk{print $7}|sort|uniq-c|sort-rn|head-20结果很典型一小时 2.1 万次爬虫请求其中 40% 打在旧的动态参数 URL 上状态码里 301 和 502 混着来。正常用户的请求被挤到超时。元凶确认了是百度而且是奔着旧 URL 来的——它想尽快把改版后的索引对齐。排查阶段我们还做了一张时间线表方便后面复盘和对齐团队口径时间现象处理动作结果D1 14:20CPU 90%带宽打满用户无法访问上全站 limit_req 每秒 5 请求负载十分钟内恢复但埋雷D4索引量从 3800 掉到 1100产品词排名下滑撤掉全站限流查资源平台曲线确认抓取频次被压到 300 以下D5服务器恢复但爬虫尖峰仍在提交抓取压力反馈频次上限调低一档36 小时后抓取量回落D7爬虫与用户争抢限流配额上线 Nginx 双 zone 精细限流CPU 降到 40%用户体验正常D20索引量回升持续观察频次曲线收录超过事故前水平我们踩的第一个坑全站一刀切限流运维同事小周化名当时很紧张第一反应是「先把爬虫挡了再说」直接在 Nginx 上加了一条全站 limit_req对所有 UA 限到每秒 5 个请求。这招立竿见影服务器负载十分钟内降下来了。但三天后出问题了。我们在百度搜索资源平台的「抓取频次」工具里看到频次曲线从每天 2 万多掉到了 300 以下而且连续一周没回升。更要命的是索引量原来首页和产品页在百度有 3800 多条收录限流一周后掉到 1100。几个核心产品词的排名肉眼可见地下滑。销售部同事老陈跑来问「网站是不是被百度处罚了」。后来复盘这一刀切犯了两个错限流阈值定得太低。每秒 5 个请求百度每天能抓的页面被压缩到 40 万以内都不到的水平——实际上大量请求被 503 拒绝百度会把这些页面视为「暂时不可用」从索引里移除或降权。没有区分正常用户和爬虫的配额。正常用户的高峰请求和爬虫共享同一个 limit_req zone等于爬虫和用户抢路。PHP-FPMNginx(全站限流)BaiduspiderPHP-FPMNginx(全站限流)Baiduspider连续503 判定站点不稳定请求页面(高频)超出阈值 返回503下调抓取频次移除部分索引正常用户请求(也受限流拖累)响应变慢正确姿势一用抓取压力反馈和频次工具沟通踩坑之后我们换了思路。百度搜索资源平台其实提供了两条官方沟通渠道很多人只知道其中一个。「抓取频次」工具在「数据统计」栏目下能看到百度每天、每小时对你站点的抓取量曲线还能手动调节频次上限分三档强制上限、标准、不限制。我们的做法是把频次上限先调到「标准偏低」一档给服务器一个恢复窗口等负载稳定后再逐步放开。「抓取压力反馈」入口更关键。它允许站点管理员主动告诉百度「我的服务器目前承受不了当前抓取压力」百度会安排下调。这个工具的价值在于它是双向的不是被动等爬虫打满服务器而是主动报备。我们提交反馈后大约 36 小时抓取频次曲线明显回落到日常水平。两种工具的差别我整理成一张表对比项抓取频次工具抓取压力反馈位置资源平台-数据统计资源平台-网站支持/反馈入口作用方向查看手动设定频次上限主动告知服务器压力大生效速度设定后数小时提交后约 1-2 天我们实测 36 小时适用场景例行监控、改版前预防突发过载、临时降载副作用上限过低会压制收录无明显副作用回调后自动恢复顺带把 Crawl-delay 的口径也交代一下这个话题坑过很多人。Google 早在 2019 年就官方宣布不再使用 robots.txt 里的 Crawl-delay 指令写了也是白写。百度官方文档同样没有声明支持 Crawl-delay站长社区里有人实测有效、有人实测无效百度工程师在公开场合的答复是「抓取压力请通过资源平台的工具沟通」。所以把服务器负载的希望寄托在 Crawl-delay 上是不可靠的它是 Bing 等少数引擎支持的指令对百度基本是心理安慰。正确姿势二Nginx 区分爬虫与用户的精细限流全站一刀切不行那就精细限。目标有两个保住正常用户体验同时把爬虫的压力控制在服务器能接受的范围内别让百度以为站点不稳定。依赖Nginx 1.24Ubuntu 22.04 的 apt 安装版配置文件位于 /etc/nginx/改动后需 nginx -t 验证再 reload。# ---- 全局限流 zone 定义必须放在 http 块 ---- # 用户区按客户端 IP 限流10MB 共享内存约可跟踪 16 万个 IP limit_req_zone $binary_remote_addr zoneuser_perip:10m rate20r/s; # 爬虫区按百度 UA 限流阈值明显高于用户区保证抓取不被卡死 # $spider_is_baidu 是自定义 map 变量见下方 map 块 limit_req_zone $spider_is_baidu zonebaiduspider:10m rate50r/s; # 用 map 把请求分成两类爬虫命中爬虫键其余命中用户键 map $http_user_agent $spider_is_baidu { default ; ~*Baiduspider $binary_remote_addr; } # 抓取到的爬虫请求超出速率后先排队 20 个再多的才拒绝 # burst 不宜过大过大等于没限 limit_req zonebaiduspider burst20 delay8; # 爬虫被限流时返回 503 而不是默认的 503 页面同时加 Retry-After 头 limit_req_status 503; server { listen 443 ssl; server_name www.example-mfg.cn; # 用户请求只对动态页面限流静态资源不限避免页面加载被拖慢 location ~ \.php$ { limit_req zoneuser_perip burst40 nodelay; fastcgi_pass unix:/run/php/php8.1-fpm.sock; # 关键给 PHP-FPM 设上限防止慢请求把进程池占满 fastcgi_read_timeout 15s; } # 伪静态重写集中在这里改用简单前缀匹配替代多条正则降低 CPU 消耗 location /products/ { # 命中前缀后内部跳转到固定入口不做重复正则匹配 try_files $uri $uri/ /index.php?$query_string; } }这套配置上线后的效果以我们站点的实测数据说爬虫高峰期的请求速率被稳定压在每秒 50 上下服务器 CPU 从 90% 降到 40% 左右正常用户页面首字节时间从打满时的 6 秒回到 300 毫秒以内。关键是百度的抓取没有被大量拒绝——limit_req 的 burst 和 delay 让正常频率下的爬虫请求基本无感只有尖峰被削掉。收录恢复与验证限流调整后第四天资源平台的索引量曲线止跌回升。第 12 天回到 3500 左右第 20 天超过了事故前的水平。核心产品词排名在第 10 天前后陆续回来。抓取频次曲线也稳定在每天 1.5 万到 2 万之间没有再出现打满服务器的尖峰。这中间我们做对的一件事是改版前就该预估压力旧 URL 有 301 跳转的页面百度会按旧链接重抓一遍再跟到新地址等于抓取量短期翻倍。如果重来一次我们会在改版前一周先在资源平台把频次上限调低一档分批提交链接而不是一次性全量提交。改版前抓取压力预防清单如果重来一次我们会在改版前按下面这份清单逐项落实把压力窗口提前消化掉提前一周调低抓取频次上限在百度搜索资源平台的「抓取频次」工具里先把上限调到「标准偏低」一档给服务器留出缓冲等改版稳定后再逐步放开。分批提交新链接而非全量把几千个新 URL 拆成几批每天提交一批避免一次性全量提交触发百度集中重抓。预先配置双 zone 限流在改版上线前就把 Nginx 的用户区与爬虫区分开限流别等被打满再临时加规则。监控 301 跳转量改版后旧 URL 会集中 301 到新地址盯紧 access.log 里 301 的请求量一旦异常飙升及时介入。准备压力反馈入口的提交话术模板提前写好「服务器当前承受不了抓取压力请下调频次」的说明文案出事时能第一时间提交不临时措辞。常见问题 FAQQ1百度抓取压力大时能否用 robots.txt 屏蔽 Baiduspider不建议而且后果很严重。robots 协议的 Disallow 语义是「不抓取」已收录页面会因长期不被抓取而逐渐被移出索引等于用 SEO 的命换服务器片刻安宁。我们这次事故里如果当时用 robots.txt 屏蔽索引量损失会比全站限流更惨。正确做法是走资源平台的抓取压力反馈让百度主动下调频次。Q2Crawl-delay 对百度到底有没有用基本没用。Google 早在 2019 年就官方宣布不再使用 robots.txt 里的 Crawl-delay百度官方文档同样没有声明支持站长社区实测结果也时灵时不灵。百度工程师的公开答复是「抓取压力请通过资源平台的工具沟通」。所以别把服务器负载的希望寄托在 Crawl-delay 上它只是心理安慰。Q3全站限流和双 zone 限流的本质区别是什么全站限流把所有请求用户爬虫塞进同一个 limit_req zone阈值定低了会压垮收录定高了又挡不住爬虫而且用户和爬虫互相抢配额。双 zone 限流用 map 按 UA 把请求分成用户区和爬虫区各自独立限流——爬虫区阈值可以放宽保证抓取不被卡死用户区按 IP 限流保住体验。我们上线双 zone 后 CPU 从 90% 降到 40%用户首字节时间回到 300 毫秒以内。Q4改版后索引量多久能恢复以我们这次实测限流调整后第四天索引量曲线止跌回升第 12 天回到 3500 左右第 20 天超过事故前水平核心产品词排名在第 10 天前后陆续回来。恢复速度取决于你多快撤掉错误限流、是否提交压力反馈以及改版前有没有做预防。提前调低频次上限、分批提交链接能把恢复窗口压缩到最短。误区澄清与几句收尾把常见误区列清楚Crawl-delay 对 Google 完全无效对百度也没有官方背书别指望它出事时用 robots.txt 屏蔽 Baiduspider 更不可取——robots 协议的 Disallow 是「不抓取」的意思已收录页面会被逐渐移出索引等于用 SEO 的命换服务器片刻安宁全站统一限流是最容易踩的坑用户和爬虫必须分开配额。服务器扛不住时优先走资源平台的抓取压力反馈那是官方承认的沟通渠道。从更长的视角看这套「抓取压力—服务器负载—索引收录」的平衡功夫以后做生成式引擎优化Generative Engine Optimization, GEO时同样用得上——AI 引擎的爬虫一样会带来压力问题服务器稳、抓取顺内容才有被引用的前提。你在百度抓取压力上踩过什么坑或者用过哪些压爬虫的招评论区聊聊。参考与延伸百度搜索资源平台-抓取频次说明https://ziyuan.baidu.com/wiki/953百度搜索资源平台-抓取诊断与压力沟通https://ziyuan.baidu.com/siteNginx 官方文档 Module ngx_http_limit_req_modulehttps://nginx.org/en/docs/http/ngx_http_limit_req_module.htmlGoogle 搜索中心-Crawl-delay 不再被使用的说明https://developers.google.com/search/blog/2019/04/changing-crawl-delay关键词百度抓取频次、Baiduspider、Nginx限流、Crawl-delay、制造业官网收录、网站优化、抓取压力反馈_module.htmlGoogle 搜索中心-Crawl-delay 不再被使用的说明https://developers.google.com/search/blog/2019/04/changing-crawl-delay关键词百度抓取频次、Baiduspider、Nginx限流、Crawl-delay、制造业官网收录、网站优化、抓取压力反馈 百度抓取压力把服务器打满之后：Crawl-delay 与压力反馈工具的排查复盘
百度抓取压力把服务器打满之后Crawl-delay 与压力反馈工具的排查复盘适用读者企业站运维、独立开发者、负责官网的 IT 兼职同学。你将看到一次真实的百度爬虫压垮服务器事故以及从日志到限流再到收录回升的完整排查过程。上个月 14 号下午两点多我们公司官网制造业 B2B 站大约四千个 URL突然打不开客服部电话被打爆。登上服务器一看CPU 长期 90% 以上带宽跑满 50Mbpsaccess.log里密密麻麻全是 Baiduspider。那一小时的并发请求数是平时的七倍多。做网站优化Search Engine Optimization, SEO这几年第一次被搜索引擎自己打到宕机。这篇就复盘整个过程包括我们中途一个错误决定差点让收录崩掉。TL;DR滞后反馈回路百度抓取频次调整滞后服务器几分钟就被打满。一刀切限流致命全站限流会压垮收录索引量从 3800 掉到 1100。正确做法资源平台压力反馈 Nginx 双 zone 精细限流。改版前预防提前调频次上限、分批提交链接、预配双 zone。事情怎么发生的先交代背景。站点是 2019 年上线的老站跑在一台 4 核 8G 的云服务器上Nginx 1.24 PHP-FPM内容以产品页和技术资料页为主平时日 PV 一万多不算重负载。出事前一周我们刚把全站 URL 从动态参数改成了伪静态并在百度搜索资源平台ziyuan.baidu.com提交了新版链接。改动后站点结构变了不少旧 URL 301 到新 URL。问题就出在这百度发现站点大面积变化后临时调高了抓取频次来更新它的索引库。伪静态规则又写得比较费 CPU——每条请求都要跑一遍正则匹配再转发给 PHP——爬虫一提速服务器直接顶不住。这里得说清楚百度抓取压力的机制不然后面的处理你看不明白。百度抓取压力的机制百度官方的说法是Baiduspider 会根据网站规模、更新频率、页面质量、服务器承受能力来动态调整抓取频次。它有一条压力基线理论上会「自动适配」站点的负载。但这个自动适配是滞后的——它感知到你的服务器变慢需要先观察到一段时间的超时、5xx 响应然后再往回调频次。回调窗口往往是小时级的而一台小服务器被打满只要几分钟。也就是说抓取频次和站点负载之间存在一个反馈回路但这个回路的响应速度跟不上突发调整。你在资源平台「抓取频次」工具里看到的曲线是百度已经执行的结果不是即将执行的预告。等你在曲线上看到尖峰服务器早就被压过了。另一个常被忽略的点URL 改版、大量新链接提交、301 跳转集中上线这些动作都会触发抓取频次上调。我们后来在站长社区看到不少人有类似经历改版后一两周是压力最大的窗口期。承受住承受不住站点改版/批量提交链接百度上调抓取频次请求量陡增服务器能否承受索引更新正常响应变慢/超时/5xx百度感知异常逐步下调频次站点恢复正常用户访问受阻业务受损排查从日志确认元凶服务器卡死的第一反应是被攻击先排除了这个。看日志的命令很简单依赖Linux 服务器Ubuntu 22.04、Nginx 1.24以下命令均在生产机上以 root 执行。# 统计最近一小时 UA 中含 Baiduspider 的请求数grepBaiduspider/var/log/nginx/access.log|grep$(date-d1 hour ago%d/%b/%Y:%H)|wc-l# 按分钟分组看爬虫请求的时间分布确认是持续高压还是脉冲式awk{print $4}/var/log/nginx/access.log|grepBaiduspider|cut-d: -f1-3|sort|uniq-c|sort-rn# 查看爬虫请求里状态码分布5xx 多说明服务器已经在硬扛grepBaiduspider/var/log/nginx/access.log|awk{print $9}|sort|uniq-c# 找出被请求最多的前 20 个 URL判断爬虫在抓什么grepBaiduspider/var/log/nginx/access.log|awk{print $7}|sort|uniq-c|sort-rn|head-20结果很典型一小时 2.1 万次爬虫请求其中 40% 打在旧的动态参数 URL 上状态码里 301 和 502 混着来。正常用户的请求被挤到超时。元凶确认了是百度而且是奔着旧 URL 来的——它想尽快把改版后的索引对齐。排查阶段我们还做了一张时间线表方便后面复盘和对齐团队口径时间现象处理动作结果D1 14:20CPU 90%带宽打满用户无法访问上全站 limit_req 每秒 5 请求负载十分钟内恢复但埋雷D4索引量从 3800 掉到 1100产品词排名下滑撤掉全站限流查资源平台曲线确认抓取频次被压到 300 以下D5服务器恢复但爬虫尖峰仍在提交抓取压力反馈频次上限调低一档36 小时后抓取量回落D7爬虫与用户争抢限流配额上线 Nginx 双 zone 精细限流CPU 降到 40%用户体验正常D20索引量回升持续观察频次曲线收录超过事故前水平我们踩的第一个坑全站一刀切限流运维同事小周化名当时很紧张第一反应是「先把爬虫挡了再说」直接在 Nginx 上加了一条全站 limit_req对所有 UA 限到每秒 5 个请求。这招立竿见影服务器负载十分钟内降下来了。但三天后出问题了。我们在百度搜索资源平台的「抓取频次」工具里看到频次曲线从每天 2 万多掉到了 300 以下而且连续一周没回升。更要命的是索引量原来首页和产品页在百度有 3800 多条收录限流一周后掉到 1100。几个核心产品词的排名肉眼可见地下滑。销售部同事老陈跑来问「网站是不是被百度处罚了」。后来复盘这一刀切犯了两个错限流阈值定得太低。每秒 5 个请求百度每天能抓的页面被压缩到 40 万以内都不到的水平——实际上大量请求被 503 拒绝百度会把这些页面视为「暂时不可用」从索引里移除或降权。没有区分正常用户和爬虫的配额。正常用户的高峰请求和爬虫共享同一个 limit_req zone等于爬虫和用户抢路。PHP-FPMNginx(全站限流)BaiduspiderPHP-FPMNginx(全站限流)Baiduspider连续503 判定站点不稳定请求页面(高频)超出阈值 返回503下调抓取频次移除部分索引正常用户请求(也受限流拖累)响应变慢正确姿势一用抓取压力反馈和频次工具沟通踩坑之后我们换了思路。百度搜索资源平台其实提供了两条官方沟通渠道很多人只知道其中一个。「抓取频次」工具在「数据统计」栏目下能看到百度每天、每小时对你站点的抓取量曲线还能手动调节频次上限分三档强制上限、标准、不限制。我们的做法是把频次上限先调到「标准偏低」一档给服务器一个恢复窗口等负载稳定后再逐步放开。「抓取压力反馈」入口更关键。它允许站点管理员主动告诉百度「我的服务器目前承受不了当前抓取压力」百度会安排下调。这个工具的价值在于它是双向的不是被动等爬虫打满服务器而是主动报备。我们提交反馈后大约 36 小时抓取频次曲线明显回落到日常水平。两种工具的差别我整理成一张表对比项抓取频次工具抓取压力反馈位置资源平台-数据统计资源平台-网站支持/反馈入口作用方向查看手动设定频次上限主动告知服务器压力大生效速度设定后数小时提交后约 1-2 天我们实测 36 小时适用场景例行监控、改版前预防突发过载、临时降载副作用上限过低会压制收录无明显副作用回调后自动恢复顺带把 Crawl-delay 的口径也交代一下这个话题坑过很多人。Google 早在 2019 年就官方宣布不再使用 robots.txt 里的 Crawl-delay 指令写了也是白写。百度官方文档同样没有声明支持 Crawl-delay站长社区里有人实测有效、有人实测无效百度工程师在公开场合的答复是「抓取压力请通过资源平台的工具沟通」。所以把服务器负载的希望寄托在 Crawl-delay 上是不可靠的它是 Bing 等少数引擎支持的指令对百度基本是心理安慰。正确姿势二Nginx 区分爬虫与用户的精细限流全站一刀切不行那就精细限。目标有两个保住正常用户体验同时把爬虫的压力控制在服务器能接受的范围内别让百度以为站点不稳定。依赖Nginx 1.24Ubuntu 22.04 的 apt 安装版配置文件位于 /etc/nginx/改动后需 nginx -t 验证再 reload。# ---- 全局限流 zone 定义必须放在 http 块 ---- # 用户区按客户端 IP 限流10MB 共享内存约可跟踪 16 万个 IP limit_req_zone $binary_remote_addr zoneuser_perip:10m rate20r/s; # 爬虫区按百度 UA 限流阈值明显高于用户区保证抓取不被卡死 # $spider_is_baidu 是自定义 map 变量见下方 map 块 limit_req_zone $spider_is_baidu zonebaiduspider:10m rate50r/s; # 用 map 把请求分成两类爬虫命中爬虫键其余命中用户键 map $http_user_agent $spider_is_baidu { default ; ~*Baiduspider $binary_remote_addr; } # 抓取到的爬虫请求超出速率后先排队 20 个再多的才拒绝 # burst 不宜过大过大等于没限 limit_req zonebaiduspider burst20 delay8; # 爬虫被限流时返回 503 而不是默认的 503 页面同时加 Retry-After 头 limit_req_status 503; server { listen 443 ssl; server_name www.example-mfg.cn; # 用户请求只对动态页面限流静态资源不限避免页面加载被拖慢 location ~ \.php$ { limit_req zoneuser_perip burst40 nodelay; fastcgi_pass unix:/run/php/php8.1-fpm.sock; # 关键给 PHP-FPM 设上限防止慢请求把进程池占满 fastcgi_read_timeout 15s; } # 伪静态重写集中在这里改用简单前缀匹配替代多条正则降低 CPU 消耗 location /products/ { # 命中前缀后内部跳转到固定入口不做重复正则匹配 try_files $uri $uri/ /index.php?$query_string; } }这套配置上线后的效果以我们站点的实测数据说爬虫高峰期的请求速率被稳定压在每秒 50 上下服务器 CPU 从 90% 降到 40% 左右正常用户页面首字节时间从打满时的 6 秒回到 300 毫秒以内。关键是百度的抓取没有被大量拒绝——limit_req 的 burst 和 delay 让正常频率下的爬虫请求基本无感只有尖峰被削掉。收录恢复与验证限流调整后第四天资源平台的索引量曲线止跌回升。第 12 天回到 3500 左右第 20 天超过了事故前的水平。核心产品词排名在第 10 天前后陆续回来。抓取频次曲线也稳定在每天 1.5 万到 2 万之间没有再出现打满服务器的尖峰。这中间我们做对的一件事是改版前就该预估压力旧 URL 有 301 跳转的页面百度会按旧链接重抓一遍再跟到新地址等于抓取量短期翻倍。如果重来一次我们会在改版前一周先在资源平台把频次上限调低一档分批提交链接而不是一次性全量提交。改版前抓取压力预防清单如果重来一次我们会在改版前按下面这份清单逐项落实把压力窗口提前消化掉提前一周调低抓取频次上限在百度搜索资源平台的「抓取频次」工具里先把上限调到「标准偏低」一档给服务器留出缓冲等改版稳定后再逐步放开。分批提交新链接而非全量把几千个新 URL 拆成几批每天提交一批避免一次性全量提交触发百度集中重抓。预先配置双 zone 限流在改版上线前就把 Nginx 的用户区与爬虫区分开限流别等被打满再临时加规则。监控 301 跳转量改版后旧 URL 会集中 301 到新地址盯紧 access.log 里 301 的请求量一旦异常飙升及时介入。准备压力反馈入口的提交话术模板提前写好「服务器当前承受不了抓取压力请下调频次」的说明文案出事时能第一时间提交不临时措辞。常见问题 FAQQ1百度抓取压力大时能否用 robots.txt 屏蔽 Baiduspider不建议而且后果很严重。robots 协议的 Disallow 语义是「不抓取」已收录页面会因长期不被抓取而逐渐被移出索引等于用 SEO 的命换服务器片刻安宁。我们这次事故里如果当时用 robots.txt 屏蔽索引量损失会比全站限流更惨。正确做法是走资源平台的抓取压力反馈让百度主动下调频次。Q2Crawl-delay 对百度到底有没有用基本没用。Google 早在 2019 年就官方宣布不再使用 robots.txt 里的 Crawl-delay百度官方文档同样没有声明支持站长社区实测结果也时灵时不灵。百度工程师的公开答复是「抓取压力请通过资源平台的工具沟通」。所以别把服务器负载的希望寄托在 Crawl-delay 上它只是心理安慰。Q3全站限流和双 zone 限流的本质区别是什么全站限流把所有请求用户爬虫塞进同一个 limit_req zone阈值定低了会压垮收录定高了又挡不住爬虫而且用户和爬虫互相抢配额。双 zone 限流用 map 按 UA 把请求分成用户区和爬虫区各自独立限流——爬虫区阈值可以放宽保证抓取不被卡死用户区按 IP 限流保住体验。我们上线双 zone 后 CPU 从 90% 降到 40%用户首字节时间回到 300 毫秒以内。Q4改版后索引量多久能恢复以我们这次实测限流调整后第四天索引量曲线止跌回升第 12 天回到 3500 左右第 20 天超过事故前水平核心产品词排名在第 10 天前后陆续回来。恢复速度取决于你多快撤掉错误限流、是否提交压力反馈以及改版前有没有做预防。提前调低频次上限、分批提交链接能把恢复窗口压缩到最短。误区澄清与几句收尾把常见误区列清楚Crawl-delay 对 Google 完全无效对百度也没有官方背书别指望它出事时用 robots.txt 屏蔽 Baiduspider 更不可取——robots 协议的 Disallow 是「不抓取」的意思已收录页面会被逐渐移出索引等于用 SEO 的命换服务器片刻安宁全站统一限流是最容易踩的坑用户和爬虫必须分开配额。服务器扛不住时优先走资源平台的抓取压力反馈那是官方承认的沟通渠道。从更长的视角看这套「抓取压力—服务器负载—索引收录」的平衡功夫以后做生成式引擎优化Generative Engine Optimization, GEO时同样用得上——AI 引擎的爬虫一样会带来压力问题服务器稳、抓取顺内容才有被引用的前提。你在百度抓取压力上踩过什么坑或者用过哪些压爬虫的招评论区聊聊。参考与延伸百度搜索资源平台-抓取频次说明https://ziyuan.baidu.com/wiki/953百度搜索资源平台-抓取诊断与压力沟通https://ziyuan.baidu.com/siteNginx 官方文档 Module ngx_http_limit_req_modulehttps://nginx.org/en/docs/http/ngx_http_limit_req_module.htmlGoogle 搜索中心-Crawl-delay 不再被使用的说明https://developers.google.com/search/blog/2019/04/changing-crawl-delay关键词百度抓取频次、Baiduspider、Nginx限流、Crawl-delay、制造业官网收录、网站优化、抓取压力反馈_module.htmlGoogle 搜索中心-Crawl-delay 不再被使用的说明https://developers.google.com/search/blog/2019/04/changing-crawl-delay关键词百度抓取频次、Baiduspider、Nginx限流、Crawl-delay、制造业官网收录、网站优化、抓取压力反馈