先看訪客要完成甚麼
更改網址，其實是把舊入口的訪客交接到新頁。顧客可能從收藏的產品連結進入，供應商可能沿用 PDF 目錄上的網址，客戶亦可能點擊舊電郵裏的服務介紹。設定轉址前，先記下每個舊頁原本承諾提供甚麼，以及新網站哪一頁真正延續該用途。Google 的網站搬遷指引要求建立新舊網址對照；對商戶而言，重點不是網址字面相似，而是新頁能否回答同一問題。轉到首頁雖然技術上成功，訪客仍可能找不到原先要看的規格、存貨或聯絡途徑。
先界定範圍：哪些頁面會改址、哪些網址保持原狀、哪些下載檔案與舊頁互相連結。若只是換主機而所有網址維持不變，工作重點另有不同，不必無端製造轉址清單。若路徑或網域確實改變，應指定一名負責人維護對照表，統一記錄目標頁、選擇理由及測試結果。實際有人使用的宣傳連結、印在單張上的 QR code 亦要納入。這份清單是編輯和營運工具，不能當成已從分析數據證實哪些頁面最受歡迎。
把每個舊網址對應到明確新頁
第一輪可由現有 sitemap 和內容系統列出網址，再補上伺服器紀錄、外部連結或宣傳物料中出現的舊入口。Google 建議參考 sitemap、紀錄、分析資料及連結報告尋找重要舊網址。每一列至少寫明舊址、建議新址、兩頁內容和服務是否仍相符、決策負責人及預定回應方式。小型網站用試算表已足夠。若平台對大小寫、尾斜線、查詢參數或語言版本有不同處理，要把這些形式列成測試個案；同一視覺頁面未必只有一條舊網址。
不要為了填滿對照表而硬找「相近」頁面。例如舊頁介紹一款藍色座燈，現在同款產品換了編號；若新產品頁清楚說明替代關係及規格差異，轉址可能合理。若座燈已停產，而分類頁只有無關商品，把舊連結一律送到分類頁反而掩蓋了答案。Google 指出沒有合適替代內容時可回傳 404 或 410，並提醒不要把大量無關舊頁轉往首頁。商戶仍可設計有幫助的找不到頁面，提供搜尋或聯絡方法，但伺服器回應應如實反映頁面不存在。
真正搬遷應直接轉往最終目的地
公開頁面若永久搬走，而且新頁承接原有用途，應要求技術人員由舊址以伺服器端永久轉址直接送往最終網址。Google 在可行時建議使用 HTTP 301 或 308，並把永久轉址視為目標頁應成為主要網址的強訊號。回應方式要符合實際搬遷性質；短期活動測試不能當成永久搬遷。舊網域和轉址設施在承諾舊連結可用期間仍須受控。Google 指出網站搬遷的轉址一般至少保留一年，若使用者長期持有舊連結，繼續保留可能更有幫助。
避免「舊目錄頁 → 過渡分類頁 → 新產品頁」這類連鎖轉址；它增加等待時間，亦令故障點變多。Google 明確建議直接指向最終目的地，避免長鏈。把最終網址寫回對照表，下一次改版才不會只在舊規則後再加一跳。團隊應檢查實際 HTTP 回應，包括非瀏覽器請求，而非只見瀏覽器最終顯示某頁就當作通過。舊網址若回傳 200 並顯示「頁面已搬遷」，那並不等於 HTTP 轉址。
同步更新新網站的內部指向
轉址只是搬遷的一部分。網站導覽、產品卡片、頁尾、公司仍可修改的電郵樣板與下載文件，都應改用新網址；先處理顧客仍會走的路徑。Google 的搬遷清單也提到在 sitemap 中列新網址，並讓目標頁的 canonical 標記指向新址。若網站另有語言版本及 hreflang 標記，也要同步更新其互相指向。轉址可照顧舊外部入口，但新站不應繼續把訪客送回舊址再兜一圈。上線前還要檢查 robots 規則及開發階段留下的 noindex，確保搜尋引擎能存取新頁。
雙語服務頁要分開決定對照，不能只把英文網址貼上中文標籤。舊英文頁應到適合的英文內容；舊繁體中文頁如有對應中文頁，也應到達該頁。若內容已合併成一個雙語頁，應記下理由，測試訪客毋須猜測就能找到所需語言。顧客常直接使用的 PDF 和圖片下載連結亦應處理。Google 在網站搬遷準備工作中明確包括圖片和下載檔，因為檔案本身也可能有流量及外部連結。
用具代表性的網址演練
上線前選一組有代表性的舊址：常用產品頁、服務頁、文章、兩種語言頁、搬走的檔案、已刪頁面，以及帶參數的網址。逐項記錄回應碼、第一個轉址目標、最終回應、頁面語言及內容能否回答原有需要。再用手機開啟目標頁，確認其內部連結可用。測試紀錄要有日期與實際觀察到的網址，日後能夠重做，而不是在項目計劃上勾一個未核實的方格。若上線時平台規則有改動，須在正式環境重跑同一批個案。
上線後，如公司可使用 Search Console，可提交新 sitemap，並觀察新舊網址的情況。Google 說明搬遷期間重新檢索及建立索引，搜尋曝光可能波動；設定轉址不等於保證即時維持排名或流量。若出現意外 404、循環轉址、目標頁被封鎖或語言不符，應追查原因。仍有真實訪客使用的舊連結可先處理，若證據顯示目的地不對，就修訂對照。過渡期每週簡短查看，之後在停用舊設施前再檢查，是可行的營運節奏，並非 Google 規定的週期。
處理例外時不要掩蓋問題
搬遷計劃需要處理無法自動對照的例外。一款產品有數個後繼型號、一項服務拆分成不同客群，或一篇指南併入較廣泛資源時，都要由內容負責人作編輯判斷。選擇最能延續舊頁承諾的目的地；若訪客可能疑惑，可在新頁簡述關係。若沒有單一新頁能做到，誠實回應找不到頁面並提供有用導覽，可能比任意轉址更合適。請沒有編製對照表的同事測試例外：他能否理解為何來到此頁，以及下一步怎樣做？
正式上線也要有修復途徑。保存已批准的對照規則副本，指明誰能修正錯誤目標，並預先說明舊連結失效時客服如何回應。若出現嚴重錯配，先修正該條規則，再測試舊網址、目標頁及相關語言版本。不要在壓力下同時改動不相關轉址，否則團隊難以確認哪個決定真正解決問題。把實際故障及修正寫回同一份對照文件。這些例外紀錄日後有助區分業務提供內容的真實變化，與單純實作錯誤。
留下可沿用的決策紀錄
交接成果不應只有一堆轉址規則。把網址對照、例外、上線測試結果、現任負責人及舊網域續期責任存放在同一處。對刻意回傳找不到的舊址，要標明理由。日後若增加替代產品，同事便能判斷是否重看該舊頁；若更換網站服務商，新團隊亦毋須倒查伺服器設定，便知道每條連結本來要做到甚麼。這亦有助區分有意停產與搬遷失誤。
小型企業可先抽取十條真實舊連結，逐條用一句話回答：訪客應到哪裏，原因是甚麼？十條只是便於啟動討論的例子，並非研究數據或規定門檻。若同事找不到真正相關的目標頁，應交由內容負責人決定，不要讓技術規則自行替他們作答。當處理顧客查詢的同事也能理解整份對照，開發人員才執行並驗收。這個次序可讓技術搬遷保持對應實際使用與售後工作。若客服反覆收到同一條舊連結的查詢，也應重新檢查原先的目的地決定。
進行前先確認
- 每條舊網址都有合理目的地，或有記錄的找不到頁面決定。
- 正式環境測試核對回應碼、最終內容及語言。
- 內部連結、sitemap 及相關標記已改用新網址。
