網站搬家、改網址、換網域，不掉排名的遷移檢查清單

本文重點

• 不是所有遷移風險都一樣。只改主機、不動網址的搬家風險最低；換網域加上重整 URL 結構同時進行，才是最容易整站掉排名的高風險組合。
• 遷移成敗的關鍵在前置作業：完整盤點現況、做好可回滾的備份、並產出一張「舊網址對舊網址」的網址對應表（URL mapping），這張表決定了 301 轉址做不做得對。
• 每個舊網址都要用 301 一對一轉到內容最相關的新網址，避免全部導回首頁、避免轉址鏈，上線當天要逐項驗證狀態碼、canonical、sitemap 與 robots.txt。
• 遷移後排名通常會先波動再回穩，用 GSC 變更網址工具加上涵蓋範圍報告監控；若兩三週後仍持續下滑，多半是轉址漏網、對應錯頁或舊版誤擋爬蟲所致。

網站遷移是 SEO 工作裡風險最高、最不能憑感覺操作的一種。無論你是要把網站搬到新主機、把 HTTP 升級成 HTTPS、重整整個網址結構，還是直接換一個全新網域，只要中間有一個環節沒接好，過去累積好幾年的排名與流量都可能在上線當天瞬間蒸發。這篇文章會用清單與表格的方式，帶你把遷移流程從頭到尾走一遍，盡量讓排名波動可控、可預測、可復原。

一、網站遷移為什麼最容易掉排名，先分清哪幾種遷移風險最高

結論先講：**遷移會不會掉排名，取決於你同時改了幾個變數。**搜尋引擎是靠網址（URL）來辨識與累積每一個頁面的排名訊號，遷移本質上就是在改動網址或網址背後的內容、伺服器與協定。改動的變數愈多、愈同時發生，Google 要重新理解你整個網站所需的時間就愈長，排名波動的幅度也愈大。

Google 在官方文件裡把網站搬遷明確分成兩大類：網址有變更的網站搬遷，以及網址沒有變更的網站搬遷。這個分法非常實用，因為它直接對應到風險高低與要做的事完全不同。

（一）六種常見遷移類型與風險分級

把實務上常見的遷移情境攤開來看，風險高低一目了然。下表的「風險」指的是排名與流量短期下滑的可能性與幅度。

遷移類型	網址是否改變	風險等級	核心動作
換主機／搬伺服器（網址不變）	否	低	確認 DNS、IP、狀態碼一致，內容不變
HTTP 升級 HTTPS	是（協定改變）	中低	全站 301 轉到 https，更新內部連結與 canonical
改版重設計（網址不變）	否	中	確認模板、結構化資料、內部連結不掉
改版加重整網址結構	是	高	建網址對應表，逐頁 301
換網域（內容網址結構不變）	是（網域改變）	中高	全站 301，GSC 變更網址工具
換網域＋重整網址結構	是（網域＋路徑都變）	最高	逐頁 301＋對應表＋分階段上線

從表中可以看出一個關鍵原則：**能不要同時改的變數，就不要同時改。**最危險的就是最後一列，網域和 URL 結構同時換，等於把網站的每一個頁面身分都重置一次，任何一頁的對應出錯都可能造成局部流量歸零。

（二）只搬主機、不動網址是最安全的遷移

如果你只是把網站從一台伺服器搬到另一台、或是換虛擬主機商，而網址（包含網域、路徑、檔名）完全沒變，那這在 SEO 上幾乎是無痛的。Google 在「網址沒有變更的網站搬遷」文件裡說得很清楚，這種情況下你要顧的是內容與回應的一致性：搬完之後同一個網址回傳的內容要一樣、狀態碼要一樣是 200、伺服器速度不要變慢、結構化資料不要掉。

這種遷移最容易被忽略的反而是技術細節，例如 DNS 的 TTL（Time To Live）沒有提前調短，導致切換期間部分使用者與爬蟲還連到舊主機；或是新主機的伺服器設定不同，把原本 200 的頁面誤回成 500。所以即使是低風險遷移，上線後仍要抽查狀態碼。

（三）換網域與重整網址結構是高風險遷移的核心

只要網址會變，你就進入了「網址有變更的網站搬遷」這個高風險領域，換網域與網址搬遷（重整 URL 結構）是其中最典型的兩種。這兩種情況的共同要求是：舊網址必須透過 301 永久轉址，一對一地指向內容最相關的新網址，並且讓搜尋引擎有足夠時間重新爬取與處理整批轉址。

