企業網站搬家 30 天流程手冊：行銷與工程的風險檢核清單

企業網站搬家 30 天流程手冊：行銷與工程的風險檢核清單

要在三十天內完成網站搬家且把搜尋與使用者風險降到最低，必須把工作分成評估、對照、測試、上線與觀察五個可驗證的階段。

概覽：為何要用 30 天節奏

這份流程手冊把搬家工作分成可交付、可檢核的小步驟，目的不是硬性限制天數，而是避免在上線前把大量細節堆在一起。若網址完全不變，風險可大幅降低；只要有任何網址變動，就需走完整流程。

關鍵原則（一句話）：把高影響的網址先保護、把轉址做成一對一並一步到位、測試環境要封鎖搜尋引擎、上線當日先檢查機器人規則與追蹤碼。

第 1–7 天：盤點與風險分級（評估）

目標：在一週內把可能受影響的資產列成清單並分級，決定哪些頁面需要逐一確認。

必做清單：
– 匯出當前可被索引的所有網址（來源：網站地圖、搜尋主控台、伺服器或 CDN 存取記錄）。
– 匯出過去 12 個月帶來曝光或點擊的網址，並以流量或轉換排序（依原始資料中的時間範圍）。
– 記錄關鍵基準指標：每月自然流量、曝光、平均排名、索引頁數（以現有報表為準）。
– 列出所有外部導入的重要連結（高價值反向連結、媒體導流頁面）。
– 盤點第三方服務與追蹤碼位置（分析工具、表單、聊天、金流 SDK 等）。

風險分級：
– 高風險：過去 12 個月有持續流量或排名的網址（通常佔約 20–30%，依站方資料驗證）。
– 中風險：偶有流量或被外部連結引導的頁面。
– 低風險：從未帶來流量且內容可棄置的頁面。

驗證步驟（交付物）：
1. 產出「可索引網址清單」CSV。
2. 產出「過去 12 個月流量清單」CSV，並標註每筆的流量貢獻。
3. 高風險清單匯總並指定負責人。

提示：不要把大量無流量的 URL 都當成優先保護對象，會浪費資源。確認比例請以站方資料為準。

第 8–14 天：製作網址對照表（核心文件）

目標：完成一份可被工程、內容與客服共同使用的「舊→新 URL 對照表」。這是整個搬家過程中最核心的文件。

對照表欄位建議：舊網址、新網址、對應類型（一次對一/一對多/多對一/無對應）、優先級、備註、負責人。

對應類型與處理原則：
– 一對一（理想）：內容對等，直接 301 轉址到新頁。
– 一對多：舊頁拆成多頁，選擇最接近內容的單一頁面為主要轉址目標，並在備註中註明拆分邏輯。
– 多對一：將多個舊頁合併到一個新頁，確保合併頁面包含所有核心資訊並在頁面內說明來源。
– 無對應（已下架）：不要一律導向首頁；寧可回傳 404/410，或導向最接近的分類頁與提供替代資源。

驗證手段：
– 請一位未參與製表的人抽驗 20 筆對照結果，確認邏輯與轉址目標正確。
– 對照表存成獨立文件（CSV 或 Excel），上線前與上線後皆會頻繁使用。

常見錯誤：把找不到對應的頁面統一導到首頁，會造成使用者混淆並浪費搜尋引擎的連結價值。

第 15–21 天：測試環境驗證（完整演練）

目標：在封閉的測試環境完整跑一次全站檢查，排除轉址錯誤、死鏈、追蹤碼遺漏與效能退步。

測試清單：
– 用爬蟲工具（示例：站方現有工具即可）爬取測試站，檢查死連結、錯誤狀態碼、重複標題與重複內容。
– 驗證所有 301/302 規則，並檢查是否有轉址鏈（任何轉址都應盡量一步到位）。
– 確認標準網址（canonical）、網站地圖（sitemap）與 robots.txt 指向新結構，且測試環境的 robots 設為封鎖。
– 檢查結構化資料是否完整搬移（若換系統，此項常被遺漏）。
– 測試表單、會員登入、金流測試、第三方服務是否正常，並檢查追蹤碼是否正確觸發事件。
– 量測效能指標（首次內容繪製、完整載入時間），與舊站比較避免效能退步。

驗證交付物：
1. 爬蟲報告（錯誤清單與優先排序）。
2. 轉址測試報告（包括示例的轉址鏈）。
3. 功能測試清單（表單、金流、登入、追蹤事件）。

提示：轉址鏈雖能到達新頁，但會損耗「流量權重」與增加失誤機率，原則上應刪除中繼轉址，改為直接指向最終目標。

第 22 天：上線當日（關鍵檢查表）

建議時段與準備：
– 選擇流量相對低的時段上線，避開週五與連假前，方便出現問題時有完整支援人力。
– 上線前把 DNS TTL 或網域存活時間設定為較短，方便必要時快速回退（上線後再恢復原設定）。

上線當日檢查清單（立即完成）：
1. 抽驗至少 30 個 URL 的轉址結果，涵蓋一對一、一對多、多對一與無對應類型。
2. 確認新的 sitemap 可存取並在搜尋主控台提交（若站方流程允許）。
3. 檢查 robots.txt 不是沿用測試環境的封鎖設定（此為最經典的災難案例）。
4. 確認追蹤碼與關鍵事件在正式站正常運作，避免隔天才發現無資料。
5. 保留舊站至少 30 天以備比對與回退。

