WordPress 搬家完整指南：301 重定向與 SEO 轉移

品牌改名或整併網站時，可能需要將 WordPress 移到新網域。這會改變公開 URL，比只換主機多了轉址、canonical、內鏈與搜尋驗證工作。應盡量分開網域、主機及版型變更，降低同時排查多種問題的難度；即使準備完整，搜尋表現仍可能暫時波動。

這篇聚焦同時需要換主機與新網域的情境，說明備份還原、URL 對應、HTTPS、Search Console 及後續監控。沒有適用所有網站的恢復比例或時程，先盤點你的網址與業務流程，再安排切換。

你以為只是搬家，其實是兩件事疊在一起

絕大多數人把「WordPress 搬家」當成一個動詞，但其實它涵蓋了風險等級完全不同的兩種操作。搞不清楚自己站在哪一邊，是悲劇的起點。

如果你只是換主機、網域保留，那是相對安全的操作，Google 看到的網址一個都沒變，仍需確認可用性、檢索與內容未受影響，不能保證排名不變。這條路徑在另一篇 保留原網域的搬家教學 裡有完整拆解，需要的話先讀那篇。

換網域會改變文章、產品及其他公開內容的 URL。應用 301 或 308 永久轉址將舊 URL 對應到新位置，再更新 canonical、內部連結與 sitemap；搜尋系統會逐一重新檢索與處理，並非一換網址就把歷史全部清空。

資料搬移、URL 訊號與業務整合都需驗證。工具可協助複製內容及替換網址，但仍須處理轉址、權限、第三方回呼與監控，不能用固定半小時估算整站遷移。

為什麼「換網域」是 WordPress 站長最該敬畏的動作

Google 官方對「附帶網址變更的網站遷移」有明確的說明文件，而且開宗明義就講：這類遷移比單純換主機複雜得多，需要更長的準備與監控週期。官方之所以這麼謹慎，是因為換網域會同時動到好幾個排名訊號。

Google 需重新探索及處理舊、新 URL。永久轉址有助於確認遷移關係；Google 明確指出 301 等永久轉址本身不造成 PageRank 損失，但排名仍會受重新檢索、內容與其他變動影響，不等於保證保留所有排名。

外部網站的連結仍可能指向舊網域。維持有效轉址可協助訪客與爬蟲抵達新內容，並可請重要合作來源更新連結。Google 建議轉址保留至少一年，從使用者與舊連結角度看，通常可保留更久。

新網域也要查核過往用途、Search Console 手動處置與移除設定。不要把網域年齡或第三方評分當成 Google 公開的「體質分」；網域權重攻略介紹的第三方指標，不能直接代表 Google 的排名分數。

先問一個更狠的問題：這個網域真的非換不可嗎

換網域前先確認品牌、法律或營運理由，以及轉址與維護成本。沒有本案數據時，不宜宣稱遷移一定掉三成流量或必須花幾個月；應以自己的風險承受能力決策。

品牌改名、企業整併或原網址不再適用，可能構成換網域的理由；但不應把換網域當成清除手動處置、垃圾連結或網站品質問題的捷徑。先查明並修正來源問題，也要查核新網域的歷史。

但更多時候，換網域只是出於一時的念頭：覺得新網域比較短、比較好記、看起來比較酷。老實說，一個網址好不好記，對排名的影響遠遠比不上換網域帶來的排名風險。如果你的舊網域已經有穩定的自然流量、有累積的反向連結、有 Google 認得的歷史，只因為「想換個更好看的網址」就全部推倒重來，這筆帳怎麼算都不划算。

比較品牌與營運收益、遷移工作、長期轉址及可能的搜尋波動，再決定是否換網域。永久轉址本身不必然損耗 PageRank，也不能推論所有網站都會承受固定幅度的流量損失。

網站能打開只是遷移驗證的一部分。若轉址服務過早停用，舊連結與搜尋結果中的舊網址仍可能失效；應按使用與檢索紀錄維護，不要只因新站上線幾天就退掉轉址環境。

動手之前，先把三張表準備好

真正的工程，在動手之前就已經開始。建議你在碰任何外掛之前，先產出三份文件。這三份表，是你萬一中途出錯時唯一能救命的東西。

第一張：URL 對照表（1:1 對應清單）

盤點有內容、流量或外部連結的舊 URL，包含重要媒體與下載檔，再記錄新位置或退役方式。有等價新內容才永久轉址；已刪除且沒有替代內容的 URL，可回傳正確的 404 或 410，不必勉強指定新頁面。

