如何遷移網域而不拖垮搜尋排名

更換網域是少數幾種 SEO 專案之一：技術上看似很小的錯誤，可能很快變得非常顯眼。少了一個重新導向、封鎖了爬取路徑，或忘了設定 canonical，都可能把一次單純的品牌重塑變成數週的排名波動。

有些變動是正常的。搜尋引擎需要時間爬取舊 URL、發現重新導向、處理訊號，並讓新網域穩定進入索引。目標不是避免每一次下滑。目標是讓遷移變得乏味：一個舊 URL 指向一個對等的新 URL，伺服器回應清楚，而且重要內容沒有消失。

從盤點開始，而不是從重新導向規則開始

最常見的遷移失敗，是把它當成伺服器設定任務。它不是。它是資訊架構任務，只是最後會落到伺服器設定上。

在碰 DNS 之前，先建立一份重要 URL 清單：

• 有自然搜尋流量的 URL
• 有外部反向連結的 URL
• 會帶來轉換、潛在客戶，或支援行銷活動的 URL
• 目前 XML sitemap 中的 canonical URL
• 被外部連結的 PDF、圖片與可下載檔案
• 高價值的舊 URL，即使它們可能已不在目前導覽中

為每個舊 URL 指定新網域上的目的地。多數情況下，目的地應該是意圖相同的同一個頁面。如果 /pricing 變成 https://newdomain.com/pricing，那很簡單。如果三個舊產品頁要合併成一篇新指南，請有意識地記錄這個決策。

避免偷懶的模式：把所有內容都重新導向到新首頁。這很方便，但會丟掉相關性。搜尋引擎和使用者都期待目的地能回答原始 URL 所對應的同一個需求。

能保留 URL 結構就保留

當路徑保持穩定時，網域遷移會容易得多。從 oldsite.com/blog/example 移到 newsite.com/blog/example，遠比同時更換網域、CMS、slug、資料夾結構與內容來得乾淨。

有時重新設計或 CMS 遷移會讓 URL 變更無可避免。若是如此，請把決策拆開：

1. 哪些變更是因為網域改變？
2. 哪些變更是因為網站結構改變？
3. 哪些內容會被刪除、合併或重寫？

你引入的變數越多，之後診斷問題就越困難。如果遷移很重要，而且目前網站表現良好，可以考慮先遷移網域，之後再重新設計。

使用永久、單一跳轉的重新導向

對真正的網域遷移而言，請使用伺服器端 301 或 308，將舊 URL 重新導向到對應的新 URL。暫時重新導向適用於暫時情境。JavaScript redirects、meta refreshes 與 soft redirects 都是較弱的訊號，也更容易出錯。

你的重新導向目標很簡單：

• 每個重要舊 URL 都回傳永久重新導向。
• 每次重新導向都直接前往最終目的地。
• HTTP 能乾淨地重新導向到 HTTPS。
• www 與非 www 版本被一致處理。
• 除非必要，重新導向不要依賴脆弱的 query-string 行為。

糟糕的鏈結會像這樣：

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

它最後也許會到正確頁面，但速度慢、較難爬取，也更容易掩蓋錯誤。目標是讓每個舊版本都只跳一次，就到最終的新 URL。

驗證行為時，請檢查實際的 HTTP 回應，而不是相信瀏覽器呈現的結果。我們的在正式環境中偵錯重新導向與 HTTP headers 的小工具包在這裡很有用，因為瀏覽器太有禮貌了：它們會跟著整條鏈走，並把混亂的部分藏起來。

上線前準備好 DNS 與憑證

DNS 不會直接轉移排名，但糟糕的 DNS 會讓遷移看起來像壞掉了。在上線窗口前降低 TTL 值，讓變更更可預期地傳播。確認新網域已為網站流量、電子郵件與任何必要子網域設定正確記錄。

你也需要為兩個網域準備有效的 TLS 憑證。這很容易被忽略。遷移後，舊網域仍需要提供 HTTPS 重新導向。如果它的憑證過期，使用者和爬蟲可能還沒到新網站，就先遇到瀏覽器警告。

如果這次搬遷影響電子郵件，不要把它當成事後補充。網域變更常會破壞 SPF、DKIM、DMARC、MX records、追蹤連結與交易郵件。若想複習哪些記錄重要，請參考我們為開發者撰寫的 MX、SPF、DKIM 與 DMARC 指南。

檢查 canonicals、內部連結與 sitemaps

上線後，新網域應該表現得像它一直都是內容的 canonical 主站。

這表示：

• Canonical tags 指向新 URL，而不是舊網域。
• 內部連結使用新網域或根目錄相對路徑。
• XML sitemaps 只包含最終、可索引的新 URL。
• 若使用 hreflang annotations，需參照新 URL。
• Open Graph、structured data 與 alternate links 都已更新。
• Robots.txt 不會封鎖重要區段。

不要發布一份塞滿舊 URL 的 sitemap，然後期待重新導向替你清理。一份 sitemap 應該列出你想被索引的 URL。遷移後，這代表新網域上的最終 URL。

