網站搬家不掉排名 SOP：中小企業老闆換廠商前必做的 7 步驟 SEO 體檢與遷移路線圖

這個搬家案，我們搞砸過。

2023 年底，一家做 B2B 工業零件的台中客戶找上恆遠數位行銷，想把五年前的老 WordPress 站換到新的主機商、同步重做視覺。我們評估後點頭接了，以為只是換個門面。上線第 14 天，客戶打電話進來：「你們知道我的流量掉了 73% 嗎？」

根據 Ahrefs 的網站遷移研究，每 4 家換站的企業就有 1 家在遷移後 30 天內掉超過 30% 的自然流量。我們那次就是活生生的反面案例——redirect 設錯了 3 個關鍵頁面，hreflang 沒更新，Sitemap 指向舊 URL，Google 花了將近八週才重新爬回原本的收錄量。那 8 週，客戶的詢問單掉了快一半。

從那次之後，我們把所有教訓整理成一份可執行的 SOP。這篇文章，就是那份 SOP 的完整公開版。如果你是中小企業老闆，正在考慮換廠商、換主機，或者要大改網站架構，這 7 個步驟是你在動工前必須親自過一遍的清單。

為什麼網站搬家會掉排名：3 個技術根因

很多老闆的直覺是「換個主機、URL 不變，應該沒事」。但 SEO 的排名訊號比你想的複雜：Google 記的不只是 URL，還有那個 URL 背後累積的 PageRank、內容相關性、使用者體驗訊號、以及 Crawl Budget 的分配節奏。

根因一：redirect chain 與 404 的連鎖反應

網站搬家時最常見的是 URL 結構改變——例如從 /product?id=123 改成 /products/zero-part-123/。若沒有設定正確的 301 redirect，Googlebot 進舊 URL 拿到 404，那個頁面累積的所有外部連結權重就此蒸發。更糟的是 redirect chain：A→B→C 三層轉跳，PageRank 每層折損約 10-15%，三層後你的傳遞效率可能只剩 70%。

根因二：Crawl Budget 重置與爬取優先序混亂

換主機或換域名後，Google Search Console 會把新站視為一個全新的實體，Crawl Budget 從零開始重新分配。如果新站有大量重複頁面（沒清 staging 環境、沒設 canonical）、或者 robots.txt 設定錯誤封鎖了重要目錄，Googlebot 就會把寶貴的爬取配額浪費在低價值頁面，真正重要的轉換頁可能要等幾週才被重新收錄。

根因三：技術訊號斷層——Schema、hreflang、Sitemap 三件套同時失效

很多遷移案只處理「頁面內容」，卻忘了附屬的技術標記也需要一起遷移並更新。Schema markup 裡的 URL 指向舊站、hreflang 的 x-default 沒更新到新域名、Sitemap 裡面混雜了舊 URL——這三件事同時發生，Google 會在混亂中降低對新站的信任度，排名在遷移後短暫上升後再次墜落（業界稱這個現象為 post-migration dip）。

知道根因之後，解法就清晰了。以下 7 步驟，是在你跟新廠商簽約、正式動工之前就該完成的體檢流程。

換廠商前必做的 7 步驟 SEO 體檢

把這 7 步驟當成「搬家前的房屋健檢報告」：每一項都要有明確的基準數字，這樣遷移後才知道哪裡出了問題。

步驟 1：建立 URL 完整清冊（Crawl Baseline）

用 Screaming Frog 或 Ahrefs Site Audit 把現有網站完整爬一遍，匯出所有 URL、HTTP 狀態碼、title、meta description、H1、內部連結數、外部連結數、以及每個頁面的自然流量（串接 GSC）。這份清冊是整個遷移的地基——沒有它，你就不知道有哪些 URL 需要做 redirect，也不知道遷移後哪些頁面流量異常。

最重要的子集是「流量 TOP 20% 頁面」：通常這 20% 貢獻了 80% 的自然搜尋流量。遷移時這些頁面的 redirect 必須優先處理、反覆驗證，絕對不能有任何遺漏。

步驟 2：截圖並匯出 Google Search Console 指標基準

