重定向链：它们如何发生、成本以及如何扁平化

重定向链是隐藏在绿灯后面的罕见技术缺陷。 输入 URL，获取页面，状态 200 — 每个普通测试都通过，因为每个普通 HTTP 客户端会静默跟随整个链并仅报告最终停留位置。 中间的跳转确实存在，它们在每次抓取时计费，浏览器中没有任何信息告诉你有多少跳转。

有用的重定向发现会显示入口 URL、中间目标和最终页面。 该记录让负责团队决定哪条规则应直接将原始请求发送到预期目标。 修复后观察也很容易验证：再次检查序列并与已保存路径比较。

一个 4 次跳转链由 4 个独立正确决策组成

链逐层累积，每层在落地时获得其位置：

1. TLS 落地。 某人添加了一个边缘规则，将 http:// 发送到 https://。 预期目标现在使用 HTTPS。
2. 选择规范主机。 团队统一使用 www，因此顶点重定向到它。 同级主机名应指向相同的预期目标。
3. 尾斜杠被规范化。 框架或 CDN 默认添加规则，追加或去除最终斜杠。 已发布链接和站点地图条目应始终使用预期样式。
4. 国际化上线。 根路径开始路由到语言前缀，/blog/ 到 /en/blog/。 本地化页面需要不同的稳定 URL，尽管从根目录的重定向是站点设计选择。

这就是 4 条正确规则，现在 http://example.com/blog 通过 4 次重定向到达其目标。 CMS 迁移将 /blog/* 重写为 /articles/*，添加了第 5 条规则而不触及前 4 条，因为它在应用程序中实现，而其他规则位于边缘、Web 服务器和路由器。 规则按请求穿越堆栈的顺序触发，而不是按最快解决 URL 的顺序。 没有人拥有此组合。

这也是为什么我们自己的数据中 http 到 https 的结果需要仔细阅读。 在 2026 年 5 月 23 日至 8 月 31 日期间，HTTP-到-HTTPS 归一化在 171 次评估中被标记为 44%，但仅在 48 个不同站点中占 8%。 站点级别的 8% 是流行率数字；评估数字描述的是我们的观察，而不是网络。 每次审核运行时都会评估一次检查，因此在缺陷持续期间被多次审核的少数站点会贡献许多失败评估，并且它们将评估率拉得远高于受影响站点的份额。 把 44% 说成“44% 的站点”会把流行率夸大超过 5 倍。

Google 跟踪最多 10 跳并建议你保持在 5 以下

跳数预算已记录，而非传说。 Google 的爬虫文档说明，默认其爬虫最多跟随 10 次重定向跳，并指出各产品不同——Google 自己的检查工具根本不跟随重定向。 站点迁移指南更为明确：Googlebot 可以跟随最多 10 跳，但“我们建议直接重定向到最终目的地。如果不可能，保持链中重定向次数低，理想情况下不超过 3，且少于 5。” 爬虫预算文档将其简化为一句话：避免长重定向链，这会对爬取产生负面影响。

成本分为 3 部分，它们的权重不等：

爬取效率。 每一次跳都是 Google 的爬虫在不获取内容的情况下所花费的请求——文档明确指出，重定向的 URL 返回的内容被忽略，只处理最终目标的内容。 在几百个 URL 的站点上，这只是噪音。 在链条位于 URL 模式的站点上，每个内部链接都会使用它，它会在整个抓取过程中乘以，并与同一主机已受限的抓取容量竞争。

延迟，在每一次未缓存的获取时。 一跳是完整的往返：DNS 可能已经热，但连接重用在跳变更主机时立即结束，而 example.com 到 www.example.com 步骤本质上就是这么做的。 用户只会感受到一次，然后就不再感受到，因为浏览器会缓存永久重定向。 机器在没有热缓存的情况下获取冷数据时，每次都会感受到。