第二張：資產盤點表

把網站「值錢的東西」全部列出來：流量最高的前 20 篇文章、帶來最多外部連結的頁面、有排名的關鍵字與對應網址、重要的結構化資料、第三方服務的串接（Analytics、Search Console、Pixel、SMTP、金流）。這份表的作用是讓你在搬家後，有一份「驗收清單」可以逐項核對，不用憑感覺猜網站正不正常。

第三張：回滾計畫

回復計畫應記錄備份位置、DNS、轉址、憑證及切換後新資料的處理方式。舊完整網站保留多久依復原需求決定，與舊網域轉址保留至少一年是不同問題；轉址可以遷至其他可靠服務，不必一直支付原主機方案。

第一步：把舊站完整打包，一份都不能少

備份不是這場工程的主角，卻是唯一不能省的底線。打包要包含兩大塊：伺服器上的所有檔案，以及完整的資料庫。很多人以為匯出文章 XML 就夠了，WordPress XML 匯出可含文章、頁面、自訂欄位、分類及選單等內容，但不是包含程式、完整設定與媒體檔案的整站備份。

檔案部分至少要涵蓋：wp-content 整個目錄（裡面有佈景主題、外掛、上傳的媒體）、.htaccess、wp-config.php。資料庫則要匯出完整的 SQL 檔，包含所有資料表。如果你用 UpdraftPlus 這類備份外掛，記得在設定裡勾選「包含檔案＋資料庫」，並且把備份檔下載到本機與雲端各一份。備份留在同一台主機上不算備份，主機掛了就一起陪葬。更完整的備份還原流程，可以看 WordPress 備份與還原指南。

這裡有一個值得反覆叮嚀的動作：備份完成後，一定要做一次還原測試。把備份檔在本機或一個臨時空間還原出來、確認能正常開啟。實務上常見的狀況是，站長以為自己有備份，出事那天才發現備份檔是壞的、或不完整。備份沒有經過還原驗證，就不算備份，只能算「一份心理安慰」。

首頁、文章、媒體與後台只是初步檢查，還要依網站用途驗證表單、會員、搜尋及沙盒交易。記錄備份版本、儲存位置、還原結果與所需時間，不能用四項抽查保證全部資料完整。

第二步：在新主機把站架起來，先別讓任何人看到

在新環境還原時，使用存取限制保護測試站，避免公開會員資料與重複內容；臨時網址或修改自己電腦的 hosts 不等於存取控制。另隔離正式郵件、付款及 webhook，待切換前再依計畫恢復。

把舊站備份還原到新主機之後，最關鍵的一步是資料庫裡的網域字串替換。WordPress 的資料庫裡，舊網域出現在成千上萬個地方：文章內文的連結、圖片網址、序列化陣列裡的路徑、外掛設定、選項資料表。如果你只改了 wp-config.php 裡的網址常數，前端看起來好像正常，但資料庫深處還藏著一堆舊網域，日後會爆出圖片破圖、內部連結指回舊站、重新導向迴圈這類疑難雜症。

正確的做法是用專門的搜尋取代工具（例如資料庫層級的 search-replace 腳本，或搬家外掛內建的取代功能），走的是序列化安全的取代。千萬別圖方便在 phpMyAdmin 裡直接對 SQL 做文字替換，那會破壞 PHP 序列化資料的長度標記，造成含序列化值的設定無法解析。先備份並使用支援序列化的工具預演取代，檢查表格範圍且避免盲目改動 GUID。若用外掛一站式處理，WordPress 搬家外掛評比 裡有幾款可以把「檔案搬移＋網域字串取代」一次做完的工具。

架好之後，逐一檢查：首頁正常、選單連結都指向新網域、圖片正常顯示、永久連結結構跟舊站一致。永久連結這件事要特別強調，它決定了新站的網址長什麼樣子，如果你在新站用的網址結構跟舊站不同，你的 URL 對照表會變成兩倍複雜。先把永久連結規則調成跟舊站一致，後面的 301 對應才會乾淨俐落，這部分的設定細節可以對照 永久連結 SEO 設定。如果你是第一次用這個新主機，順便確認 PHP 版本、記憶體上限、執行時間上限都符合你外掛的需求，避免搬家後某些功能因為主機環境差異而罷工。

第三步：畫出 301 重定向地圖，這是整件事的心臟

換網域時，301 重新導向對照表是重要環節，但成功與否也取決於網址盤點、canonical、內部連結、Sitemap、Search Console、伺服器設定與上線後監測。轉址應盡量維持新舊網址的一對一對應，不能將整站結果歸因於單一比例。

