網站改版如何保住搜尋訊號？從網址清冊到轉址驗證

先說結論：先保存「頁面對頁面」的關係，再更換網站外觀

網站改版無法保證搜尋排名完全不波動。真正能控制的，是讓每個舊 URL 都有清楚的新狀態：內容仍存在，就以伺服器端永久轉址送到最接近的新頁；內容已合併，就送到真正承接原需求的整合頁；沒有替代內容，就回傳 404 或 410，而不是全部塞回首頁。

要降低可避免的損失，依序做好四件事：

1. 改版前保存基線與網址清冊：盤點搜尋入口、外部連結、內部連結、索引狀態與頁面用途。
2. 為每個舊網址做明確映射：一對一優先，合併要有內容理由，刪除要回正確狀態。
3. 上線時讓訊號一致：永久轉址、canonical、內部連結、XML Sitemap 與實際內容都指向新 URL。
4. 上線後分層驗證：先查伺服器與轉址，再看爬取、索引，最後才判讀曝光與點擊。

Google 說明，重大網站搬移期間可能暫時出現排名波動，處理速度也會受網址數量與伺服器速度影響。因此目標不是承諾「零流量下降」，而是避免把技術錯誤誤認為正常等待，也避免同時改網域、內容、版型與追蹤，最後無法知道哪一項造成變化。

先分辨改版類型：網址不變與網址改變是兩套工作

「換網站」可能只是換主機，也可能連公開 URL 都改掉。兩者風險與做法不同，不能共用一張模糊的改版檢查表。

變更情境	搜尋入口是否改變	主要工作
換主機、伺服器或內容傳遞網路，公開網址不變	否	測試新環境、降低 DNS 切換風險、確認爬蟲可取得相同內容
更換版型或 CMS，網址保持不變	原則上否	防止內容、metadata、結構化資料、內部連結與索引控制意外消失
路徑重整，例如 /blog/a/ 改成 /guides/a/	是	建立舊到新 URL 映射並逐條永久轉址
從未加密 HTTP 升級為加密連線，或統一 www 與非 www	是	憑證、主機版本、永久轉址與 canonical 一致化
更換網域或子網域	是	完整映射、驗證新舊站資產、永久轉址，並在適用時提交地址變更

如果只是更換主機而 URL 不變，不需要為每一頁建立新路徑，也不該平白新增轉址。Google 對這種搬移的建議重點，是先測試新基礎設施、切換 DNS、監測新舊主機流量，確認使用者與爬蟲都穩定取得內容後才停用舊環境。

若 URL 會變，工作重心就轉為「舊網址如何對應新網址」。Google 建議大型搬移在合理時分段測試，並盡量一次只改一類重大變因。先搬網域、再改版型，通常比同一天同時更換網域、CMS、資訊架構與全文更容易驗證。

網址清冊要記什麼？不只是一欄舊網址

先從分析工具的自然搜尋到達頁、Search Console 頁面資料、Sitemap、網站爬取結果、伺服器日誌、後台內容與重要外部連結來源合併候選。這些資料的涵蓋範圍不同，不能只匯出一份 Sitemap 就當作全站清冊。

每列至少記錄：

欄位	要回答的問題	常見資料來源
舊 URL 與頁面類型	目前是哪一個公開入口？	路由、爬取、Sitemap
主要用途與意圖	使用者來這頁要解決什麼？	標題、正文、查詢、產品資料
搜尋與連結價值	是否有曝光、點擊、轉換或外部連結？	Search Console、分析、連結報表
新 URL	哪一頁真正承接同一需求？	新站內容模型與資訊架構
搬移決策	一對一、合併、保留原址或移除？	內容與產品負責人確認
預期回應	200、301／308、404 或 410？	技術規格
驗證結果	實際終點、跳數、canonical、索引允許是否正確？	自動測試與人工抽查

搜尋數據可以協助排優先順序，卻不能單獨決定頁面生死。暫時沒有點擊的法規說明、售後資訊或長尾內容，仍可能有清楚用途；有流量的頁面也不代表內容必須原封不動保留。先釐清使用者需求，再決定承接方式。

轉址怎麼選？永久搬移用 301 或 308，不相關就不要硬導

依 HTTP 標準，301 與 308 都表達永久搬移；308 明確要求自動轉址時不得改變請求方法。對一般只讀取內容的頁面，實務上常見 301；若系統必須保留原請求方法與內容，才需要特別評估 308。這是應用與伺服器決策，不是排名技巧。

Google 將永久伺服器端轉址視為新目標應成為 canonical 的強訊號；302、303、307 則用於暫時搬移，通常不表示原 URL 應被永久替換。已確定的新路徑若長期回 302，會讓站方意圖變得不清楚。

