Google Search Console Redirect error：循环、长链与空跳转排查

先区分正常跳转与 Redirect error

Page with redirect 表示源 URL 正常跳到另一 URL，源本身不会被索引，目标是否索引另行判断。Redirect error 则表示 Google 无法走完链，最终内容没有成功取得。不要把所有 3xx 都当错误，也不要为了消除报告而取消必要的站点迁移跳转。

查看报告中的首次发现、最近抓取和验证历史，并记录样本 URL。URL 检查的实时测试可能发生在修复之后；它与历史抓取时间不同，且实时测试不覆盖所有索引条件，因此“现在成功”不能否定此前错误。

保存完整跳转链

从外部网络发请求并禁止客户端自动隐藏过程：记录每一跳的状态码、原始 Location、解析后的绝对 URL、响应时间、服务器/CDN 标识和最终状态。分别测试 Googlebot Smartphone、普通移动浏览器和无 Cookie 客户端，但不要只靠修改 User-Agent 假冒验证真实 Googlebot。

检查 HTTP 与 HTTPS、www 与裸域、大小写、尾斜杠、查询参数和语言路径。任何一步有条件分支，都要保存对应请求头与响应头，才能复现 Google 当时走到的路径。

重定向循环如何形成

最常见循环是 CDN 强制 HTTPS，而源站根据错误的代理协议头又重定向回 HTTP；或一层要求 www，另一层要求裸域。尾斜杠、大小写规范化、语言前缀和登录中间件也可能相互反转。

按链逐跳比较“输入 URL”和“Location”。A→B→A 是显式循环；A→B→C→B 也一样。多层架构要检查 CDN、负载均衡器、Web 服务器、应用框架和 CMS 的规则顺序，不能只看其中一份配置。

链过长为什么失败

Google 的通用抓取通常会跟随有限数量的重定向，官方抓取文档说明一般内容可跟随约 10 跳，但不同产品和检查工具可能有不同限制。Google 的站点迁移建议仍要求避免链式跳转，最好直接指向最终目标，并把链控制得很短。

历史迁移最容易累积 /old→/new→https→www→/zh/→新 slug。将每个旧 URL 的规则合并成一次到最终 canonical 的服务器端永久跳转，同时确认中间 URL 的外链和内链也已更新。

空 Location 与坏 URL

3xx 响应若 Location 为空、含非法控制字符、模板变量未替换，或相对引用无法基于当前 URL 正确解析，浏览器可能以自己的容错方式显示页面，但爬虫会认为链损坏。检查原始字节，别只看开发者工具格式化后的值。

常见错误包括 Location: https://、缺少 host、双重协议、反斜杠、未编码空格、把 JSON null 写进地址，或应用在缺少 Host/语言参数时返回空字符串。为所有分支设置明确的失败状态，不要生成无效 3xx。

URL 越跳越长

登录、语言选择、A/B 测试或追踪中间件可能每跳追加 returnUrl、redirect、UTM 或原始查询串。若目标再次把整个当前 URL 编入下一个参数，长度会指数或线性增长，最终超过 Google 可处理范围。

比较每一跳的 URL 长度和参数集合。对 return URL 做一次规范化和白名单验证，禁止递归嵌套；营销参数不应进入 canonical 路径。遇到异常输入应返回 4xx，而不是继续构造更长跳转。

CDN 与源站条件不一致

CDN 边缘规则、缓存的 301/302、Bot 管理和源站应用可能对相同 URL给出不同结果。某一 POP 缓存了旧 Location，或 IPv6 到另一源站版本，会让错误只在部分 Googlebot 请求中出现。

按区域、IPv4/IPv6、HTTP 版本和边缘节点采样，检查缓存年龄与规则版本。修复后清理对应重定向缓存键，但不要把所有静态缓存无差别清空。确保 CDN 传递并规范化受信任的 Forwarded/X-Forwarded-Proto 信息。

Cookie、语言和地区跳转

Googlebot 通常以无登录状态抓取，不能依赖用户已有 Cookie。首次访问若被语言选择器跳到 /select-language，该页面又因没有 Cookie 跳回首页，可能形成循环。IP 地理定位也会让不同地区走不同链。

