網站改版、換域名、調整栏目结构之後，舊地址一般會通過 301 指向新地址。問题在于，這類跳轉往往不是一次做完的：第一次改版把 A 指向 B，第二次改版又把 B 指向 C，几年下来，一個老連結可能要走三四跳才落到能打開的頁面上。平时点着看不出大毛病，但在抓取和速度层面，這些鏈路會一点点积累成本。
重定向鏈是怎么堆起来的
多數多层跳轉不是有人故意设計，而是几次改動叠加的结果：
- 域名层面：http 跳 https、裸域跳 www，再叠加一次目錄調整，一次訪問就产生三次跳轉。
- 栏目調整：舊栏目整体指向新栏目，新栏目後来又換了地址，舊地址没有同步更新，于是變成两跳。
- 插件與配置：CMS 或 CDN 自動补尾斜杠、自動加語言前缀，與人工寫的跳轉規則撞在一起。
- 临时跳轉：為上线測試寫的 302 一直没撤，時間久了被当成長期規則使用。
需要重点排查的几種形態
- 多层跳轉：A → B → C → D。每多一跳就多一次請求，抓取工具和浏览器都要多等一轮。
- 循环跳轉：A → B → A，或者自己跳自己，訪問者會直接看到报错頁。
- 跳到 404：舊地址确實做了跳轉，但目标頁早已刪除，等于把問题往後推了一站。
- 全量跳首頁：整個舊栏目的地址统统指向首頁，用戶找不到原内容，搜尋引擎也难以判断新舊對應關系。
- 大小寫與尾斜杠差异：/Page 和 /page、/a 和 /a/ 之間互相跳，形成没有必要的往返。
- 内鏈仍指向舊地址：站内導航、正文連結、Sitemap 里還是老 URL，等于自己给自己制造跳轉。
把跳轉鏈盘出来的做法
- 先收集地址来源：歷史版本的 Sitemap、抓取日誌里出現過的舊地址、後台的失效連結报告、老頁面的導出清單。
- 用命令行看鏈路：curl -IL 加目标地址，可以打印完整的响應头序列，狀態碼和 Location 一目了然；去掉 -L 則只看第一跳。
- 在浏览器開發者工具的 Network 面板里打開一個舊連結，看請求列表中出現几次文档類型請求，几次就是几跳。
- 用爬虫工具批量跑站内連結，導出重定向類型的地址列表，按跳轉次數排序，優先處理三跳以上的。
- 抽样打開跳轉後的落地頁，確認内容主题與舊地址是否相關，別只看狀態碼是 200 就放過。
修复时的几條原則
- 一跳到位：能直接指到最终地址的，就不要中間再垫一层，把 A 的規則改成指向 D。
- 能改連結就別靠跳轉：站内導航、正文、Sitemap 里的地址直接寫成最终 URL，跳轉留给站外和無法修改的歷史連結。
- 永久迁移用 301：確認不再回头的地址用 301，临时調整才用 302，並且记得撤掉。
- 別做全站兜底跳首頁：規則尽量精确匹配，宁可让确實失效的地址返回 404，也不要让所有舊地址都堆到首頁。
- 改動後回归驗證：修完用同一批地址再跑一遍，確認没有新增循环和断鏈。
重定向是给舊地址留的一個出口，不是可以長期通行的主干道。鏈路越短，抓取和訪問的损耗越小。
容易被忽略的细节
- CDN 和源站各配了一條跳轉規則，看似一條，實际叠加成两條。
- 跳轉過程中丢掉查询參數，落地頁内容與用戶预期不一致。
- 移動端單獨域名或單獨目錄有自己的一套規則，桌面端修好了，手机端還在绕。
- 測試环境的規則被同步到正式环境，出現指向内部地址的跳轉。
重定向鏈不是什么高深的問题，但它和抓取预算、打開速度、頁面主题判断都有關。建议把這項工作放進改版流程的收尾清單，每次结构調整後跑一遍；日常结合抓取日誌看看 301 的訪問量有没有異常抬头，比等到訪問者反馈打不開再回头查要轻松得多。