站点改版、換域名、調结构、上 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）→ 建立時間」记成一張表。站点每次有结构調整、域名變化、协议變化时，拿出来對一遍。跳轉規則之間很容易互相覆盖，凭记忆判断往往不准，尤其是接手別人配置的时候。
复查节奏不必太密，跟随站点變更走即可。真正要避免的是規則层层叠加、没人清理，過几年自己都说不清哪條還在生效、哪條早已失效。
跳轉是為了把訪問者和爬虫带到正确的地方，而不是让他們多走几段路。鏈條短一点，排查起来也清楚一点。