为搜索可发现页面提供稳定、可抓取的默认语言 URL。地区提示可作为页面内选择，不要让爬虫必须通过 Cookie 才能到达内容。每个语言版本用独立 URL、正确 canonical 与 hreflang 表达，不把 User-Agent 当语言判断依据。

JavaScript 与 meta refresh

Google能识别服务器端 301/308、临时 302/303/307、meta refresh 和 JavaScript 等多种跳转，但官方优先推荐服务器端重定向。客户端跳转依赖 HTML 解析或渲染，故障面更大，也可能与服务端规则叠加成隐性链。

抓取原始 HTML 查找 meta refresh 和脚本中的 location，浏览器 Network 面板只看到 HTTP 链时还不够。若能在服务器层表达迁移，就避免同时保留重复的 JS 跳转。

状态码选对但仍可能出错

301/308 是强永久信号，302/303/307 是临时跳转。选错永久/临时会影响 canonical 信号，但 Redirect error 更直接关心链能否成功完成。一个语义正确的 301 仍可指向循环或 500 目标。

逐跳验证最终目标必须返回可处理的 200 页面，并且内容不是软 404、登录墙或空错误页。目标的 robots、noindex 和 canonical 是下一阶段索引条件，不能用来解释链本身走不完。

robots.txt 与重定向链

普通页面的重定向排障不要误用 robots.txt 阻止中间 URL。Google需要请求源 URL 才能看到 3xx；阻止抓取会妨碍信号处理。robots.txt 自身的重定向还有专门限制，不能从网页 3xx 行为直接推断。

站点迁移时确保旧、新站 robots 规则允许 Google 访问需要传递信号的 URL。若目标明确不应索引，先让 Google能抓取并看到 noindex，而不是同时 robots 阻止。

验证真实 Googlebot 路径

日志中 Googlebot User-Agent 可以伪造。需要判定是否 Google请求时，按官方方法做反向 DNS 后再正向验证，或匹配公开的 Googlebot IP 范围。记录已验证请求的源 IP、时间、URL、状态和 Location。

不要对 Googlebot 返回与用户实质不同的内容或秘密旁路，只应消除 WAF 误拦截和不稳定挑战。相同 URL 在等价条件下应有稳定跳转结果。

Sitemap、内链与 canonical 清理

Sitemap 应列出最终 canonical 的 200 URL，而不是旧跳转 URL。站内链接、hreflang、结构化数据、分页和 canonical 也应直接指向最终地址，减少 Google重复抓取源 URL 和链中间节点。

迁移期间保留旧 URL 的服务器端永久跳转，但不要继续在新内容模板生成旧链接。修复链后重新生成 crawl 样本，确认全站没有同类规则残留。

推荐排查顺序

区分 Page with redirect 与真正的 Redirect error。

对齐 Search Console 抓取日期与当前部署时间。

从无 Cookie 外部客户端保存每一跳原始 Location。

检查循环、跳数、URL 长度与空/坏地址。

分层核对 CDN、LB、服务器、框架与 CMS 规则。

测试移动端、地区、IPv4/IPv6 和缓存节点差异。

验证最终目标的 HTTP 状态和内容可用性。

更新内链、Sitemap、canonical 后启动验证。

修复后的验收

为典型旧 URL、带参数 URL、HTTP/www 变体和多语言 URL 建立自动化测试。每个源地址应在尽可能少的跳数内到达唯一 HTTPS canonical，链中没有 4xx/5xx、空 Location、循环或参数增长。

使用 URL 检查实时测试确认 Google可访问最终页面，再在 Search Console 的问题详情中启动验证。报告恢复需要重新抓取，可能晚于线上修复；持续监控服务器日志与索引报告，不要反复改规则干扰验证。

总结

Search Console 的 Redirect error 是“跳转没走完”，不是“页面用了重定向”。以完整链为证据，逐层检查循环、跳数、空/坏 Location、URL 增长、CDN 与源站差异、Cookie/地区条件和最终目标。修复后让内链、Sitemap 与 canonical 直接指向最终 200 URL，再用实时检查和报告验证闭环。