重定向是站点维護里的常規手段，改版、換域名、調整栏目、從 HTTP 切到 HTTPS，几乎都离不開它。麻烦的是，重定向常常不是一次做完就結束——每次調整都可能在新舊地址之間再插一层，几年下来，一條連結要跳三四次才能落到真正的頁面。對用戶来说是几毫秒的等待，對蜘蛛来说則是額外的抓取成本和一层层的不确定性。
重定向鏈通常是怎么長出来的
多數長鏈不是刻意设計的，而是歷史操作叠加的结果。常见的几種：
- 域名迁移时，老域名跳新域名，後来又加了一次 HTTP 到 HTTPS 的强制跳轉，两次叠在一起。
- 栏目改版，舊目錄跳新目錄，後来新目錄又改名，于是舊地址跳中間地址、中間地址再跳最终地址。
- 临时跳轉用得太多：先上 302 观察一段時間，後来忘了改成 301，临时方案變成了長期方案。
- 多域或多端並存，同一個頁面存在带 www、不带 www、带结尾斜杠等多個版本，互相跳来跳去。
一次跳轉的代價到底是什么
單次跳轉本身没問题，問题在于叠加。鏈越長，中間环节出错的概率越大：某一跳返回的是 302 而不是 301，最终地址的传递效果就可能被打折扣；某一跳配置寫错，整條鏈直接断掉；某一跳指向的中間頁已经下线，就變成先跳到一個错誤頁再被拦回来。
更實际的影响是排查成本。当一條鏈上挂着三四個地址，後面無论做連結建设、做資料分析還是做日誌归因，都很难说清流量到底落在哪個 URL 上。
把跳轉控制在一到两跳之内，是维護时比較省心的做法。超過两跳，就值得查一查中間那些地址還有没有繼續存在的必要。
自查时可以看這几個地方
用命令行看完整跳轉過程
最简單的办法是跟着請求走一遍。用 curl 查看响應头里 Location 依次指向哪里，再加上跟随跳轉的參數，就能打印出每一跳的狀態碼和目标地址。看到 301 → 301 → 200 這種结构，說明鏈上有两跳；看到 302 夹在中間，就要確認当初的临时方案是不是忘了收尾。
從服務器日誌里找高频跳轉
日誌里大量重复出現的 301、302 记錄，往往就是長鏈的入口。把返回 3xx 的請求按来源 URL 聚合一下，排在前面且長期存在的，基本就是需要處理的候選。注意区分人為点击和蜘蛛抓取，两類来源的處理優先級並不完全一样。
回头检查站内連結和站点地图
很多長鏈的入口其實就是站内自己寫的連結：導航、正文、頁脚、站点地图里還留着舊地址。服務器上的重定向只解决了“舊地址能到新地址”，但如果站内連結本身就直接指向终点，根本不需要绕這一圈。把内鏈和站点地图里的舊地址替換掉，往往能一次性消掉大部分跳轉。
修复时的几條原則
- 能直達就不跳。凡是站内可控的入口，一律指向最终地址。
- 永久用 301，临时用 302，別混着用。确定不會回退的變更用 301；活動頁、短期測試這類才用 302，並且提前设一個清理時間点。
- 减少大小寫、结尾斜杠和跟踪參數带来的變体。這些差异會让同一條鏈多出几個分支，最好在服務器层面统一規整。
- 處理循环跳轉。A 跳 B、B 又跳回 A 這類配置错誤不常见，但一旦出現，浏览器會直接报错，蜘蛛也不會繼續跟。上线新的跳轉規則前，把主要路径跑一遍就能發現。
- 保留必要的舊地址。清理不等于全删，被外部引用較多的舊地址可以用一條跳轉長期保留，只要确保它是最後一跳即可。
把重定向自查放進例行巡检
不需要每天做。改版、迁移、調整栏目之後做一次完整排查，之後按季度或半年抽查一遍主要路径就够了。排查清單可以很简單：站内主要入口能不能一跳直達；3xx 日誌里有没有長期挂在高位的舊地址；服務器配置里的跳轉規則有没有重复嵌套。
重定向做得干净，不直接等于抓取變多或排名變好，它更多是一種减负：少一层跳轉，就少一层说不清的地方。