Googlebot 报 Server error (5xx)：间歇超时与 CDN/源站排查

先固定确切 URL 和时间

记录 Search Console 中的完整 URL、错误类型、上次抓取时间、抓取使用的 Googlebot 类型和页面是否允许抓取。使用 URL Inspection 的索引状态与实时测试分别保存证据；实时成功只能证明现在可访问，不能否定历史 5xx。

把时间转换到服务器、CDN 和应用日志的统一时区，并保留请求 ID。不要只用当天平均可用率；几分钟部署或高峰超时足以影响一次抓取。

5xx 对 Google 抓取的含义

Google Search Central 说明，5xx 和 429 会让 Googlebot 暂时降低抓取速率；持续错误会进一步减少抓取，长期仍失败的 URL 可能从索引中删除。服务器错误不是控制抓取预算的正常工具。

维护或过载时应尽快恢复稳定服务。不要用长期 503“保留排名”，也不要把不存在页面返回 500；永久删除应返回合适 404/410。

区分 500、502、503 与 504

500 通常表示应用或服务器内部异常；502 表示网关从上游收到无效响应；503 表示服务暂不可用或过载；504 表示网关等待上游超时。不同状态指向不同层，不能统一归为“服务器慢”。

采集最终公网状态、响应头、CDN Ray/Request ID、反向代理 upstream 状态和应用 trace。错误页的 Server/Via 等头部可帮助识别谁生成了响应，但不要向普通用户暴露内部堆栈。

浏览器正常不代表 Googlebot 路径正常

浏览器可能命中已热缓存、登录后的不同页面、某个区域 CDN 或 IPv4；Googlebot 可能来自另一网络、请求无 Cookie、支持不同协议或命中冷缓存。按 Google 官方方法验证真实 Googlebot，不能只相信 User-Agent 字符串。

从日志筛选抓取时间的请求，比较 host、IP 版本、edge POP、cache status、upstream time 和 response code。不要对白名单 User-Agent 返回特殊成功页，这可能造成 cloaking 和掩盖真实故障。

CDN 与源站状态码要分层

CDN 可能因连接源站失败返回 502/504，源站日志里却完全没有对应请求；也可能缓存源站 5xx，使源站恢复后边缘继续报错。反过来，CDN stale-if-error 可能向浏览器返回旧 200，隐藏源站实际故障。

分别测试 CDN 公网地址和受控源站健康端点，记录 Age、Cache-Status、Via、upstream status。检查 CDN 是否缓存错误响应、错误 TTL 和回源超时，不要全局绕过 CDN 作为长期方案。

冷缓存页面特别容易超时

缓存命中时页面几十毫秒，首次回源却要实时查询数据库、渲染大量模板或调用外部 API，Googlebot 刚好命中冷缓存就可能 504。普通管理员反复访问后缓存已热，因此无法复现。

用独立 URL/缓存键模拟冷请求，测量 DNS、连接、TTFB 和总耗时。减少首请求依赖、预计算公共页面并为外部服务设置短超时与降级，不要只扩大网关 timeout。

应用异常与错误模板

未处理异常、数据库连接池耗尽、模板缺字段、内存 OOM 或进程重启会产生 500。某些错误中间件反而在渲染错误页时再次失败，客户端只看到空响应或连接重置。

按 request ID关联代理与应用日志，保存异常类型和安全堆栈到内部诊断。错误页本身应轻量、无数据库依赖，并返回正确 5xx，而不是 200 的“系统繁忙”。

资源耗尽与排队

CPU、内存、线程池、文件描述符、连接池和 listen/accept queue 饱和都可能造成超时。平均 CPU 低不代表单实例或单 worker 没被卡住。扩容过程中旧实例排空不正确也会产生短暂 502。

采集每实例并发、队列、p95/p99 TTFB、重启、OOM、FD、数据库等待和 upstream active connections。按实例 ID分组，避免整体指标掩盖一台坏节点。

DNS 与 IPv6 路径

