站点改版、换域名、调结构、上 HTTPS，这些动作多少都会留下重定向。短期内看，跳转能保住老链接，但跳转一旦连成一串，就会变成另一种问题：爬虫和访客都要多走几步，抓取预算被消耗，页面加载变慢，出错概率也跟着上升。这一篇讲的是怎么把重定向链理清楚。
一条链接跳了几次，值得关注吗
单次 301 通常没有太大问题，浏览器和爬虫都能处理。但当 A→B→C→D 这种链条出现，成本就叠加上来了：每一次跳转都是一次额外的请求与等待，中间任意一环超时或返回异常，整条路径就断掉了。链条越长，越容易在某次调整中被人改错，也越难追溯原因。
这类链条的常见成因是分次改动。第一次改版用 301 把旧地址指到中间地址，第二次调整栏目时又加了一条新跳转，第三次上线 HTTPS 时再补一层。每次单独看都合理，放在一起就绕了远路。
怎么把链条摊开来看
从最终地址倒推
先确定页面现在真正的地址，再去看哪些入口还在指向中间地址。可以用带跟随参数的 curl、浏览器开发者工具的网络面板，或者命令行的重定向检查工具，逐跳记录状态码和 Location 头，把每一跳的方向写下来。
覆盖几个常见入口
- 旧域名和旧目录结构下的地址
- http 到 https 的历史链接
- 带 www 与不带 www 的两种写法
- 末尾带斜杠与不带斜杠的变体
- 大小写不同的旧地址
- 带旧参数（来源追踪、分页参数）的地址
这些入口往往是链条的起点。逐个跑一遍，记录跳转次数，超过一跳的单独列出来。
留意循环与自跳
A 跳到 B、B 又跳回 A，会让客户端直接报错；指向自己的 301 同样没有意义。这类问题通常来自规则冲突，比如服务器配置和 CDN 规则同时生效，方向却相反，或者一条规则被后来加的规则覆盖了一半。
修正时把握几个原则
- 每一层旧地址都直接指向最终地址，能一步到位就不要分两步
- 需要长期保留的跳转用 301，临时的用 302，别混着用
- 不要用 JS 或 meta refresh 承担主要跳转，这类方式对抓取端不够明确
- 能通过规则批量处理的（统一结尾斜杠、统一协议、统一域名写法），在服务器或 CDN 层做一次，别在页面里散着写
- 站内链接直接写最终地址，不要经过跳转
内部链接是最容易被忽略的一环。外链进站跳一次还能接受，站内每个链接都跳一次就没有必要，既拖慢点击速度，也让日志里全是跳转记录。
建立一份跳转清单并定期复查
把「旧地址 → 最终地址 → 状态码 → 生效位置（服务器 / CDN / CMS）→ 建立时间」记成一张表。站点每次有结构调整、域名变化、协议变化时，拿出来对一遍。跳转规则之间很容易互相覆盖，凭记忆判断往往不准，尤其是接手别人配置的时候。
复查节奏不必太密，跟随站点变更走即可。真正要避免的是规则层层叠加、没人清理，过几年自己都说不清哪条还在生效、哪条早已失效。
跳转是为了把访问者和爬虫带到正确的地方，而不是让他们多走几段路。链条短一点，排查起来也清楚一点。