換 URL 等于換身份
搜尋引擎的索引是按 URL 逐條记錄的。站点改版換域名、調整目錄结构、把參數頁改成静態頁之後，同一個頁面在新地址上對你来说是老頁面，對搜尋引擎来说是全新 URL。舊地址上的抓取歷史和已有记錄不會自動搬過去，需要你用跳轉和連結明确交接。
所以迁移期要同时做两件事：让舊 URL 把用戶和爬虫送到新 URL；让新 URL 尽早被發現、被抓取、被重新判断内容。只做前者，收錄會拖很久；两件都不做，舊 URL 會陆續掉出索引，新 URL 又迟迟進不来。
先做一張靠谱的映射表
映射表是整次迁移的底稿，做不好後面全是返工。
- 尽量一對一。舊 A 對應新 A，舊 B 對應新 B。整站跳首頁會让大量舊 URL 指向同一目标，等于主動制造重复入口，用戶也找不到内容。
- 不要跳轉鏈。舊地址到中間頁再到新地址，两跳以上會拖慢抓取，也削弱交接效果。舊 URL 直接 301 到最终地址。
- 区分该跳和该删。确實下线的頁面用 404 或 410，不要把每一個舊 URL 都往新站首頁導。
- 统一 URL 寫法。大小寫、结尾斜杠、參數顺序、http 與 https，趁迁移一次性收敛成一種形式。
301 只是交接的一半
内鏈和導航先改
站内所有指向舊地址的連結都要替換成新地址，包括導航、面包屑、列表頁和正文里的相關連結。否則爬虫會一直從内鏈走到舊 URL，再靠跳轉绕到新 URL，白白多走一层。
sitemap 與提交入口
新站發布後尽快产出新的 sitemap，只放新 URL，並且只放可索引的頁面。舊 sitemap 不必立刻刪除，可以保留一段時間，让爬虫繼續從舊地址被引導過去。平台上的站点驗證與提交入口也要同步到新域名。
新頁面自己声明自己
新 URL 上的 canonical 應该指向自身。迁移期最常见的疏漏，就是頁面換了域名，但 canonical、og:url、结构化資料里的地址還停留在舊站，等于让新頁面主動認领舊身份。
舊站要不要繼續保留
如果舊域名還能訪問，保留 301 一段時間是常见做法，跨度往往在几個月以上，具体取决于站点規模與抓取频率。跳轉层長期存在本身不是問题，前提是它稳定、直達、不返回 5xx。
迁移期容易踩的几個坑
- 用 302 或 JS 跳轉代替 301，信号传递弱，收敛更慢。
- 新站上线时忘了去掉測試阶段的 robots 屏蔽或 noindex 标记，爬虫進不来。
- 跳轉過程中丢失參數，導致原本带參數的頁面全部落到同一個地址。
- 新舊两套 URL 長期同时可訪問且内容相同，形成重复。
- 只處理了 HTML 頁面，忽略了图片、附件、PDF 等资源的地址。
迁移不是一次操作，而是一段观察期。上线後舊 URL 還會被持續抓取，索引里的记錄會逐步替換，中間出現新舊混排属于正常現象。
上线後的自查顺序
先確認新 URL 是否被抓取、是否進入索引，再看舊 URL 上的抓取是否已经指向新地址。把服務端日誌和索引报告對照着看，比只盯某一邊更容易定位問题。如果某一批目錄始终没有新 URL 進索引，優先检查這批頁面的跳轉是否可達、站内連結是否已经更新。
規模較大的站点可以按目錄分批迁移，一次處理一块，每块走完“跳轉—内鏈—sitemap—观察”的流程再動下一块。分批的好處是出問题时影响面可控，也更容易把原因归到具体的改動上。