舊頁狀態	正確處理	不該做的事
新站有內容與用途相同的頁面	直接 301／308 到新頁	先到中繼頁再跳一次
多篇舊文已實質整合成一篇	各舊頁轉到完整承接內容的整合頁	只因同分類就導到分類首頁
頁面短暫維護，原網址之後恢復	視情境使用 302／307	永久轉址後又頻繁改回
內容永久下架且沒有相近替代	回傳 404 或 410，提供可用導覽	回 200 的「找不到」頁，或全部導首頁
URL 根本不需要更換	保持 200，更新頁面內容	為了改版新增沒有必要的路徑

把數百個舊 URL 全部導到首頁，沒有保存原本的頁面關係。Google 明確提醒，不相關的大量轉址可能被當成 soft 404。轉址鏈也要縮短：舊 A 若先到舊 B、再到新 C，應把 A 與 B 都直接改到 C，並同步更新站內連結。

不只設轉址：五種訊號要說同一件事

永久轉址上線後，新頁本身還要能被爬取、回傳成功、允許索引，並呈現真正承接舊頁需求的內容。接著檢查五個一致性來源：

1. 轉址：舊 URL 直接到預定新 URL，沒有迴圈、長鏈或跳到無關頁。
2. canonical：新頁的 rel="canonical" 指向新正式 URL，不再指回舊站、暫存站或錯誤主機。
3. 內部連結：導覽、正文、麵包屑與相關文章直接連新 URL，不依賴轉址替自己收尾。
4. XML Sitemap：只列新站希望被搜尋的成功、可索引 canonical URL，不列舊 URL 與轉址來源。
5. 內容與資源：正文、圖片、PDF、結構化資料、語系標註與社群 metadata 都使用正式新位置。

Google 將轉址與 rel="canonical" 視為較強的 canonical 訊號，Sitemap 納入則較弱；多個方法一致時，站方偏好會更清楚。但 canonical 仍是訊號，不是搜尋引擎必須服從的命令。若新頁內容不相符、被 noindex、canonical 指回舊頁，不能期待一條 301 自動修復所有衝突。

若搬的是整個網域或子網域，先在 Search Console 驗證新舊資產，完成搬移與轉址後，再依適用範圍使用 Change of Address。單純從未加密 HTTP 升級為加密連線，或同站內改幾條路徑，不使用這項工具；後者只需正確轉址並更新 Sitemap。

完整案例：240 個舊搜尋入口，222 個轉址與 18 個移除

以下是虛構教學案例，數字只用來示範映射與驗證，不是 MKT Notes 或任何客戶的改版結果。

一個居家用品教學站更換網域並重整內容。團隊從搜尋到達頁、Sitemap、外部連結與爬取資料整理出 240 個重要舊 URL：

舊頁類型	舊 URL	決策	新目標數
教學文章	140	128 篇一對一；12 篇整合成 4 篇完整指南	132
商品頁	60	52 項有同等新頁；8 項退場且沒有替代	52
分類頁	24	20 頁一對一；4 頁整合成 2 個新分類	22
活動頁	16	6 頁改為長期內容；10 頁到期且沒有替代	6

一對一映射共有 128 + 52 + 20 + 6 = 206 個；整合映射共有 12 + 4 = 16 個舊 URL，分別進入 6 個真正承接內容的新頁。因此永久轉址來源是 222 個，最後對應 212 個新 canonical 頁；其餘 18 個無替代頁回傳 404 或 410。

新 Sitemap 只列 212 個成功、可索引的新 URL，不列 222 個舊轉址來源。上線前測試發現其中 7 條規則先導到舊站的加密連線版本，再跳到新站；團隊把規則改成直接到最終新頁。另有 3 篇新頁的 canonical 還指向預覽網域，也在發布前修正。

這個案例不能推論「做完 301 就一定保住原排名」。合理結論是：每個舊搜尋入口都有可驗證狀態，轉址、內容與 canonical 的矛盾已在上線前被找出，後續若曝光下降，也能按頁群追查，而不是只看全站總流量猜原因。

上線後怎麼驗證？先技術，再索引，最後才看流量

第一層：立即驗證回應與頁面完整性

以完整清冊自動檢查每個舊 URL 的第一個狀態、最終 URL、總跳數與最終 200；另外抽查高流量、高轉換、高外部連結與不同模板的代表頁。同步確認 robots.txt、noindex、canonical、標題、正文、結構化資料、圖片與分析追蹤沒有因版型切換消失。

5xx、轉址迴圈、錯誤主機與全站 noindex 不需要等待搜尋引擎「重新學習」，應立即修復。正式站的 robots.txt 若仍保留開發期全站封鎖，也屬同級故障。

第二層：觀察爬取、canonical 與索引搬移

提交新 Sitemap，對首頁、重要分類與代表內容使用 URL Inspection；在 Page indexing report 看舊 URL 是否逐步成為轉址、重要新 URL 是否可索引，以及 Google 選擇的 canonical 是否符合預期。Bing 可透過 Webmaster Tools 的 URL 與 Sitemap 狀態交叉檢查。

