網站遷移怎麼做才不把 SEO 一起遷沒：從換主機、換 URL 到換域名的完整執行順序（2026）
網站遷移最怕的不是上線當天出錯，而是把換主機、換 URL、換域名、換平臺混成一次動作，最後掉了流量卻找不到原因。本文按 Google 官方遷移邏輯，系統講清網站遷移怎麼做，哪些動作必須拆開，哪些驗證不能省。
網站遷移最怕的不是上線當天出錯，而是把換主機、換 URL、換域名、換平臺混成一次動作，最後掉了流量卻找不到原因。本文按 Google 官方遷移邏輯，系統講清網站遷移怎麼做，哪些動作必須拆開，哪些驗證不能省。
網站改版最容易出問題的，不是“新設計好不好看”，而是你到底改了什麼。對 SEO 來說，換設計、換主機、換平臺、換 URL、換域名，風險完全不是一回事。很多團隊把這些動作捆在一次上線裡，結果一旦流量掉了，根本分不清到底是哪一步出了問題。
Google 當前關於 site move with URL changes 和 site move with no URL changes 的文件，其實已經把最關鍵的原則說得很明確：能分步就分步，一次儘量只改一類變數；如果是 URL 變化，就先把 old-to-new 對映和重定向策略做對；如果只是換主機或 CDN、使用者可見 URL 不變，就按 hosting 遷移的邏輯處理，不要把兩類問題混在一起。
所以，這篇文章不再按那種泛泛的“改版前、改版中、改版後”老模板來講，而是先把改版型別拆開，再給你一套更接近 Google 官方文件的遷移順序。這樣做的好處是：你不僅更容易避免掉排名，也更容易在出問題時快速定位。
不是所有“網站改版”都叫同一種遷移。至少可以先分成這 4 類：
Google 在官方文件裡把這件事分得很清楚：如果使用者可見 URL 發生變化，就看 site move with URL changes；如果只是換 hosting 基礎設施，URL 不變，就看 site move with no URL changes。這一步一定要先分清，因為它決定了你後面該不該做 URL 對映、301/308 重定向、Change of Address 等動作。
| 遷移型別 | 最關鍵動作 | 最容易犯的錯 |
|---|---|---|
| 僅換主機/CDN | 保可訪問性、控 DNS、查日誌 | 誤以為不用做任何上線驗證 |
| 僅改 URL 結構 | 補對映、做永久重定向、改內鏈 | 把很多舊頁都跳到首頁 |
| 換域名 | 一對一遷移、提交 Change of Address | 舊域名過早停用 |
| 平臺+URL 同時改 | 拆變數、全鏈路驗收 | 設計、內容、結構一次全換 |
這是 Google 在 site move 文件裡反覆強調的核心原則之一：change only one thing at a time。如果你要換域名、換 CMS、換頁面結構、順便重寫內容，最好拆開做，而不是壓成一次“大升級”。Google 的遷移建議和 launching a redesigned or migrated site 裡的上線清單，本質上講的是同一件事：變數越多，驗證越難。
原因很簡單：
更合適的做法通常是：
如果你的網站規模不大，卻還要一次性把所有東西都換掉，那至少要接受一個現實：這不是“常規改版”，而是高風險遷移專案。
Google 官方文件在“Determine your old URLs”部分給了很實用的方向：先看 sitemap、伺服器日誌、analytics 和 Search Console 裡真正重要的頁面，再建立對映。也就是說，遷移前你最該做的不是“匯出全站然後鬆一口氣”，而是先識別哪些 URL 最不能掉。像 Performance report、URL Inspection 和日誌資料，放在一起看才更有用。
優先順序更高的頁面通常包括：
如果你們站已經在用 Search Console 和日誌分析，建議把這些資料交叉起來看：
| 資料來源 | 遷移前看什麼 | 為什麼不能漏 |
|---|---|---|
| Search Console | 高展示、高點選、高價值頁面 | 避免把真正拿流量的 URL 當普通頁處理 |
| Analytics | 落地頁、轉化頁、詢盤頁 | 避免只保 SEO，不保商業結果 |
| 日誌 | Googlebot 抓取頻率、狀態碼 | 能看出哪些頁本來就被重點抓 |
| Sitemap | 計劃保留的 URL 集 | 能發現對映缺口和遺漏頁 |
這也是為什麼在做遷移前，先讀一遍SEO 資料分析清單和伺服器日誌分析指南，會比只靠肉眼列頁面穩得多。
如果你的遷移涉及 URL 變化，那麼最關鍵的基礎檔案就是對映表。Google 的 URL move 文件要求很清楚：先列出 old URLs，再決定 each old URL should redirect to which new URL，然後按對映去部署重定向。
一個合格的對映表，至少要回答這 3 件事：
這裡最常見的錯誤不是“沒有做重定向”，而是做了錯誤的重定向，例如：
Google 在 site move 文件裡明確提醒過：不要把很多 old URLs 重定向到一個不相關的目標，比如首頁，這可能被當成 soft 404。只有當多箇舊頁面被合理合併進一個新頁面時，才適合做這種彙總式重定向。相關邊界，最好一起對照 redirects and Google Search 和 HTTP status and network errors 一起看。
| 舊 URL 現狀 | 更合適動作 | 不建議怎麼做 |
|---|---|---|
| 新站有明確等價頁 | 301/308 到最相關新頁 | 統一跳首頁 |
| 多頁合理合併 | 跳到合併後的核心頁 | 跳到無關目錄頁 |
| 內容已下線且無替代 | 返回 404/410 | 為了“保權重”亂跳 |
| 測試頁/低價值舊頁 | 按規則清理 | 照搬進新站繼續膨脹 |
Google 在 site move 和 redirects 文件裡給的建議很直接：如果技術上可行，優先使用 server-side permanent redirects，也就是 `301` 或 `308`。這類訊號對遷移最穩。
執行時要注意 4 個點：
Google 現在的文件也明確說了，雖然 Googlebot 可以跟隨更長的 redirect hops，但仍然建議直接跳最終頁；如果實在避免不了，鏈條也應該儘量低，理想上不超過 3 跳。因為鏈式重定向不僅影響抓取，也會拖慢真實使用者訪問。上線後也可以配合 Page indexing report 看是否開始出現大量 soft 404 或異常狀態。
這一步是很多團隊改版後才意識到的問題。Google 在 site move 文件裡專門提到：images、videos、downloads、JavaScript、CSS 這些嵌入資源，也要納入遷移計劃。因為它們本身可能在拿搜尋流量，也可能直接影響新頁面的抓取、渲染和體驗。尤其如果新站前端輸出和舊站不一樣，最好再對照 JavaScript SEO basics 和 structured data intro 複查一遍。
同時，遷移時還要一起檢查這些訊號：
rel="canonical" 是否都已改成新 URL。hreflang 是否都已指向新 URL。很多站點改版後排名掉，不是因為“Google 不喜歡新設計”，而是因為 canonical 還在指舊地址、站內連結沒改、模板把主內容擠下去了，或者資原始檔路徑根本沒遷完整。
Google 在 URL move 和 hosting move 兩類文件裡都特別提醒了同一類錯誤：開發環境裡為了避擴音前索引而加上的 `noindex`、robots block，如果忘了撤，遷移會直接卡關。這類問題比“內容質量”更先影響結果。
如果你們是換主機而非換 URL，還要額外注意 DNS 相關步驟。Google 的 hosting move 文件建議：至少提前一週把 DNS TTL 降到較低值，例如幾個小時，這樣切換時傳播會更快。同時，上線前要確認新環境沒有防火牆或 DoS 配置誤傷 Googlebot。
Google 在 site move 文件裡明確建議：舊站和新站相關 property 都要提前驗證，包含你實際會用到的各類變體。對域名遷移來說，這一步尤其重要，因為後面你還需要用到 Change of Address 工具。
更合適的做法是：
如果是域名或子域名變更，Google Search Console 文件也明確說明：Change of Address tool 可以告訴 Google 這是一個站點遷移。但如果只是 HTTP → HTTPS，則不需要使用這個工具。相關說明可以直接看 Change of Address 和 About Search Console。
Google 對遷移後的預期其實很現實：可見度會波動，這是正常的；中型站點通常需要幾周時間讓大多數頁面完成遷移，更大的網站可能更久。所以，遷移後的監控重點不是“今天某個詞掉了沒”，而是看遷移過程是不是在正確推進。
更值得看的監控項包括：
如果你只有少量關鍵頁需要補抓，可以用 URL Inspection 請求重新抓取；但如果是大規模遷移，Google 官方建議仍然是以 sitemap 為主，因為 sitemap 對大量 URL 的發現更有效。這個動作和 Sitemaps overview、ask Google to recrawl 一起用，思路會更清楚。
Google 在 site move 文件裡給出了很明確的時間建議：redirects 儘量保留至少 1 年，從使用者角度甚至可以更久。同時，Google 也建議儘快更新自己的 internal links，以及外部高流量連結、社媒資料頁和廣告落地頁。
這背後有兩個原因：
也就是說，301 不是終點，而是遷移期的緩衝層。真正更好的狀態，還是讓站內系統、導航、正文內鏈和外部關鍵資料都直接指向新地址。
這種情況不要把它當成 URL 遷移。更關鍵的是：
Google 也提到，這類 hosting move 之後，Googlebot crawl rate 先暫時下降、再逐步恢復甚至升高，是正常現象。
這類遷移最容易被低估。真正決定成敗的通常是：
如果還要順便換設計，建議把主題或模板測試放到遷移前獨立完成，而不是留到上線當天一並發現問題。
這是風險最高的一類，因為你不僅在改 URL，還在改站點身份。更穩的順序通常是：
不要以為“全站 301 到新首頁”就算換域名完成了。對 Google 和使用者來說，那通常只是更糟的錯誤頁體驗。
正常。Google 官方明確說，重要站點變更後排名會臨時波動。關鍵不是有沒有波動，而是重定向、抓取、索引和新 URL 替換過程是否在正常推進。
Google 當前建議是儘量至少保留 1 年。從使用者體驗角度，能長期保留更穩，但同時也要儘快把內部連結和高價值外部連結直接改成新地址。
不應該。Google 明確提醒過，把大量舊 URL 跳到不相關首頁可能被視為 soft 404。正確做法是一對一跳到最相關的新頁面；確實刪除且無對應內容的頁面，則返回合適的 404 或 410。
不用。如果使用者可見 URL 沒變化，這類遷移重點不在重定向，而在 DNS、抓取可訪問性、移除開發期遮蔽，以及新舊伺服器日誌監控。
如果只是少量關鍵頁，可以用 URL Inspection 請求重新抓取；但大規模遷移時，更重要的是提交 sitemap，因為 Google 官方明確說 sitemap 對站點啟動或 site move 時的大量 URL 發現更有幫助。
真正穩的網站遷移，不是上線當天“沒報錯”就算完成，而是舊 URL、重定向、新 URL、抓取、索引和內部結構這條鏈路全都接上。只要這條鏈路斷一段，掉的就不只是幾個排名，而是你過去積累的整套搜尋訊號。