301 表示資源已永久移到另一個網址，瀏覽器通常會跟隨轉址。Google 的 遷移說明文件建議以永久伺服器端轉址，將舊 URL 對應到相關的新 URL；這是標準網址與遷移訊號，並不保證排名立即恢復。狀態碼的差異可看 301 與 302 轉址完整教學。

兩種寫法：逐筆對應 vs 規則式

如果你的舊站和新站的網址結構完全一致、只差網域本身（例如 old.com/a-post 對應到 new.com/a-post），那你可以用一條規則式 301，把所有請求整批轉過去：

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

以上是 Apache／相容 mod_rewrite 環境的範例，需置於適當的舊站規則位置；目前只匹配非 www 舊網域。使用前改成實際網域，另處理 www、HTTPS 憑證及特殊路徑，測試最終狀態與目的地；Nginx 或 CDN 應使用各自設定。

若同時改了路徑或合併內容，先整理 URL 對照表，再用伺服器、CDN 或合適工具產生規則。有等價替代頁才永久轉址；沒有相應內容的退役頁應回傳 404 或 410，不要為了「回收權重」一律轉到首頁。

301 地圖的三個地雷

在進入地雷之前，先用一個迷你範例讓你看懂「對應表」長什麼樣子。假設你的舊網域是 old-shop.com、新網域是 new-shop.com，而且你順手把其中一篇舊文章的網址結構也改了，你的對應表會類似這樣：

URL 對照表要涵蓋重要舊網址的處理結果，包括轉址、保留及退役；404 或 410 可以是正確的退役結果，並非每個舊網址都應被導向某個新頁面。

A 轉 B、B 再轉 C 會增加請求與延遲，也可能造成爬蟲追蹤問題。應讓舊網址直接抵達最終對應頁；不要宣稱每經過一層永久轉址就必定損失一部分 PageRank。

第二個地雷是忘了首頁與根路徑。很多人記得轉文章頁，卻忘了 old-domain.com 這個根網址本身也要 301 到新網域首頁。結果有人直接打舊網域、或舊網域的首頁出現在搜尋結果裡，卻沒有被轉過去。

第三個地雷是canonical 自相矛盾。新站如果還殘留指向舊網域的 canonical 標籤，等於一邊用 301 告訴 Google「內容搬到新網址了」，一邊又用 canonical 告訴 Google「權威版本還是舊網址」。這兩個訊號打架，Google 會困惑、排名轉移會卡住。上線前務必檢查每一頁的 canonical 都指向新網域自己。檢查的方法很直白：在新站隨機挑十幾個頁面，用瀏覽器檢視原始碼，找 rel="canonical" 那一行，確認網址開頭是新網域；如果你的 SEO 外掛有全站 canonical 設定，優先在那裡統一修正，比起逐頁手改更可靠。Canonical 的運作邏輯可以對照 Canonical URL 完整指南。

第四步：DNS 切換與 SSL，讓新網域正式接管

新站公開前需準備新網域的 DNS 與有效 HTTPS，舊網域的 HTTPS 轉址端也需有效憑證。具體順序取決於憑證驗證方式及主機支援，不是所有服務都能在網站 DNS 切換前完成 HTTP 驗證。

可用 DNS-01 或主機商支援的驗證流程，提早為正式新網域準備憑證；臨時網址的憑證不會自動涵蓋正式網域。若使用 HTTP-01，驗證請求必須能抵達正確伺服器。安排驗證與流量切換時，確認公開 HTTPS 已可用，詳細觀念見 SSL 憑證安裝指南。

提前降低 TTL 可加快之後取得的新 DNS 回應更新，但舊快取仍依原 TTL 到期，撤回也不保證立即完成。依原紀錄及供應商限制安排時程，300 秒只是範例；細節可對照 DNS 設定教學。

切換之後，用工具確認新網域真的指向新主機的 IP，而且 https 版本能正常開啟。順帶一提，如果你的站同時有 www 與非 www 版本、或 http 與 https 版本，記得只保留一個正規版本，其餘的 301 過去，這跟 HTTP 與 HTTPS 的選擇 是同一個邏輯。

HTTPS 網頁若仍引用 HTTP 資源，可能出現混合內容問題。瀏覽器會依資源類型嘗試升級或阻擋，不能只看網址列圖示。檢查主控台與 Network，找出主題、外掛、資料庫或第三方服務中的來源；先確認資源支援 HTTPS，再修正網址，重新測試各類頁面。