在動工的前一天，登入 Google Search Console，匯出以下三份數據：① 過去 90 天的 Search Performance（query + page 維度），② 覆蓋率報告（索引狀態），③ 核心網頁指標報告（CWV）。這三份數據是遷移後「是否有掉」的比對基準。

特別注意：如果你的網站有跑廣告，還要記錄 UTM 參數的頁面 URL 格式，因為改版後這些 URL 可能會跟著改變，廣告追蹤會斷掉。關於核心網頁指標的監控邏輯，可參考 這篇 Core Web Vitals 完整指南，裡面有詳細的 LCP / INP / CLS 監控框架。

步驟 3：外部反向連結清冊（Backlink Audit）

用 Ahrefs 或 Moz 匯出所有外部反向連結，特別是 Domain Rating > 30 的高權重來源。這份清冊有兩個用途：一是確保遷移後這些外鏈的目標 URL 都有對應的 301 redirect；二是在遷移後主動聯繫重要外鏈來源，請他們直接更新連結到新 URL，避免長期依賴 redirect 傳遞權重。

步驟 4：內容重複性與 canonical 設定檢查

爬取報告跑出來後，重點檢查三類問題：① 重複的 title + meta description（通常是 CMS 自動產生的分頁或標籤頁），② 缺少 canonical 的動態 URL（例如帶 ?sort= 或 ?page= 的篩選頁面），③ 未正確封鎖的 staging / testing 環境頁面。這些問題若帶著一起搬到新站，會讓 Crawl Budget 的浪費從舊站複製到新站。

步驟 5：撰寫舊新 URL 對應表（Redirect Map）

用 Google Sheets 建立一張三欄表格：舊 URL ｜新 URL ｜狀態碼（301 或 302）。這張表格是交給新廠商的核心交接文件之一。原則上除非是臨時性搬遷，所有永久性的 URL 變更一律用 301，不用 302。

這張 Redirect Map 必須涵蓋：流量 TOP 20% 的頁面、所有外部反向連結指向的 URL、所有在 GSC 有收錄記錄的 URL。如果是域名遷移（換網域），還要把根域名的 redirect 也列進去（http://old.com → https://new.com，以及 www/non-www 的四種組合）。

步驟 6：新站上線前的 Staging 環境驗收清單

要求新廠商提供 staging 環境讓你驗收，逐項確認以下技術指標再點頭上線：

• robots.txt 是否正確（staging 封鎖 index，正式版開放）
• Sitemap.xml 是否存在且包含正確的新 URL
• canonical 標籤是否指向正確的新版 URL（而不是 staging 域名）
• SSL 憑證是否安裝，HTTPS 是否正常跳轉
• Schema markup（Organization、LocalBusiness、Article）是否更新為新 URL
• hreflang（若有多語言版本）是否更新
• Google Analytics 4 追蹤碼是否正確埋入
• Google Tag Manager container 是否匯入並啟用
• Core Web Vitals 初步測試（PageSpeed Insights / Lighthouse）
• 404 頁面是否自訂，且包含網站地圖入口

步驟 7：DNS 切換後 72 小時緊急監控協議

DNS 切換後的前 72 小時是最高風險期。這段時間要每 4 小時確認一次：① Screaming Frog 快速爬取新域名確認 redirect chain 是否正常，② GSC 是否有新的爬取錯誤訊息，③ 流量是否開始從舊站往新站轉移（GA4 即時報表）。

如果在 48 小時內發現重大 redirect 錯誤或大量 404，要立即暫停並先用 DNS 切換回舊站，避免損失繼續擴大。這個「緊急回切」的決策點要在上線前就跟廠商白紙黑字寫清楚。

5 個 Redirect 紅線：廠商常犯、老闆一定要親自驗

根據 Search Engine Land 的 redirect 最佳實踐，以及Google Search Central 的站台搬遷指南，以下 5 種 redirect 問題是最常見也最容易造成 SEO 災難的：

紅線一：302 誤用（暫時轉址用於永久遷移）

