網站改版、換域名、調整目錄结构，都是运营中难免會遇到的事。很多团队把精力放在新頁面的设計和内容上，等到切換上线後才發現：老連結成片打不開，搜尋蜘蛛抓到的還是一堆失效地址，本来积累的訪問量直接掉一截。問题往往不在改版本身，而在迁移前的 URL 映射和重定向没有提前梳理。
為什么迁移阶段最容易出問题
平时的頁面改動是零散的，改一個修一個，影响面小。迁移不一样，它是一次性把大量地址同时換掉，只要有一批没處理好，蜘蛛顺着舊連結爬過来就會连續吃到 404。抓取预算被浪費，新地址也因為缺少入口而迟迟没被發現。
更麻烦的是，迁移往往伴随栏目重组。原来一篇文章在 /a/123.html，新系統里可能變成 /news/2024/xxx/，如果只是把老目錄删掉，等于亲手把過去的入口全部切断。
一、先盘清舊地址清單
動手之前，先把“舊地址有哪些”這件事整理清楚。来源可以有几個：
- 服務器訪問日誌，篩選狀態碼為 200 的請求路径，按訪問量排序；
- 已有的站点地图文件，尤其是歷史分片；
- 網站後台的内容導出，包含每篇内容的原連結；
- 外鏈工具或站長平台的收錄資料，能看到哪些地址有外部引用。
清單不用追求绝對完整，但要覆盖流量最高、外鏈最多、被收錄最多的那部分。把這份清單存成表格，後面每一步都基于它来做。
二、建立舊到新的映射表
映射表的每一行，至少包含三列：舊地址、新地址、處理方式。處理方式通常只有几種：
- 一一對應：内容還在，只是地址變了，做單條重定向；
- 合並：几篇舊内容被整合成一篇新内容，全部指向同一個新地址；
- 栏目級：整個目錄規則统一，可以用一條通配規則覆盖，比如把 /old/(.*) 指向 /new/$1；
- 彻底下线：内容不再保留，指向最相關的上級栏目頁，而不是首頁。
這里有個细节值得注意：把大量無關舊地址统统重定向到首頁，是最常见的偷懒做法。用戶点進来發現内容和预期完全不符，蜘蛛也會判断這是一次软性的失效跳轉，價值不大。宁可指向一個分類頁，也不要一律丢给首頁。
三、重定向要一步到位
重定向鏈條越長，损耗越大。A 跳到 B、B 又跳到 C，中間任何一环出問题，整條鏈就断了。迁移时最好直接寫成“舊地址 → 最终地址”的一步跳轉，不要依赖舊系統里遗留的規則层层轉發。
另外，重定向的狀態碼要用對。永久性的地址變更用 301，临时的活動頁、短期跳轉用 302。如果拿不准，宁可先按临时處理，观察一段時間再定，也不要随手寫成 301——一旦寫错，纠正過来需要不短的時間。
四、切換之後要做的驗證
上线不等于結束。切換後的头几天，建议固定做几件事：
- 抽查映射表里訪問量最高的几十條舊地址，確認全部正常跳到目标頁；
- 看服務器日誌里 404 的數量，如果某個目錄集中出現，說明映射有遗漏；
- 確認新站点地图已经更新，提交的是新地址而不是舊地址；
- 检查站内連結有没有還指向舊路径的，尤其是導航和正文里的老内鏈；
- 观察各栏目被抓取的频次變化，判断蜘蛛有没有顺利過渡到新结构。
五、几個容易踩的坑
迁移不是一次單纯的技術上线動作，而是一次入口的搬家。老地址是過去的入口，新地址是未来的入口，中間必须有一根明确的绳子连着。
- 只改了前端菜單，正文和侧栏里的内鏈還指向舊地址；
- 新舊站点同时在线，同一篇内容出現两個可訪問地址，形成重复；
- robots.txt 或屏蔽規則忘记同步，新地址被自己挡在门外；
- 映射表只做了一次就不再维護，後續新增的舊地址無人處理。
说到底，URL 迁移的难点不在技術，而在是否有耐心把清單一條條過一遍。做之前多花半天整理表格，往往比上线後花几周收拾 404 要划算得多。