改版最容易忽略的資產，是客戶已收藏的網址、搜尋引擎已找到的內容，以及每天仍在運作的表單與下載連結。開始設計前，應先記錄舊站有哪些東西值得保留，再決定哪些要重做。
改版前：建立一份「不能弄丟」的清單
匯出既有網址，搭配搜尋成效、流量與業務紀錄，找出帶來有效需求的頁面。有些看起來過時的教學文，可能正是客戶第一次認識公司的入口；刪除前應先判斷它回答的問題是否仍然存在。
同時記錄表單通知對象、追蹤事件、下載檔、外部系統、會員權限與郵件設定。這些東西不一定出現在設計稿中，卻可能是網站最重要的日常工作。若打算換平台，還要試匯出一筆完整資料，確認附件、分類與文字不會遺失。
用網址對照表，安排內容的去向
| 舊頁面狀態 | 建議處理 | 不應只做什麼 |
|---|---|---|
| 主題仍有效，網址不變 | 保留網址並更新內容 | 重新建立另一個重複頁面 |
| 有對應的新頁 | 301 或適當的永久轉址至新頁 | 全部轉到首頁 |
| 多篇重複且整合成一篇 | 轉到真正涵蓋原需求的整合頁 | 只保留最短的頁面 |
| 內容取消且無替代 | 回傳合適的 404 或 410 | 假裝不存在的頁面仍正常 |
測試站：避免客人與搜尋系統走錯門
測試環境應限制非必要公開存取，並由負責人確認索引控制。單純在 robots.txt 阻擋爬取，不等於保證網址不被索引。若使用 noindex，正式上線時也要確認沒有連同測試設定一起留下。
請用真實內容測試：長產品名稱、直式照片、空值與較大的下載檔，都可能讓版面出現設計稿沒有的問題。會員與訂單等資料則使用適當的測試資料，避免複製後不小心寄信給客戶。
正式切換：驗收一條完整的使用路徑
從外部搜尋或舊網址進入內頁，閱讀內容、開啟下載、送出表單，再確認公司收到資料。若網站提供交易，還需按既定測試程序核對付款回覆與訂單狀態。只確認首頁能開，容易漏掉最直接影響營運的環節。
變更 DNS 時，也要避免刪掉與網站無關的郵件紀錄。網站搬家不代表公司信箱一定要一起搬。切換後如遇到新舊頁交替出現，可先判斷快取與 DNS，而不是立即重做整個部署。
舊站還有新資料進來，怎麼避免漏搬？
如果網站持續接單或收件，要約定移轉資料的時間點與切換期間的處理方式。第一次匯出後，舊站又新增的資料是否補搬，必須有明確程序。不能在兩邊都持續更新，卻沒有合併與核對安排。
可以先測試移轉流程，再於正式切換時依計畫暫停必要的寫入或採用適當同步方式。實際方法取決於系統與營運需求，重點是確保每筆新資料有可追查的去向。
上線後：用舊站基準找問題
追蹤重要網址狀態、自然搜尋落地頁、表單成功與異常流量。不同網站的波動原因不一，不宜看到一天的下降就認定失敗。先排除明確錯誤：錯誤轉址、忘記移除 noindex、內頁 404、圖片遺失及追蹤中斷。
保留修改紀錄，讓後續觀察知道何時改了內容、網址與技術設定。網址遷移細節可參考 Google：網站搬移與網址變更。