網站改版交接流程手冊：為行銷與技術團隊設計的上線檢核與回退策略

官網改版交接流程手冊：上線前後必做的檢查與決策

這份流程手冊列出改版上線前後必要的交接與驗證步驟，逐項檢查可降低掉排名、流量與轉換損失風險。

本手冊以決策樹、清單與驗證步驟為主，方便技術、產品與行銷在上線前、當日與後續監控時逐項執行與簽核。所有數字沿用原始事故檢討的實務經驗；具體值請依各站實際資料驗證。

上線前十四天：必備備份與資料清單（逐項取得）

目的：確保任何回退、比對或轉址作業有完整原始檔與參考表。

檢查表（十四天前完成，每項都必須有檔案與儲存位置）：

  • 全站網址清單：匯出 sitemap.xml 並從 Search Console 匯出頁面報表，存成試算表（一列一個網址）。
  • 每頁標題與描述：用爬蟲工具抓取，匯出試算表，欄位含網址、標題、描述。
  • 近十二個月流量頁面：GA4 的網頁與畫面報表，匯出試算表，含工作階段數並排序。
  • 有外部連結的頁面：外連分析工具匯出報表，含連入網域數。
  • 表單提交紀錄：後台匯出 CSV，保留欄位與時間戳。
  • 圖片與檔案：下載伺服器上傳資料夾，壓縮並保留原始路徑結構。
  • 資料庫備份：主機面板匯出 SQL 檔，至少存兩份於不同位置（例如不同雲端或外接儲存）。

儲存原則：備份檔名加上日期、版本與儲存地點標示；關鍵檔案（redirect 表、資料庫）至少存兩處且記錄取用帳號。

限制 / 例外：若站內存在動態產生的頁面（session 參數頁、短期活動頁），需於清單中註明有效期並列為合併或刪除候選。

轉址表（Redirect map）怎麼做：三欄一列對應法

格式建議（試算表每列）：舊網址 | 新網址 | 狀態碼

  • 狀態碼統一使用 301（永久轉址）。
  • 找不到逐一對應的新頁時：轉到最接近的分類頁，而非全部轉向首頁。
  • 不要把大量舊頁全部 301 到首頁，這會被視為軟性 404，損及索引品質。

常見舊網址類型與處置：

舊網址類型 應轉到 常見錯誤
產品頁（仍有相同產品） 新的同一支產品頁 轉到產品列表首頁
已下架產品 該產品的分類頁 全部留 404（可能浪費外部連結價值）
部落格文章（已改網址） 新的同一篇文章 網址結構改變後未對應
分頁（第2頁以後） 該列表第1頁或對應頁 逐頁對應造成鏈式轉址
含參數的網址 去掉參數的正規網址 參數保留造成重複內容

驗證步驟（上線當日與上線後抽查）：

  1. 隨機抽 20 個舊網址，逐一貼入瀏覽器，確認實際回應為 301 並指向清單上的新網址。
  2. 在 Search Console 查看轉址後的索引提示與抓取錯誤。

驗收建議：承包方提供轉址表時，委託方隨機抽查 50 筆（合約條款可寫入）。

上線當天的九項逐項檢查（上線後第一個小時內完成）

  1. 檢視 HTML 原始碼，確認 robots meta 標籤不是 noindex（最快的失誤檢查）。
  2. 開啟網域 /robots.txt，確認沒有 Disallow: /（整站封鎖）。
  3. 送出新的 sitemap.xml 到 Google Search Console（或其他主搜尋平台）。
  4. 隨機抽二十個舊網址，逐一貼進瀏覽器，確認回應 301（見上節）。
  5. 確認 GA4 追蹤碼在新版每一頁都有；用即時報表觀察是否有流量進入。
  6. 確認主要轉換事件（如表單提交）在新版表單可正常觸發，實測送出一次並檢查後台有紀錄。
  7. 確認 canonical 指向新網址（且不再指向測試站或開發子域名）。
  8. 確認 HTTPS 憑證有效，且 http 自動導向到 https。
  9. 用手機開五個主要頁面（首頁、代表性產品頁、表單、結帳等），確認顯示正確與按鈕可點。

上線那天還要反向操作測試站防護：移除測試站上的密碼保護、noindex 標籤與 robots 全站封鎖（若有三層防護，三層都需解除）。