302 是「暫時轉移」的語意，Google 遇到 302 時不會把 PageRank 傳遞給目標 URL，會繼續等舊 URL 恢復。如果廠商用 302 做永久域名遷移，你的舊域名排名不會轉移到新域名，通常要等 Google 自己「猜出來」這是永久搬遷才會切換——這個等待期可能長達數月。

紅線二：Redirect Chain 超過 2 層

A→B→C 三層 redirect，PageRank 傳遞效率下降明顯。更嚴重的是 Crawl Budget 浪費：Googlebot 每爬一個 URL 都消耗爬取配額，三層 redirect 等於消耗了 3 倍的配額來處理同一個 URL。檢查方法：用 Screaming Frog 開啟「Follow Redirects」模式爬完後，篩選 Redirect Chain = 3+ 的所有 URL。

紅線三：Redirect Loop（循環轉址）

A→B→A 的循環轉址會讓 Googlebot 直接放棄爬取，且前台使用者會看到瀏覽器的「ERR_TOO_MANY_REDIRECTS」錯誤。最常見的原因是 WordPress 插件的 canonical 設定跟 nginx redirect rule 互相衝突。上線前必須用 curl -L 追蹤每一個關鍵 URL 的完整跳轉鏈。

紅線四：Canonical 指向被 redirect 的 URL

如果頁面 A 的 canonical 指向的是 URL B，而 URL B 又 301 到 URL C，Google 會覺得你的 canonical 設定有問題，可能忽略 canonical 宣告。正確做法是 canonical 永遠指向最終的規範 URL（即 redirect 鏈的終點）。

紅線五：圖片 / CSS / JS 資源的舊路徑沒一起更新

很多遷移案只處理 HTML 頁面的 redirect，卻忘了頁面內嵌的靜態資源（圖片、CSS、JS 檔案）如果還指向舊 URL，瀏覽器會看到大量的 mixed content 警告或資源 404，直接影響 Core Web Vitals 的 LCP 分數。新站上線後，用 Chrome DevTools 的 Network 面板開啟幾個主要頁面，確認沒有任何資源回應 404 或 301。

3 個交接合約陷阱：簽約前必看的法律紅線

網站搬家不只是技術問題，還有一個老闆最容易忽略的面向：合約。換廠商時，你跟舊廠商的合約裡可能藏著幾個坑，踩到了輕則多花錢、重則整個域名或資料被鎖住。

陷阱一：域名代管在廠商帳號下，轉移需額外費用

台灣中小企業很常見的情況：當初請廠商幫忙申請域名，域名就登記在廠商的 DNS 代管帳號下。換廠商時才發現，要把域名轉移到自己的帳號，舊廠商可能收取「服務終止費」或拖延轉移流程（ICANN 規定域名轉移需要 60 天冷靜期後才能提出，很多廠商把這個規定當藉口拖延）。

對策：合約簽訂時就要在條款裡明定「域名登記人為甲方（你）」，廠商只是代管，且合約終止後 5 個工作日內必須配合完成域名轉移，否則視為違約。關於供應商合約陷阱，也可以參考 這篇客製化系統採購的合約紅線解析，同樣的合約邏輯適用於網站建置。

陷阱二：網站原始碼「智慧財產權屬廠商」條款

某些廠商的合約會在角落藏一句「本公司保留網站設計之著作權，授權甲方使用」。這表示你付了錢、網站在你手上，但原始碼的著作權不是你的——換廠商時，新廠商可能無法在舊的程式碼基礎上繼續開發，必須從頭重寫，成本直接翻倍。

對策：合約必須明定「乙方（廠商）開發完成之所有程式碼、設計稿、資料庫結構，驗收完成且款項結清後，著作財產權全部移轉予甲方」。

陷阱三：SEO 成效保證條款的「退路」文字

如果新廠商在提案時承諾「保證前三名」或「保證月流量成長 X%」，合約裡的對應條款你要特別檢查：成效計算的基準期是哪一段？不達標的違約金是多少？很多這類保證在合約裡會加上「不可抗力因素（含 Google 演算法更新）不在保證範圍內」——而 Google 幾乎每週都在更新某些演算法，這個條款等於讓保證完全形同虛設。

