先想清楚這次改的是什么
域名更換、目錄结构重排、URL 規則變化、协议或 www 前缀切換，這几類改動的處理方式並不一样。比較稳妥的做法是先给這次迁移定性：是整体換址，還是局部調整？影响的是全站地址，還是某個栏目下的頁面？把范围寫清楚之後再動手，能避免很多漏網的地址。
最麻烦的情况是几件事叠在一起做，比如一邊換域名，一邊改 URL 規則，同时還調整了栏目结构。這时排查問题时很难判断是哪一步出的错，建议拆開分批推進。
迁移前的准备：把舊地址盘清楚
舊 URL 清單從哪来
- 站内 sitemap 里列出的地址
- 服務器訪問日誌中出現過的真實訪問路径
- 站内連結抓取结果，包括導航、列表頁、相關推荐
- 外部平台導出的入站連結清單
只看 sitemap 通常會漏掉一批歷史頁面，尤其是早期做過調整、後来又没更新的那些地址。日誌和站内連結能补上這部分缺口。
建立一對一映射表
- 内容對應的頁面互相映射，语义接近的優先配對
- 已经确定刪除的頁面，單獨列出，不要硬塞给首頁
- 多個舊地址合並到一個新地址时，只保留一個最终去向
把成批的舊地址统一跳轉到首頁，對用戶和蜘蛛来说都等于“這個頁面已经不存在了”，同时首頁還會收到一堆内容不相關的信号，得不偿失。
跳轉怎么寫才不添乱
用 301，尽量一跳到位
跳轉鏈條越長，中間损耗越多。A 跳到 B，B 再跳到 C 這種结构，既让用戶多等一次，也让蜘蛛多走一趟。能在配置里直接指向最终地址，就不要保留中間环节。
不要用 302 長期顶替
临时跳轉适合短期的灰度或活動，但如果它長期存在，蜘蛛會持續把舊地址当作有效地址来看待，不利于地址的交接。
舊域名和證书別急着放掉
舊域名繼續解析、證书繼續覆盖、服務器繼續返回 301，這個狀態建议维持較長時間。中断之後，從舊地址進来的訪問會直接進死胡同。
站内自己先改干净
- 導航、面包屑、正文内鏈里的地址是否已換新
- canonical 是否指向新地址，而不是舊地址
- sitemap 是否已替換，舊地图是否已下线或更新
- 结构化資料、分享卡片、RSS 里的地址是否同步
如果站内連結還指着舊地址，等于每一次点击都要多走一次跳轉，蜘蛛發現新地址的速度也會被拖慢。
上线前後的核對
上线前
- 预發布环境確認禁止抓取，或者至少與正式环境隔离
- 检查配置和模板里有没有硬编碼的測試域名
- 確認 robots 規則没有顺手把新站整站挡住
上线後
- 抽查一批代表性地址，看跳轉是否落到正确頁面
- 在訪問日誌里盯 404 和 5xx 的變化，而不是只看總量
- 观察新地址的抓取情况是否逐步起来
- 確認 sitemap 里提交的地址都能正常打開
迁移後的抓取和索引波動是常见現象，重点看趋势和错誤類型，不要因為某一天的數字起伏就急着改規則。
几個容易漏掉的细节
- 地址的大小寫和结尾斜杠是否保持统一
- 带參數的舊地址是否也在映射表里
- 图片、样式、脚本等静態资源是否還挂在舊域名上
- 邮件模板、QR Code、外部合作頁面里寫死的連結
這些地方不直接影响主頁面，但會在日誌里留下大量混杂的請求，给後續排查添麻烦。
把過渡期当成正常阶段
迁移不是一次切換動作，而是一段需要盯着的過渡期。映射表留档、日誌定期看、舊域名维持解析，這几件事做到位，地址交接基本就不會出大問题。至于新地址多久被重新抓取、頁面何时恢复原有的表現，取决于站点自身情况，能做的是把可控的环节先做對。