重定向是站点运营里很常见的手段：換域名、上 HTTPS、調整目錄、合並頁面，几乎都會用到跳轉。單次跳轉通常没什么問题，麻烦的是跳轉一层接一层，訪客和蜘蛛每訪問一次就要多等几轮。這個环节不容易被注意到，因為它不會报错，頁面看起来也能正常打開。
跳轉鏈為什么會累积
大多數跳轉鏈不是一次设計出来的，而是多次改動叠加的结果。比如最早的地址是 http，後来加了 www，再後来上了 HTTPS，每一次都加了一條規則，但没人回头清理舊的那條。结果就是一次訪問要经過三次跳轉才落到最终頁面。
類似的叠加還有：目錄结构調整後，老地址跳到新地址，新地址又跳到另一個新地址；頁面合並时，被合並的地址跳到一個中轉頁，中轉頁再跳到最终頁。鏈條越長，中間任何一环出問题，整條鏈路就断了。
值得優先检查的几種情况
- 协议與主机名不统一：http 跳 https、不带 www 跳带 www，如果規則分開寫，很容易變成两跳甚至三跳。
- 末尾斜杠與大小寫：带斜杠與不带斜杠被当成两個地址，互相跳来跳去。
- 跳轉類型混淆：该用 301 的地方用了 302，或者反過来，临时改動被当成永久規則留了下来。
- 跳轉目标又跳走：落点本身還有一條重定向規則，形成鏈式反應。
- 落点已失效：跳轉指向一個已经下线的頁面，最终返回 404 或错誤頁。
- 非服務端跳轉：用 meta refresh 或 JavaScript 做跳轉，不同客戶端和蜘蛛的處理方式並不一致。
自查可以從這几步開始
- 挑一批有代表性的地址，用命令行工具查看完整跳轉鏈，记錄每一跳的狀態碼和目标地址。
- 把跳轉超過一跳的地址整理出来，判断哪些規則可以合並成一條。
- 核對跳轉類型：長期有效的迁移用 301，临时维護或活動頁用 302，不要長期混用。
- 確認最终落点返回 200，且頁面内容與原来的主题一致，没有變成不相關的頁面。
- 把 meta refresh 和脚本跳轉尽量改成服務端跳轉，减少處理方式上的差异。
站内連結應该直接指向终点
很多跳轉鏈的源头不在規則里，而在站内連結上。導航、面包屑、站内推荐、站点地图里的地址，如果還停留在老版本，每次訪問都要绕一圈。把内鏈统一改成最终地址之後，跳轉規則就只需要服務外部連結和歷史收藏了。
這一步的收益比較直观：訪客少等几轮，蜘蛛也不會把抓取次數浪費在同一批地址上。
從日誌里看跳轉的痕迹
跳轉會在一段時間的訪問日誌里留下连續记錄。同一類訪問集中在几個老地址上，通常就是跳轉規則仍在生效的信号。观察這類记錄的變化，可以判断站内連結是不是已经清理干净。
跳轉規則能少一條就少一條，能合並就合並，別让訪客和蜘蛛在路上绕圈。
什么时候需要重新查一遍
換域名、迁移 HTTPS、調整目錄结构、做頁面合並之後，建议都把跳轉鏈過一遍。平时也可以按季度抽查一次，重点看新增的規則有没有和目标地址冲突。規則本身不复杂，难的是记得回头清理舊的那一层。