站内連結指向的地址如果已经變了，訪客和搜尋引擎蜘蛛並不會直接到達目标，而是先被服務器“指”到另一個地址。一跳两跳還好，怕的是跳成一串，甚至绕回原地。這類問题平时不顯眼，等到抓取频率下降、訪問速度變慢时才被注意到，排查起来却要翻日誌、翻模板、翻歷史配置。
跳轉是怎么一步步變成鏈的
大多數跳轉鏈不是一次决定的，而是多次改動叠加出来的。比如站点從 http 換成 https，舊地址 301 到 https 版本；後来又換了域名，舊域名再 301 到新域名；再後来栏目調整，頁面從 /a/ 挪到 /b/。三次改動單獨看都合理，叠加起来就是三跳。如果新内容把連結寫成最早的那個地址，訪客和蜘蛛就要重新走一遍這條鏈路。
還有一種情况来自服務器层面的預設行為：末尾斜杠自動补全、大小寫自動纠正、www 與非 www 互跳。這些規則往往寫在 Nginx 或 Apache 配置里，寫規則的人換了，後来接手的人不知道，于是又叠上一层。
容易被忽略的几類問题
301 和 302 混用
301 表示永久迁移，302 是临时跳轉。頁面已经彻底換地址却用 302，蜘蛛會持續回訪舊地址，抓取预算被反复消耗在一條没有终点的路上。反過来，临时活動頁用了 301，等恢复时又要改回来，容易留下歷史记錄混乱。
重定向环
A 跳 B、B 跳 A，或者 A 到 B、B 到 C、C 又回到 A。這種配置错誤通常出現在域名切換期間，CDN 回源規則和源站規則互相打架的时候。表現是浏览器报“重定向次數過多”，蜘蛛則直接放弃這一條路径。
内鏈仍指向舊地址
頁面地址已经迁移，但導航、面包屑、正文里的連結、甚至站点地图里寫的還是舊地址。每一處都在制造一跳，數量多了就是持續不断的額外開销。
參數與斜杠引起的多余跳轉
带參數的首頁地址跳到不带參數的首頁，末尾少一個斜杠被补一次，這些看起来都很轻，但量大了會明顯拖慢整站响應，也會让日誌里的狀態碼分布變得难看。
動手自查的几種方式
- 用命令行看跳轉過程。對重点 URL 發起带跟随跳轉並顯示响應头的請求，观察最终落点是不是你想要的地址，中間经過了几跳，狀態碼分別是多少。
- 看服務器日誌里的狀態碼分布。按狀態碼分组統計，重点看 301、302 的數量和来源路径。排在前面的跳轉源，往往就是數量最大的那批問题。
- 抽样检查站内連結。從首頁、栏目頁、文章頁各抽一些連結，看 href 寫的是目前地址還是歷史地址，尤其是经歷過多次改版的栏目。
- 核對配置文件。把服務器、CDN、框架路由里的跳轉規則集中列出来，看有没有互相冲突、互相覆盖或者完全重复的條目。
修复的優先級
先處理重定向环和大量 302，這两類影响面最大；再把跳轉鏈压缩到一跳，能直接指向最终地址的就直接寫最终地址；最後清理站内連結和站点地图里的舊地址。修复之後仍然建议保留舊地址的跳轉，不要直接删掉，因為外部連結和用戶书簽不會跟着你一起更新。
跳轉本身不是問题，問题是没人知道現在一共跳了几跳。
隔一段時間把跳轉規則重新過一遍，比等到出問题时再翻配置要轻松得多。
如果你的站点经歷過換域名、換协议、換目錄结构這几件事中的任意一件，就值得专门花半小时把跳轉規則理一遍。這類工作不产生新内容，但能减少訪客等待，也能让蜘蛛把時間花在真正需要抓的頁面上。