緊急回退策略：
– 若重大錯誤（整站無法索引或大規模 5xx），立刻把 DNS 指回舊站或調整伺服器路由，同時把 TTL 再調短以縮短生效時間。

提示重點：上線後首件要做的事就是檢查 robots.txt，確認沒有把站點全封鎖。

第 23–30 天：觀察（判讀與修正）

目標：用明確的訊號判定哪些變動屬於正常調整期、哪些需立刻處理。

正常波動（示例）：
– 上線後 1–2 週內出現約 10% 至 20% 的下滑，隨後逐步回升（屬於重新索引期間的常見曲線，需以站方資料驗證）。

需立刻處理的訊號：
– 索引頁數斷崖式下降超過 50%：優先檢查 robots 與 canonical、sitemap 是否被錯誤設定。
– 特定類型頁面全部消失：檢查是否某組轉址規則或系統模板誤操作。
– 錯誤狀態碼數量持續上升：代表對照表或部署有遺漏。
– 平均排名無大幅下滑但點擊量大跌：檢查每頁標題與描述是否被系統預設覆蓋。

調查步驟（依優先順序）：
1. 以索引頁數與機器人規則為首要檢查項目。
2. 依照對照表，抽測轉址正確性與狀態碼。
3. 檢查搜尋主控台的抓取錯誤與 sitemap 回報。
4. 若為點擊率下降，抽查頁面片段（title/description）是否為預設值並修正後回報搜尋引擎。

提示：在重新索引期間避免做大幅的內容或轉址調整，否則無法判斷變動原因。

三十天之後：收尾與長期維護

收尾工作清單：
– 確認流量是否恢復到搬家前水準的 90% 以上；未達標者，回到對照表逐項排查。
– 逐一聯絡外部重要連結的來源，請對方更新為新網址（轉址有效但直接連結更穩定）。
– 移除臨時設定（例如短 TTL、測試期間放寬的存取規則）。
– 將搬遷紀錄整理成文件，包括對照表、遇到的問題與解法、關鍵決策與責任人，作為未來改版範本。

經驗提示：轉址是可以保護流量的，但長期而言直接更新外部連結更穩定，且轉址規則也可能被未來誤刪。

決策樹（簡化版）

如果搬家會改變任何網址 → 走完整 30 天流程。

如果搬家不改變任何網址 → 重點放在效能、安全與功能測試，可縮短週期但仍須測試追蹤碼與第三方整合。

遇到抽樣指標異常（如索引頁數大跌或某類頁面消失）→ 先檢查 robots、sitemap、canonical，再檢查轉址規則 → 如仍無解，回退到舊站並啟動完整排查。

限制與例外

• 本手冊假設站方能在測試環境完整模擬生產環境；若測試環境限制較多，應延長測試週期。
• 若站點流量與索引極大（數十萬頁以上），對照表與抽驗比例需調整，本文示例比例需依站方資料驗證。
• 金流或會員系統的回歸測試須在受控環境下進行，避免在生產環境測試真實交易。

FAQ（本文直接回答）

Q1：如果網址完全不變，我還需要做對照表或轉址檢查嗎？
A1：若網址與內容完全不變，轉址工作可以簡化，但仍需做基準指標記錄、追蹤碼驗證與效能比較，確保系統替換未意外改變頁面輸出或 meta 資訊。

Q2：上線後發現 robots.txt 被封鎖，該怎麼做？
A2：立即把 robots.txt 恢復正確版本，並提交 sitemap 與索引請求；同時查看搜尋主控台的抓取紀錄與索引頁數，確認是否已造成索引減少並依情況回退。

Q3：轉址鏈會造成什麼影響，該如何避免？
A3：轉址鏈增加抓取成本並可能造成權重損耗，原則上把所有轉址改為一步到位（舊 URL 直接 301 到最終目標），並在對照表上標記中繼轉址需要修正之處。

Q4：上線後一到兩週流量下滑是否需要立即處理？
A4：不一定。若下滑幅度在約 10% 至 20% 並在索引頁數未大幅下降，通常屬於重新索引期。但若索引頁數大跌或特定頁面消失，則應優先處理。

Q5：為何要主動聯絡外部連結來源，而不是只依靠轉址？
A5：轉址是間接保護，長期而言直接更新外部連結更可靠；轉址規則也可能在未來被誤刪或修改，導致流量斷裂。

下一步（內部參考連結）

如需進一步服務或案例參考，可參考我們的服務與案例頁面，或透過表單預約諮詢：
– 服務介紹：服務頁
– 成功案例：案例
– 常見問答：常見問答
– 聯絡表單：聯絡表單
– 關於我們：關於我們
– AI 決策支援：AI 決策模組（若需與自動化驗證串接）

---

本文資料邊界：本文的操作建議與數值描述基於原始內文的實務經驗與範例比例；如需將建議套用到特定網站，必須以該站的後台報表、搜尋主控台與伺服器日誌為準並由技術團隊驗證。

參考資源：Google 搜尋中心