谷歌在 2026 年 10 月 6 日改写了「降低 Google 抓取频率」文档。按更新日志的说法，这次重组了紧急降速一节，并把 Retry-After 响应头的说明和示例直接写进了这篇指南。日志也说明 Retry-After 的支持不是新功能，原来写在「暂停或停用网站」那篇里，这次只是放到更容易找到的地方。对用小机器跑网站的人来说，这是一份值得收藏的官方「刹车」说明。
先找原因，再踩刹车
文档说，根据过去收到的反馈，抓取量突然暴涨最常见的原因是网站自身的 URL 设计：分面导航和各种排序、筛选功能，按日期生成大量 URL 的日历，以及动态搜索广告的目标页。谷歌建议先联系主机商、查看服务器最近的访问日志，确认流量来源是不是这些情况。查日志的思路可以参考 VPS CPU 占用 100% 怎么排查；如果来的其实是 AI 爬虫或冒充的爬虫，那是另一类问题，见 AI 爬虫正在吃掉你的服务器带宽。
紧急降速：返回 500、503 或 429
- 怎么做：在短时间内（文档举的例子是几个小时，或 1-2 天），对谷歌的抓取请求返回
500、503或429，而不是200。 - 效果：谷歌遇到大量这类状态码时，会对整个主机名（例如
subdomain.example.com）降低抓取频率，返回错误的 URL 和正常返回内容的 URL 都算在内；错误减少后会自动恢复。 - Retry-After：返回
503或429时可以带上Retry-After，写秒数（如Retry-After: 120）或一个 UTC 绝对时间，告诉爬虫什么时候再来。
代价也写得很清楚
- 对搜索来说，降速期间谷歌发现的新页面变少，已有页面刷新变慢（比如价格、库存的变化要更久才能反映出来），已删除的页面会在索引里停留更久；对 Google Ads，广告系列可能被取消或暂停，广告可能无法投放。
- 不要超过 1-2 天。如果谷歌连续多天在同一个 URL 上看到这些状态码，这个 URL 可能被移出索引。
- 如果没法对爬虫返回错误码，可以提交特殊请求反映抓取量异常，但不能申请提高抓取频率，而且处理可能要好几天。
落到 VPS 上
返回 503 要做在 Web 服务器或应用这一层，只针对爬虫、只在紧急时段生效，事后记得撤掉。User-Agent 可以被冒充，谷歌文档提供了用反向 DNS 或对照公布的 IP 地址来核实谷歌爬虫的方法。如果负载已经让网站出现 502 / 504，先按 502 / 504 排查指南把服务救回来；长期看，机器本身扛不住正常抓取，就该按业务重新估算 VPS 配置，或者用 CDN 分担静态资源。