做站時間長了，重定向几乎是绕不開的東西：換域名、換目錄、合並栏目、下架产品、從 HTTP 升到 HTTPS，都會留下一批 301。問题不在跳轉本身，而在于没人回头清理，規則一层叠一层，最後變成一條谁都不想走的路。蜘蛛走到這里要多花几個来回，用戶看到的是迟迟不出現的頁面，而日誌里狀態碼一多，排查別的問题也更費劲。
跳轉鏈是怎么長出来的
大多數跳轉鏈不是一次设計出来的，而是几次改動叠加的结果。第一次改版把 /a/ 指到 /b/，第二次又把 /b/ 指到 /c/，两邊的規則都還留在配置里，于是訪問 /a/ 就變成了两跳。常见的形態大致有這几種：
- HTTP 跳 HTTPS 一次、非 www 跳 www 一次，再加上尾斜杠，三次跳轉才落到终点。
- 舊栏目整体重定向到一個中間頁，中間頁又重定向到新的列表頁。
- 頁面早就删了，舊規則却仍然指向一個已经 404 的地址，用戶点進来只看到错誤頁。
- 当初為了活動加的 302 临时跳轉，活動結束後没人改回 301 或直接落地。
- 規則互相咬合形成循环，A 指 B、B 指 A，浏览器直接报错。
- 跳轉目标带着查询參數，工具跑一轮下来，地址數量比真實頁面多出好几倍。
判断标准其實很简單：從入口地址到最终落地頁，中間任何多余的一跳，都值得問一句為什么還在。
用命令行把鏈路走一遍
不需要多复杂的工具，curl 就能把跳轉過程摊開来看：
- 用 curl -I 請求地址，看返回的 Location，再手動請求這個 Location，重复几次直到狀態碼變成 200。
- 想省事一点，用 curl -sIL -o /dev/null -w '%{num_redirects}' 看跳轉次數，數字大于 1 就要留意。
- 加上 -w '%{url_effective}' 看最终落到哪個地址，確認它和你想给的终点一致。
- 把站点的主要入口地址列一張表，逐個跑一遍，记錄跳轉次數和最终地址。
- 翻一段時間的訪問日誌，統計 301、302 出現的次數，找出被反复命中的跳轉規則。
- 顺手核對 sitemap 和内鏈寫的是不是最终地址，如果寫的還是起点，等于每天都在主動制造跳轉。
如果站点規模大，用爬虫工具跑一遍全站，按跳轉次數排序，通常前几十個地址就能覆盖大部分問题。
修的时候按這個顺序来
修跳轉鏈不是把所有規則都删掉，而是保證每個入口只跳一次，並且跳到對的终点。可以按下面的顺序處理：
- 先把协议和主机名统一，HTTP、非 www、尾斜杠這些基础規則整理到一起，避免在別的跳轉上再叠一层。
- 把指向中間頁的規則改成直接指向最终頁，中間地址如果還有人訪問，也让它直接跳终点。
- 更新站内連結和 sitemap，让它們從一開始就寫终点地址，而不是让蜘蛛自己跳過去。
- 确定不再提供的内容，用 404 或 410 明确表達，不要统一甩到首頁，那样只會让用戶和蜘蛛在一個無關頁面上打轉。
- 對确實需要保留的临时跳轉设一個复查時間，到期就處理，別让它一直挂着。
- 改完規則後按同样的方法再跑一遍，確認跳轉次數降到 1 以内，且没有循环。
改動跳轉規則前，先導出目前配置或至少记下改了什么。規則寫错的时候，可能不只是某個頁面進不去，而是整站入口都被绕進死循环。
上线前後各看一眼
後續再動站点结构时，把這几件事固定成习惯：上线前拿主要入口地址跑一遍跳轉检查；上线後隔一两天再看日誌里 301、302 的分布有没有異常升高；维護一份跳轉清單，记錄每條規則的目的和建立時間；每次改版前先搜一遍現有的重定向規則，避免重复添加。
跳轉鏈不是立刻要命的問题，但它會慢慢吃掉抓取和耐心。把它当成一次普通的整理，花一两個小时把鏈路理顺，後面每次改動都會轻松一些。