值得提醒的是，這類遷移即使每一步都做對，短期內排名出現波動仍是正常現象。Google 需要重新爬取、處理轉址、更新索引，這個過程通常需要數週到數個月不等，網站規模愈大、頁面愈多，所需時間愈長。理解這點，才不會在上線後第三天就因為流量微跌而恐慌性回滾。

二、遷移前的準備，盤點現況、完整備份與建立網址對應表

結論先講：**遷移的成敗，八成在上線前就決定了。**遷移當天的操作只是執行，真正困難且決定排名能不能保住的，是前置的盤點、備份與網址對應表。這一階段做得愈紮實，上線後要救火的機率愈低。

（一）遷移前必須盤點的現況清單

在動任何東西之前，先把現況完整記錄下來，這是日後比對「遷移有沒有掉東西」的唯一基準。建議逐項勾選完成：

• 用爬蟲工具（如 Screaming Frog）爬完整站，匯出所有可索引網址清單
• 從 Google Search Console 匯出「成效報告」近 3 至 6 個月的所有著陸頁與查詢，記下高流量頁面
• 匯出 GSC「涵蓋範圍／網頁索引」狀態，記錄目前有多少頁被索引
• 盤點目前的 sitemap.xml 與 robots.txt 內容
• 記錄每頁的 title、meta description、H1、canonical 標籤現況
• 盤點站內既有的 301／302 轉址規則，避免遷移後產生轉址鏈
• 記錄目前的結構化資料（schema）類型與覆蓋頁面
• 從 GA4 匯出近期自然搜尋流量基準，作為遷移後比對用

這份盤點的核心目的有兩個：一是找出最值錢的頁面（高流量、高排名、多外部連結指向的頁面），這些頁面在對應表裡要優先確認、絕不能出錯；二是建立基準線，讓你在遷移後能客觀判斷「掉的是正常波動還是真的出問題」。

（二）做一份可回滾的完整備份

備份不只是「以防萬一」，而是遷移計畫的必要組成。如同 Ahrefs 在網站遷移指南中強調的，你必須準備一個「萬一出大事可以回滾」的方案。實務上至少要備份：

• 舊站的完整檔案與資料庫（可在新站出問題時快速還原）
• 舊站完整的網址清單與其對應內容（對應表的來源）
• 現行的伺服器設定檔（.htaccess、nginx 設定、轉址規則）
• DNS 設定的現況快照

關鍵在於：**舊網域與舊主機在遷移後不要立刻退租。**換網域時，舊網域至少要保留半年以上、甚至更久，因為 301 轉址必須持續有效，Google 才能把權重穩定轉移到新網域。太早把舊網域放掉，所有轉址會一次失效，等於把累積的排名直接斷頭。

（三）建立網址對應表是整個遷移的地基

網址對應表（URL mapping）是遷移工程裡最重要的一份文件，它列出每一個舊網址，以及它在新站上應該對應到哪一個新網址。301 轉址規則就是照這張表寫出來的，表錯了，轉址就全錯。

一張合格的對應表至少包含以下欄位：

欄位	說明
舊網址	遷移前的完整 URL
新網址	遷移後內容最相關的完整 URL
對應類型	一對一／合併／已刪除
頁面重要性	依流量與排名標記高／中／低
轉址狀態	待設定／已設定／已驗證

製作對應表時要把握幾個原則。第一，盡量做到一對一對應，舊的某一頁就對到新的某一頁，內容主題要一致。第二，不要偷懶把全部舊網址都轉到首頁，這是遷移最常見也最致命的錯誤，後面會專門講。第三，對於確實要刪除、沒有對應內容的頁面，要明確決定它的命運（轉到最相近的分類頁，或直接回傳 410，詳見 HTTP 狀態碼指南），而不是放著不管變成 404。

三、301 轉址與網址對應的正確做法

結論先講：**遷移的權重能不能保住，幾乎全押在 301 轉址有沒有做對。**只要網址有變，301 永久轉址就是把舊網址的排名訊號傳遞到新網址的唯一正規手段。做對了，權重平順轉移；做錯了，輕則部分流失，重則整站排名重置。

（一）為什麼遷移一律用 301、而不是 302

301（Moved Permanently）告訴搜尋引擎「這個網址永久搬到新位置了」，Google 會把舊網址的排名訊號傳遞給新網址，並逐步用新網址取代搜尋結果裡的舊網址。302（Found／暫時轉址）則代表「只是暫時轉走，舊網址之後還會用」，搜尋引擎會保留舊網址在索引中。

