Google 抓取预算、Crawl Capacity、Crawl Demand、Crawl Rate、429、503 和 Retry-After 有什么区别？
快速对照
名称 所在层 主要含义 典型影响 常见误解
--------------
Crawl Budget Google 抓取调度概念 容量与需求共同决定的可抓取量 大型或高变化站点的抓取覆盖 每站每天固定 URL 配额
Crawl Capacity Limit 主机负载与网络层 不影响服务稳定时可承受的并发与速率 5xx、超时增多时可能下降 服务器越强索引必然越多
Crawl Demand 搜索系统需求层 Google 对 URL 抓取或重抓的需求 受流行度、陈旧度、站点变化等影响 能用配置强制提高
Crawl Rate 观测指标 某时段 Googlebot 请求频率 随调度、响应和站点状态变化 等于 Crawl Budget
429 HTTP 状态码 Too Many Requests 表示请求方触发限流 永久删除或 noindex
503 HTTP 状态码 Service Unavailable 表示服务暂时不可用或维护 可长期当维护模式使用
Crawl Budget 不是固定日配额
Google 的大型站点抓取预算文档把 Crawl Budget 定义为 Googlebot 希望且能够抓取的 URL 集合规模。它会动态变化，不是 Search Console 中一个可充值的“每日剩余次数”，也不是每个域名都有同样数字。
多数发布频率普通、URL 数量有限且内部链接清晰的网站，不需要专门优化抓取预算。若新页面能在合理时间被发现和抓取，服务器也没有因 Googlebot 过载，继续微调抓取频率通常收益有限。技术团队应先检查可索引性、内容质量和链接结构。
真正需要重点管理的通常是大型站点、快速变化的库存/新闻站、由参数生成海量 URL 的站点，或 Search Console Crawl Stats 显示发现与抓取长期不匹配的站点。
Crawl Capacity Limit：Googlebot 能抓多少
Crawl Capacity Limit 关注主机在不降低真实用户体验和稳定性的前提下可承受多少 Googlebot 连接。Google 会根据响应速度、网络错误、服务器错误和自身抓取资源动态调整。站点快速且稳定时，上限可能上升；持续超时、连接重置或 5xx 时，上限会降低。
容量是主机级和基础设施相关问题，不只是一台应用服务器的 CPU。CDN、WAF、负载均衡、TLS、DNS、数据库、对象存储和第三方依赖都可能成为瓶颈。Googlebot 看到的是端到端结果。
增加服务器容量只解决“能不能抓”。如果站点没有足够抓取需求、URL 重复或内容长期不变，更强硬件不会自动带来更多抓取或索引。
Crawl Demand：Google 想抓多少
Crawl Demand 体现 Google 对特定站点 URL 的抓取需求。Google 文档指出，URL 的相对流行度、内容是否陈旧以及整个站点的变化会影响需求。重要且经常实质更新的 URL 通常更值得重抓。
仅修改页面时间戳、随机调整几个词或每日重写 Sitemap lastmod，不等于产生真实更新需求。若内容主体没有变化，虚假的新鲜度信号会浪费抓取并降低信号可信度。
内部链接、Sitemap 和外部链接帮助发现 URL，但发现不等于高需求或必然索引。Google 仍会根据重复性、质量、规范 URL 和搜索价值决定后续处理。
Crawl Rate：日志里看到的实际请求速度
Crawl Rate 是某个时间窗口内的实际抓取请求数或并发表现。它受 Capacity、Demand、Google 调度、缓存、响应时间和不同 Google crawler 类型共同影响。短时间的峰值或低谷不应直接解释为算法惩罚。
分析时至少按已验证的爬虫身份、主机、路径、状态码、响应时间、字节数和时间桶拆分。将搜索抓取、AdsBot、图片、视频、用户触发 fetcher 和伪造 User-Agent 混在一起，会得出错误速率。
Search Console Crawl Stats 是聚合视图，服务器/CDN 日志提供请求级证据。两者统计边界和时区可能不同，应关注趋势与异常，而不是要求每个数字完全相等。
Crawl Capacity 与 Demand 如何共同限制
可以把实际抓取直观理解为“Google 想抓多少”和“站点允许安全抓多少”两者中的较低可行范围，但这不是公开的精确计算公式。容量高而需求低，Google 没有必要填满服务器；需求高而容量低，重要更新可能排队。
优化应针对真正短板。大量 503、长尾延迟和连接超时指向容量；成百上万的筛选参数、重复日历页和软 404 指向 URL 空间质量；新内容无内部入口、Sitemap 不更新则指向发现；抓取成功但未索引则需检查规范化和内容价值。
不要把所有“未索引”都归为预算。索引发生在抓取之后，抓到页面也可能因为重复、noindex、质量或 canonical 选择而不进入索引。
哪些站点更可能遇到预算问题
Google 的指导重点面向大型站点、更新极快的站点，以及大量 URL 被标记为 Discovered - currently not indexed 的站点。规模要结合可抓 URL 数而非产品数判断：筛选、排序、会话 ID、站内搜索、日历和 API 参数可把少量内容膨胀成巨大 URL 空间。
一个只有几千个稳定 URL 的站点若每天都能抓到关键更新，通常没必要“提升预算”。相反，一个百万级电商站若 90% 抓取落在重复参数 URL，即使请求量很高，重要库存页仍可能更新不及时。
先用日志估算独立规范 URL、无价值 URL 占比和重点模板重抓间隔，再决定是否属于预算治理，而不是按域名年龄或服务器带宽猜测。
429 Too Many Requests：主动限流
RFC 9110 定义 429 表示用户在一定时间内发送了过多请求。对爬虫而言，它明确传达当前客户端或请求集合触发了限流。响应可以带 Retry-After，说明建议等待多久。
429 适合精确限流，但大量或长期返回会告诉 Googlebot 当前容量不足，从而降低抓取。它不是控制索引的工具：不希望抓取的路径应通过合理 URL 设计、robots.txt 或访问控制处理；不希望索引应使用可抓取页面上的 noindex 或删除语义，而不是常态 429。
限流规则要识别真实来源并允许合理突发。仅按单个共享出口 IP 限制，可能误伤 Google 分布式抓取或其他合法用户；仅信任 User-Agent 又会被伪造。
503 Service Unavailable：服务暂时不可用
503 表示服务器当前因临时过载或维护无法处理请求。它适合短期维护窗口和瞬时故障，可以配合 Retry-After。Google 的状态码文档将 5xx 视为服务器错误；持续服务器错误会减慢抓取，长期存在的 URL 还可能从索引中消失。
维护时应让所有受影响页面返回真实 503，而不是返回状态 200 的“维护中”HTML。200 会让搜索引擎把维护页当正常内容，可能形成软错误或替换原页面信号。
503 只能短期使用。无法给出可靠恢复时间时仍应快速、轻量地返回 503，避免请求占满线程后再超时。监控恢复后要确认 CDN 和代理没有缓存旧 503。
429 与 503 如何选择
429 表示“这个请求方或速率超过限制”，503 表示“服务整体或该资源当前不可用”。若站点只需要削减 Googlebot 或特定客户端的访问速率，429 语义更具体；若维护或后端过载影响所有用户，503 更准确。
两者都应被视为临时失败，不应与 404/410 永久不存在、403 禁止访问或 robots.txt disallow 混用。返回码必须与真实状态一致，否则爬虫调度、监控和客户端重试都会误判。
Google 对具体状态码的处理可能随产品更新，应以当前官方状态码文档为准。不要依赖多年前关于“503 最多几天”的硬编码传闻替代监控。
Retry-After：建议，不是强制预约
Retry-After 可使用延迟秒数或 HTTP-date：
或：
它告诉客户端服务器预计何时可再次处理请求，但客户端可以根据自身策略、缓存和安全限制决定何时重试。它不是 Googlebot 一定在指定秒数准确返回的预约机制。
使用日期格式要求服务器时钟正确；延迟秒数更不易受时钟偏差影响。值应真实、有限且与恢复计划一致。对所有失败都机械设置极大时间，会延迟恢复后的重新抓取。
5xx、网络错误与容量下降
Google 抓取不仅观察 HTTP 状态，还会遭遇 DNS 失败、连接超时、TLS 错误、连接重置和响应超时。这些错误没有可用 HTTP 响应，无法携带 Retry-After，但同样会表明主机不稳定。
应用日志可能看不到在 CDN、WAF、负载均衡或 TLS 层失败的请求。必须合并各层指标：DNS 解析、边缘连接、TLS、源站状态、TTFB、完整响应和上游依赖。只查应用的 200 比例会漏掉真实容量问题。
超时通常比快速 503 消耗更多资源并让恢复更慢。过载保护应尽早拒绝、限制排队和隔离关键业务，而不是让所有请求一起拖到超时。
robots.txt 不是抓取速率控制器
RFC 9309 标准化 Robots Exclusion Protocol，Google 的 robots.txt 文档说明其规则用于控制允许或禁止抓取路径。标准没有通用 Crawl-delay 规则，Google 也不支持把它作为 Googlebot 的速率控制手段。
robots.txt disallow 可减少被禁止路径的抓取，但 URL 仍可能因外部链接被发现并以无内容形式出现在搜索结果。它也会阻止 Google 读取页面上的 noindex，因此不能用“先 disallow，再 noindex”期望可靠删除索引。
若目标是减少无价值 URL 空间，应同时修正内部链接、参数生成、规范 URL、Sitemap 和服务器行为。robots.txt 是访问声明的一层，不是 URL 生命周期管理的全部。
不要用 404 页面返回 200
不存在、空结果或无效筛选页面若返回 200 和模板化“没有内容”，Google 可能将其判为 Soft 404，也可能继续浪费抓取。真实不存在应返回 404 或 410；暂时缺货但页面仍有用户价值的产品则可保留 200 并提供替代信息。
状态码要对应资源状态，而不是模板是否成功渲染。应用捕获所有异常后统一返回 200，会同时破坏抓取调度、缓存、监控和客户端语义。
大规模清理无效 URL 时，不要把全部改成同一个 301 首页。无相关替代内容的 URL 应返回 404/410，相关迁移才使用定向重定向。
Sitemap 如何帮助预算使用效率
Sitemap 应只列出希望被抓取和索引的规范 URL，并为实质更新提供准确 lastmod。把重定向、404、noindex、重复参数和不可访问 URL 放入 Sitemap，会提供相互冲突的信号并浪费诊断时间。
lastmod 应反映页面主要内容变化，不是 Sitemap 文件生成时间。所有 URL 每天统一改为今天，会让 Google 无法区分真正更新，并不保证提高 Crawl Demand。
大型站点可按模板、地区或更新时间拆分 Sitemap，结合日志比较提交、抓取和索引覆盖。拆分是观测手段，不会自动增加预算。
参数 URL 与无限空间
分面导航、排序、站内搜索、日历、会话 ID 和任意组合参数可以产生近乎无限 URL。Googlebot 若不断发现新组合，可能把容量花在重复内容，而重要页面重抓变慢。
治理顺序是停止生成无价值链接、让应用拒绝无效组合、统一参数顺序与规范 URL、只在必要处使用 robots 规则，并保证有价值筛选页面拥有独立内容和内部入口。Canonical 是规范化提示，不是阻止抓取命令；Google 仍需抓取候选页才能比较。
仅在 Search Console 隐藏参数或删除工具中操作，不能代替源站 URL 设计。长期解决方案必须从链接图和服务器响应消除无限空间。
验证 Googlebot 身份
User-Agent 可以伪造，不能看到 Googlebot 字符串就放宽限流或访问敏感内容。Google 官方建议使用反向 DNS 查询来源 IP，再对得到的 Google 主机名执行正向 DNS，确认包含原始 IP；也可使用官方发布的爬虫 IP 范围。
身份验证结果应缓存合理时间并处理 IPv4/IPv6。不要在每个请求同步执行多次 DNS 查询，否则验证本身可能成为延迟和故障源。
即使确认是真 Googlebot，也只应获得抓取所需的公开内容，不应绕过认证查看用户数据或管理端点。
降低抓取速率的正确顺序
若 Googlebot 确实导致服务器过载，Google 当前文档建议优先让服务器对过量请求返回 429、500 或 503，Google 会根据错误自动降低抓取。Search Console 的 Crawl rate 设置能力和适用范围可能变化，应以当前账号界面与官方文档为准。
同时修复容量根因：缓存热点页面、减少动态渲染成本、限制无价值 URL、隔离爬虫队列、扩容瓶颈和优化数据库。长期返回错误不是速率管理方案，而是服务持续不可用。
不要用网络层永久阻断 Google IP 作为第一反应。这样缺乏语义信号、难以安全维护 IP 范围，也可能让重要页面长期无法更新。
一套可执行的诊断流程
确认站点规模、更新频率与是否真的属于预算重点场景；
从 Search Console 查看 Crawl Stats 趋势、主机状态和响应分布；
验证 Googlebot 身份后解析 CDN、WAF 与源站日志；
按规范 URL、参数模板、状态码和响应时间统计抓取；
区分 Capacity、Demand、Discovery 与 Indexing 问题；
查找 429、5xx、DNS、TLS、超时和连接重置；
清理无限 URL、软 404、重定向链与错误 Sitemap；
为实质更新维护准确 lastmod 和内部链接；
常见误区
每个网站都有固定每日 Crawl Budget
错误。抓取是动态调度，容量与需求共同影响；多数中小站不需要专门管理预算。
服务器扩容一定会增加索引量
错误。扩容提高 Capacity，不会自动提高 Crawl Demand、内容质量或可索引性。
Crawl Rate 等于 Crawl Budget
错误。Rate 是实际请求速率，Budget 是容量与需求共同形成的抓取概念。
返回 429 可以让页面从索引删除
错误。429 表示临时限流，不是永久删除或 noindex 信号。