信号整合，这是传说所在。 旧说法是每一跳都会流失一定比例的链接权益。 Google 在 2016 年 7 月公开反驳了它，当时 Gary Illyes 明确表示 30x 重定向不会失去 PageRank，澄清了 John Mueller 在当年早些时候关于 http‑to‑https 迁移所说的内容。 对此担忧的持久版本更狭窄且仍然真实：一个 301 是可用的最强 canonicalization 信号，而重定向的价值在于它明确命名一个目标。 链条仍然命名一个目标，因此权益论点是 3 使其扁平化的最弱理由。 抓取效率和延迟支持此论点。

AI 抓取器和代理处理链条的容忍度低于浏览器

浏览器是站点将被测试的最宽容的重定向客户端。 它们无声地跟随长链，积极缓存永久重定向，并将目标呈现为就像它是 URL 请求的一样。 程序化客户端——AI 助手、检索管道和代理实际通过的层——在浏览器测试无法揭示的方式上各不相同。

curl 在没有 -L 的情况下根本不跟随；链条返回一个裸 301 和空正文。 库 HTTP 客户端各自选择自己的跳跃上限和是否跟随的默认值，这些默认值由编写抓取代码的人设置，而不是由站点决定。 规范兼容客户端在重定向跨域时丢弃凭据，这正是 apex‑to‑www 跳跃所做的。 方法语义也会改变：301 和 302 长期以来都有将 POST 重写为 GET 的历史，而 307 和 308 保留原始方法——当代理提交而非读取时，这一区别就很重要。

加上预算约束。 在时间限制下工作的摘要器或代理会把一部分时间花在返回无内容的跳跃上，而超过内部跳跃上限的抓取看起来与站点宕机一样。 链条不会报告自己是链条；它报告为空结果。 这与我们索引数据中的指令冲突具有相同的失败形态（our indexability data）——站点对人类有效，却悄悄拒绝机器使用。

在 4 步骤中扁平化：清点、压缩、重新链接、保持映射

1. 清点真实跳跃计数。 测量，而不是推理配置。对于单个 URL：

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

第一行给出计数，第二行给出路径。 在 http:// 和 https:// 表单、apex 和 www 上运行它，带或不带尾斜杠，并针对每个模板的代表性 URL —— 链通常位于模式中，而不是页面中。 audit 在主页、规范目标和备用主机上执行相同的遍历，并在一次通过中报告跟踪路径作为证据。

2. 将每条链压缩为单个 301。 取入口 URL 及库存中的最终目标，编写一条规则将第一个直接映射到最后一个，在能够同时看到两者的最外层——通常是边缘或 CDN。然后退役链中组成的中间规则，而不是在新规则后保留它们。 使用 301 表示永久移动，使用 308 当方法必须存活。 目标必须是声明自身为规范的 200；重定向落在其规范指向其他位置的页面上会在不同的词汇中重新启动歧义，这正是我们的 canonical tags guide 所处理的交互。

3. 将内部链接指向最终 URL。 扁平化规则仍会在每个命名旧 URL 的内部链接上产生一次跳转。站点地图、导航、hreflang 注释、规范标签和正文内链接都应直接引用目标，因此重定向仅用于外部入站链接和旧书签。 这一步将配置修复转化为爬取效率提升。

4. 保留链图。 记录每条已退役规则、其入口 URL 及其最终目标到一个与基础设施配置同在的文件中。链会重新形成，因为下一个添加语言前缀或迁移路径方案的人无法看到请求路径中已有的 4 条规则。 该图使得谁在交付层 5 时可见组合，并且是下一个库存 的输入。 完整的逐项检查处理方案存在于我们的 重定向和 URL 规范化指南.

扁平化重定向层是少数几种技术改进之一，没有内容依赖、无排名滞后，并且验证步骤只需一条命令。 它在这么多站点上保持失效，因为没有人手动运行的测试会报告跳转。 一旦跟踪成为审核的一部分，4 团队正确决策之间的接缝就变成了带路径的发现，每跳一次状态，以及一条要编写的规则。