第五步：通知 Google，別讓它自己猜

轉址啟動後，使用 Search Console 提交遷移資訊與 sitemap，並監控檢索。這有助於提供訊號，但不能保證大幅縮短空窗或取得特定排名。

第一件事是在 Google Search Console 驗證新網域。建議直接用網域層級的 DNS 驗證，一次涵蓋所有子網域與協定版本。新網域驗證完成後，也要保留舊網域的 GSC 資料，因為接下來幾個月你還需要靠舊網域的報表，觀察 301 有沒有正常被消化。把新舊網域都加進同一個 GSC 帳號，方便對照。完整的 GSC 操作可以看 WordPress 提交 Search Console 教學。

在新網域的 GSC 提交包含新標準網址的 XML sitemap，協助 Google 探索遷移後的頁面。格式與提交方式可參考 XML Sitemap 教學。sitemap 是探索提示，不會把既有內容變成全新網站，也不保證索引；舊 sitemap 可暫時保留以監控舊 URL 的轉址處理。

以 URL 檢查工具確認重要新頁可供檢索，必要時要求建立索引；提交有配額，且不保證索引或加速。全站應主要透過有效內鏈、sitemap 和轉址讓 Google 探索。

新舊網域驗證完成後，可在 GSC 用相同時間、查詢與頁面條件比較曝光、點擊和索引變化。新站增加、舊站減少可能符合遷移進程，但曲線交叉不能單獨證明所有訊號已轉移；也要核對 URL 對應、轉址與 Google 選定的標準網址。操作方式可參考 Google Search Console 完整指南。

Search Console 目前仍提供 變更網址工具（Change of Address）。符合整站網域遷移條件時，先驗證新舊資源、完成轉址，再從舊站設定依流程提交；純 HTTP 改 HTTPS 或單一路徑調整不使用此工具。它不能代替轉址與內容驗證。

那些會讓你悄悄掉排名的隱形地雷

最危險的錯誤，往往是那種「網站看起來好好的、排名卻一天天往下掉」的慢性病。這一段是整篇最值錢的部分，因為這些地雷很少出現在一般搬家教學裡。

地雷一：行動版的 301 沒有同步

Google 現在全面採用行動優先索引，也就是用它抓到的行動版內容來評估排名（見 2023 年 10 月的 搜尋中心公告）。如果你的桌面版 301 設好了，但行動版因為快取外掛、AMP、或獨立行動主題的關係沒有跟著轉，Google 的行動爬蟲打舊網域會拿不到正確的 301，排名轉移就會大打折扣。上線後務必用手機網路實測舊網域的幾個網址，確認行動版也正確 301 到新網域。如果你用的是響應式主題（同一份 HTML 同時服務桌面與行動），這個風險相對低；但若你啟用了獨立的行動版或 AMP，就得另外檢查那一條轉址路徑。

地雷二：快取外掛把 301 吃掉

轉址是否生效取決於 CDN、代理、伺服器與外掛的處理順序；不能一概說外掛會繞過已在前方執行的 .htaccess 規則。切換時檢查各層快取與規則，從實際 HTTP 回應確認 301／308 及最終位置。相關設定可參考 網站快取指南。

地雷三：Core Web Vitals 在新主機上退步

新主機的速度、機房位置、SSL 握手效率都可能跟舊主機不同。如果新站載入速度明顯變慢，Core Web Vitals 指標會退步，這本身就是一個獨立的排名風險，而且會跟「換網域的排名空窗期」疊加，讓跌幅看起來更嚇人。上線前後先用實驗室測試及監控比較，再追蹤真實使用者的 LCP、CLS、INP；CrUX 為滾動期間統計，不能在搬家當下立即代表新站。相關概念看 Core Web Vitals 與 SEO，測速工具則參考 網站測速工具。

地雷四：內部連結還指向舊網域

前面講的資料庫網域替換如果沒做乾淨，新站的文章內文、選單、側邊欄裡，會藏著一堆還指向舊網域的連結。訪客點下去就被 301 跳回新網域、再 301 一次，製造無謂的重新導向、也浪費爬蟲預算。上線後用爬蟲工具或外掛掃一遍新站，把殘留的舊網域內部連結全部改成新網域。

地雷五：舊主機太早退租

舊 URL 的永久轉址應至少保留一年，並視舊連結與使用需求維持更久。原主機不必保留同樣久，只要新接手的轉址服務持續支援全部路徑與 HTTPS；停用原主機前先驗證承接結果。