也要留意 canonical 矛盾。某頁從舊網域重新導向到新網域，但 canonical 又指回舊網域，這會送出混合訊號。搜尋引擎通常能處理一些不一致，但你不應該要求它們這麼做。

不要在上線當天改變所有事情

遷移本身已經是足夠大的事件。如果可以，避免同時進行大型內容刪減、模板重寫、導覽變更、JavaScript rendering 變更，或導入新的效能輪廓。

這不是迷信，而是偵錯紀律。如果上線後排名下滑，你需要知道原因是重新導向對應、爬取存取、內容變更、渲染變慢、structured data 遺漏，還是其他問題。

初次上線應盡量接近舊站的狀態。等新網域穩定後，再以較小批次進行較大的編輯與設計變更。

告訴搜尋引擎發生了什麼變化

在 Google Search Console 中，驗證舊網域與新網域。接著，當這是網域層級變更且內容正在移到新網域時，使用 Change of Address 工具。上線後提交新的 sitemap。

這無法取代重新導向。它是支援重新導向。搜尋引擎仍需要可爬取、持續存在的重新導向，才能理解 URL 層級的對應。

對 Bing 與其他搜尋引擎，請在可用時使用它們的 webmaster tools。也更新你能控制的地方：社群檔案、商家資訊、廣告目的地、電子郵件頁尾、文件、合作夥伴連結，以及同步發布內容中的 canonical references。

外部連結不會全部被更新，這沒關係。但最重要的那些應該要更新。如果主要合作夥伴、app marketplace、文件入口網站或媒體頁面連到舊網域，請要求更新。

上線後監控正確的項目

遷移後的前幾天應該是主動監控，而不是慶祝。

檢查：

• 伺服器紀錄中舊網域與新網域的爬取活動
• 404 與非預期的 5xx errors
• Redirect chains 與 loops
• Search Console 中的索引狀態
• Sitemap 發現與處理情況
• 自然搜尋到達頁與查詢模式
• 依賴舊 URL 的轉換路徑
• Analytics filters 與 referral exclusions

預期報表會有雜訊。有些 analytics tools 若未正確設定，會把新網域視為新資源。有些儀表板會比較舊網域流量與新網域流量，讓遷移看起來比實際更糟。

搜尋能見度可能會波動幾週。你不希望看到的，是高價值舊 URL 被反覆爬取卻沒有正確重新導向，或新頁面被發現後卻標記為舊網域的重複內容。

效能也不該被忽略。如果新網域上線時帶著更重的模板、壞掉的快取，或未最佳化的資產，使用者可能會把遷移感受為變慢。如果你把 Lighthouse 納入檢查，請帶著優先順序閱讀；我們的如何閱讀 Lighthouse 報告而不驚慌說明了如何把有意義的問題與雜訊區分開來。

長期保留舊網域

不要在遷移「成功」後就讓舊網域過期。請維持註冊、維持憑證有效，並盡可能長時間地保持重新導向運作。實務上，這通常代表好幾年。

舊連結會持續存在於部落格文章、書籤、文件、PDF、電子郵件與社群貼文中。重新導向是這些歷史足跡與新網域之間的橋樑。太早關閉它們，會中斷使用者路徑，也浪費累積的訊號。

也請保留一份重新導向對應表與上線紀錄。六個月後，當有人問某個舊 URL 為什麼會有特定行為時，你會很慶幸自己有記錄下來。

<!-- tool-cta:start -->

💡 試試這個： 切換完成後，透過 Redirect Checker 追蹤你的舊 URL，以確認每個舊 URL 都只經過一次 301 跳轉就解析到正確的新頁面。

<!-- tool-cta:end -->

一份合理的遷移檢查清單

上線前：

• 在 Search Console 中驗證兩個網域。
• 爬取目前網站並匯出重要 URL。
• 建立一對一重新導向對應表。
• 降低 DNS TTL。
• 為舊網域與新網域準備 TLS 憑證。
• 更新 canonicals、內部連結、hreflang、structured data 與 sitemaps。
• 在 staging 或受控環境中測試重新導向。

上線當天：

• 部署重新導向。
• 確認 HTTP 到 HTTPS 的行為。
• 從每種模板類型中抽樣測試重要 URL。
• 提交新的 sitemap。
• 在適當情況下使用 Change of Address 工具。
• 監看伺服器錯誤、redirect loops 與被封鎖的資源。

上線後：

• 監控爬取錯誤與索引報告。
• 盡可能更新重要外部連結。
• 依到達頁意圖比較流量，而不只是比較網域總量。
• 無限期維持重新導向運作。
• 等遷移穩定後，再進行無關的重新設計或內容實驗。

網域遷移並非零風險，但可以管理。排名通常會在遷移送出不清楚訊號時受損：缺少重新導向、內容改變、canonical 矛盾、爬蟲被封鎖，或舊網域被遺忘。給搜尋引擎與使用者一張清楚的地圖，這次搬遷就會少很多戲劇性。