遷移是永久性的動作，所以一律用 301。如果遷移時誤用 302，Google 可能持續保留舊網址、不把權重轉移到新網址，造成排名長期卡住或混亂。關於兩者的判斷細節，可參考 301、302、Canonical 怎麼選 這篇的完整拆解。Google 的301 轉址官方文件也建議，永久性的網址變更應使用伺服器端的 301 轉址。

（二）伺服器端轉址的常見設定方式

301 轉址應該在伺服器端完成，而不是用 JavaScript 或 meta refresh，因為伺服器端轉址最快、最明確，爬蟲一定看得到。常見環境的設定位置如下：

伺服器／環境	設定位置	說明
Apache	.htaccess	用 Redirect 或 RewriteRule
Nginx	站台 conf	用 return 301 或 rewrite
Cloudflare	Bulk Redirects／Rules	適合大量規則或整站轉址
WordPress	外掛或主機面板	小量可用外掛，大量建議寫進伺服器設定

換網域且網址路徑結構完全不變時，可以用一條通用規則把整個舊網域對應到新網域（同路徑搬移）；但只要路徑結構有變，就必須依照對應表逐條設定，沒有捷徑。

（三）三個會吃掉權重的轉址錯誤

以下三種錯誤是遷移時權重流失的主因，務必避開：

1. 全部轉到首頁：把所有舊網址無差別 301 到新首頁，Google 會把這類大量「不相關轉址」視同軟性 404（soft 404），幾乎不傳遞權重，等於那些頁面的排名直接放棄。一定要轉到內容相關的對應頁。
2. 轉址鏈（redirect chain）：A 轉到 B、B 又轉到 C。轉址鏈會拖慢爬取、稀釋權重，過長甚至會讓爬蟲中斷跟隨。正確做法是讓 A 直接轉到最終的 C，把中間節點消掉。
3. 轉址迴圈（redirect loop）：A 轉到 B、B 又轉回 A，頁面直接無法開啟。上線前一定要用工具掃過所有轉址，確認沒有迴圈。

Moz 在其轉址（redirection）說明中也指出，正確使用 301 是保住搜尋權益的關鍵，而錯誤的轉址設定則是遷移流量損失的常見來源。

（四）別忘了同步更新 canonical 與內部連結

301 只是讓舊網址指向新網址，遷移後新站內部的設定也要一起到位，否則會自相矛盾。請確認：新頁面的 canonical 標籤指向自己的新網址（而非還殘留舊網址）、站內的內部連結直接指向新網址（而非指向會被轉址的舊網址，徒增轉址跳轉）、以及 hreflang 標籤（若為多語系站）也更新成新網址。多語系站的 hreflang 在換網域時特別容易出錯，細節可參考 hreflang 繁中實作指南。

四、遷移上線當天的逐項檢查清單

結論先講：**上線當天不是憑感覺按下發布，而是照清單逐項驗證。**遷移上線是高度流程化的工作，每一項都要實際驗證通過，而不是「應該沒問題」。建議把這份清單印出來，做完一項勾一項。

（一）上線前最後確認（部署前）

在正式對外切換之前，先在新站（測試環境或預備上線狀態）確認：

• 對應表內每一條轉址規則都已設定完成
• 抽查高流量頁面的轉址，舊網址 301 後確實到達正確新網址
• 新站的 robots.txt 沒有殘留測試環境的 Disallow: /（這是最致命的低級錯誤）
• 新站頁面的 canonical 指向自己的新網址
• 新站可正常被爬取，重要頁面回傳 200
• 新版 sitemap.xml 已產出，內含全部新網址、不含舊網址
• HTTPS 憑證有效，全站走 https、無混合內容警告

（二）上線當天驗證（部署後）

實際切換、新站對外之後，立即驗證：

• 隨機抽查一批舊網址，用工具確認回傳 301（而非 302、404 或 200）
• 確認沒有轉址鏈與轉址迴圈
• 首頁、主要分類頁、高流量內容頁皆可正常開啟並回傳 200
• 結構化資料（schema）在新頁面仍正常、無錯誤
• 內部連結點擊後直達新網址，不經過多餘跳轉
• 行動裝置版面正常、頁面載入速度未明顯惡化

（三）上線後立刻在 GSC 要做的事

新站上線後，搜尋引擎相關設定要馬上跟上，不要拖：