上線後的監控：第1天、第7天與第30天要看的數字與紅線

監控節點與紅線如下，若觸發紅線，請立即啟動應變流程。

  • 第1天（紅線重點）：404 錯誤數、GA4 即時使用者。

  • 紅線：404 超過 20 筆 → 立即檢查轉址表是否遺漏、是否有 noindex 或 robots 錯誤。

  • 第7天（紅線重點）：Search Console 的收錄頁數、平均排名。

  • 紅線：收錄頁數掉超過 30% → 先查兩件事：轉址表是否漏頁；頁面是否被加上 noindex。

  • 第30天（紅線重點）：自然搜尋工作階段（Sessions）、表單完成數（Conversions）。

  • 紅線：比上線前月均低超過 20% → 啟動完整回溯：索引問題、內容搬移是否有遺失、或結構改變導致重要頁面不可得。

檢查步驟（範例）：
1. 當第7天收錄掉超過 30%：匯出收錄清單與轉址表比對，找出缺頁；同時逐頁確認是否有意外的 noindex。
2. 當第30天流量下降超過 20%：檢查前 50 名流量頁是否都已搬移與正確 301；檢驗是否有漏裝追蹤碼或事件。

限制說明：部分搜尋排名波動屬正常佈局期，但若超過以上紅線，通常表示實務錯誤或重大技術遺漏。

合約要寫進去的五句話（範例條款）

  1. 轉址表由承接方製作，逐列對應，驗收時由業主抽查 50 筆，抽查未過為不合格。
  2. 上線後 30 天內，因轉址遺漏造成的 404，由承接方無償修正。
  3. 原始設計檔與程式碼於結案時交付，格式為可編輯狀態（如 PSD、Figma、原始程式碼）。
  4. 主機、網域、GA4、Search Console 帳號皆應於合約簽訂時開在業主名下，或明確記錄授權方式。
  5. 結案前提供操作手冊一份，含發文、替換圖片、變更選單等三段圖文教學。

契約要點解釋：把轉址責任寫清楚，並規定抽查與修正期，可顯著降低以後雙方的責任爭議。

改版的四種做法與決策樹（風險與適合對象）

四種常見做法：

  1. 換皮（網址不動、內容不動）——風險低，適合只要改外觀的情形。
  2. 換架構（部分改網址、保留大部分內容）——風險中等，適合選單與分類要重排的需求。
  3. 換系統（可能大量搬遷網址）——風險高，適合系統更新或主機環境變動。
  4. 全部重做（大量改內容與網址）——風險最高，適合品牌轉型或併購情境。

決策原則：先明確需求（只是視覺還是內容與系統都要變），再對照預算與可容忍風險。把換皮當全部重做來發包，會多付兩倍以上成本且承擔更多風險。

決策樹（簡要步驟）：

  • 要不要改網址？否→換皮；是→進入下一步。
  • 要不要重寫內容？否→換架構；是→評估為換系統或全部重做，視搬遷量級決定是否分階段上線。

測試站不能被搜尋引擎看到：三層防護法與上線反向作業

為避免測試站被收錄（變成正式站的競爭對手），建議三層防護都要做：

  1. 測試站加密（Basic Auth / 密碼保護）。
  2. 每頁加上 noindex meta。
  3. 測試站 robots.txt 全站封鎖（Disallow: /）。

上線當天的反向作業：三層防護都要解除，並立即確認正式站不再有 noindex 或 robots 錯誤。多數改版事故的首因是正式站沿用測試站設定，整站掛著 noindex 上線。

驗證方法：上線後 5 秒鐘內查看首頁原始碼中的 robots 或 meta，就能快速確認是否放行。

內容搬移的優先順序與合併流程（節省時間、保留權重）

優先順序（從高到低）：

  1. 近十二個月流量前 50 的頁面，逐字保留且進行 1:1 網址對應。
  2. 有外部連結指入的頁面（即使流量低，也應保留並對應）；外部連結是長期資產。
  3. 帶來詢問或轉換的頁面（表單頁、案例頁），先搬並測試表單。
  4. 其餘頁面依主題合併：將多篇同一主題短文合成一篇（建議合成約 2000 字完整長文），舊網址 301 到新的綜合頁。
  5. 過期活動頁或明確重複頁可刪除，刪除後轉到分類頁。