Google 表示，中型網站多數頁面的搬移可能需要數週，更大的網站可能更久，而且是逐 URL 處理。暫時波動不等於失敗；但若某一模板持續不被爬取、canonical 系統性選錯或錯誤狀態暴增，就不該只用「再等一下」解釋。

第三層：用同口徑比較曝光、點擊與商業結果

保存上線日期，將舊 URL 與新 URL 依映射合併成同一頁群，再比較查詢、曝光、點擊、裝置、國家與搜尋外觀。只比較新網域與舊網域的總量，會把仍在搬移中的資料拆成兩半。

如果曝光與點擊一起跌，先定位受影響頁群，再對照索引與技術狀態；曝光持平但點擊跌，才檢查搜尋結果標題、摘要與需求變化。也要排除季節性、追蹤遺漏、搜尋演算法更新與內容本身改寫，不能把所有變化都歸因於轉址。

八步工作流：把網站改版變成可以驗收的搬移

1. 界定本次變更：寫清楚是否改網域、協定、路徑、主機、CMS、內容與追蹤，能拆開的重大變更分期做。
2. 保存改版前基線：匯出重要 URL、查詢、曝光、點擊、轉換、外部連結、索引與爬取錯誤，標記資料日期。
3. 建立完整映射清冊：為每個舊入口指定一對一、整合、保留或移除，讓內容與產品負責人確認語意相符。
4. 在非公開環境測試新站：檢查模板、內容、metadata、canonical、內部連結、結構化資料、圖片與分析，不讓預覽網址被索引。
5. 實作並全量測試轉址：永久搬移採伺服器端 301／308，避免長鏈、迴圈與無關首頁轉址。
6. 同步更新站內訊號：新站內部連結、canonical、Sitemap、語系與媒體資源全部使用最終新 URL。
7. 低風險時段上線並通知：確認容量與監測可用；適用時提交 Search Console 地址變更及新 Sitemap。
8. 按技術、索引、流量三層監測：記錄異常頁群、修正日期與再驗證結果，長期保留轉址；Google 建議通常至少一年，使用者需求則可能值得永久保留。

七個常見失敗與判斷限制

先做新站，最後一天才想舊網址去哪

沒有映射清冊，就容易遺漏有外部連結或長尾曝光的頁面。網址去向是資訊架構與內容決策，不只是上線前請工程師寫幾條規則。

所有舊頁都導向首頁

首頁通常不承接舊文章、商品或活動的具體需求。沒有相近替代內容時，誠實回傳 404／410，並在錯誤頁提供導覽，比不相關轉址更清楚。

只測轉址，不測最終頁

轉址成功仍可能落在 noindex、錯誤 canonical、空白模板、缺少主內容或持續 5xx 的新頁。測試必須走到最終回應與實際渲染。

舊 URL 在站內繼續大量出現

搜尋爬蟲與使用者每次都多走一跳，也讓站方持續送出舊路徑。轉址是接住歷史入口，不是取代內部連結更新。

搬移期間頻繁改轉址目標

同一舊頁先到 A、幾天後改 B、再改 C，會增加診斷與重新處理成本。上線前應完成內容決策；必要修正也要留下版本與原因。

看到流量波動就立刻回滾全部

重大搬移本來可能波動。先檢查可立即證明的技術錯誤與受影響頁群，再判斷是否回滾；沒有基線與映射時，倉促回滾可能再製造一次變更。

把 301 當成內容品質保證

永久轉址能表達位置改變，不能讓內容不相符的新頁自動繼承所有表現。搜尋可見度仍取決於爬取、索引、內容品質、需求與競爭；需要時可回到爬取、索引與排名的三道關卡逐層判斷。

最後帶走：成功改版靠的是一致、可追蹤與可回復

• 先分辨是否真的改 URL；只換主機時，不要平白製造網址搬移。
• 改 URL 前建立清冊，讓每個重要舊入口都有明確決策與負責人。
• 相同或整合內容使用直接的永久伺服器端轉址；無替代內容回 404／410。
• 不把大量不相關頁面導到首頁，也不留下長轉址鏈。
• 讓 canonical、內部連結、XML Sitemap、內容與媒體資源一致指向新 URL。
• 網域搬移完成轉址後，才在適用時使用 Search Console Change of Address。
• 上線後依序看回應與渲染、爬取與索引、曝光與點擊，不用單一總流量下結論。
• 長期保留映射清冊、基線、變更日期與修正紀錄，才能區分正常處理時間與真正故障。

網站改版不是一次性的版面更新，而是一場需要交接歷史入口的系統搬移。當每條舊路徑都有合理去向、每個新頁都送出一致訊號，而且團隊能用同一份清冊持續驗證，搜尋引擎比較容易理解新舊關係，讀者也不會在改版後走進失效或無關的終點。