站点做久了，几乎都會经歷几次改版、栏目合並、路径調整。每次調整都會留下一批跳轉規則，当时看没問题，一年後再回头看，同一條地址可能要绕過三四個跳轉才落到最终頁面。跳轉鏈平时不疼不痒，真出問题时却很难排查：訪客多等几百毫秒，蜘蛛可能中途放弃，日誌里也全是难以判断的狀態碼。
跳轉鏈通常是怎么堆起来的
- 頁面從 A 改成 B，後来 B 又改成 C，但 A 的規則没同步更新，仍然指向 B。
- HTTP 跳 HTTPS、带 www 跳不带 www、舊域名跳新域名，几层規則各自為政，串在一起。
- 栏目停用後统一跳到首頁，首頁後来又加了一层跳轉。
- 移動端與桌面端互相判断跳轉，條件寫错就會出現来回跳。
- 外部連結、广告投放、QR Code里寫的還是舊地址，而舊地址又被新規則接管。
自查要看哪几個点
- 鏈路長度：随机抽一批老地址，看從輸入到最终頁面要经過几次跳轉。超過一次就该問一句為什么。
- 最终狀態碼：终点必须是正常返回，不能是一條 301 指向 404，也不能指到另一個同样在跳轉的地址。
- 是否成环：A 跳 B、B 又跳回 A，浏览器會直接报错，抓取也會记一次失敗。
- 規則是否還有效：迁移时临时加的全站跳轉，任務結束後忘了撤。
- 大小寫與结尾斜杠：同一個路径因為寫法不同各跳一次，白白多出一跳。
- 站内連結：導航、内鏈、Sitemap 里是否還在用舊地址，直接改掉比靠跳轉更省事。
跳轉方式本身也要挑
永久性變更用 301 或 308，临时活動頁用 302 或 307，這属于基本约定。需要留意的是另外几種：meta refresh 和 JavaScript 跳轉對訪客還算能用，但對抓取和調试都不友好，能不用就不用；服務器配置里的重寫規則要注意優先級，寫重了可能把静態资源也卷進去。
检查方法不必复杂
用浏览器的開發者工具看 Network 面板，勾上保留日誌，刷新一次就能看到整條鏈路；命令行下也可以只請求响應头，观察狀態碼和 Location 字段。更稳妥的做法是在訪問日誌里按狀態碼篩選，把持續返回 301、302 的地址列出来，人工過一遍哪些是必要的、哪些可以合並。
改版或迁移时的清單
- 先梳理舊地址清單，明确哪些是永久失效、哪些是一一對應迁移。
- 新的跳轉規則尽量直接指向最终地址，不要一层套一层。
- 上线後复查站内連結和 Sitemap，把它們直接更新成新地址。
- 给跳轉規則留备注和添加日期，方便以後判断還有没有保留的必要。
- 過一段時間再回看日誌，確認老地址的請求量已经降下来。
跳轉的作用是過渡，不是長期的目錄结构。規則一旦變成歷史包袱，清理它比添加它更需要耐心。
跳轉鏈這件事，不需要一次清得干干净净。每隔一段時間挑几條最常被訪問的老地址跟一遍，把明顯多余的跳轉合並掉，訪問路径就會越来越短、越来越清楚。這對訪客、對抓取、對以後接手维護的人，都是省事的選擇。