• 若為換網域：在舊網域的 GSC 資源使用「變更網址工具」，把搬遷告知 Google
• 為新網域／新網址在 GSC 建立並驗證資源（HTTP 升 HTTPS 時，https 是不同資源，要另外驗證）
• 在新資源的 GSC 提交新版 sitemap.xml
• 暫時保留並提交舊版 sitemap，強制 Google 去爬舊網址、更快發現 301 訊號（待轉址被充分處理後再移除）
• 在 GSC 用「網址檢查」工具抽測幾個重要新網址，確認可被索引

把舊 sitemap 暫時留著提交，是加速遷移被 Google 處理的實用技巧：它主動把舊網址餵給爬蟲，讓 Google 更快撞上你的 301 規則，從而加速整批權重轉移。

五、遷移後的監控，用 GSC 與流量數據確認排名復原

結論先講：**遷移不是上線就結束，而是進入觀察期。**遷移後排名通常會先波動再回穩，你的工作是用數據持續監控，分辨「正常波動」與「真的出事」，並在出事時及早發現。建議把觀察期拉長到至少 4 到 8 週。

（一）遷移後要盯的核心指標

監控的重點不是看單日流量起伏，而是看趨勢與結構性變化。以下指標來源與用途整理如下：

指標	來源	看什麼
索引涵蓋範圍	GSC 網頁索引報告	新網址被索引數量是否穩定上升、舊網址是否逐漸退出
自然點擊與曝光	GSC 成效報告	整體曲線、重點頁面查詢排名是否回穩
轉址錯誤	GSC＋爬蟲工具	是否冒出 404、轉址鏈、伺服器錯誤
自然搜尋流量	GA4	與遷移前基準線比對
頁面體驗	GSC＋Core Web Vitals	新站速度與穩定度是否退步

（二）排名復原的合理時間預期

遷移後的數據曲線通常會經歷三個階段：上線後一兩週先下滑（Google 正在重新爬取與處理轉址），接著進入波動回升期，最後逐步回到甚至超過原本水準。整個排名復原過程，小型網站可能兩三週見明朗，中大型網站往往要一到三個月。

判斷是否正常有個簡單原則：看趨勢方向而非單日數字。如果索引中的新網址數量穩定增加、舊網址數量穩定減少、整體曝光在波動中緩步回升，那就是健康的遷移,耐心等待即可。反之，如果上線兩三週後流量仍持續單向下滑、看不到任何回升跡象，就要進入下一段的診斷流程。

（三）善用 GSC 的逐頁比對找出失血頁

當總流量下滑時，不要只看總數，要鑽進 GSC 成效報告逐頁比對遷移前後：哪幾個頁面的點擊掉最多？把這些頁面拉出來對照當初的網址對應表，逐一檢查它們的舊網址是否正確 301 到了對的新頁、新頁是否被正常索引。問題幾乎都集中在少數幾個頁面上，逐頁比對能讓你快速定位失血點，而不是大海撈針。

六、遷移常見錯誤與救援，排名掉了怎麼診斷與回補

結論先講：**遷移後排名大跌，先別急著全部回滾，先照順序診斷。**多數遷移事故的根因都集中在幾個可預期的地方，按部就班排查通常能在短時間內找到並修復。回滾是最後手段，不是第一反應。

（一）遷移掉排名的診斷順序

當遷移後出現明顯且持續的流量下滑，依照以下順序由最致命、最常見往下查：

1. 檢查 robots.txt 與 noindex：第一個要看的就是新站的 robots.txt 是否誤留 Disallow: /，或頁面是否殘留測試環境的 noindex 標籤。這是最常見、影響最大、也最容易修的災難。
2. 驗證 301 轉址是否生效且正確：抽查（尤其是高流量頁）舊網址是否真的 301 到對的新頁，而不是 404、302 或被轉到首頁。
3. 掃描轉址鏈與迴圈：用爬蟲工具全站掃一遍，找出多重跳轉與迴圈並改成一步到位。
4. 確認 canonical 沒有指錯：新頁的 canonical 是否誤指回舊網址，導致 Google 不索引新頁。
5. 比對內容是否掉了：新站頁面的主要內容、title、H1、結構化資料是否相較舊站有缺漏。
6. 檢查 sitemap 與 GSC 設定：新 sitemap 是否提交、是否還在送舊網址、變更網址工具是否有送出。

（二）常見錯誤與對應修法

把上述診斷對應到具體修法，整理成一張速查表：

