站点改版、栏目重排、域名更換，都會让一批 URL 換地址。收錄层面的麻烦通常不在改版当天出現，而是在之後几周里慢慢顯形：舊地址還留在索引里，新地址迟迟没進来，搜尋结果点進去落在一條已经 301 的舊連結上。迁移期的核對重点，是把“地址變更”這件事拆成几個能逐個检查的环节，而不是改完就等。
一、先把 URL 變更清單列出来
動手改之前，先做一次地址盘点。把現有 URL 按變化類型分開，後面才知道每條舊地址该跳去哪。
- 彻底刪除的頁面：没有對應新地址，只能 404 或 410，不要硬跳首頁。
- 路径變化的頁面：有明确的一對一新地址，做 301。
- 合並的頁面：多條舊地址並到一個新地址，需要判断哪個是主版本。
- 只改了參數或结尾斜杠的頁面：這類容易被忽略，但舊形式可能已经被收錄過。
列清單的好處是能提前發現“找不到去處”的舊地址。這些頁面如果被批量跳轉到首頁或栏目頁，往往會被当成软 404 處理，反而拖慢整体迁移。
二、跳轉鏈尽量做成一條直线
理想狀態是舊 URL 经過一次 301 直接落到最终新 URL。A 跳到 B、B 再跳到 C 這種多跳，會消耗抓取、拉長確認時間，也更容易在中途断掉。
- 用 curl -I 或抓取工具抽样驗證每條舊地址的跳轉次數。
- 检查是否出現跳轉循环，尤其是带參數和斜杠的地址。
- 確認新地址返回的是 200，而不是又一次跳轉或 200 包装的错誤頁。
跳轉鏈本身不复杂，麻烦的是改版後临时加的重定向規則层层叠加。建议在迁移前把跳轉規則整理一遍，删掉不再需要的舊規則。
三、内鏈和站点地图的切換顺序
常见的失誤是：站点地图已经換成新地址，站内連結却還指着舊地址。蜘蛛從地图進来的是新頁面，顺着頁面里的連結又跑回舊地址，判断起来會更慢。比較稳妥的顺序是：
- 先改站内連結，包括導航、面包屑、正文内鏈、分頁和列表頁。
- 再更新站点地图，只保留可索引的新地址。
- 確認 robots.txt 没有挡住新的路径或目錄。
- 观察服務端日誌里新地址的抓取是否逐步出現。
如果站点地图先于内鏈更新，也不是不能做，但要意识到這几天站内會出現“新舊混用”的狀態，核對时別把它当成異常。
四、新舊地址同时出現在索引里，属于過渡狀態
索引不會在改版当天完成切換。舊地址被 301 之後，需要被重新抓取、確認跳轉關系，再把积累的信号轉交给新地址。在這之前，两邊同时出現是正常的，不必急着提交刪除。
什么情况才需要動手處理
- 舊地址仍返回 200，没有跳轉——這是規則没生效，要修。
- 舊地址跳到了無關頁面或首頁——先確認有没有更合适的目标。
- 跳轉鏈過長或形成循环——按上一节的办法收口。
- 新頁面本身没有被收錄——先解决新地址的抓取和索引，而不是纠结舊地址。
換句话说，舊地址的“残留”多數时候會随新地址的稳定收錄而逐步消退；真正需要優先處理的，是新地址進不去。
五、改版後值得盯的几項
- 搜尋结果里的落地頁是否仍指向舊地址。
- 日誌中新 URL 的抓取频次是否在上升。
- 站点地图是否存在报错或抓取失敗。
- 站内是否還有指向舊地址的連結残留。
- 流量回落的曲线是否在數周内趋于平稳，而不是持續下滑。
改版的收錄問题，大多不是“提交得不够多”，而是顺序没理顺：跳轉没跳對、内鏈没跟上、地图和内鏈不同步。把這几項按顺序核對一遍，比反复提交地址更有用。
迁移不是一次動作，而是一段需要核對的過渡期。舊地址什么时候登出索引，取决于新地址什么时候被稳定地抓取和確認。