站点改版、栏目調整、URL 規范化之後，站内往往會积累不少重定向規則。單看一條“A 跳 B”似乎没問题，但如果 B 又跳 C、C 再跳 D，蜘蛛每次顺着舊連結爬進来都要多跑几跳，抓取效率就被慢慢磨掉了。這篇文章整理一套重定向鏈與跳轉层級的自查方法，重点是让舊 URL 一步到位、让跳轉目标稳定可预期。
為什么要看“跳轉鏈”，而不是只看單次跳轉
大多數人检查重定向时，只會打開一條舊 URL，看到跳轉成功就放過。但蜘蛛面對的是整站歷史連結的集合：早年文章連結、被替換的栏目頁、带參數的分享連結、外站留下的舊地址。這些入口只要有一條形成三級以上的跳轉鏈，就會持續消耗抓取額度。
更麻烦的是，鏈式跳轉经常伴随目标不稳定：今天的终点是栏目頁，明天栏目合並後又變成新目錄頁，终点一變，之前所有指向它的跳轉都要重新判断。把跳轉层級压到一层、终点固定下来，後續维護會轻松很多。
重定向鏈自查清單
- 跳轉次數：從任意舊入口出發，是否能在一次跳轉内到達最终頁面。
- 狀態碼使用：永久迁移用 301，临时活動或灰度用 302，不要把临时跳轉長期留在生产环境。
- 跳轉终点：终点是否為仍然可訪問、内容相關的正式頁面，而不是首頁或某個宽泛的列表頁。
- 跨域跳轉：是否跳到了其他域名或其他子域，跨域跳轉要確認目标确實承接该内容。
- 协议與域名版本：http 到 https、www 與非 www 是否反复来回跳。
- 大小寫與斜杠：同一路径的大小寫、结尾斜杠是否产生額外一跳。
- 與 canonical 的一致性：頁面自身的 canonical 是否與跳轉终点指向同一個地址。
- 規則冲突：服務器配置、CDN 邊缘規則、應用层路由是否叠加了多套跳轉，互相追加。
四類高频問题
1. 鏈式跳轉层层叠加
典型场景是 URL 结构調整分几次完成：第一次把日期目錄去掉，第二次把栏目名改成新命名，第三次又统一了结尾斜杠。如果每次都新增一條規則而没有回头合並，舊連結就會走完三轮才落地。處理方式是把歷史規則逐條走通，能直接指向最终地址的就改寫成一步。
2. 临时跳轉被当成永久跳轉用
302 常用于活動頁或灰度驗證，但如果活動結束後忘了替換，搜尋引擎會持續把它当作临时狀態看待，舊地址的權重传递和收錄替換都會變得犹豫。定期掃一遍站点里所有 302，確認每一條都有明确的保留理由。
3. 跳轉终点與 canonical 不一致
跳轉把蜘蛛送到 B 頁面，而 B 頁面又用 canonical 指向 C，這會让蜘蛛在两個信号之間反复確認。正常情况下，跳轉终点就應该是 canonical 指向的地址，两者對齐後再谈其他優化。
4. 一律兜底跳首頁
内容已刪除、栏目已合並时，把舊連結全部指到首頁是省事的做法，但對用戶和蜘蛛都没有帮助：用戶找不到想要的内容，蜘蛛也會把大量舊入口聚到同一個頁面上。能對應到同類内容就對應，确實没有承接頁面的，用明确的 410 或 404 反而更清楚。
一次可执行的排查流程
- 從蜘蛛抓取日誌中筛出狀態碼為 3xx 的請求，按出現频次排序，優先處理高频舊地址。
- 對每條地址手工走一遍跳轉，记錄跳轉次數與最终落点，形成一份跳轉清單。
- 把两級以上的跳轉合並為一級，把终点改為目前的正式地址。
- 检查服務器配置、CDN 規則與應用路由，確認没有多套規則同时對同一路径生效。
- 確認跳轉终点頁面可訪問、内容相關、自带 canonical 且指向自身。
- 更新内鏈與站点地图，把仍在使用舊地址的内部入口替換掉。
- 把跳轉清單纳入版本管理，下次改版前先對照清單，避免重复叠加規則。
复查节奏
重定向不是一次性工作。建议每次栏目調整、域名或协议變更、CDN 規則更新之後都做一轮快速复查，重点看有没有新增的鏈式跳轉和失效终点。日常也可以按季度抽查一次日誌中的 3xx 請求，观察高频舊地址是否在逐步减少。
判断标准很简單：一條舊連結，蜘蛛一跳就能到位，用戶点击也不會觉得突兀，這條規則就算合格。其余的情况，都值得再改一次。