域名同时发布 A/AAAA 时，Googlebot 可能使用 IPv6，而管理员网络只走 IPv4。AAAA 指向旧服务器、防火墙未放行、IPv6 源站路由错误，都会造成部分抓取失败。

分别从外部测试 IPv4/IPv6 的 DNS、TLS 和 HTTP。所有权威记录与 CDN host 配置应一致；若暂不支持 IPv6，应移除错误 AAAA，而不是保留不可达地址。

TLS/连接错误也可能归入抓取错误

证书链、SNI、协议协商、连接重置、DNS 超时和握手问题可能在 Search Console 中以服务器/网络相关错误表现。查看 URL Inspection 细节和服务器端握手日志。

检查证书覆盖、完整链、到期时间和所有边缘节点。不要只在一个浏览器测试，因为浏览器可能缓存中间证书或自动选择不同协议。

Robots 与 5xx 是不同问题

robots.txt 返回 5xx 时，Google 对全站抓取会采取保护性处理，因为无法确认允许规则。robots.txt 应由高可用、轻量路径提供，避免依赖应用数据库。

单页面 5xx 与 robots 获取失败要分别监控。确保 /robots.txt、Sitemap 和关键 HTML 都有独立状态与延迟指标。

429 与 503 的选择

429 表示请求过多，503 表示服务暂不可用。Google 会对两者采取降低抓取等行为。若限流器错误地把 Googlebot 当攻击流量返回 429，先修容量和公平限流，而不是伪装 200。

不要用 403 替代过载状态，也不要给 Googlebot无限优先级影响真实用户。设计可恢复的全局容量、缓存和合理重试提示。

维护窗口如何处理

短暂维护可返回 503，并可使用 Retry-After 提示何时重试，但窗口应尽量短。维护页必须真正返回 503，不能返回 200，否则可能被当作正常内容或 soft 404。

对滚动部署使用健康检查、readiness 和连接排空，尽量避免全站维护。部署后验证所有节点、所有协议和冷缓存，而不只看首页。

重试风暴与外部依赖

应用在上游超时时立即多层重试，会把小故障放大成线程池耗尽和 504。Googlebot 降速不会自动解决内部重试风暴。为外部 API设置总 deadline、有限退避、熔断和可用的降级内容。

公共 SEO 页面不应因推荐、统计或非关键 API失败而整页 500。将非关键组件隔离，核心正文可正常返回并标记局部不可用。

Sitemap 和内链的辅助作用

修复 5xx 后，保持 Sitemap 中 URL 与 lastmod 准确、内部链接可达，有助于 Google重新发现；但 Sitemap 不能强制立即重抓，也不能抵消服务器持续错误。

不要每天无意义修改 lastmod 或批量请求索引。先证明服务器稳定，再用 URL Inspection 对少量关键 URL测试。

一套逐层排查流程

第一步，固定 URL 和历史抓取时间。第二步，关联 CDN/代理/应用请求 ID。第三步，区分状态码生成层。第四步，测试冷缓存、无 Cookie、IPv4/IPv6 和不同区域。第五步，检查实例级资源、重启和依赖。第六步，验证 robots/Sitemap 独立可用。第七步，修复后运行 URL 实时测试。第八步，持续观察 Googlebot 日志和抓取统计。

修复后测试首页、深层页、参数页、静态资源、robots.txt、Sitemap、冷缓存、部署切换和高峰负载。浏览器 200、Googlebot 200、源站健康和关键页面 TTFB 都应达标。

常见错误

常见误区包括：实时测试成功就否定历史 5xx；只看平均可用率；用 User-Agent 伪造 Googlebot；只测 IPv4；扩大网关 timeout 不修慢依赖；错误页返回 200；维护长期 503；缓存 5xx；非关键组件失败导致整页 500；以及修复前反复请求索引。

总结

Search Console 的 5xx 需要按历史抓取路径还原，而不是用当前浏览器 200 否定。可靠排障要关联 CDN、代理和应用，测试冷缓存、IPv6、实例资源与部署窗口，并确保非关键依赖不会拖垮整页。持续稳定的 200、正确维护语义和可观测请求链，才是恢复 Google 抓取与索引的基础。