用戶点一個連結，浏览器先跳到 A，再跳到 B，最後才落到 C。這種体驗不算罕见，也很容易被忽略。對蜘蛛来说，每一次跳轉都是一次額外的請求，鏈條越長，损耗越大。跳轉本身不是错誤，但它會把一次抓取變成三次，也會让權重和用戶耐心在中間被磨掉。
跳轉鏈是怎么攒出来的
很少有人主動去设計一條三层跳轉。多數情况是站点在持續演進中一层层叠上去的：換域名时加了整站跳轉，後来某個栏目改版又加了一條規則，再後来又為了统一协议加了一條。單看每一步都合理，合起来就成了一條長鏈。
- 协议跳轉叠加 www 與非 www 的跳轉，變成两跳起步。
- 舊域名的整站規則没有排除已迁移的地址，形成二次跳轉。
- 栏目改名只做了舊目錄到新目錄的跳轉，但站内導航仍指向舊地址。
- 内容下线後先跳到栏目頁，栏目頁後来又改了地址，鏈條再加一环。
- 短鏈或推廣連結在服務端又加了一次中轉。
自查的基本方法
不需要复杂工具，關键是把「最终地址」和「经過了几步」這两個信息拿到手。
從一個入口開始逐跳记錄
- 挑出站内主要入口：首頁、導航里的栏目頁、頁脚，以及外鏈最多的几條内鏈。
- 對每個地址，记錄返回狀態碼和 Location 指向，一次记一跳。
- 把每一跳串起来，數一數到最终正常頁面用了几次 3xx。
- 重点看超過两步的鏈條，以及跳轉後的落点與目前頁面是否语义一致。
從日誌里找批量問题
單頁排查只能發現個例。訪問日誌里狀態碼為 301、302、308 的請求占比，以及這些請求的路径分布，能告诉你問题是局部的還是全站的。如果某個舊目錄每天都有大量跳轉請求，說明站内或站外還有不少連結指着它。
處理原則：能一步到位就不要两步
- 尽量直指终点。舊地址如果确定要指向新地址，就直接指向最终頁面，中間不要再垫一层。
- 避免鏈式規則。服務器重定向尽量做到一次匹配，別让多條規則互相接力。
- 同步更新源头。把站内仍指向舊地址的連結改掉，能從根上减少跳轉請求。
- 跳轉類型要選對。永久迁移用 301，临时調整用 302，不要長期用 302 承担迁移任務。
- 保留必要例外。承接大量外鏈的老地址，跳轉是有意义的，不必為了「干净」直接删掉。
判断一條鏈要不要拆，不只看它有几跳，還要看它承接了多少外部連結和用戶习惯。鏈條短但落点错誤，同样是問题。
容易忽略的几種情况
一是结尾斜杠。同一個頁面带斜杠和不带斜杠各返回一次跳轉，累积起来數量不小，最好在服務器层统一。二是大小寫。有些系統對路径大小寫敏感，連結里混用會多出一次跳轉。三是尾随參數。舊連結带的跟踪參數被原样保留，最终地址也拖着參數，看起来像两個頁面。四是移動端跳轉，如果做的是獨立移動域，设备判断出错會把用戶和蜘蛛来回甩。
把它放進日常巡检
跳轉鏈不是修一次就完事的東西。每次改版、換域名、調整栏目结构之後，都值得重新跑一遍核心入口。把「關键路径的跳轉步數」当作一個固定观察項，比等到日誌里 3xx 請求堆积再回头找原因要從容得多。