換網域後的 90 天，你該盯著哪些數字

90 天可作為初期追蹤安排，不是保證完成遷移的期限。應按網站大小、檢索速度及異常情況持續觀察，下列月份只是檢查節奏，不是排名恢復里程碑。

第一個月：檢查檢索與索引。對照新舊 URL 的回應、轉址與索引狀態，追蹤 404、5xx、noindex 及 canonical。數量未呈現固定交叉曲線，不足以單獨判定 Google 沒讀懂轉址。

第二個月：持續觀察曝光與點擊。比較合併後的新舊資源趨勢，考慮季節、內容與搜尋需求變化。若有異常，依網址與技術證據排查，不能假設這個月必然開始回升。

第三個月：比對流量與轉換。依重要頁面及業務流程比較遷移前後，沒有官方「三個月恢復八至九成」標準。若差距仍大，檢查轉址、索引、內容、速度及需求變化，按結果延長監控。

遷移後可請重要連結來源更新目的地，並維持原有內容品質與營運。發布新文章應依讀者需求規劃，不能把固定一兩篇新稿當作縮短遷移期或證明新網域「活著」的必要手段。

還有一個容易被看漏的監控點：舊網域的 301 健康度。定期用工具抽查舊網域上幾十個網址，確認它們仍然穩定回傳 301、並且最終落地到正確的新網址。實務上常見的狀況是：舊主機續約出問題、或某次主機端的自動更新把 .htaccess 覆寫掉了，301 在你沒注意的時候悄悄失效，排名就會跟著悄悄往下掉。把「抽查舊網域 301」排進你的月度例行工作，這件事要持續到舊網域完全退役為止。

如果你的流量在搬家後已經出現明顯崩跌、而且遲遲沒有回升，那不是「再等等就會好」，而是要啟動一套有系統的排查與搶救流程，這部分可以參考 網站流量恢復指南 一文。從 SEO 角度看搬家這件事為什麼是高風險動作，也可以對照 SEO 網站搬家與改版的風險拆解。

換網域行動清單：照著跑就不會漏

把前面所有內容濃縮成一份你可以印出來貼在螢幕旁的清單。每跑完一格打一個勾，全部打完，你的換網域工程才算真正收尾。

1. 產出三張表：URL 對照表、資產盤點表、回滾計畫。
2. 完整備份舊站：檔案＋資料庫，下載到本機與雲端，並做一次還原測試。
3. 在新主機架好新站：用臨時網址測試，不對外公開，用序列化安全的工具做網域字串替換。
4. 把永久連結結構調成跟舊站一致，降低 URL 對應的複雜度。
5. 寫好 301 地圖：能用規則式就用規則式，結構有變就逐筆手寫，每個舊網址一步到位、不留鏈。
6. 檢查 canonical：新站每一頁的 canonical 都指向新網域自己。
7. 依驗證方式準備新舊網域所需的有效 HTTPS，並按既有 TTL 提前調整 DNS。
8. 切換 DNS 到新主機，確認新網域 https 正常開啟。
9. 清除必要快取，確認有等價新內容的舊 URL 正確永久轉址；退役且無替代內容者回傳 404／410。
10. 驗證並保留新舊 GSC 資源；符合條件時提交變更網址，提交新 sitemap 並檢查重要 URL。
11. 手機實測舊網域幾個網址，確認行動版也正確 301。
12. 量測新站 Core Web Vitals，跟舊站比對，有退步先解決。
13. 保留舊網域的有效轉址至少一年，原主機可在可靠轉址服務承接並驗證後停用。
14. 以 90 天作初期觀察計畫，依檢索、索引及業務結果延長，不預設固定恢復比例。

換網域這件事，技術門檻不高，但它考驗的是另一種能力：你願不願意為了「可能出問題」而多準備一份備援、多寫一張對照表、多留一個月的舊主機費用。這種看起來笨拙的謹慎，恰恰就是業餘與專業的分水嶺。SEO 從來不是花錢買來的捷徑，而是一點一滴把信任與排名存起來的過程；換網域的每一個步驟，都是在保護你已經存進撲滿裡的那筆資產。

如果你正準備換網域、但看了這篇之後覺得獨自操作風險實在太高、自己評估沒有把握全程壓住每一個細節，Whoops SEO 也提供搬家與 SEO 遷移的協助，需要的時候，我們可以陪你把這份清單從頭走一次。重點是：不管你自己來還是找人幫忙，上面那份清單的每一格，都不能省。