網站改版完成，畫面更整齊、功能也更新了，卻發現原本的搜尋流量下降，重要文章找不到，甚至客戶從舊連結進來只看到錯誤頁。
這些問題不一定是設計本身造成，而可能來自網址對應、內容刪改、索引設定、內部連結或追蹤中斷。若等上線後才處理，團隊往往已經缺少舊站資料，難以判斷改了什麼。
網站改版要降低 SEO 流失風險，不能只在最後加上 301 轉址；需要從改版範圍、舊站盤點與網址對應開始，連同功能驗收及上線後監測一起安排。 以下以既有網站改版與網址遷移為主，整理企業可以交辦的工作，不承諾改版後完全沒有搜尋波動。
若想先掌握 SEO 的全貌，可參考〈完整 SEO 入門教學〉，本文的主題是其中的「技術體質」。
網站改版如何降低 SEO 流失風險？先界定變更範圍
版型、內容、網址、網域與系統變動的影響不同
先列清楚這次改版會改哪些項目。只是更新視覺，與同時更換內容管理系統、網址結構及網域，涉及的工作不同。
即使網址不變，正文、標題、導覽或載入方式改變，也可能影響內容理解與使用。若網址變更，則需要舊新對應與轉址；若網域變更，還要確認舊站維持、Search Console 資源與適用的遷移工具。
Google 的網站遷移說明建議盡量不要同時變更所有事情。例如換網域、換系統與換版型，可以評估分階段處理，讓異常比較容易定位。實際發布方式仍要依網站規模、系統限制與使用者需要安排，不是所有網站都適合逐頁分批搬遷。
改版可以管理風險，但不能保證零波動
Google 官方提醒，重大變更與網址遷移期間，搜尋可見度可能暫時波動。企業不應把「已做轉址」理解為排名與流量完全不變的保證。
可管理的，是內容是否保留、網址是否合理對應、網站是否正常，以及異常是否能快速發現。不能直接控制的，則包括搜尋系統何時重新處理所有網址，以及相關查詢的後續表現。
因此，改版驗收要分成工作與結果。工程與網站團隊可以核對部署、回應及功能，SEO 團隊可以核對索引訊號與網址關係；搜尋流量與商機則需要後續觀察。
上線前一：盤點舊站價值與建立基準
重要網址、內容、查詢、連結與詢問資料如何保留？
先保存舊站網址清單、主要內容與設定，再整理搜尋及業務資料。不要只備份首頁畫面，也不要只保留流量最高的幾篇文章。
重要頁面可以包含服務入口、帶來相關查詢的內容、被外部網站引用的資料，以及業務常分享給客戶的頁面。流量小但承接合作評估的頁面，也可能具有價值。
| 盤點項目 | 建議保存的資料 | 用途 |
|---|---|---|
| 網址與內容 | 完整網址、頁型、標題、正文與重要附件 | 確認搬移與內容差異 |
| 搜尋表現 | 查詢、頁面、曝光與點擊的期間及篩選 | 建立可比較的基準 |
| 連結與入口 | 重要內部連結、外部引用與業務分享頁 | 避免既有閱讀路徑失效 |
| 網站與商機 | 來源定義、聯絡事件與有效詢問紀錄 | 分辨需求與承接變化 |
| 技術設定 | 索引指示、Canonical、Sitemap 與既有轉址 | 避免舊規則遺失或互相衝突 |
保存資料時要確認權限與保密，公開範例則使用授權或去識別化材料。企業不必把所有客戶資料交給每個合作方，應依工作提供必要範圍。
哪些內容要搬移、更新、整併或保留？
每個舊頁面都應有處置，不只是「有流量就留，沒流量就刪」。先確認頁面用途、資料是否過期、與新站其他內容是否重複，以及是否仍支持企業服務。
內容整併時，要確認新頁面真正保留了舊頁的重要答案，不能只保留標題就視為完成搬移。更新服務頁，也應確認範圍、案例、限制與聯絡方式沒有漏掉。
可以將處置分成原樣搬移、更新、合理整併、保留原網址，以及移除無替代內容。每項決定留下理由與核准者，後續才知道流量變化是否與刻意調整有關。
上線前二：建立舊新網址對應與轉址計畫
一對一或合理整併對應，不全部導向首頁
舊網址應指向能滿足原本需求的新頁。相同文章更換路徑，可以建立一對一對應；多篇內容整併，則可以對應到完整承接內容的新頁。
Google 官方提醒避免不相關轉址，將大量舊網址全部導向不相關的首頁，可能讓使用者困惑，也可能被視為 soft 404。首頁存在，不代表它是所有舊頁的合理替代。
以下是假設性的網址規劃示例，不是實際網站設定：
| 舊內容 | 新站安排 | 建議處理方向 |
|---|---|---|
| 原服務頁，路徑改名 | 相同服務的新頁 | 直接對應新網址，核對完整內容 |
| 兩篇重複說明 | 已整合答案的新文章 | 對應實際承接內容的整併頁 |
| 已停止且沒有替代的內容 | 無新頁面 | 評估合理移除與正確回應 |
| 持續使用的文章 | 網址與內容保留 | 不因改版就強迫更換路徑 |
正式對照表要填完整網址、處置理由、預期回應與檢查結果，也要涵蓋重要參數版本、附件或其他舊入口，不只看網站選單中列出的頁面。
永久轉址、失效頁及無替代內容需分別評估
Google 的轉址說明建議永久搬移時，盡可能使用伺服器端永久轉址。HTTP 301 與 308 都表示永久搬移；暫時安排則需要依用途採適當的暫時轉址，不能全部當成同一種訊號。
轉址應盡量直接到最終新頁，避免 A 到 B、B 再到 C 的不必要鏈條，也不能形成循環。實作由工程依伺服器與系統確認，不適合直接套用不明來源的通用規則。
對沒有合理替代的已移除內容，可以依實際情況回傳 404 或 410，而不是硬導首頁，或回傳正常狀態卻只顯示「找不到內容」。有用的錯誤頁導覽與正確 HTTP 回應，可以同時存在。
轉址不是上線後幾天的臨時措施。Google 建議遷移轉址盡可能保留，通常至少一年；從訪客使用角度，也可以評估更長期維持。這是維護建議，不代表一年後所有網址或成果一定完成轉移。
上線前三：測試內容、索引設定與重要功能
標題、正文、Canonical、內部連結與 Sitemap 是否一致？
測試站驗收應對照舊站資料與核准的新內容，確認標題、正文、重要圖片與附件沒有漏移。頁面可以正常開啟，不等於內容已完整搬移。
新頁的 Canonical、站內連結與 Sitemap，也應支持正式的新主要網址。不要一邊轉址到新頁，一邊讓新頁指回舊站或測試網域。若要確認不同轉址的差異與適用情境，可以接著閱讀〈301、302、307、308 轉址的差異〉。
站內連結應直接更新為新網址，不只依賴轉址讓舊連結繼續可用。Sitemap 則核對正式版本與處理狀態，避免包含測試頁、錯誤網址或不應索引的內容。
測試環境限制、行動閱讀、表單及追蹤是否驗證？
測試環境可以有必要的存取與索引限制，但要明確記錄正式發布時哪些設定需要變更。全站 noindex、robots.txt 封鎖或登入要求，不應誤留在預期公開的正式頁面。若要分清楚這幾種索引設定各自負責什麼，推薦搭配〈robots.txt、noindex 與 Sitemap 的差異〉一起閱讀。
也要避免反過來移除測試站應有的保護。正式站與測試站是不同環境，需要各自驗收，不能只用「網站開了」一句話處理。
重要功能要實際操作：行動版導覽是否可用、表單成功與錯誤提示是否正常、實際收件是否完成，以及電話、LINE 與必要追蹤是否仍符合原定規劃。測試資料與真實名單要分開，並按同意與隱私要求驗證。
上線當天：按清單確認實際網站
抽查重要網址回應、轉址鏈及目標頁內容
測試站通過後，正式環境仍需要檢查。部署、快取、主機與網域設定，都可能讓實際結果與測試不同。
重要網址應逐一驗收，其他網址則可以搭配批次測試與分頁型抽查。不要只看瀏覽器最後停在哪一頁，也要核對過程中的回應與轉址目標。
| 上線檢查 | 建議確認內容 |
|---|---|
| 舊網址 | 回應是否符合對照表，是否直接導向合理新頁 |
| 新網址 | 正常提供完整內容，無錯誤或循環轉址 |
| 索引設定 | 無誤設 noindex 或檢索限制，Canonical 正確 |
| 網站入口 | 導覽與相關連結使用正式新網址 |
| Sitemap | 可取得，網址與主要版本一致 |
| 聯絡與追蹤 | 表單收件、聯絡入口、事件與同意管理正常 |
這是交付檢查，不代表搜尋系統已完成處理。每項結果應記錄日期、責任與異常，不能只有一張首頁截圖。
確認正式站可存取，必要帳號與監測仍有效
若更換網域或主機，確認必要的網域、憑證與服務管理能力，並保留企業可使用的帳號與權限。舊站轉址所依賴的網域與服務，也不能過早停用。
Search Console、分析與標籤工具需要按新架構檢查。不要為了換網站就任意重建所有資料來源，造成基準中斷；必要變更則記錄日期與口徑差異。
網域或子網域遷移時，可核對Google 地址變更工具的適用說明。它不是所有改版都要使用的步驟，同網域路徑變更、HTTP 改 HTTPS，或同網域 www 與非 www 的切換，不需要以這個工具處理。
上線後：分層觀察異常並安排修復
索引、錯誤網址、重要頁面及相關查詢如何追蹤？
上線後，先追蹤是否出現實際故障，再看索引與搜尋變化。重要頁面不能存取、轉址錯誤或正式站仍有 noindex，不應因為「遷移本來會波動」就延後修復。
可以搭配 Search Console 網址檢查、索引報表與搜尋表現，確認新舊主要頁的變化。舊網址逐漸減少、新網址逐漸出現，需要對照處置計畫，不把每個舊網址不再索引都視為損失。
同時檢查仍被訪客使用的失效入口。若是對照表遺漏，補上合理安排；若內容刻意移除，則確認回應與使用者導覽。問題分類清楚，才能避免把所有 404 一律導向首頁。
流量、有效詢問與季節性分開比較
流量比較先核對追蹤是否正常，日期、來源與指標是否一致。若改版時改了事件或資料來源，數字下降可能包含量測差異，不宜直接歸因於搜尋流失。
也要分開重要頁面、品牌與非品牌需求，以及不同地區或裝置。整站總量可能掩蓋個別服務頁的問題，首頁仍有流量也不能證明所有搬移都成功。
有效詢問與業務進度另行核對，不把表單事件數直接當成名單數。季節性、同期廣告、內容刪改與市場需求，也需要一起記錄，避免把所有變化都歸給改版。若要確認優化做完之後怎麼評估成果，可參考〈評估 SEO 優化成果的檢查方法〉。
企業怎麼指定責任與回退條件？
工程、內容、SEO 與網站商的交付節點要對齊
企業需要有人負責整體上線決定，而不只是請各合作方完成自己的部分。內容確認搬移與更新，工程確認轉址與部署，SEO 核對搜尋相關訊號，分析與業務核對聯絡及資料。
建議在發布前確認：誰核准舊新網址對照、誰實作轉址、誰驗收正式站，以及哪些問題未解決就不能發布。缺少存取權限、重要內容未核准或表單無法收件，都不能在上線後才第一次發現。
會議紀錄要留下未完成事項與相依條件。如果網站商已部署，但企業尚未驗收內容，就不能將整個改版寫成全部完成。
記錄異常、修復與必要回退方案，不盲目重做改版
上線前就應安排可用的備份、回復方式與決策權限。重要頁面大範圍失效、核心聯絡流程故障，與短期排名變化，是不同層次的情況，需要不同處理。
回退不只是把版型換回去。網址、轉址、系統資料與上線後新增紀錄，都可能需要協調，應由工程確認可行性與資料完整性。
若只是局部問題，優先修復明確錯誤；若需要回退，也應記錄原因、範圍與後續網址安排。不要因為一天流量下降，就反覆搬回舊站，再重新發布，讓版本與訊號更加混亂。
網站改版沒有通用的搜尋恢復日期，也不能保證完全不流失。企業可以做到的是保留舊站價值、建立合理對應、驗收重要功能，並讓異常有明確負責人。
降低 SEO 流失風險的關鍵，不是「有做 301」，而是每個重要舊網址都有合理處置，新站內容與設定一致，而且上線後能持續核對與修復。
把這些工作放進改版計畫，SEO 才不會成為最後補救的項目，而是網站交付與合作管理的一部分。
延伸閱讀
- 〈Canonical 是什麼？重複內容與網址版本該怎麼處理〉：重複內容與網址版本的處理
- 〈網站速度與 Core Web Vitals 怎麼改善？SEO 與使用者體驗的優先順序〉：網站速度與 Core Web Vitals 的改善順序