站点換域名、把 http 換成 https、把主站從子目錄搬到獨立域名，都會碰到同一件事：舊地址已经在索引里，新地址還没有。這段過渡期最怕两件事——舊地址繼續被抓取端当成有效頁面，新地址迟迟進不了索引；或者两邊都在，同一份内容在索引里挂着两套地址。
迁移不是一次性動作，而是一個按顺序推進的過程。下面這几步的先後關系，往往比每一步做得多精细更重要。
先把舊地址和新地址的對應關系列成一張表
動手改配置之前，先從一個完整的 URL 清單開始。来源可以是站点地图、服務器訪問日誌、搜尋後台的索引报告，取並集去重。
- 能一對一對應的頁面：舊地址 → 新地址。
- 已经下架、不打算保留的頁面：标注為不再提供，而不是随手指到首頁。
- 带參數的地址、大小寫變体、结尾斜杠變体：先归一，再進映射表。
- 确實没有對應頁面的分類頁、标簽頁、篩選地址：單獨列出来，决定是保留還是收口。
這張表决定了後面 301、canonical、内鏈到底指向哪里。表没整理好，後面每一步都會带着错誤往下传。
301 是主力，別用 JS 跳轉或 meta refresh 顶替
服務器层的 301 是迁移里最可靠的信号，它明确表達“這個地址永久換了地方”。常见的替代做法各有問题：
- JS 跳轉：抓取端要先执行脚本才知道去哪，等于多了一道不确定性，迁移期容易原地卡住。
- meta refresh：信号弱于 301，也不带永久迁移的含义。
- 302 / 307：表達的是临时跳轉，長期挂着會让舊地址一直被视為有效。
如果新舊站由不同系統承载，優先在舊站這一层做 301，不要指望新站自己把流量接過去。
重定向要一步到位，別铺成長鏈
迁移时最容易出現的鏈條是：舊 http 地址 → 舊 https 地址 → 新域名 http → 新域名 https。每多一跳，抓取端要花的成本就多一分，判断最终地址的時間也往後拖。
做法是让所有歷史形態的地址都直接跳到最终唯一的目标地址，一條鏈路只走一步。改完之後抽一批地址實测，跟着跳轉走一遍，確認最後一跳落在正确的頁面上，而不是落在 404 或者首頁。
canonical、内鏈和站点地图要一起更新
301 只解决“從舊地址到新地址”的問题，頁面自身的信号還得同步換過去。否則索引可能已经记着新地址，頁面里的自指 canonical 却還寫着舊域名，两邊互相矛盾。
- 頁面内的 canonical 改成新域名下的自身地址。
- 站点地图重新生成，只放新域名下可訪問的地址。
- 站内連結全量替換為新域名，避免正文和導航里還留着舊地址。
- 如果舊站還在线，不要在舊站里繼續加新内容。
這几項的顺序是先改頁面信号，再提交新站点地图。反過来的话，新地图里的地址在抓取时還會被 canonical 指回舊域名。
舊地址不要保留可訪問的副本
有些迁移為了“過渡稳妥”，把舊站原样保留着，只在入口加一层 301。問题在于，只要舊地址還能返回完整頁面，它就依然可能被当成獨立有效地址反复抓取。更稳的做法是舊站只保留跳轉能力，内容不再對外提供。
如果個別頁面确實下架不保留，返回 404 或 410 比统一指到首頁更合适。把大量失效地址都指到首頁，會让首頁收到一批無意义的信号。
迁移期的回查顺序
- 抽查一批舊地址，確認狀態碼和最终落点符合映射表。
- 抽查新地址，確認自指 canonical 和頁面内連結都是新域名。
- 看站点地图是否只包含新域名地址，提交後观察抓取進展。
- 在索引报告里對比新舊地址的出現情况，重点關注两套地址同时存在的頁面。
迁移期不要一邊改一邊删舊站。顺序是：映射表整理完 → 新站内容可訪問 → 301 上线 → 頁面信号更新 → 舊站收口。中間任何一步没做完就進入下一步，後面的回查都會變得很难判断。
整個過程里，判断标准不是舊地址掉了多少，而是最终地址是否稳定、可達、信号一致。映射清晰、跳轉干净、信号统一，索引里的地址替換通常只是時間問题；反過来，映射含糊或者鏈條過長，等待期會被拉長，而且不容易看出卡在哪一步。