先分清是哪一類改版
換域名、調路径、切协议、合並栏目，表面上都叫“URL 變了”，實际要處理的問题並不一样。先归類，再决定映射策略，能省掉後面很多返工。
- 換域名：整站 URL 前缀變化，需要全量對應，一對一是底线。
- 路径調整：比如 /news/123 變成 /article/123，通常能做規則批量映射。
- 协议或 www 切換：同一内容換了前缀，重点在统一出口，別让两種寫法長期並存。
- 栏目合並：多個舊地址指向一個新地址，属于多對一，要挑最相關的那一個作為落点。
把這四類分開列，後面寫重定向規則时不容易漏。混在一起處理，規則很容易互相覆盖。
迁移前先把两邊的 URL 清單對齐
很多人直接從舊站導出 sitemap 就開始寫規則，结果漏掉的往往是 sitemap 里本来就没收錄的那批頁面——參數頁、带尾斜杠的地址、大小寫混用的連結。更稳的做法是几個来源交叉：站点地图、服務器日誌里被真實訪問過的路径、站内連結抓取结果。
然後把舊地址和新地址做成一張對應表，逐條確認。表里至少要标清楚三件事：舊 URL、新 URL、以及這是不是一對多。凡是暂时找不到對應頁面的，宁可让它返回 404，也不要先随便指到首頁。
301 要一對一，整站跳首頁是常见誤区
把大量舊 URL 统统重定向到首頁，短期看不出問题，長期會让搜尋引擎把這些舊地址判成“软 404”一類的结果——目标頁和原頁面主题對不上，信号也就传不過去。首頁也承受不了成百上千個不相關地址的集中指向。
判断标准很简單：用戶從搜尋结果点進来，看到的内容是否和标题里承诺的接近。差得越遠，這次重定向的價值就越低。
如果确實有頁面在新站不存在了，直接让它返回 410 或 404 更干净，比硬塞一個不相關的落点要好。
内鏈和站点地图要跟着一起改
只加服務器重定向、不動站内連結，等于一邊告诉搜尋引擎“舊地址作废”，一邊又繼續在站内给它投票。常见的遗漏点包括：
- 文章正文里指向舊地址的超連結
- 導航、面包屑、侧栏推荐位里的寫死路径
- 分頁、标簽頁、作者頁這類由模板生成的連結
- 站点地图里仍然保留的舊 URL 條目
- canonical、结构化資料里的 URL 字段
這些位置用全站搜尋過一遍再上线，比上线後靠日誌發現問题快得多。顺带提醒一句：canonical 指向的應该是新地址，如果它和重定向目标不一致，反而會制造新的混乱。
迁移期間盯哪几组資料
改版上线不等于迁移完成，接下来一段時間要看的是替換進度，而不是某一天的收錄數字。
- 服務器日誌：舊 URL 的抓取是否在减少、返回碼是不是稳定的 301；新 URL 的抓取量是否在上升。
- 索引狀態：新舊地址在索引里的替換情况，重点看舊地址有没有長期停留。
- 落地頁表現：搜尋来源的落地頁是否已经換成新地址，有没有出現明顯断档。
這三组資料要放在一起看。只看索引报告容易得出“還没開始迁移”的结论，其實日誌里舊地址的抓取可能早就降下来了。
几個容易踩的坑
- 鏈式重定向：A 跳到 B、B 又跳到 C，多跳一层就多一次损耗，規則要一次到位。
- 長期用 302：永久性改版就该用 301，302 更像是临时安排。
- 重定向目标本身也失效：跳過去是 404，等于白跳，上线前要逐條驗證返回碼。
- 一次改太多：URL 结构、模板、内容结构同时大改，出問题时很难定位是哪一步造成的。
重定向什么时候能撤
没有必须撤掉的時間点。只要舊地址還有外部連結指向、還有用戶從舊书簽或搜尋结果進来，保留重定向就是划算的——它的维護成本很低，撤掉之後要恢复却几乎没有办法。與其纠结撤不撤，不如定期检查這些規則有没有繼續指向有效頁面。