很多人以為「網站搬家」都是同一件事，其實裡面藏著風險差好幾個等級的兩種操作。換主機，多半只是把同一批檔案從一台伺服器搬到另一台，網址沒變，運氣差一點網站慢個幾天，運氣好甚至完全無感。換網域就不一樣了。它動到的是網址本身，而 Google（連同倚賴 Bing 索引的 ChatGPT 這類 AI 搜尋引擎）認的正是那組網址。網址一換，等於在搜尋引擎眼中憑空冒出一個全新網站，半年、一年慢慢累積的排名，有機會在切換的那一刻直接歸零。
這也是為什麼WordPress 換網域搬家不能照著換主機的節奏隨便搬。ServMask 的遷移風險分級把「同網域換主機」列為低風險、幾天到兩週就恢復，卻把「換網域名稱」列為最高風險之一，恢復期抓在 2 到 6 個月。同樣是搬家，代價差了一個數量級。
好消息是，這件事有一套被驗證過的標準做法，只要每一步都不漏，掉下去的排名幾乎都補得回來，甚至可能爬得比原本更高。先從「換網域到底跟換主機差在哪」講起，再一關一關把準備、搬移、轉址、通知搜尋引擎的順序拆開。
換網域跟換主機，有什麼差異？
先把結論放前面。換主機動的是「網站放在哪」，換網域動的是「網站叫什麼」，對搜尋引擎來說，後者才是傷筋動骨。
換主機時，只要網域沒變，Google 在資料庫裡記的那組網址（www.yoursite.com/about）就一個字都沒動。它照樣爬得到同樣的頁面，外部連結照樣連得到，使用者存的書籤照樣打得開。伺服器換了台機器，這件事對搜尋引擎幾乎透明，排名基本不受影響。這也是為什麼很多人搬完主機沒感覺。
換網域則是把「網站叫什麼」整組換掉。原本所有指向 yoursite.com 的外部連結、社群分享、使用者書籤、還有搜尋引擎資料庫裡記的每一筆網址，全都停在舊網址上。Google 得重新認識 newsite.com 這個「新面孔」，把它跟舊網站的信任、權重、排名對應起來。這個重新認識的過程，就是排名短期波動的來源。
這種風險差距不是憑感覺說的。把常見的幾種遷移攤開來看，愈往「動到網址」的方向走，風險與復原時間就愈長：
| 遷移類型 | 風險等級 | 大致復原時間 |
|---|---|---|
| 同網域換主機 | 低 | 幾天到兩週 |
| HTTP 換成 HTTPS | 低到中 | 一到四週 |
| 子網域改成子目錄 | 中 | 一到三個月 |
| 網址結構調整 | 中到高 | 兩到八週 |
| 換網域名稱 | 高 | 兩到六個月 |
| 整站改版重建 | 最高 | 一到六個月 |
Google 官方的網站遷移文件也是用同一套邏輯分類的，它把「網域名稱從 example.com 換成 example.net」「HTTP 換成 HTTPS」「網址路徑從 example.com/page.php？id=1 改成 example.com/widget」並列為三種帶網址變更的遷移，並直言：對網站做任何重大變更，Google 重新爬取與索引期間，排名都可能出現波動，這是正常的。換句話說，短期掉排名不是你做錯了什麼，而是換網域這件事本身內建的成本；真正決定成敗的，是你有沒有把後面那套流程做完整。
什麼情況下非換網域不可？
換網域既然代價這麼高，理想上能不換就不換。但有些情境下它是繞不過去的必要之惡。先對號入座，看看你屬於哪一種。每一種背後要特別留意的重點都不太一樣。
品牌改名或企業更名。 這是最常見、也最正當的理由。公司名字變了，繼續掛著舊名字的網域反而讓人困惑，換域名是品牌重塑的一部分。這種情境下要特別注意：新舊品牌認知的轉移需要時間，轉址與對外溝通要同步做，別讓使用者連到新站卻搞不清楚這是不是同一家。
從免費部落格平台搬到自架 WordPress。 原本內容放在痞客邦、Blogger 這類免費平台，網址是別人家的子網域或子路徑，等於幫平台養流量。搬到自己的網域和自架 WordPress，才真正把資產拿回自己手上。要留意的是，免費平台能設定的轉址往往很有限，甚至完全不能設，這會讓權重的轉移比一般換網域更吃力，得先確認平台肯不肯讓你做 301。
多個網站或品牌合併成一個網域。 手上有好幾個各自為政的網站，想集中火力經營成一個主網域。合併能讓權重集中，但難度也最高：不是整批導到新首頁就好，每一個舊頁面都要對應到新網域上最相關的那一頁，對應表沒做細，合併反而稀釋掉原本的排名。
舊網域忘記續約被搶註。 網域到期沒續約，被專門盯著過期網域的人搶去（俗稱網域蟑螂），只能被迫啟用新網域。這種是最狼狽的情境，因為你連舊網域的轉址都設不了了，只能盡量從外部連結、社群、直接通知客戶這幾條路把流量導回來。這也反過來提醒一件事：換網域後的舊網域，千萬別在該續約的時候斷了它。
原本的頂級域名不合適，想換一個。 例如原本用 .net、想換成辨識度更高的 .com，或原本用國別域名、想換成通用域名。這種換法技術上跟其他情境沒兩樣，只是動機是「升級」而非「被迫」，反而最容易被輕忽。正因為網站本身沒出問題，很多人就少做了備份和數據存證這些前置功課。
不論你屬於哪一種，接下來的準備工作都一樣重要。這一階段做得完不完整，直接決定日後排名復原得快不快。
動手換網域之前，先把這些準備好
換網域最怕的不是切換那一刻出錯，而是切換之前根本沒留退路、也沒留下比對的依據。真正老練的做法，是在動任何一根手指之前，先把三件事準備好：完整備份、現況數據存證、新網域環境測試。這三塊做紮實了，後面就算出狀況也救得回來。
備份整個網站，不是只備份檔案
備份聽起來像老生常談，但換網域的備份有個很多人漏掉的重點：要備的不只是檔案。
一個完整的 WordPress 網站，有兩塊東西。一塊是檔案，包括佈景主題、外掛、你上傳過的所有圖片和媒體；另一塊是資料庫，你寫過的每一篇文章、每一個頁面、留言、使用者資料、還有各種設定，全都存在資料庫裡。只備份檔案不備份資料庫，等於留了空殼卻丟了內容。所以動手前，一定要把檔案和資料庫兩邊都完整打包一份。
WordPress 生態系裡有不少專門做搬家和備份的外掛，能把整個網站（檔案加資料庫）壓成一個搬遷包，之後在新網域一次匯入。用哪一類工具是其次，重點是在新舊網站切換的過程中，你手上永遠有一份可以隨時還原的完整備份。ServMask 在它的遷移檢查清單裡也把「遷移前先做一次完整的 SEO 稽核」放在第一步，包括把資料庫、檔案、還有 .htaccess 這種伺服器設定檔全部備份下來，因為換網域一旦中途出錯，能不能全身而退，就看這份備份夠不夠完整。
先記錄現在的排名與流量基準值
換完網域後，你一定會焦慮地盯著流量問一句話，排名到底掉了沒、掉多少、正不正常？這句話要答得出來，前提是你切換前有留下一組基準值。沒有基準，你連「現在算不算異常」都判斷不了。
具體要導出兩份資料。第一份是 Search Console 的成效報表，把查詢字詞、頁面、點擊數、曝光數都匯出存檔。ServMask 的建議是至少導出最近三個月的資料當基準線，三個月夠涵蓋一般的流量起伏，換完之後拿新數據對照，就知道下跌是換網域造成的、還是本來就有的季節波動。第二份是 Analytics 的流量與到達頁面資料，一樣導出最近三個月。
導完基準值，順手做一件事：把高流量頁面和高外部連結頁面挑出來。在 Search Console 的成效報表裡切到「網頁」分頁、依點擊數由高到低排序，馬上就看得出哪些頁面在幫你帶最多自然流量；GA4 的部分則到「參與」報表看各頁面的瀏覽與互動數據。這份清單很關鍵，因為等一下設轉址時，這些頁面要優先、精準地一對一對應到新網址，絕不能讓它們混在一堆頁面裡被草草導去首頁。
在新網域架好網站，但先別讓搜尋引擎看到
準備的最後一步，是在新網域上把整個網站完整建起來（用搬家外掛匯入剛才那個搬遷包，或手動把資料庫和檔案複製過去），然後在正式切換前，把每個功能都測過一遍：頁面能不能開、圖片有沒有跑掉、表單和金流通不通、內部連結會不會斷。全部正常了才切。
這裡有一個地雷，踩到會讓整個新站直接消失在搜尋結果裡，那就是測試期間的 noindex 忘記拿掉。
新站在測試階段，為了避免搜尋引擎提前把它爬進去、造成新舊網站內容重複，通常會先掛上 noindex，或用一個暫時網址擋著。這一步是對的。問題出在切換上線時，很多人一忙就忘了把 noindex 拿掉，結果新網站等於主動舉手告訴 Google「別收錄我」，整站排名瞬間清零，而且往往過了好幾天才發現不對勁。ServMask 直接把「忘記移除 staging 的 noindex」列為最致命的錯誤之一，它的說法很直接：如果你在測試站掛了 noindex 又忘了在上線前拿掉，Google 會把你整個網站從索引裡移除。
Google 官方文件也給了一個很實用的防呆做法：如果你在開發階段用了 noindex，就先列一張清單，把所有掛了 noindex 的網址記下來，開始搬遷時照著清單一個一個確認拿掉。多花五分鐘列這張清單，換來的是不會在上線那天把半年的排名一次送掉。
正式換網域：從搬資料到更新內部連結
準備都到位了，接下來進入實際動手的技術步驟。順序照時間序走：先改 WordPress 的網址設定，再把資料庫和檔案搬到新網域，最後批次更新網站內部所有連結。
WordPress 的網址設定在後台的「設定」→「一般」裡，有兩欄要改：WordPress 位址（WordPress Address）和網站位址（Site Address），把這兩欄從舊網域改成新網域。這兩欄決定了 WordPress 認為自己「住在哪」，改對了，網站的核心網址才會跟著換過去。
資料庫和檔案的搬移，如果你前一步是用搬家外掛打包的，這裡就是把那個搬遷包在新網域匯入；如果是手動搬，就是把檔案上傳到新主機、資料庫匯入新資料庫，再改 wp-config.php 對到正確的資料庫連線。
真正容易被輕忽的是第三步：主動更新內部連結。很多人以為反正之後會設 301 轉址，內部連結不改也會自動被導過去，技術上確實會，但這是在偷懶。你網站內文彼此的連結、選單、CSS 和 JS 檔案的路徑，只要還寫著舊網址，每一次載入都得先走一趟轉址才繞到新網址。使用者多等一點、伺服器多做一次工，更要命的是爬蟲的預算被白白消耗在這些沒必要的轉址上。內部連結是你自己網站裡的東西，你有能力也有責任把它一次改乾淨，而不是丟給 301 硬撐。
更新網站內部所有連結指向新網域
內部連結要改的範圍，比多數人想的更廣。除了文章內文彼此的連結，還有導覽選單、側邊欄小工具、佈景主題裡寫死的路徑、CSS 和 JS 檔案的引用網址，甚至如果你用了 CDN，CDN 的網址也要一併換掉。這一條 Kinsta 特別提醒過，很多人改完內文卻漏了 CDN，結果圖片和靜態資源還連著舊網域。
這些連結大多不是躺在後台某個欄位裡讓你手點的，而是散落在資料庫的各張表裡，甚至被序列化存成一長串字串。所以正確做法是在資料庫層級做搜尋替換，把整個資料庫裡的「舊網址」一次換成「新網址」。
命令列熟的人，最穩的做法是用 WP-CLI 的 wp search-replace 指令。它的好處是懂得處理 WordPress 那些序列化的資料，不會像單純的 SQL 全文取代那樣把序列化字串改壞。ServMask 示範的寫法帶了兩個關鍵參數：
wp search-replace 'https://olddomain.com' 'https://newdomain.com' --precise --recurse-objectsCode language: Bash (bash)--precise 讓它逐筆精確比對、--recurse-objects 讓它連序列化物件內部也一起替換。不習慣命令列的人，也有圖形化的資料庫搜尋替換工具能做同一件事，原理相同：從資料庫根源把舊網址換乾淨，讓每一個內部連結一開始就指向新網域，而不是靠使用者點進去被轉址繞一圈。
設定 301 轉址，讓舊網址的分數轉移到新網址
如果整篇只能記住一件事，那就是換網域一定要用 301 轉址，而且要一對一精準對應。這是全篇的技術核心，也是排名能不能平順轉移的關鍵。
先講為什麼非 301 不可。轉址有很多種，最常被搞混的是 301（永久轉址）和 302（暫時轉址）。差別在「意圖」：301 告訴搜尋引擎「這個網址永遠搬到新地方了，請把權重、排名都轉過去」；302 則是「我只是暫時借用一下，原本那個網址還會回來」。換網域是永久性的搬遷，用 302 等於一直暗示 Google「舊網址過陣子會回來」，它就遲遲不把排名轉移給新網址。Google 官方的建議也很明確：技術上做得到的話，優先用伺服器端的永久轉址，也就是 301 或 308。
再講對應方式。301 不只是「有轉就好」，重點在對得準不準。正確做法是舊網址一對一對應到新網域上「內容最相關」的那一頁，像舊的關於頁對到新的關於頁、舊的某篇文章對到新的同一篇文章。最偷懶、也最傷的做法，是把所有舊網址不分青紅皂白全部導到新首頁。這樣一來，每個舊頁面辛苦累積的排名權重，到了新網域全被沖進首頁這個大水桶裡，各頁原本的排名等於歸零重來。前面之所以要先挑出高流量、高外部連結的頁面，就是為了確保這些最有價值的頁面，一定拿到精準的一對一對應。
還有一個容易被忽略的細節：避免連續轉址，也就是轉址鏈。舊網址先轉到 A、A 再轉到 B、B 又轉到新網址，這種一層接一層的轉址會拖慢速度、消耗爬蟲預算。Google 的說法是，Googlebot 雖然最多能跟到十層轉址，但仍建議把鏈裡的轉址數壓低，理想上不超過三層、無論如何少於五層。所以設轉址時要盡量讓舊網址「一步到位」直接跳到最終的新網址，而不是接力賽跑。
舊網域上要怎麼寫轉址規則？
轉址規則要寫在舊網域這一端，讓所有走到舊網址的流量，不管網址後面接的是哪一條路徑，都能對應轉到新網域的同一條路徑。這裡的核心是「萬用字元」的概念：一條規則涵蓋全站，而不是一頁一頁手寫。
如果你的舊主機是 Apache，最典型的寫法是在 .htaccess 裡放一條萬用字元規則：
RewriteEngine On
RewriteRule (.*) https://newdomain.com/$1 [R=301,L]Code language: Apache (apache)這條規則的意思是：抓住舊網址斜線後面的所有路徑（(.*)），原封不動接到新網域後面（$1），並且以 301 永久轉址送出。這樣 olddomain.com/blog/post-a 就會準準轉到 newdomain.com/blog/post-a，路徑一一對上，而不是全部倒進首頁。
其他環境也有各自對應的做法。用 Nginx 的主機，是在設定檔裡放一條 return 301 規則，把 $request_uri（也就是路徑）接到新網域後面。不想碰伺服器設定的，很多主機商後台本身就內建轉址工具，支援萬用字元規則；甚至可以把網域掛在 Cloudflare 上，用它免費的轉址規則做全站 301，連舊主機都不必留著跑。做法很多，挑一個你這台舊主機做得到的即可，原則只有一個：全站萬用字元、路徑對路徑、一律 301。
舊網域要留多久，才不會前功盡棄？
轉址規則寫好了，接著是一個最常被問、也最常被做錯的問題：舊網域該留多久。多數人的直覺答案比實際該做的短很多。基本盤是至少保留並持續繳費續約一年以上，大型、歷史悠久的網站甚至建議近乎永久地留著。Google 官方的建議是把轉址盡量留久一點，一般至少一年；而 Kinsta 講得更直白：如果你的舊網域有很多歷史，最好把 301 轉址「永遠」留著，或至少留很久很久，因為想靠手動去更新所有外部連結，是一件不可能的任務。
道理在這裡：外部連結（別的網站、社群、目錄裡指向你舊網址的連結）不會因為你換了網域就自動更新。它們永遠指著舊網址，靠的就是舊網域上那條轉址，才能把點進來的人和搜尋引擎的權重導到新站。轉址要發揮作用，前提是舊網域還活著、還在你手上。一旦舊網域到期沒續、被別人註冊走，那條轉址就跟著消失。所有外部連結不但斷了，還可能直接連到搶走網域的人架的網站，前面所有功夫一次歸零。
ServMask 把「讓舊網域過期」列為換網域最致命的錯誤，它算過一筆很實在的帳：維持一個舊網域一年可能只要十美元左右，跟你辛苦累積的外部連結權重比起來，這筆錢便宜到沒有不續的理由。這也正好呼應了開頭那個反差：換主機的成本，機器搬完就結束了；換網域真正的隱藏成本，是你得為那個「已經不用」的舊網域，一年一年地繼續繳費、繼續養著它，直到權重都轉移乾淨為止。
通知 Google、Bing 與 AI 搜尋引擎，網站搬新家了
轉址設好、也測試過確實會準準跳到新網址之後，還差最後一哩：主動告訴各家搜尋引擎「這是我計畫好的搬遷，不是網站被駭或出事」。這件事漏掉，搜尋引擎只能靠自己慢慢摸索，復原速度會拖很久。要做的有三件：跟 Google 說、跟 Bing 說、重新提交 Sitemap。
前兩件是主動遞出「變更網址」的通知，第三件是給搜尋引擎一張新網站的完整地圖。提交新網域的 Sitemap 後，舊網域那份 Sitemap 就可以功成身退移除掉。而這裡有一個本站想特別提醒的切角：別以為通知了 Google 就萬事大吉。Bing 這端也要一起做，而且它的重要性正在被低估。
原因是 AI 搜尋引擎的崛起。ChatGPT 這類 AI 助手在回答需要即時資訊的問題時，很大程度倚賴 Bing 的索引結果。也就是說，如果你只顧著設定 Google 的變更網址、卻漏掉 Bing 的網站搬遷，那麼在「使用者問 AI、AI 引用網頁」這個愈來愈重要的新戰場上，你的排名復原會比別人慢一大截。過去「Bing 反正沒什麼流量、可有可無」的想法，在 AI 搜尋時代已經不成立了。
Search Console 的「變更網址」怎麼點？
Google 這端用的是 Search Console 的「變更網址」工具（Change of Address）。它的操作邏輯是：在舊網域的資源裡告訴 Google，這個網站要搬去哪個新資源。
動手之前有個前提條件卡住很多人：新舊網域必須各自都先在 Search Console 完成驗證，各自是一個獨立的「資源」。少了任何一邊的驗證，這個工具根本點不動。都驗證好之後，路徑是進到舊網域資源的「設定」，找到「變更網址」工具，選擇你已驗證好的新網域資源，工具會自動幫你檢查轉址設定對不對、驗證通過後，再確認提交。
提交完不是立刻生效。ServMask 提到這個變更流程走完最長可能要到 180 天，所以送出之後別急著判定成敗。它是一個讓 Google 慢慢把索引和權重從舊網域挪到新網域的過程，你要做的是耐心等它跑完，同時繼續維持舊網域上的轉址至少一年。
別漏了 Bing，因為 ChatGPT 也靠它
Bing 這端，在 Bing 網站管理員工具裡有一個對應的「網站搬遷」（Site Move）功能，操作邏輯跟 Google 那套幾乎一樣：一樣需要新舊網域都先完成驗證，一樣是告訴 Bing「這個網站的網址要搬到另一個已驗證的網站」。依 Kinsta 的說明，這個功能藏在「Diagnostics & Tools」（診斷與工具）底下的「Site Move」，進去之後選「把這個網站的網址搬到另一個已驗證的網站」即可。
這一步之所以最常被漏掉，是因為多數人只熟悉 Google，設完 Search Console 就覺得收工了。但前面說過，正因為 ChatGPT 這類 AI 助手主要透過 Bing 的索引結果來回答問題，漏掉 Bing 端的網站搬遷設定，等於讓你的網站在 AI 搜尋這個新場域裡復原得更慢、更被動。花的時間跟設定 Google 差不多，卻能守住一整塊愈來愈重要的能見度，這筆帳很划算。
換完網域之後，多久排名才會恢復？
該做的都做完了，剩下的是最煎熬的部分：等待。這裡先給你一個心理準備：換網域後短期一定會掉排名、掉流量，這是正常現象，不是你哪裡做錯了。真正該擔心的不是「有沒有掉」，而是「掉的幅度和持續時間正不正常」。把時間軸拆成幾個階段來盯，就不會自己嚇自己。
前 48 小時，重點是確認新網站有沒有被正常收錄，以及有沒有意外的 noindex 殘留。這段時間你要做的不是看排名（排名這時還在混亂中），而是檢查技術面：用 Search Console 看新網域有沒有開始被爬、被索引，回頭確認前面那張 noindex 清單是不是真的全部拿乾淨了。這 48 小時抓的是「有沒有致命錯誤」，而不是「排名回來了沒」。
前 2 週，會是下跌最明顯的階段，你會看到流量和排名往下掉，這在換網域的正常範圍內。搜尋引擎正在重新爬取、重新對應舊網址和新網址的關係，權重還在半路上。這段時間最忌諱的就是慌張地又去大改設定。你越動，搜尋引擎越難把新舊對應算清楚。沉住氣，讓轉址和變更網址通知去發揮作用。
1 到 3 個月，才是排名逐漸回穩的階段。ServMask 給的復原區間是換網域約 2 到 6 個月，而 Search Console 的變更網址流程本身最長也可能跑到 180 天，所以真正判定「這次搬家成不成功」，得等到這個區間走完，而不是看前兩週的臉色。
至於什麼時候該警覺？給你一條實用的判斷線：如果跌幅超過三成，而且是持續惡化、遲遲不見回穩的跡象，那就不是正常波動，要回頭一項一項排查：轉址是不是有漏、有沒有轉址鏈、noindex 是不是真的拿乾淨了、Sitemap 提交了沒。正常的換網域是「先跌、然後在幾週後見底、再慢慢往上爬」；只跌不回、跌幅又深，才是真的出了問題。
一個換網域案例：流量先跌、後來反而衝更高
想證明換網域不是世界末日，有一個公開可查、規模夠大的案例很有說服力：金融科技公司 TransferWise 改名成 Wise，網址也從 transferwise.com 換成 wise.com。
換域名前，transferwise.com 的自然流量高峰約在每月三千兩百三十萬次。換完網域的短期，流量確實明顯下滑，掉到每月約一千三百萬次左右。這正是前面說的「先跌」，連這種規模的公司也躲不掉。但故事沒有停在這裡，長期經營下去，wise.com 的每月自然流量後來成長到約兩億次，遠遠超過改名前的規模。
這個案例不需要你去糾結細節，記住那條曲線的形狀就好：先跌、見底、然後在正確的轉址與持續經營下爬回來，甚至爬得比原本更高。換網域從來不是排名的終點，它只是一段有陣痛期的過渡；陣痛期能不能安然度過，靠的正是前面每一步有沒有做到位。
換網域比拚的不是技術，而是耐心。技術部分沒有那麼玄：備份、搬檔、改內部連結、設 301、通知搜尋引擎，每一步都有標準做法可循；真正難的，是在流量往下掉的那兩三個星期沉得住氣，不去亂動、也不放棄。只要步驟做對了、舊網域別在中途斷了、該通知的搜尋引擎一個都沒漏，掉下去的排名會回來，甚至因為你趁這次搬家把整個網站的結構和規劃重新理順，而爬得比從前更高。時間到了，它自然會補回來。