合併提示：合併最花時間，但效果最大。舊站常見十幾篇談同一議題的短文，合成後往往比任何原文排名更好。

上線時間怎麼挑、待命與回退方案（實務流程）

上線時間原則：避免在週五下班前或旺季前一週上線，風險與無法即時處理的成本太高。建議上線時段：週二或週三上午（流量穩定、整週有時間處理）。淡季月初為次佳時機。

具體安排：

  • 上線後留兩個人待命 4 小時：一人監看後台錯誤，另一人手動測試主要流程（首頁、產品頁、表單、結帳）。4 小時內沒事，方可宣告上線完成。
  • 待命名單寫在紙上或流程文件，含姓名、手機、負責範圍三欄，並把主機商客服電話一併備註。
  • 回退方案：不要當天刪除舊站，舊站保留在原主機上至少 30 天。若新站出現無法短期修復的問題，將網域指回舊主機可在約 10 分鐘內恢復營業。這 30 天的主機費是整個改版案最便宜的保險。

限制與例外：若舊站與新站無法共存於同一主機環境（例如衝突的應用或資源），請事先準備可快速重新部署舊站的映像檔或容器方案。

檢核步驟總表（上線前→當日→後續）

  1. 上線前 14 天：備份全部清單、製作轉址表、確認表單與外連清單。
  2. 上線前 7 天：完成第一輪 QA、採用抽查清單測試重要頁面。
  3. 上線當天（上線後 1 小時內）：完成九項逐項檢查並移除測試站防護。
  4. 上線後第1天：檢查 404 與即時流量（紅線：404 > 20）。
  5. 上線後第7天：檢查收錄數與平均排名（紅線：收錄掉 > 30%）。
  6. 上線後第30天：檢查自然搜尋工作階段與表單完成數（紅線：掉 > 20%）。

本文資料邊界

本文的檢查流程與數值基於顧問團隊過往案件的實務經驗與事故檢討，所列數字（例如「第九天發現 300 多個頁面變 404」、「驗收抽查 50 筆」、「保留舊站 30 天」、「上線待命 2 人 4 小時」等）為實作時常見的參考值；實務中請依各站點流量、資源與合約條件微調。

下一步內連（官方資源）：

  • 若需了解服務內容與報價，請參考我們的服務頁面：服務項目。
  • 想看成功案例與搬遷實例，請參閱：案例。
  • 若要預約諮詢或提出網站改版需求，請使用：聯絡表單。
  • 常見問題與操作細節，可先查閱：FAQ。
  • 團隊與公司介紹：關於我們。
  • 想進一步討論決策流程或 AI 輔助決策，可瀏覽：AI Decision Pod。

常見問答（FAQ）

Q1：第7天收錄掉超過 30%，第一步該做什麼？

A1：先比對轉址表與 Search Console 收錄清單，確認是否有大量舊網址沒有 301；同時檢查站內是否被意外加上 noindex 或 robots 封鎖；若兩者都正常，擴大檢查 sitemap 與站內結構是否有誤。

Q2：為何不要把所有舊網址都 301 到首頁？

A2：大量 301 到首頁會被搜尋引擎判定為軟性 404，既浪費外部連結權重也降低索引品質。較好的策略是將每個舊頁導到最相關的新頁或對應分類頁。

Q3：若上線當天發現整站掛著 noindex，怎麼處理？

A3：立即把 noindex 移除並重新送出 sitemap 並在 Search Console 要求重新抓取；同時檢查是否有測試站設定遺留在正式站，並啟動回退方案（若需要，將域名指回舊主機）。

Q4：轉址表驗收只能靠抽查嗎？

A4：抽查是必要步驟（建議抽查 50 筆），同時應搭配自動化比對工具將舊站 URL 列表與轉址表做批次比對，找出未對應或指向錯誤的筆數。

Q5：上線後 4 小時內沒事就能安心嗎？

A5：4 小時是最初關鍵時段的實務標準；若無即時錯誤與重要流程失敗，表示第一輪大多隱憂已被排除，但仍須於第1、7、30天做完整追蹤。

本文由顧問流程與實務檢核角度撰寫，供技術與行銷團隊在改版專案中作為清單與決策參考。若需進一步討論或外包服務，可使用上方聯絡表單安排諮詢。

延伸閱讀：

參考資源：Google 案例