務實的做法：不要追求「排名保證」，改追求「可量化的技術交付清單」——例如「上線後 30 天內提交 Sitemap 並在 GSC 確認收錄率達 95%+」，這類指標才是廠商能真正控制的。

網站搬家決策與執行流程

以下是從「決定換廠商」到「上線後穩定期」的完整決策與執行路線圖：

上線後 90 天監控框架：數字會說話

「上線就完事」是網站搬家最危險的心態。Google 重新爬取、評估、排名調整的週期通常在 4-12 週之間，這段時間的異常必須及早發現、及早處理。

第 1-14 天：技術層確認期

重點是確認所有技術設定都正確執行，此時還不用擔心排名變化（排名這時候本來就會有些波動）。每日確認項目：GSC 爬取錯誤數量（目標 < 遷移前基準的 110%）、4xx 錯誤數（目標趨勢下降）、Sitemap 提交狀態、Search Impressions 趨勢。

第 15-30 天：收錄率穩定期

這個階段最重要的指標是「索引覆蓋率」——GSC 的「有效」頁面數應該在第 30 天回到遷移前的 90% 以上。如果到第 30 天收錄率還不到 80%，代表有系統性問題需要排查（最常見是 Sitemap 有錯誤、或是新站有大量的 5xx 伺服器錯誤導致 Googlebot 無法爬取）。

這個階段也要開始監控 Core Web Vitals 的實際數據（Field Data，而非 Lab Data）。如果 LCP 或 INP 在遷移後劣化，要立即跟廠商確認是主機效能問題還是前端程式碼問題。

第 31-60 天：排名回穩觀察期

第 30-60 天是排名最容易出現「post-migration dip」的區間。這個時期要每週比較：當前關鍵字排名 vs 遷移前基準（用 Ahrefs 或 Google Search Console 的排名追蹤功能）。重點追蹤流量貢獻前 20% 的關鍵字組，若超過 30% 的關鍵字下降超過 5 名且持續兩週，需要立即啟動技術稽核。

第 61-90 天：全面回穩驗收

第 90 天是整個遷移的結案節點。此時應該對照遷移前的基準，進行完整的 SEO 稽核：自然流量是否回到遷移前的 95% 以上、關鍵字排名是否穩定、外部反向連結的 redirect 是否仍然正常、Core Web Vitals 是否維持 Good 評級。若一切正常，可以進入日常維護模式；若仍有缺口，第 90 天的稽核報告就是向廠商追究責任的依據。

遷移到現代架構時的額外考量

近年來越來越多企業在換廠商時同步升級架構——例如從 WordPress 遷移到 Headless CMS，或從傳統 MPA 改成 Next.js 靜態站。這類「架構升級 + 網站搬家」同步進行的案子，SEO 風險是最高的，因為 URL 結構、渲染方式、技術標記都可能同時改變。

如果你在評估 Headless CMS 方案，可以先看 這篇 Headless CMS 採購指南，裡面有 Strapi / Sanity / Payload / Contentful 的 SEO 能力比較，可以幫你在選型階段就排除 SEO 風險較高的選項。

如果你的網站有 3D 互動或 WebGL 效果需求，換廠商時也要確認新廠商的技術能力，可以參考 這篇 WebGL 網站技術指南。技術選型的決策會直接影響遷移的複雜度和 SEO 風險。

下一步：讓搬家前體檢成為你的標準流程

網站搬家是一件一旦搞砸就要付出數個月流量損失的高風險決策。但它完全是可預防的——只要你在動工前把這 7 個步驟走過一遍。

如果你目前正在評估換廠商，或是已經接到廠商提案、不確定對方的技術能力是否足夠，歡迎聯繫恆遠數位行銷進行 SEO 遷移風險評估諮詢。我們的 客製化網站服務和 SEO 顧問服務在正式報價前都會先做這份體檢，讓你有足夠的資訊做決策。

想先看我們做過的案子？可以瀏覽 網站架設作品集，以及 WordPress 客製化案例。如果你的需求跨越網站架設與 SEO 整合，歡迎直接填寫需求表單預約諮詢。