症狀	可能原因	修法
整站幾乎不被索引	robots.txt 擋全站／全站 noindex	移除 Disallow: /、拔掉 noindex，GSC 重新檢查
個別頁面掉光排名	舊網址沒轉址或轉錯頁	依對應表補上正確的一對一 301
流量緩慢流失、權重不集中	轉址鏈過長	改成舊網址直接轉到最終新網址
新頁不被索引	canonical 指回舊網址	改為 self-canonical 指向新網址
排名長期卡住不轉移	誤用 302 暫時轉址	全部改成 301 永久轉址
大量頁面被當 soft 404	全部轉到首頁	改轉到內容相關的對應頁

（三）什麼時候該回滾、什麼時候該等

回滾（rollback）是把網站還原到遷移前狀態的最後手段，代價高、也會再造成一次波動，因此判斷要謹慎。原則上，只有在出現「結構性致命錯誤」且短時間內無法修復時才考慮回滾，例如整站無法被索引、新站大規模回傳伺服器錯誤、或對應表根本性錯誤導致無法逐項補救。

反之，如果只是排名在合理範圍內波動、索引數量在緩步轉移、問題能定位到少數頁面並逐一修復，那就不要回滾，照診斷清單修正後耐心觀察。遷移本來就需要時間讓 Google 重新理解網站，過早回滾反而會讓搜尋引擎在新舊版本間反覆,延長整體的不穩定期。這也是為什麼前置的備份與對應表如此重要：它們既是回滾的本錢，也是讓你有底氣「不急著回滾」的依據。

七、常見問題 FAQ

（一）網站遷移後多久排名才會回穩？

沒有固定天數，但有合理區間。小型網站（數十至數百頁）通常 2 到 4 週可看出回穩趨勢；中大型網站（數千頁以上）則常需 1 到 3 個月。判斷重點不是看單日流量，而是看趨勢：只要 GSC 裡新網址的索引數量穩定上升、舊網址穩定退出、整體曝光在波動中緩步回升，就代表遷移健康，耐心等待即可。若兩三週後仍是單向下滑且毫無回升跡象，才需要進入診斷流程。

（二）換網域時，舊網域可以馬上退租嗎？

不行，這是換網域最危險的地雷之一。301 轉址必須持續有效，Google 才能把權重穩定地從舊網域轉移到新網域，而這個過程需要數週到數個月。如果太早把舊網域放掉，所有 301 轉址會一次全部失效，等於把累積的排名直接斷頭。建議舊網域至少保留 6 個月以上，確認 GSC 中流量與索引已穩定轉移到新網域後，再評估是否釋出。

（三）HTTP 升級 HTTPS 算是網站遷移嗎？需要做哪些事？

算，這在 Google 眼中屬於「網址有變更」的搬遷，因為協定（http 對 https）改變了，等於整站網址都變了。要做的事包含：全站 http 網址 301 轉到對應的 https 網址、更新所有內部連結與 canonical 為 https、處理混合內容（mixed content）警告、在 GSC 另外建立並驗證 https 資源（http 與 https 是不同資源）、並提交新的 sitemap。雖然風險比換網域低，但漏做轉址或留下混合內容，一樣會掉排名。

（四）所有舊網址都轉到新首頁，這樣不行嗎？

非常不行，這是遷移最致命的錯誤之一。把大量不相關的舊網址全部 301 到新首頁，Google 會把這類轉址視為軟性 404（soft 404），幾乎不傳遞任何權重，等於那些頁面累積的排名全部放棄。正確做法是依照網址對應表，讓每個舊網址一對一轉到內容主題最相關的新頁面；只有當某頁真的沒有任何對應內容時，才考慮轉到最相近的分類頁，或乾脆讓它回傳 410。

（五）遷移後發現流量大跌，第一步該檢查什麼？

第一步永遠先查 robots.txt 和 noindex。最常見的災難就是上線時把測試環境的 Disallow: / 或頁面的 noindex 標籤一起帶到正式站，導致整站無法被索引，而這也是最容易修復的問題。確認索引沒被擋之後，再依序驗證 301 轉址是否生效且指對頁面、有沒有轉址鏈或迴圈、canonical 有沒有指錯。多數遷移事故的根因都集中在這幾個地方。

（六）小網站和大網站的遷移做法有差別嗎？

核心流程一樣（盤點、備份、對應表、301、驗證、監控），差別在規模帶來的策略調整。小網站頁面少，對應表可以手動逐頁做，甚至能一次全站上線。大網站頁面動輒上萬，建議優先確保高流量頁的對應萬無一失，轉址規則盡量用模式化規則（pattern）批次產生而非逐條手寫，並可考慮分階段、分區塊上線以降低一次性風險。網站愈大，Google 完成爬取與權重轉移所需的時間也愈長，觀察期要拉得更久。