主機搬家是一件比更換佈景主題更容易讓站長捏一把冷汗的操作。網站程式、資料庫、媒體檔案全數搬移完畢，瀏覽器開啟確認畫面正常，往往就宣告完工。然而搬遷後的 48 至 72 小時，搜尋排名卻開始出現波動，有時甚至跌落第二頁。這不見得代表哪個步驟出錯，而是搬遷牽動了幾個 Google 高度依賴的訊號，在訊號穩定前，排名確實會短暫浮動。
問題的根源通常不是「有沒有複製檔案」，而是「有沒有讓 Google 讀到正確的轉向與品質訊號」。301 轉向（永久重新導向）、搜尋主控台（Google Search Console）的地址申報、核心網頁指標（Core Web Vitals）這三條線只要有一條沒接好，輕則需要多等兩週才能回穩，重則讓已累積的連結權重部分流失。
下文按操作時間軸展開，從網域名稱系統（DNS）切換前的準備工作到切換後的驗收稽核，每個步驟的目的與判斷標準都一併說明。
DNS 切換前先把這幾件事做好
切換 DNS 後，新舊主機的流量交接窗口大約 24 至 48 小時。這段期間新舊伺服器可能同時收到請求，如果準備工作沒做足，爬蟲來訪時抓到的是舊主機的快取內容，或者新主機的回應速度比舊主機慢太多，都會在日後的排名評估中留下痕跡。
提前壓低 TTL 值
DNS 的存活時間（TTL）決定舊 IP 在全球各地快取節點上要保留多久。預設值通常是 3,600 秒（1 小時）乃至 86,400 秒（24 小時）。若在切換前 24 至 48 小時把 TTL 壓到 300 秒（5 分鐘），一旦正式將 A 紀錄指向新主機，全球快取最多 5 分鐘內就能完成更新，大幅縮短新舊並行的混亂期。不少站長忽略這一步，切換後才發現部分訪客仍被導向舊主機，此時再調 TTL 已無法縮短等待時間。
在新主機預先驗證 SSL 憑證
SSL 憑證（即網站的 HTTPS 加密）必須在 DNS 切換前於新主機完成申請並通過驗證。若憑證在切換後才開始申請，從申請到生效的空窗期間，訪客的瀏覽器會顯示「不安全」警告，Google 爬蟲也可能因此無法正常索引。Let’s Encrypt 等免費憑證的 DNS 驗證模式需要先將域名指過來才能核發，建議改用 HTTP 驗證，或另行申請通配符（Wildcard）憑證預先部署，確保切換當下新主機能立即以 HTTPS 回應。
用臨時網址跑基準測試
新主機還沒接上正式網域時，先透過主機商提供的臨時網址（或修改 hosts 檔繞過 DNS）進行效能測試。工具用 PageSpeed Insights 或 Chrome 的使用者體驗報告（CrUX）均可。重點是把新主機的最大內容繪製（LCP）、互動到下一次繪製（INP）與累計版面配置位移（CLS）三項數值記錄下來，作為切換後比對的基準。若基準測試就不合格，代表主機規格或網站設定需要調整，不應急於切換。
301 轉向的確認不能只靠瀏覽器點一點
轉向設定是搬遷後最容易出現疏漏的環節。站長通常會在後台或 .htaccess 寫好規則，然後用瀏覽器開幾個頁面確認有沒有跳轉，看到畫面正常就放心了。但瀏覽器的顯示結果並不等於 HTTP 回應碼，兩者之間的落差才是真正的問題所在。
正確的做法是用命令列工具或線上 HTTP 標頭查詢服務，逐一確認每個重要 URL 的回應碼確實回傳 301，而非 302（臨時重新導向）或 200（直接回應，代表沒有觸發轉向）。302 對 Google 而言代表「這個移動是暫時的」，不會將連結權重傳遞給目的地頁面，長期下來等同於讓原有的反向連結能量歸零。
除了逐 URL 檢查，還要確認以下幾種常被遺漏的變體也都有正確轉向：
- HTTP 轉 HTTPS：
http://example.com必須 301 轉到https://example.com，中間不能多一個臨時的 302 跳板 - www 與非 www 統一：
www.example.com與example.com只能保留一個主版本，另一個 301 轉過去，且兩個版本都要確認 - 尾斜線一致性：
/page/與/page的處理方式要與搬遷前一致，若原站沒有尾斜線，搬到新主機後也不應出現 - 子路徑完整覆蓋：若搬遷同時調整了目錄結構，每一個舊路徑都需要對應的轉向規則，不能只靠根目錄的萬用轉向了事
若網站頁數達數百頁，建議用 Screaming Frog 或類似爬蟲工具爬一遍，匯出所有回應碼後集中比對，不要依賴人工逐頁點擊。
Search Console 地址變更申報的時機與步驟
不少站長把 Search Console 的地址變更申報視為可做可不做的加分項，實際上它對 Google 重新評估新主機可信度的速度有直接影響。正確申報能讓排程爬蟲較快重新抓取並更新索引；跳過不做，Google 同樣會自行發現，只是時間可能延長兩到四週。
地址變更功能適用的情境是「網域本身有改變」，例如從 oldsite.com 遷移到 newsite.com。若只是換主機商、IP 換了但域名不變，則不需要申報地址變更，只需確保 robots.txt 與 Sitemap 可正常存取，並在 Search Console 提交一次更新後的 Sitemap 即可。
若此次搬遷同時更換了網域，申報步驟如下。先確認新網域已在 Search Console 完成驗證，新舊兩個資源都必須由同一個帳號擁有；接著進入舊網域資源的設定，找到「地址變更」功能，選擇目標網域後執行系統內建的三項前置檢查，依序確認轉向正確性、Google 可存取性與 HTTPS 有效性，三項全數通過才能送出申請。申請送出後無法撤銷，因此務必在 301 轉向全面生效後才操作。
申報完成後，舊網域的搜尋排名訊號會逐步轉移至新網域，過程通常需要六至十二週才能完全穩定。這段期間排名出現波動屬於正常現象，不必急於再次申報或做其他干預。
切換後的核心網頁指標再驗證
DNS 切換後最容易被遺忘的一步，是確認新主機的頁面效能是否與臨時網址測試時的基準值相符。正式網域接上後，CDN（內容傳遞網路）快取、DNS 解析延遲、主機的伺服器回應時間（TTFB）都會與臨時網址時的結果有所出入，不能假設「基準沒問題，正式環境也沒問題」。
LCP 在新主機的常見問題
最大內容繪製（LCP）在搬遷後劣化，通常來自兩個方向。一是新主機的伺服器規格比原本低，導致初始 HTML 回應就慢了半秒以上；二是 CDN 快取尚未預熱，首批訪客的請求全數回源，等 CDN 完成快取建立後才恢復正常。後者可以在切換後 24 小時內主動用爬蟲觸發各主要頁面的快取，加速預熱過程。
INP 與 CLS 的排查重點
互動到下一次繪製（INP）惡化，多半與 JavaScript 執行環境有關。若新主機的 PHP 版本與舊主機不同，某些外掛在新版本下的行為可能改變，影響前端 JavaScript 的載入順序。累計版面配置位移（CLS）問題則常見於字型或圖片在新主機的快取設定差異，導致資源載入時間點改變，版面在渲染過程中出現位移。
用 Search Console 追蹤真實流量指標
PageSpeed Insights 給的是實驗室數據（單次模擬），Search Console 的「核心網頁指標」報告反映的是過去 28 天真實訪客的體驗數據。搬遷後建議每三天進入 Search Console 確認一次「良好 URL 數量」與「待改善 URL 數量」的趨勢。若良好 URL 比例在搬遷後兩週仍持續下滑，就需要重新對照基準測試結果，找出是主機配置還是外掛設定造成的差異。
遷移後 90 天的觀察節奏
主機搬家的影響不會在一週內完全顯現，也不會等三個月才結束。一般而言，Google 對新主機的信任重建分三個階段：切換後第一週，爬蟲密集重新抓取；第二到四週，排名波動最明顯；第五週到第十二週，訊號逐步回穩並反映在排名上。
這段觀察期最重要的原則不是頻繁調整設定，而是保持穩定——不更換網域、不大規模調整 URL 結構、不更換佈景主題。搬遷同期疊加多個大型變動，等於讓 Google 同時重新評估多個訊號，排名回穩的時間會成倍拉長。若有計劃中的網站改版，建議與搬遷至少錯開三個月再執行。
站長最需要關注的是 Search Console「覆蓋範圍」報告中，已索引頁面數量有沒有在搬遷後出現異常下跌。正常情況下索引數量應在一到兩週內回到搬遷前的水位；若持續下跌超過三週，就需要逐一排查是否有 robots.txt 封鎖、noindex 標籤誤植，或 Sitemap 路徑失效等基礎設定問題。