網站改版、換域名、調整目錄结构，最容易出問题的地方不是新頁面做得好不好看，而是老地址還能不能正常打開。改動上线的那一刻，搜尋引擎和用戶手里攥着的都是舊 URL，如果它們成批變成死鏈，之前积累的訪問和連結就白費了。
先做一份舊地址清單
跳轉這件事，靠记忆是做不完的。上线前至少要拿到三類資料：
- 服務器訪問日誌里最近 30—90 天被請求過的 URL，按請求量排序；
- 站点地图、站内連結、外部連結中出現的地址；
- 已有跳轉規則文件（如 Nginx、Apache 配置）中记錄的歷史規則。
把這三份合並去重，按流量和重要性排出優先級。高優先級的地址，上线後要逐條人工驗證，不要只看規則文件寫得對不對。
再决定每個地址的归宿
能不動就不動
如果舊路径還能保留，優先保留。跳轉本身是一種损耗，能不跳就不跳。只有确實無法保留的地址，才進入跳轉清單。
一對一迁移用 301
内容被搬到了新地址，且舊地址不會再回来，用 301 永久跳轉。關键是一跳到终：A 跳 B、B 跳 C 這種鏈條會让抓取多走几步，鏈條越長越容易被放弃。
内容真的没了就用 404 或 410
不要把所有舊地址统统跳到首頁。内容不相關的首頁跳轉，容易被判定為软 404，也會让用戶点進来發現货不對板。整块栏目下线的，可以保留一個說明頁，把剩余内容的相關入口放上去。
临时調整用 302
只是短期換版、A/B 測試或者维護期間的临时轉移，用 302。長期使用 302 會让搜尋引擎一直不确定最终地址，不利于新地址稳定下来。
检查跳轉鏈條和环路
規則一多就容易互相打架。上线前用脚本或爬虫工具跑一遍：
- 随机抽取舊地址請求，记錄跳轉次數和最终落点；
- 確認没有 A→B→A 的环路，也没有跳到已经下线的頁面；
- 確認 http 與 https、带 www 與不带 www、带斜杠與不带斜杠的版本，最终都收敛到同一個地址。
分批上线，邊看日誌邊补
一次性全量切換的風險在于出問题时無從回退。更稳妥的做法是先把高流量目錄切過去，观察一两天日誌里的 404 數量和抓取情况，再逐步扩大范围。上线後重点關注：
- 日誌中舊地址的响應碼分布，看還有多少漏配；
- 新地址被請求的频次是否在上升；
- 是否存在大量来自站内鏈的舊地址（說明模板里還留着硬编碼）。
跳轉規則寫完不等于做完了。真正影响效果的是上线後那几天的日誌观察和补漏，而不是規則文件本身有多漂亮。
几個常见的坑
- 只改了首頁，栏目頁和詳情頁模板里還寫着舊域名；
- 跳轉規則寫在错誤的层級，被更靠前的規則拦截；
- 大小寫、參數顺序不同導致的地址被当成新頁面重复處理；
- 把带參數的舊地址全部跳到無參數首頁，丢失原有定位。
把舊地址当成需要迁移的内容资产来對待，比事後到處找断鏈要省力得多。