換域名、改目錄结构、把 http 升級為 https，這類操作在搜尋引擎看来都是“一批 URL 集体換了位置”。很多人以為配好 301 就結束了，實际上跳轉只解决了訪問该去哪，頁面能不能繼續被發現、被抓取、被编入索引，還要看後面几個环节有没有跟上。

跳轉只是第一步，鏈路上還有別的环节

一條 URL 從被發現到重新出現在索引里，大致要经過：内鏈或其他入口指向它、爬虫抓取到新地址、新地址返回正常狀態碼並渲染出内容、索引里逐步用新地址替代舊地址。301 只解决了“舊地址有人訪問时去哪”這一個問题，其余环节任何一處断掉，都會表現為“跳轉没問题，但收錄迟迟不回来”。

迁移前：把 URL 映射表做扎實

一對一映射優先于批量兜底

最省事的做法是把所有舊 URL 统一跳到首頁，這在收錄层面代價很大：原本有獨立價值的頁面會集体失去落点。更稳的做法是先導出站内被抓取和已收錄的 URL 清單，逐條给出新地址，形成映射表。

• 能一對一的，尽量不合並；确實要合並的，合並到主题最接近的頁面，而不是首頁。
• 舊地址已经完全没意义的（例如過期活動頁、失效商品頁），让它返回 410 或 404 比乱跳更清楚。
• 大小寫、带參數、带尾斜杠的變体，在迁移前先收敛，避免把老問题一起搬過去。

避免跳轉鏈和伪跳轉

舊地址 A 跳到 B、B 又跳到 C，這種鏈式跳轉會让爬虫在中間多走几步。另外用 meta refresh 或 JS 做的跳轉，對爬虫来说不等于 301，很容易被当成頁面内容而不是跳轉指令。

跳轉鏈條越長，到達目标頁的损耗越大，也越容易被中途放弃。

迁移中：让新舊两套体系保持一致

迁移期最怕的是内部信号互相打架：内鏈指向舊地址、canonical 寫着舊域名、sitemap 里新舊混在一起。只要這些地方不一致，爬虫就需要花額外時間判断哪個版本才是你想要的。

需要同步检查的位置

1. 站内導航、面包屑、列表頁與正文里的内鏈，尽量替換為新地址。
2. sitemap 只保留新地址，並更新其中的時間标记。
3. canonical 指向新地址自身，不要再指向舊域名。
4. robots.txt 里声明的 sitemap 地址、站点地图索引文件，一並更新。
5. 如果有 hreflang、分頁 rel 或 RSS，其中的 URL 也要跟着換。

迁移後：用日誌和抽样驗證效果

迁移完成後，收錄的變化通常不是一瞬間發生的，會出現一段新舊並存期。判断是否正常，比盯着 site 指令更可靠的办法是看服務器日誌：

• 新域名下爬虫訪問量是否在缓慢上升，而不是只在迁移当天来一波。
• 舊域名收到的請求里，301 命中比例是否在逐步下降。
• 是否有大量 404、5xx，或者本该跳轉的地址返回了 200 但内容為空。
• 抓取是否落在你希望保留的頁面上，而不是被參數頁、失效頁占满。

再抽一小批迁移前有稳定訪問的 URL，逐條检查：打開是否落到正确頁面、狀態碼是否符合预期、canonical 是否自指、内鏈是否已更新。抽样几十條通常就能發現系統性問题。

几個常见的誤判

第一，把“跳轉生效”当成“收錄完成”，其實索引替換還需要時間。第二，迁移後舊站仍可訪問，又希望新站被優先收錄，结果两套内容長期並存。第三，看到收錄數下降就急着大改，實际上迁移後的波動属于正常過程，應该先看日誌和狀態碼，再决定要不要調整。

迁移的难点不在技術動作本身，而在于舊结构留下的痕迹太多。把映射、内鏈、sitemap、跳轉這几處保持同一口径，剩下的就是按节奏观察，不必用額外手段去催。