換域名、加 www、從 http 迁到 https，這類操作在站点运营里很常见。不少人以為把 301 配好，索引里的舊地址就會自動換成新地址。實际過程更像一次地址簿的替換：蜘蛛需要重新發現新地址、重新抓取，再判断两個地址指向的是不是同一個頁面，中間會有新舊並存的阶段。

一、先把新舊 URL 的映射關系列出来

跳轉規則寫得再漂亮，如果映射本身是乱的，结果也是乱的。迁移前建议先導出一份目前被訪問、被連結的 URL 清單，逐條確認它應该去往哪個新地址，形成尽量一對一的關系。

• 列表頁、詳情頁這類有規律的 URL，可以用規則批量映射，但規則要覆盖到分頁、篩選參數等邊界情况。
• 首頁、栏目頁、临时活動頁這類没有規律的 URL，逐條登记，別指望規則自動兜住。
• 只被站内連結引用、外部没有入口的頁面同样要照顾到，它們也是蜘蛛曾经走過的路径。
• 已经下架、本来就不该出現在索引里的舊地址，让它返回 404 或 410，而不是硬塞一個跳轉。

二、跳轉本身要干净

跳轉是這次迁移里最容易做错的一环，常见問题有几類：

• 跳轉鏈太長：舊地址跳到中間地址，再跳到最终地址，甚至跳三四次。鏈條越長，越容易在某一环被中断，後續判断落点也更麻烦。
• 用 JS 或 meta refresh 代替 301：這些方式對用戶可用，但對蜘蛛来说信号弱得多，不如服務端直接返回 301 来得明确。
• 把临时跳轉当永久跳轉用：302、307 表達的是“暂时”，長期使用會让舊地址的去留變得含糊。
• 把不相關的頁面互相跳：為了保住舊地址的表現，把 A 頁面跳到完全不相關的 B 頁面，用戶和蜘蛛都會被绕晕。

目标其實很简單：舊地址收到請求後，用一次 301 指向新地址，新地址返回 200。

三、让新地址自己站得住

跳轉只解决“從舊到新”這一段。新地址能不能被稳定收錄，還要看它自身的信号是否一致。

• 站内連結全部改為指向新地址，不要繼續鏈向舊域名；内部連結還指着舊地址，等于在告诉蜘蛛舊地址仍然重要。
• canonical、sitemap、RSS、结构化資料里的 URL 一並更新，避免同一個頁面出現两套地址。
• 提交新域名的 sitemap，舊 sitemap 可以保留一段時間，但内容要逐步收敛到新地址。
• 確認没有遗留的 robots.txt 規則、訪問限制或安全策略，把新域名的抓取挡在门外。

四、舊域名別急着關

迁移完成後立刻停掉舊域名，是很容易踩的坑。舊地址上的跳轉需要繼續存在一段時間，因為在迁移之前就已经存在的連結、收藏和外部引用，不會因為你換了域名就同步更新，蜘蛛也需要時間把舊地址重新走一遍。

另一個方向相反的坑是：為了“让舊站彻底登出”，把舊域名整個用 robots.txt 屏蔽，或者干脆让它解析失敗。這样做的结果是蜘蛛讀不到跳轉，也就無法把舊地址和新地址關联起来，索引替換反而會更慢。

舊域名在過渡期的作用是“指路”，不是“繼續运营”。跳轉保留到舊地址的訪問量明顯下降之後，再考虑下线。

五、观察重点放在“替換”而不是“數量”

迁移期的索引資料會有波動，盯着總收錄數涨跌很容易誤判。更有意义的观察方式是把注意力放在具体地址上：

• 抽样一批新地址，看它們是否已经能被抓取、是否進入索引。
• 抽样一批舊地址，看返回的是不是 301，落点是不是预期的新地址。
• 看新域名的抓取量是否在逐步上升，而不是只有首頁被反复訪問。
• 借助後台的索引狀態报告，確認新地址是否被识別為規范地址。

整個替換過程通常以周為單位推進，站点規模、外鏈结构、舊地址數量都會影响节奏。與其追求“一次換干净”，不如保證每一步都是确定的：映射清楚、跳轉干净、信号一致、舊地址保留到位。

如果迁移一段時間後，新地址被抓取却迟迟不進入索引，或者舊地址長期停留在索引里，可以回头检查两件事：跳轉是否真的返回 301，以及新地址上是否存在重复内容或质量問题。這两個方向排查完，多數情况能找到线索。