搬新家從來不是把家具跟紙箱搬到新地址就結束。水電要過戶，親友要通知新地址，信件也不能中途寄丟，只要漏掉一件事，通常要等到帳單寄不到、包裹被退回才會發現。網站搬家的道理幾乎一樣，多數人以為把檔案搬到新主機、網址設定好，這件事就算完成了，實際上要同時交接的系統不只一個，任何一個環節沒對齊，都會變成搬完之後才浮現的漏洞，而這正是網站搬家風險最難提前抓到的地方。
這種落差，其實有清楚數字可以佐證。根據 Search Engine Journal 於 2025 年發布的一份研究，分析了 892 個網域遷移案例後發現，新網域的自然流量平均要花 523 天，才追得上舊網域原本的水準，甚至有 17% 的案例超過 1000 天都還沒追回來，速度最快的個案也要 19 到 33 天。換句話說，搬家當下看起來順利，不代表流量或訂單真的安然過渡，很多問題要等切換後一段時間才會浮現。
接下來要盤點的，是搬家過程中最容易被忽略、卻會在事後才爆出問題的幾個環節，動工前先摸清楚，才不會等到出包才發現。先從最基礎的網域設定講起，看 DNS 沒切換完全，會留下什麼樣的空窗期。
原因一：DNS 沒有真的切換完成，只留了一段空窗期
把 DNS 設定改完、指向新主機，不代表全世界的訪客立刻都看得到新網站。DNS 記錄有快取機制，術語叫 TTL（Time to Live，存活時間），簡單說就是各地的網路服務商會把查到的網址記錄暫存一段時間，在這段時間內，就算你已經改好設定，對方查到的還是舊資料。以 Cloudflare 的文件為例，非企業方案帳戶的 TTL 最低可以設到 60 秒、最長可以拉到一天，Auto 模式預設是 300 秒。TTL 設得越長，新設定生效的速度就越慢，正確做法是在真正切換前幾天先把 TTL 調低，等各地查到的記錄都換成短效期，再動手改網址指向；不是切換當下才臨時調低，那樣舊的長效期記錄早就散布出去，調了也來不及。
這段空窗期最常見的誤判，是只看自己電腦或自己所在地區一切正常，就以為所有訪客都跟你看到一樣的畫面。實際狀況比較像是「部分正常、部分異常」，首頁能開，不代表表單通知、子網域、憑證驗證都已經跟上，可能有人已經連到新站，有人還停在舊站，兩邊同時存在一段時間是常態，不是意外。
Google Search Central 的文件也提到，遷移完成後，Google 對新網站的檢索作業會比平常更繁重，因為舊網站累積的流量與檢索都要重新導向新網站，文件建議大型網站採分階段遷移、小型網站可以一次做完，這也是判斷要不要分批切換時可以參考的方向。
如果搬家同時也換了網域註冊商，還有一件容易被忽略的事，就是網域轉出需要先在原本的受理機構申請取得授權碼，而且這組授權碼有時效限制。TWNIC（財團法人台灣網路資訊中心，是 .tw 網域名稱主管機關委託的非營利註冊管理機構，不是商業代理商）的說明明確寫到，授權碼要在時限內完成轉入，逾期可能失效，屆時得重新申請一次。網域轉移跟 DNS 記錄切換其實是兩件事，要分開盤點，不能以為改完 DNS 設定，網域本身的手續也一併搞定了。
原因二：資料庫版本不一致，舊語法悄悄失效
很多人以為資料庫搬家，只要把整個檔案複製到新主機就結束，但新舊主機的資料庫版本經常不一樣，語法跟預設設定也會跟著改變。最常見的情境是從 MySQL 5.7 升級到 8.0，舊網站原本用得好好的寫法，到新版本可能直接被拿掉，或是行為悄悄變了樣。網站表面上還是能打開，只是某些功能開始出問題，這種「能開但半殘」的狀態，反而比整站直接掛掉更難第一時間發現，因為沒有明顯的錯誤畫面提醒你哪裡出了狀況。
MySQL 官方文件列出了 8.0 版本移除或改變的項目，其中兩項特別容易讓一般網站中招。第一，預設的字元集與比對規則從 latin1 改成了 utf8mb4，如果搬家過程沒有特別確認資料表的字元集設定，存進去的文字可能出現亂碼或無法正確比對。第二，資料表分割功能（partitioning）現在只剩 InnoDB 跟 NDB 兩種引擎原生支援，用其他引擎做分割表的網站，升級前得先手動轉換，否則升級後這些資料表可能無法正常運作。
搬家時另一個常見動作，是把舊網址用文字取代的方式直接換成新網址，這個動作看起來單純，卻可能連帶破壞外掛儲存設定用的序列化資料（serialized data）格式。WordPress 官方開發文件明確提醒，序列化資料如果被單純的文字取代改動長度，資料就會跟原本的格式對不上，進而毀損。文件建議，對資料庫做網址搜尋取代時，只在 wp_posts 這張資料表做全庫取代，其餘資料表要透過專門工具處理，例如 Better Search Replace 這類外掛，或是 WP-CLI 提供的 search-replace 指令，才不會把佈景主題與外掛的設定資料一起搞壞。
原因三：表單與通知信，是最容易被忽略的環節
前台看起來一切正常，是搬家後最容易讓人放心的假象。表單類的功能就是最典型的例子，訪客填完資料、按下送出，頁面顯示感謝訊息，你看到的就只有這樣，看不到後端有沒有真的把資料寫進資料庫，也看不到通知信有沒有寄出去。這中間的每一步都可能因為搬家而中斷，卻不會反映在前台的畫面上。
表單外掛用來儲存欄位設定與紀錄的方式，同樣屬於前面提到會被序列化資料問題影響的一類，只是原因二談的是技術層面的資料損毀，這裡影響的是實際的營運面，客戶詢價、預約、留言，一筆一筆悄悄消失或延遲。舉例來說，一家做電商的中小企業搬完家之後，網頁都能正常瀏覽，直到三天後才發現詢價表單完全沒有寄出通知信，那三天累積的客戶名單跟詢問，幾乎等於白白流失。
正因為這個環節不會主動跳出來提醒你，搬家後的第一件事，應該是自己實際送出一次測試表單，確認有沒有收到通知信、後台紀錄有沒有正常寫入，而不是只看首頁能不能開就宣布搬家完成。
原因四：SSL 憑證與網域驗證，換了主機就得重新設定
SSL 憑證能不能正常運作，很大程度取決於舊主機當初的設定，不是網域本身就有的東西。換到新主機之後，憑證通常不會自動延續過去，需要重新申請或重新啟用，一旦漏掉這一步，訪客打開網站就會看到瀏覽器跳出不安全連線的警示，也連帶影響搜尋引擎對網站的信任程度。
憑證之所以常常沒跟著搬，是因為它是安裝在主機這一層，新主機在預設狀態下並不會帶著舊主機的憑證資料。除了 SSL 憑證，還有幾種驗證方式也很容易在網址變動後跟著失效，包括用來確認 Search Console 網站所有權的 HTML 驗證檔案、meta 標記，以及分析工具的追蹤碼設定，這些都要記得在新網站重新放回去。
Google Search Central 的文件也提到，如果搬家同時要遷移到 HTTPS，必須在伺服器上取得必要的 TLS 憑證並完成設定，也要確認 Search Console 的驗證狀態是否依然正常。如果原本是用 HTML 檔案驗證，別忘了在新版網站中放進目前的驗證檔案；如果是用 meta 標記或 Google Analytics 驗證，也要確認新的內容管理系統（CMS）裡有沒有包含這些項目。
原因五：robots.txt 設定沒跟上，AI 爬蟲照樣讀不到新網站
搬家清單裡，除了要顧好 Google 這類傳統搜尋引擎，現在還多了一層要留意的對象，也就是 ChatGPT、Claude 這類 AI 服務派出來讀取網站內容的爬蟲。網頁本身能不能正常打開，是搬家後最容易被盯著看的指標，但 robots.txt 有沒有不小心擋掉這些 AI 爬蟲，或是原本該擋的爬蟲反而漏掉沒擋，同樣容易被忽略，結果搬完家之後，被 AI 工具收錄或引用的狀況，跟預期完全不一樣。
Google Search Central 的文件建議，搬家時要為新網站重新設定 robots.txt，並確認裡面的規則正確反映哪些內容要禁止檢索。文件也特別提醒，有些網站在開發階段會先封鎖所有檢索，如果採取這種做法，正式遷移時就要記得準備好完整的 robots.txt，不要讓開發階段用的封鎖規則跟著上線。網域有變動時，也可以透過 Google 提供的「異動網址」工具主動通知，而不是被動等 Google 自己發現。
AI 爬蟲不是只有一種。OpenAI 的官方文件說明，GPTBot 用於訓練資料蒐集，OAI-SearchBot 則是用於搜尋，兩者是各自獨立的使用者代理（user-agent），站長可以分別允許或封鎖。文件也提到，robots.txt 更新後，系統大約需要 24 小時才會調整，提醒搬家後檢查 AI 爬蟲設定不會馬上生效，得預留一段觀察時間再確認結果是否符合預期。
回到搬新家的比喻，網站搬家的風險從來不是某一個環節單獨出錯，而是網域、資料庫、表單、憑證、搜尋引擎與 AI 爬蟲，好幾個系統得在同一個時間點一起交接，任何一個環節沒對齊，都會變成事後才被發現的漏洞。與其搬完之後才到處抓漏，不如把這幾個環節都先排進「搬家前」與「搬家後」的驗收清單，提前知道風險藏在哪裡，真正動手搬家的那一天，才不會手忙腳亂。