- 登入
- 註冊
網站搬家完整指南 2026｜內容、網域、SEO 與追蹤碼怎麼安全轉移
內容目錄
顯示
網站搬家不是把 WordPress 檔案壓縮後傳到新主機就結束。完整遷移還要確認資料庫、媒體、網域、DNS、Email、SSL、網址、301、canonical、內部連結、表單、付款、GA4、GTM 與 Search Console 是否延續。
開始前先回答：搬完後，使用者看到的每個 URL 會不會改變？如果網域與路徑都不變，只是更換主機，主要任務是複製網站，測試新環境及切換 DNS；如果網域或路徑改變，就要另外建立舊 URL 到新 URL 的 mapping，設定永久轉址，更新 canonical、內鏈及 sitemap，並在 Search Console 監控新舊網址。
主要依據：Google Search Central Changing your hosting與Google Search Central How to move a site（查證 2026-07-24）。Google 將不改 URL 的主機變更與 URL 變更分成不同流程，並提醒重大遷移可能出現暫時排名波動。
網站搬家是什麼？主機、網域、DNS、CMS 與網址怎麼分？
網站搬家是把網站提供內容與功能所需的全部或部分資產，從現有環境轉到新環境。它可能只是更換主機 IP，也可能包含換網域、換 CMS、重做版型及改網址結構。
| 項目 | 主要作用 | 搬家時可能的變更 | 常見誤解 |
|---|---|---|---|
| 網域 | 使用者輸入的網站名稱，例如 example.com | 保留原網域或更換新網域 | 網域與網站主機一定在同一家 |
| DNS | 把網域及子網域導向網站、Email 與其他服務 | 更改 A、AAAA、CNAME 或 nameserver | 改 DNS 只會影響網站 |
| 網站主機 | 執行網站程式及提供檔案與資料庫 | 更換伺服器、代管商、地區或 CDN | 複製檔案就代表網站完整搬好 |
| CMS | 管理內容、帳號、版型及外掛的系統 | WordPress 換主機或換成其他 CMS | 換 CMS 不會影響網址及內容結構 |
| URL | 每一頁及資源的公開位址 | 網域、協定、子網域或路徑改變 | 首頁能開就代表其他舊網址也正常 |
| 以同一網域收發郵件的獨立服務 | 可保留原服務，也可另行遷移 | 網站搬家時一定要把信箱一起搬 |
網域註冊商與網站主機不是同一件事
網域可以在 A 公司註冊，DNS 由 B 公司代管，網站放在 C 公司，企業信箱使用 D 公司的服務。只換網站主機時，通常不需要把網域註冊商一起轉移；只要新主機準備完成，再於正確的 DNS 服務修改網站解析紀錄。
DNS 不是網站專用設定
同一個 DNS zone 可能包含：
- 網站主網域與
www。 - 商店、會員或 API 子網域。
- 企業信箱的 MX。
- SPF、DKIM 及 DMARC。
- Search Console 與第三方服務驗證 TXT。
- CDN、圖片或檔案服務 CNAME。
- 舊站、測試站及短網址。
CMS 搬移不只包含檔案
以 WordPress 為例，網站通常包含：
- WordPress 核心、主題、外掛及上傳檔案。
- MySQL 或 MariaDB 資料庫。
wp-config.php與環境設定。- 排程任務、快取及伺服器規則。
- 使用者與角色。
- 媒體、PDF 及其他下載檔。
- SMTP、金流、發票、表單及 API 憑證。
- SSL、CDN、物件快取及安全設定。
URL 是否改變，決定 SEO 搬遷工作量
下列變更會讓公開 URL 改變：
http://example.com改為https://example.com。example.com改為new-example.com。www.example.com改為example.com。/product.php?id=10改為/products/widget/。/blog/post-name/改為/insights/post-name/。- 多個舊站合併到同一個新站。
四種網站搬遷類型差在哪裡？
開始排工作前，先把專案歸入最接近的類型。同一個專案可能同時符合兩類，但這通常代表風險疊加，應評估能否拆成兩個階段。
| 類型 | 主要變更 | 公開 URL | 是否需要逐頁 301 | DNS 工作 | 主要 SEO 風險 |
|---|---|---|---|---|---|
| 一、只換主機 | 伺服器、代管商、IP 或 CDN | 不變 | 通常不需要 | 指向新主機並監控新舊流量 | 新環境錯誤、速度、封鎖爬蟲或內容不一致 |
| 二、換網域 | old.com 改為 new.com | 網域改變 | 需要 | 新網域解析與舊網域保留轉址 | mapping 錯誤，轉址失效，舊網域太早到期 |
| 三、換 CMS 但保留 URL | 例如其他 CMS 改為 WordPress | 理想上不變 | URL 真正一致時不需要 | 視主機是否同時更換 | template、canonical、schema、內容及狀態碼變動 |
| 四、改網址結構或合併網站 | 路徑、分類、子網域或站點架構改變 | 大量改變 | 需要 | 依是否換網域或主機決定 | 漏掉 URL，一律導向首頁，出現 redirect chain，內鏈及 sitemap 不一致 |
類型一：只換主機，不改 URL
這是 SEO 搬遷相對單純的情況。使用者仍開啟同一個網域與路徑，搬家動作由 DNS 切換到新基礎設施完成。
- 在新主機建立完整網站副本。
- 以受限 staging 或 hosts 對應測試。
- 確認 Googlebot 不會被防火牆或安全服務阻擋。
- 提前依計畫調低網站 DNS 紀錄的 TTL。
- 同步切換前最後一批內容或交易資料。
- 修改網站使用的 DNS 紀錄。
- 同時監控舊主機與新主機 log。
- 確認舊主機流量歸零且新站穩定後，再依計畫退場。
類型二：更換網域
從 old-example.com 搬到 new-example.com 時，每個公開 URL 都改變。即使路徑完全相同，仍要讓舊網址永久轉向新網址。
| 舊 URL | 新 URL | 對應 |
|---|---|---|
https://old-example.com/ | https://new-example.com/ | 首頁對首頁 |
https://old-example.com/services/ | https://new-example.com/services/ | 服務頁對應服務頁 |
https://old-example.com/blog/a/ | https://new-example.com/blog/a/ | 同內容文章一對一 |
類型三：更換 CMS，但保留網域與 URL
從舊 CMS 換到 WordPress，或 WordPress 換到其他平台時，理想作法是盡量保留既有高價值 URL。URL 看起來相同，仍要逐項比較：
- HTTP 狀態碼是否相同。
- title、meta description 及 H1 是否正確。
- canonical 是否仍指向自己。
- robots meta 與 robots.txt 是否開放正式頁。
- schema 是否遺失或重複。
- 主內容、圖片、alt 及下載檔是否完整。
- 分頁、標籤、作者及分類頁是否仍存在。
- 表單、搜尋、會員、購物及付款流程是否正常。
- GA4、GTM、廣告像素及 Search Console 驗證是否延續。
類型四：改網址結構，合併站點或大量整併內容
這類專案需要最完整的 URL mapping。每個舊 URL 要有明確結果：
- 對應到內容相同或高度相關的新 URL。
- 多頁內容真正合併時，對應到新的整合頁。
- 沒有替代內容時，回傳 404 或 410。
- 不應索引的系統頁，依需求處理 robots 或存取權限。
備份、複製、切換、301 與監控各自做什麼？
網站搬家會用到多個看似相近的動作，但它們處理的風險不同。把其中一項當成全部，常造成「有備份卻無法上線」「新站能開，但舊網址全部失效」或「切換完成後沒人發現表單漏信」。
| 動作 | 主要目的 | 完成證據 | 不能取代 |
|---|---|---|---|
| 備份 | 保存切換前可回復的檔案、資料庫及設定 | 可讀備份、雜湊或清單、還原測試結果 | 新站功能測試 |
| 複製 | 在新環境建立可運作的候選站 | staging 頁面、版本、資料量及功能測試 | DNS 正式切換 |
| 切換 | 讓正式流量前往新環境 | 公開 DNS、請求回應、新舊 server log | URL 改變時的逐頁轉址 |
| 301／308 | 把永久改變的舊 URL 導到新 URL | 每筆 mapping 的狀態碼與最終目的地 | DNS、canonical、內鏈與 sitemap |
| 監控 | 在切換後發現錯誤、流量轉移及索引變化 | log、GA4、GSC、告警與重測紀錄 | 搬家前測試及 rollback |
備份要同時包含檔案與資料庫
WordPress 官方文件把網站備份拆成資料庫與檔案兩部分。資料庫通常包含文章、頁面、留言及設定，但不會自動包含主題、外掛、上傳圖片、wp-config.php 及其他伺服器檔案；只備份檔案，也不等於資料庫已保存。
- 檔案範圍、大小、數量及產生時間。
- 資料庫名稱、資料表數量、匯出格式及產生時間。
- WordPress、PHP、資料庫、主題及外掛版本。
- 伺服器規則、排程、環境變數與必要憑證的保存方式。
- 備份存放位置、存取權限及保留期限。
- 還原到隔離環境後的驗證結果。
複製是建立候選站，不是直接讓它公開被索引
新主機的候選站應在正式切換前測試。可以使用：
- 受 IP 或登入限制的 staging。
- 暫時 hostname，並加上
noindex。 - 本機 hosts 檔把正式網域暫時指向新 IP。
- 主機商提供的預覽 URL，但要確認 HTTPS、cookie 及絕對 URL 是否能正確測試。
- 重要 URL 的 HTTP 狀態碼。
- 主要內容、title、H1、canonical 及 robots。
- 圖片、PDF、CSS、JavaScript 與字型。
- 登入、搜尋、表單、會員及交易。
- Email 通知、排程及 webhook。
- GA4、GTM 及廣告事件。
- 快取、防火牆、CDN 及 Googlebot 存取。
- 效能與伺服器資源。
切換是控制流量方向
只換主機時，切換通常是把網站相關 DNS 紀錄指向新環境。URL 有變時，切換還包含在舊站啟用轉址及讓新網域提供正式內容。
- 日期、時區及預計窗口。
- 操作人、核准人及回報頻道。
- 凍結內容或同步增量的起訖時間。
- 要修改的 DNS 或伺服器設定。
- 每一項驗收指令及預期結果。
- 觸發 rollback 的條件。
- 回復時要還原哪些 DNS、資料及服務。
301 與 308 是永久 URL 變更訊號
Google 把 301 與 308 視為伺服器端永久轉址，適合告知使用者及搜尋系統內容已永久移到新位置。302 與 307 則是暫時轉址訊號。
| 舊 URL | 新 URL | 預期狀態 | 新頁 canonical | 新站內鏈 |
|---|---|---|---|---|
/old-service/ | /services/main/ | 301 | 指向 /services/main/ 自己 | 直接連新 URL |
- 新頁 self-referencing canonical。
- 站內連結直接使用新 URL。
- sitemap 只列正式新 URL。
- hreflang、schema 及 Open Graph 使用新網址。
- 高流量外部連結在可行時更新。
- robots.txt 與 robots meta 不阻擋新頁。
哪些情況適合搬家？哪些情況應先停下整理？
網站搬家有合理商業目的，例如服務停止，資源不足，管理權失控或平台已不符合需求。但「搬家」不是每個網站問題的答案。若根因是內容品質、追蹤設定或不清楚的權限，換主機可能只是把問題複製到新位置。
適合規劃搬家的情況
下列情況通常值得進入正式評估：
- 現有主機長期無法滿足可用性、效能、版本或容量需求。
- 供應商將終止服務，或關鍵元件已停止維護。
- 公司無法取得主機、網站檔案或資料庫的合理控制權。
- 現有平台無法支援必要的會員、電商、內容或整合需求。
- 合約、資料區域、安全或內部政策要求更換環境。
- 網站併購、品牌整合或網域變更已有明確商業決策。
- 維護成本及風險經完整比較後，搬遷方案較合理。
應先整理所有權的情況
如果公司不知道下列問題的答案，不應直接排切換日期：
- 網域登記人及到期日。
- DNS 由誰代管。
- 主機及 WordPress 最高管理帳號。
- 檔案、資料庫與備份取得方式。
- GA4、GTM、GSC、廣告及社群像素所有權。
- 金流、發票、SMTP 及第三方 API 帳號。
- 原廠或前廠商是否有自訂程式及授權限制。
應先修復安全事件的情況
網站若已有陌生管理員、惡意轉址、可疑檔案、瀏覽器警告或資料外洩跡象，不要未經分析就把現況完整複製到新主機。備份可能已包含惡意程式，舊帳號及憑證也可能持續有效。
應先建立 URL inventory 的情況
換 CMS、換網域或改結構前，如果團隊不知道站上有多少 URL，哪些頁面有流量及外部連結，就無法建立可靠 mapping。
- 現有 sitemap。
- CMS 內容匯出。
- Search Console 有曝光及點擊的頁面。
- GA4 的 landing page。
- server log 最近被請求的 URL。
- 爬蟲取得的可連結頁面。
- 外部連結報表。
- 圖片、PDF、影片及其他資源。
來源：GA4 到達網頁官方說明、GA4 報表官方說明與GA4 DebugView 官方說明（查證 2026-08-03）。搬家前後應以相同資料期間、事件設定與 URL 口徑比較。
搬家前要盤點哪些資產、權限與回復條件？
網站搬家前的 inventory 不是為了做一張漂亮表格，而是確保每一個會受影響的資產都有 owner、來源、目標及驗收方式。缺少其中一項，切換當天就可能由技術人員臨時猜測。
第一步：盤點網站、網域、DNS 與 Email 所有權
先建立權限表：
| 資產 | 服務商／位置 | 主要管理員 | 備援管理員 | MFA | 到期日 | 搬遷工作 |
|---|---|---|---|---|---|---|
| 網域 | 註冊商 | 公司帳號 | 指定主管 | 已啟用／待補 | 日期 | 保留或轉移 |
| DNS | DNS 供應商 | 技術負責人 | 備援人員 | 已啟用／待補 | 不適用 | 修改網站紀錄 |
| 舊主機 | 代管商 | 網站管理員 | 備援人員 | 已啟用／待補 | 日期 | 匯出、監控及退場 |
| 新主機 | 代管商 | 網站管理員 | 備援人員 | 已啟用／待補 | 日期 | 建站、測試及正式服務 |
| WordPress | 正式站 | 個人管理帳號 | 備援管理帳號 | 已啟用／待補 | 不適用 | 權限稽核 |
| 企業信箱 | 郵件供應商 | 郵件管理員 | 備援管理員 | 已啟用／待補 | 日期 | 保留或另案遷移 |
第二步：建立網站技術與功能 inventory
技術清單至少包含：
- 網站核心、主題、子主題及外掛版本。
- PHP、資料庫、Web server 及必要延伸模組。
- 檔案大小、數量及資料庫大小。
- 自訂程式、自訂資料表及 must-use plugins。
- cron、queue、CLI 及背景工作。
- CDN、快取、WAF、物件儲存及備份。
- SMTP、表單、webhook、API 及 IP allowlist。
- 金流、發票、物流、會員及訂閱。
- robots.txt、sitemap、canonical、hreflang 及 schema。
- GA4、GTM、廣告像素及第三方追蹤。
第三步：建立 URL inventory 與 mapping
URL 表建議包含：
| 欄位 | 內容 |
|---|---|
| old_url | 舊站完整 URL |
| source | sitemap、GSC、GA4、log、crawl 或 CMS |
| status_before | 搬家前狀態碼 |
| traffic_or_value | 點擊、工作階段、轉換、外部連結或商業重要性 |
| action | 保留、redirect、合併、404、410 或不索引 |
| new_url | 對應的新 URL |
| expected_status | 預期 200、301、404 或 410 |
| canonical | 新頁預期 canonical |
| owner | 內容或技術負責人 |
| qa_status | 待測、通過、失敗及重測 |
- 舊 URL 總數：
sitemap 320＋GSC 額外 40＋log 額外 25－重複 55＝330 - 已決策：
保留 180＋redirect 120＋404／410 30＝330 - 待決策：
330－330＝0
第四步：保存搬遷前基準
搬後是否異常，必須有搬前對照。至少保存：
- 首頁及重要模板截圖。
- 重要 URL 狀態、title、canonical、robots 及 schema。
- sitemap URL 數量。
- 404、5xx 及 redirect chain 數量。
- 最近 28 天 GSC 點擊、曝光、CTR 及平均排名。
- 最近 28 天 GA4 使用者、工作階段、landing page 及主要事件。
- 表單、訂單、付款及其他轉換數。
- PageSpeed 或真實使用者效能基準。
- 網站、DNS 及憑證的現況。
來源：GA4 到達網頁官方說明、GA4 報表官方說明與GA4 DebugView 官方說明（查證 2026-08-03）。搬家前後應以相同資料期間、事件設定與 URL 口徑比較。
從 preflight 到監控，網站搬家流程怎麼走？
搬家可以拆成 preflight、staging、cutover、驗收及 monitoring 五個階段。每一階段都要有輸入、輸出與停止條件，避免前一階段尚未通過，下一階段就因排程壓力直接開始。
步驟一：盤點所有權與變更範圍
輸入：
- 網域、DNS、主機、CMS、Email 及第三方服務帳號。
- 現有架構、合約及新環境需求。
- 商業目標、時程與可接受風險。
- 權限表。
- 搬遷類型。
- in scope／out of scope。
- RACI 或負責人清單。
- 變更及核准窗口。
- 網域或 DNS 無法合法取得控制。
- 不知道誰能核准停機、資料凍結及 rollback。
- 原廠或新供應商的交付邊界未確認。
步驟二：建立可還原備份與 URL inventory
輸入：
- 網站檔案、資料庫、設定及 URL 資料來源。
- 同一時間點的備份集合。
- 隔離環境還原結果。
- 舊 URL inventory。
- URL mapping 草案。
- 搬遷前技術、搜尋及轉換基準。
- 備份無法解壓、匯入或還原。
- 網站資料量與備份內容明顯不符。
- mapping 總數無法對帳。
- 高流量及高轉換 URL 尚未決策。
步驟三：在 staging 完成搬移及測試
輸入：
- 已驗證備份、新環境、mapping 及正式站設定清單。
- 可供驗收的候選站。
- 版本與設定紀錄。
- 功能、內容、SEO、追蹤及效能測試報告。
- 已測轉址規則。
- 上線版 robots、canonical 及 sitemap。
- 開啟重要 landing page。
- 點擊站內連結到服務或產品頁。
- 填寫表單或完成測試交易。
- 確認資料寫入、Email 及 webhook。
- 確認 GA4／GTM 事件。
- 查看 server log 及前端錯誤。
- 正式功能仍有 P0 問題。
- staging 的
noindex或存取限制沒有上線移除方案。 - 新環境無法處理必要排程、外部連線或流量。
- 付款、會員、表單或 Email 無法完成端到端驗收。
步驟四：安排 cutover 及資料凍結
輸入：
- 通過驗收的候選站。
- DNS／轉址變更。
- 最後同步方案。
- rollback 文件。
- 對內溝通及客服腳本。
- 最後備份或增量同步。
- 變更紀錄及時間戳。
- 正式 DNS 與轉址。
- 新站公開流量。
- 切換當下驗收結果。
步驟五：執行立即驗收
切換後第一輪要確認：
- 主要網域及
www的 DNS。 - HTTP 到 HTTPS 及主機名稱轉址。
- TLS 憑證及 chain。
- 首頁、重要 landing page、表單及交易。
- 404、5xx、PHP error 及前端 console error。
- robots、canonical、sitemap 及 Search Console 驗證。
- GA4、GTM 及廣告事件。
- Email、webhook、cron 及背景工作。
- 舊 URL 到新 URL 的 301／308。
- 舊新主機 log 的流量方向。
| 項目 | 舊站基準 | 新站實際 | 證據 | rollback 條件 |
|---|---|---|---|---|
| 首頁 | HTTP 200 且 canonical 正確 | 待填 | HTTP header＋HTML | 5xx 或 canonical 錯誤 |
| 聯絡表單 | 資料寫入＋Email | 待填 | 後台紀錄＋收件 | 資料遺失或通知全面失敗 |
| 付款 | 測試訂單成功 | 待填 | 訂單＋金流回傳 | 金額或訂單狀態錯誤 |
| GA4 event | 指定事件可見 | 待填 | DebugView | 核心轉換完全未觸發 |
| 舊 URL | 預期 301 到新頁 | 待填 | header＋最終 URL | 大量錯頁或導首頁 |
來源：GA4 到達網頁官方說明、GA4 報表官方說明與GA4 DebugView 官方說明（查證 2026-08-03）。搬家前後應以相同資料期間、事件設定與 URL 口徑比較。
步驟六：監控新舊站與搜尋資料
搬遷後的監控節奏可分為：
- 前 2 小時：每 15 至 30 分鐘查看可用性、5xx、交易、表單及 server log。
- 前 24 小時：持續監看 DNS、新舊主機流量、錯誤、轉換及客服回報。
- 前 7 天：每日檢查 GSC crawl、索引、sitemap、404、GA4 landing page 及主要事件。
- 前 4 至 8 週：每週比較自然搜尋、外部連結、重要 URL 索引及商業轉換。
步驟七：舊環境退場
只換主機時，等不同解析器已指向新環境，舊主機 log 流量歸零，Googlebot 與使用者均從新主機取得正常內容後，再關閉舊主機。
- 最終備份。
- 搬遷報告。
- DNS 前後差異。
- URL mapping 及轉址設定。
- 異常、處理及重測紀錄。
- 帳號及供應商退租清單。
- 舊資料保存或銷毀的核准。
來源：Google 主機變更步驟、Google URL 變更網站遷移步驟、Search Console URL Inspection 官方說明與Search Console Sitemap 官方說明（查證 2026-07-24）。Google 要求搬遷前測試新環境，準備 mapping，切換後檢查轉址、canonical 及索引，並持續監控新舊網址。
網站搬家常見的八個風險怎麼避開？
網站搬家事故通常不是單一技術不會操作，而是範圍、責任及完成證據沒有先定義。以下八項可直接放進搬遷風險登錄表。
風險一：同時改主機、網域、CMS、版型及內容
所有變更同時上線時，排名下降可能來自轉址、內容縮減、canonical、效能或爬蟲封鎖，團隊很難快速判斷。
- 依可能性拆成多個階段。
- 每階段保留搬前基準及健康對照。
- 若必須一起執行，建立逐層驗收矩陣。
- 上線窗口停止加入未核准的改版需求。
風險二：只從 sitemap 取得舊 URL
sitemap 可能漏掉舊文章、下架頁、PDF、圖片、錯誤參數及曾經有外部連結的 URL。只用 sitemap 建 mapping，搬後仍可能出現大量有價值的 404。
- 合併 sitemap、CMS、GSC、GA4、server log、crawl 及外部連結。
- 為每一列保存 source。
- 去重後核對總數。
- 優先人工確認高流量、高轉換與高外鏈頁面。
風險三：把大量舊頁都導向首頁
一條萬用規則可以讓 404 變少，卻不代表轉址正確。使用者點擊舊產品頁，卻到完全無關的首頁，可能找不到原本資訊；Google 也提醒這類不相關轉址可能被視為 soft 404。
- 一對一導向內容相同或高度相關的新頁。
- 真正整併的多頁可導向新的整合頁。
- 沒有替代內容時回傳正確 404 或 410。
- 先測一筆，再 batch 驗證完整 mapping。
風險四：Email 因 DNS 變更停止收發
更換 nameserver 或匯入不完整 DNS zone 時，最容易漏掉 MX、SPF、DKIM、DMARC 及郵件服務驗證紀錄。網站首頁正常，不代表企業信箱也正常。
- 搬家前完整匯出 DNS。
- 把網站紀錄與郵件紀錄分組審核。
- 只改真正需要變更的網站紀錄。
- nameserver 變更前，在新 DNS 先建立完整 zone。
- 切換後測試不同外部服務的寄入及寄出。
- 查看郵件驗證及退信結果。
保留網域與更換網域的搬家流程有何不同？
以下用兩個情境示例收束差異。它們不是特定客戶案例，也不是固定指令；實際執行要依主機、CMS、DNS、Email 與交易架構調整。
示例 A：WordPress 換主機，保留原網域與 URL
情境：
- 原站：
https://example.com - 新站：仍為
https://example.com - CMS：WordPress 不變。
- 網域及路徑：全部保留。
- Email：保留原郵件供應商。
- 目的：更換主機及提升資源。
- 驗證網域、DNS、舊新主機及 WordPress 權限。
- 匯出完整 DNS，標記網站與 Email 紀錄。
- 備份網站檔案及資料庫，完成隔離還原測試。
- 記錄版本、URL 數量、內容及功能基準。
- 把網站複製到新主機。
- 使用 hosts 或受限 staging 測試正式網域情境。
- 確認新 IP、TLS、排程、SMTP、表單及交易。
- 依計畫提前調低網站 DNS 紀錄 TTL。
- 進入內容或交易凍結窗口。
- 執行最後檔案與資料庫同步。
- 再次測試候選站。
- 修改網站 A／AAAA／CNAME 指向新主機。
- 不修改 MX、SPF、DKIM 及 DMARC。
- 執行首頁、重要頁、表單、交易及追蹤測試。
- 同時監看舊新主機 log。
- 確認不同公共解析器取得新值。
- 檢查 Googlebot 及一般流量逐步轉到新主機。
- 監控 5xx、速度、cron、Email、GA4 及 GSC。
- 舊主機流量歸零且新站通過觀察期後，依核准計畫退場。
- 把 TTL 調回長期設定。
- 保存搬遷報告及最終備份。
示例 B：WordPress 搬到新主機，同時更換網域
情境：
- 原站：
https://old-example.com - 新站：
https://new-example.com - CMS：WordPress 不變。
- 路徑：大多保留，少數頁面整併。
- Email：新舊網域信箱另有獨立計畫。
- 目的：品牌改名並更換主機。
- 驗證新舊網域、DNS、主機及 Search Console property。
- 查新網域是否有舊站、手動處置或 URL 移除紀錄。
- 完成檔案、資料庫、DNS 及追蹤基準。
- 從 sitemap、GSC、GA4、log、CMS 及外部連結建立 URL inventory。
- 為每個舊 URL 決定新 URL、404 或 410。
- 先用一筆 mapping 驗證產生規則，再批次建立。
- 新站更新 canonical、內鏈、hreflang、schema、Open Graph 及 sitemap。
- 新舊網域的 Email 與 DNS 紀錄分開規劃。
- 在 staging 測試新網域完整功能及轉址。
- 完成最後資料同步。
- 讓新網域提供正式內容及有效 TLS。
- 在舊網域啟用逐頁 301／308 到最終新 URL。
- 移除新站的
noindex及正式站封鎖。 - 確認新頁 canonical 指向自己。
- 提交新 sitemap。
- 符合條件時，在舊 Search Console property 送出 Change of Address。
- 測試重要舊 URL、外部連結、媒體及子網域。
- 監控新舊網址的 crawl、索引、404、soft 404 及轉址。
- 比較 GSC 與 GA4 的 landing page 轉移。
- 更新公司控制的站內連結、社群、商家檔案及高流量外部連結。
- 保留舊網域及永久轉址一般至少一年，並評估長期維持。
- 持續續約舊網域、DNS 及轉址層憑證。
- 等索引及商業流程穩定後，再執行舊 CMS 與主機的資料退場。
來源：GA4 到達網頁官方說明、GA4 報表官方說明與GA4 DebugView 官方說明（查證 2026-08-03）。搬家前後應以相同資料期間、事件設定與 URL 口徑比較。
兩個示例的驗收差異
| 驗收項目 | 保留網域 | 更換網域 |
|---|---|---|
| 公開 URL | 應完全不變 | 每個舊 URL 有新目的地或明確退場 |
| DNS | 網站紀錄指向新主機 | 新網域指向新站，舊網域保留轉址 |
| 301／308 | 通常不因換主機新增 | 逐頁 permanent redirect |
| canonical | 應維持原 URL | 新頁指向新 URL 自己 |
| sitemap | URL 通常不變 | 只列新 URL |
| 內部連結 | 應維持原正式 URL | 全部直接連新 URL |
| Search Console | 保留原 property 及驗證 | 驗證新舊 property，符合條件時 Change of Address |
| 舊環境 | 流量歸零後可退場 | 舊 CMS 可退場，但舊網域轉址要保留 |
| 主要風險 | 新環境內容、功能及爬蟲存取不同 | mapping、轉址、索引及舊網域續用 |
兩種情境都需要備份、staging、功能測試、追蹤驗證與監控。差別不是「有沒有 SEO」，而是 URL 改變後多出一整套搜尋訊號及使用者路徑遷移。
來源：Google 不改 URL 的主機搬遷流程、Google URL 變更的網站遷移流程與Search Console Change of Address 官方說明（查證 2026-07-24）。只換主機的正式切換由 DNS 完成；更換網域還要建立 mapping，永久轉址並依條件向 Search Console 通知網址變更。
內文精華總結
- 網站搬家是什麼？主機、網域、DNS、CMS 與網址怎麼分：網站搬家是把網站提供內容與功能所需的全部或部分資產，從現有環境轉到新環境。
- 網域註冊商與網站主機不是同一件事：網域可以在 A 公司註冊，DNS 由 B 公司代管，網站放在 C 公司，企業信箱使用 D 公司的服務。
- DNS 不是網站專用設定：因此，不要為了搬網站直接把 nameserver 改成新主機商提供的值，除非已先逐筆核對及建立所有必要紀錄。
- CMS 搬移不只包含檔案：只複製 wp content 會漏掉資料庫及網站設定；只匯出文章，可能漏掉媒體、選單、外掛資料及自訂資料表。
想把網站搬家規劃成能長期營運的網站？
先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。
- 1 小時免費試用：不必信用卡，先確認後台與編輯流程是否適合。
- 查看秒站方案：標準方案 NT$24,000、專業方案 NT$36,000、輕電商方案 NT$48,000 年費。
- 瀏覽 80+ 真實案例：從不同產業的內容、版型與功能安排找參考。
延伸閱讀
網站基礎建設系列文章
- 企業信箱怎麼選？Google Workspace、Microsoft 365 與台灣服務比較
- 網域轉移教學 2026｜授權碼、DNS、Email 與停機風險一次看
- 網站改版前要準備什麼？保留 SEO、內容與數據的 12 項清單
秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。
重點整理
網站如何搬家？
網站搬家是把網站提供內容與功能所需的全部或部分資產，從現有環境轉到新環境。它可能只是更換主機 IP，也可能包含換網域、換 CMS、重做版型及改網址結構。
WordPress 如何搬家？
依序備份網站檔案與資料庫，建立新環境並匯入，調整設定後用 hosts 或暫時網址測試。切換前做最終同步，再更新 DNS，驗收前台、後台、表單、排程及追蹤，並保留舊環境供監控與回復；若同時換網域，另做逐頁 mapping 與 301。
只換主機需要 301 嗎？
這是 SEO 搬遷相對單純的情況。使用者仍開啟同一個網域與路徑，搬家動作由 DNS 切換到新基礎設施完成。Google 的不改 URL 主機遷移文件建議，可在搬遷前至少一週把 TTL 調到保守的較低值，例如數小時，讓快取較快更新。這只是規劃範例，不代表每個 DNS 供應商都會在固定時間完成傳播；實際值及生效情況要由公開 DNS 查詢與新舊主機 log 驗證。
網域可以改嗎？
可以，但換網域會讓公開 URL 改變，必須建立逐頁 mapping，永久轉址，並更新 canonical、內鏈及 sitemap，同時監控新舊 Search Console。不要把換網域與單純轉移註冊商或改 DNS 混為一談。
網域轉移要多久？
若指註冊商轉移，時程依 TLD、註冊商及網域狀態而異；若指 DNS 生效，也沒有適用所有設定的固定時間。轉移前先確認你要換的是註冊商、DNS 代管、網站主機或網域名稱，再查相應規則。
搬家會不會掉排名？
可能暫時波動，無法保證零影響。主要變因包括轉址是否逐頁正確、內容與內鏈是否保留、canonical、robots、sitemap、網站效能及新伺服器容量；上線後要持續看抓取、索引、流量與轉址錯誤。
DNS、Email 與網站是否要一起轉？
更換 nameserver 或匯入不完整 DNS zone 時，最容易漏掉 MX、SPF、DKIM、DMARC 及郵件服務驗證紀錄。網站首頁正常，不代表企業信箱也正常。網站與企業信箱可以共用網域，但兩者是不同服務。沒有信箱搬遷需求時，不應因換網站主機順便更動 MX。搬家前完整匯出 DNS。；把網站紀錄與郵件紀錄分組審核。；只改真正需要變更的網站紀錄。
URL mapping 怎麼做？
資料合併前先顯示一筆 sample row，確認欄位解析正確。例如： old url=https://old.example.com/service a/ new url=https://new.example.com/services/a/ expected status=301 確認 parser 取得的 old url、新 URL 及狀態欄位正確後，再 batch 處理全集。
