站点运营一段時間後，很少有一次都不動連結结构的情况：換域名、上 HTTPS、栏目改名、把 .html 後缀改成目錄形式，每一次調整都會留下几條 301。單條跳轉本身不是問题，問题是跳轉叠着跳轉——訪問 A 跳到 B，B 又跳到 C，用戶和搜尋蜘蛛每来一次就要多走一两步。
跳轉鏈為什么值得單獨查一遍
跳轉鏈不會让頁面直接被拒之门外，但它實實在在地增加了每一次請求的成本：多一次往返、多一次 DNS 或连接建立、多一段時間等待。当站内大量地址都存在两跳以上时，蜘蛛在同样時間内能走完的頁面就變少了，新内容被發現的速度也會受影响。此外，跳轉鏈還會让日誌變得难以阅讀，你很难判断某個地址究竟是被訪問了，還是只是被人顺路点了一下。
几種常见的连环跳形態
- 协议與域名分两步走：HTTP 先跳到 HTTPS，HTTPS 再跳到带 www 的版本，一次請求走三跳。
- 栏目改名叠加單篇調整：舊栏目先指到新栏目，後来單篇文章地址又變了，于是變成舊栏目 → 新栏目 → 最终頁。
- 末尾斜杠来回指：/a 指向 /a/，而 /a/ 的規則又指回 /a，形成循环，浏览器报错，蜘蛛也拿不到内容。
- 列表頁規則被套用到參數地址：分頁或篩選參數繼承了栏目級的跳轉規則，生成一批很長的中間地址。
- 插件與舊規則表残留：CMS 插件自動生成的重定向，與人工添加的規則同时生效，谁先命中取决于配置顺序。
怎么查：三條路径配合使用
- 單條驗證用命令行：對可疑地址执行一次只看响應头的請求，逐跳观察狀態碼和 Location，重点確認是否超過两跳、是否 301 與 302 混用、终点是不是 200。
- 全站掃描用爬虫工具：跑一遍站内抓取，打開重定向报告，導出跳轉层數達到两层及以上的地址清單，按出現次數排序。
- 看服務器日誌：检索返回 301、302 的訪問记錄，被反复請求的跳轉地址往往就是蜘蛛在持續消費的那條鏈，優先級應该排在前面。
修正时優先處理這几件事
- 合並規則：把 HTTP → HTTPS、裸域 → www、舊路径 → 新路径合成一次性直连，让請求一步落到返回 200 的目标地址。
- 限制跳轉层數：以一跳為常態、两跳為上限，超過两跳的地址逐條改寫，不要指望蜘蛛自己摸清路线。
- 统一末尾斜杠策略：全站只保留一種形式，另一種直接指過去，不要再反向指回来。
- 清理失效目标：跳轉终点本身已经 404 的，要么改指到最相關的現存頁面，要么干脆让原地址正常返回失效狀態。
- 核對規則表：把迁移期用的临时規則、插件生成的規則導出来看一遍，删掉已经没有任何指向意义的條目。
- 内鏈寫最终地址：站内連結和 sitemap 里直接寫终点 URL，不要图省事繼續沿用會跳轉的舊地址。
跳轉鏈本身不是错誤，它只是被反复叠加之後變成了額外成本。能压到一跳的，就別留两跳；已经没人訪問的舊規則，就让它安静退场。
把它變成周期性動作
重定向規則最容易在几次小改動之後悄悄膨胀，所以不适合只在出問题时才看。比較省事的做法是：每次结构調整、域名或协议變更之後跑一次全站掃描；每隔一個季度再把重定向报告和服務器日誌對照着看一遍，確認跳轉层數没有回升、没有新的循环出現。把這一步固定下来，連結结构就不會随着時間越缠越乱。