你的服务器报错正在悄悄削掉抓取容量，而恢复要好几周
这个月的两条小新闻加在一起，值得放进你的检查清单。
第一条：Google 更新了抓取速率文档，加入了 Retry-After HTTP 的说明等——那是服务器用来告诉爬虫「什么时候再来」的信号。
第二条来自 Gary Illyes 关于搜索各阶段耗时的数据。其中一行值得单独拉响警报：当 Google 退让时，抓取容量可以在几秒内掉下去——比如你的服务器撑不住的时候——而抓取容量的更新，典型情况是 4 小时到 1–2 周，恢复期则是 1–3 周。
为什么这种不对称代价很大
Google 对你站点的抓取速率不是一个固定数字。它是一个持续被重新评估的判断：你的站点能承受多少、又值不值得。当你的服务器开始报错、超时或者响应变慢，爬虫最礼貌的做法就是退让。Google 退得很快。
回来却很慢。按同一份数据，一到三周。
所以序列是这样的：周五发了一个有问题的版本，周末 5xx 升高，抓取容量在几秒内掉下去，而恢复一直拖到接下来那两周。在这个窗口里，Google 看你站点的次数变少了——这也意味着新页面、更新过的页面、以及你刚拿到的那些链接，全都被更晚处理。
一次服务器事故和一次 SEO 事故，其实是同一起事故，只是其中一起会出现在你的错误监控面板上。
该配上什么
| 控制项 | 它防的是 |
|---|---|
| 对 5xx 速率告警，而不只对「站点是否在线」告警 | 站点可以「在线」，同时一直在流血 |
在 429 和 503 上返回正确的 Retry-After |
爬虫不再靠猜，而是知道该等 |
| 对机器人限制或延后重负载的需登录路由 | 抓取预算浪费在永远不会被收录的页面上 |
| 每周在 Search Console 看抓取统计 | 在同一周内发现容量下滑 |
| 永远不要在周五上线模板或跳转改动 | 最便宜的事故预防手段 |
第四行是你及时知道的方法。Search Console 会按属性报告抓取统计，一次持续的下降在那里可见的时间，远早于它表现成排名变化。
为什么这件事比以前更重要
抓取容量是所有想读你站点的东西共享的资源，而读者名单还在变长：Googlebot、Bingbot、AI 搜索爬虫，以及现在代表用户实时抓取页面的 AI 客户端。
如果你的容量被封顶或被限流，它们全都受同一个限制影响。而依赖被抓取的那些环节——页面收录、链接标注、结构化数据更新——全都排在它下游。按那份时间数据：链接标注典型从几分钟到 1–3 周；索引端到端典型约 1.5 小时，最慢到数月；结构化数据更新数小时到两周。
这些时钟，全都是从「抓取真的发生」那一刻才开始走的。
和站外工作的连接点
你挣来的每一个位置，都是一条「去读某个页面」的指示，而你自己的站点就是其中要被读到的一个页面。这就是为什么提交工作和站点健康工作属于同一次复查，即使负责它们的是不同的人。
这就是那个分工：https://backlinksubmit.org 站在其中一侧——从一份手工筛选的清单里把产品匹配到相关目录、人工提交，并在控制台里展示提交了哪些平台、各自进度如何。服务器健康站在另一侧。而一次抓取容量的崩塌，并不在乎哪一侧原本做得不错。
一次半小时的季度复查
拉出最近九十天的抓取统计，找持续性的下降，而不是逐日噪声。然后确认 5xx 告警存在、Retry-After 在需要的地方被返回、以及面向机器人的路由没有把抓取预算花在永远不会被收录的页面上。
它花半小时，防住的是一类要几周才能收拾的问题，而且是这份清单上最不时髦的一项。
常见问题
服务器性能差真的会影响 SEO 吗？
会，间接地、机械地影响。当站点撑不住时，Google 会降低抓取容量，而典型恢复期是一到三周。
Retry-After 是干什么用的？
它告诉爬虫在遇到限流或临时故障后什么时候再来；Google 更新后的抓取速率文档现在覆盖了这一点。
我怎么知道抓取容量掉了？
Search Console 会报告随时间变化的抓取统计。一次持续的下降在那里可见的时间，远早于它影响排名。
这也会影响 AI 爬虫吗？
它们共享同一个约束。一个被限流或正在出错的站点，会拖慢每一个读者，不只是 Googlebot。
分享文章
