中大型網站搬家實作：837 頁網站 72 小時上線與檢查清單

中大型網站搬家實作：837 頁網站 72 小時上線與檢查清單

網站能在 72 小時內完成切換並達到初步穩定，但搬家後兩週內流量下滑為常態，需事前準備與後續追蹤。

判斷（先給結論）

• 若你要在一個週末把中大型網站（本例 837 頁）從舊平台移到新平台：可在 72 小時內上線並修正大部分問題，但成功關鍵在於搬家前 6 天的清單準備與搬家後至少 30 天的監控與保留舊站。

步驟總覽（快速清單）

1. 前兩週完成四份清單（完整網址表、流量表、外連表、轉址對照表）。
2. 搬家前 6 天完成所有清單並做本地備份。
3. 週五晚間開始切換，按小時檢查並立即修正日誌錯誤。
4. 週六上午逐項執行 19 項上線檢查。
5. 搬家後兩週密集監控伺服器日誌與 Search Console，30 天內不改設計或內容。

輸入（必備資料）

• 舊站完整 URL 清單（爬蟲匯出）；本案為 837 個 URL，含狀態碼、標題、描述、H1、canonical。
• 最近 12 個月的到達頁流量匯出（用來識別高流量頁）；本案前 200 頁佔總流量 87%。
• 外部連結清單（反向連結頁），本案匯出到 114 頁。
• 一對一的轉址對照表（舊 URL -> 新 URL），本案 837 列、無空白。
• 完整資料庫與檔案備份（下載到本機與異地備援）。

輸出（預期成果）

• 新站上線，301 轉址大部分正確；初步索引與抓取回報；前 14、28、42 天的流量恢復曲線。
• 問題清單與已修正項目紀錄，19 項上線檢查完成紀錄。

搬家前兩週：把清單做出來（詳解）

1. 完整網址表（爬蟲匯出）
   – 用爬蟲工具抓舊站並匯出 837 個 URL，包含狀態碼、標題、description、H1、canonical。
2. 流量表
   – 分析工具匯出最近 12 個月的到達頁，按工作階段排序，確認前 200 頁貢獻流量比例（本案 87%）。
3. 外部連結表
   – 用外連工具匯出反向連結指向的頁面（本案 114 頁），這些頁面不可失效。
4. 轉址對照表
   – 舊網址逐列對應新網址，確保一對一，837 列無空白。

備註：做這四份清單花了 6 天；搬家當天順利與否在很大程度取決於這 6 天的準備。

週五 18:00–21:00（上線前的最後檢查與備份）

• 18:00：在舊站公告區張貼維護通知，並打開 Search Console 的變更網址工具（備用）。
• 18:20：完成資料庫備份與檔案備份，兩份皆下載到本機與遠端備援。
• 19:00：在測試網域對新站做最後一次爬蟲，發現 31 頁的 canonical 指向測試網域，立即修正。
• 20:10：第二次爬蟲發現 14 頁的圖片路徑仍指向舊主機，已修正。
• 21:00：第三次爬蟲結果「乾淨」。

週五 21:00–週六 02:00（DNS 切換與初期流量）

• 21:30：將 DNS 的 TTL（存留時間）先調到 300 秒，本案其實在搬家前三天就完成，但原則是應在 48 小時前降低 TTL。
• 22:00：切換 DNS。
• 22:40：第一批使用者到達新站；錯誤日誌出現 72 筆 500 錯誤，集中在會員登入流程。
• 23:15：定位並修正登入問題（原因為新主機的 session/工作階段設定不同）。
• 00:00–02:00：用指令碼逐一測試 837 條轉址並紀錄狀態碼，結果如下：
• 819 條回 301
• 11 條回 404
• 7 條回 302
• 02:30：所有 404 與 302 問題修正完成（11 條 404 為舊站分頁參數網址，7 條 302 為設定錯誤）。

週六上午：19 項上線檢查（逐項列出並說明修正）

以下為當日檢查項目與結果摘要（19 項，耗時 5 小時）：

1. robots.txt 是否仍有殘留 Disallow：有一行，已移除。
2. 網站地圖是否換成新網址：未更新，已重新產生。
3. 每頁的 canonical 是否正確：已檢查並修正。
4. noindex 標籤是否遺留：首頁沒有，三個分類頁有，已移除。
5. 標題與描述是否遺失：62 頁遺失，從舊站匯入補回。
6. H1 是否變成 logo：有例外，已修回文字 H1。
7. 結構化資料（Organization）是否遺失：遺失，已補上。
8. 圖片替代文字（alt）是否遺失：遺失 211 張，以舊站資料回填。
9. 內部連結是否指向舊網址：發現 340 條，批次替換為新網址。
10. 分析工具追蹤碼是否安裝：已安裝並測試通過。
11. 轉換事件是否觸發：三個事件未觸發，已修正。
12. Search Console 新資源是否驗證：已驗證。
13. 網站地圖是否提交：已提交。
14. 載入速度測試：首頁 1.4 秒，內頁 1.8 秒。
15. 行動裝置可用性：通過檢查。
16. HTTPS 與混合內容：兩處混合內容，已修正。
17. 自訂 404 頁面：已設定（含搜尋框）。
18. 表單送出測試：五個表單全部測試通過。
19. 金流測試：實際刷一筆示例金額（本文註記為示例 / 需依讀者資料驗證）。

這 19 項中，第 5 項（標題與描述）與第 8 項（圖片 alt）最耗時，因為要對照舊站資料逐頁修正。

週六下午到週日：持續監控與抓取行為

• 自週六下午起，每兩小時檢查伺服器日誌與 Search Console 抓取統計。
• Googlebot 在切換後第 5 小時開始大量抓取；週六全天抓取 4,100 次（約為平常的 3 倍），此為正常現象，搬家後 2–3 週抓取量與索引會回到常態。
• 週日中午發現搜尋結果仍有部分顯示舊標題，屬於索引更新延遲，需等待或逐頁用網址審查工具提交。
• 週日下午把 114 個有反向連結的頁面逐一用網址審查工具提交以加速索引更新。

週一 18:00：第一份搬家後一週對照表（指標比較）

指標｜搬家前一週｜搬家後一週
—｜—｜—
自然點擊｜8412｜6218
曝光｜182000｜171000
平均排名｜14.2｜17.8
索引頁數｜819｜604
轉換｜97｜74

• 如表所示，短期內流量與索引數量下降是預期內的。
• 後續恢復軌跡：第 14 天索引頁數回到 807，自然點擊回到 7,860；第 28 天自然點擊 8,790（超過搬家前）；第 42 天自然點擊 9,640。
• 經驗值：八成網站的排名或流量回穩時間在 3–6 週；超過 8 週仍未回穩，多半原因是轉址表有遺漏或一對一轉址不完整。

五條事後檢討（寫在交接文件第一頁）

1. TTL（存留時間）要在 48 小時前調低，本案提前 3 天完成，無成本且有幫助。
2. 轉址表必須一對一；不要用萬用字元把整個目錄丟回首頁（會喪失權重傳遞）。
3. 舊站不要立刻關閉，至少保留 30 天，以便救回遺漏的網址。
4. 標題與描述要在搬家前匯出為檔案，它們是搬家過程中最常遺失的元素。
5. 搬家後 30 天內不要同時改設計、資訊架構或內容，避免同時改動造成問題難以除錯。

十一條 404 教會我的事（取捨與判斷）

• 本案 11 條 404 全部是舊站的分頁參數頁（例如商品列表第 2、3 頁），在流量表與外連表上均未出現。理論上可以放棄，但我們仍一律轉過去。
• 原因：外部連結工具與流量報表有時間與抓取限制；實際存在的外部連結比列表顯示的更多。
• 現行規則：舊站的每個 URL 都要有去處（轉址），即便該 URL 在最近 12 個月沒有帶來流量。多花 20 分鐘多寫十一條轉址規則，成本低於漏掉一條可能造成的長期流量損失。

客戶常問的三個問題（搬家期間真實問答）

Q1：網站無法打開，這是不是資料遺失？
A1：遇到錯誤先看錯誤日誌。例：週五 23:00 客戶看到網站打不開，經查是登入的 session 設定不同，非資料遺失，40 分鐘內回覆並提供錯誤日誌截圖說明問題原因。

Q2：為何 Google 上搜尋公司名稱還是舊網站外觀？
A2：索引更新有延遲，通常需 3–10 天；這段時間不要重複提交同一頁，會浪費配額並無助於加速索引。

Q3：這次搬家值不值得？流量何時會回來？
A3：以本案為例，週一的對照顯示短期跌幅，但第 42 天自然點擊超過搬家前約 14.6%（本文列出實際對照數字）。回答時請提供對照表與後續 42 天的實際數據作為衡量。

檢查表（可列印回歸用，搬家前三天與上線後 30 天重複使用）

• DNS TTL：< 確認已調低至 300 秒或更低>
• 備份：<資料庫 / 檔案已下載並存放於異地>
• 轉址表：<一對一、837 列無空白>
• robots.txt：<無殘留 Disallow>
• sitemap：<新網址已產生並提交>
• canonical：<每頁皆指向正確新 URL>
• 標題 / 描述：<匯出檔案比對並補回缺失>
• 圖片 alt：<缺失以舊站資料回填>
• 內部連結：<無指向舊網址>
• 追蹤碼 / 轉換事件：<測試通過>
• HTTPS 與混合內容：<已修正>
• 自訂 404：<含搜尋功能>

限制 / 例外（何時上述流程不適用）

• 若站點使用大量動態分頁參數或站內搜索結果頁為索引來源，需另訂分頁與參數處理策略，本文範例中的規則需視情況調整。
• 若站點涉及多語系、複雜電商變種或大量使用 API 動態渲染，前置測試需延長且可能增加人力。

本文資料邊界（必讀）

• 本文內容為實務時間軸與檢查紀錄改寫，數字與時間點皆沿用原始紀錄（例如：837 頁、72 小時時間軸、19 項檢查、11 條 404 等）。
• 若要以此為公司內部 SOP 範本，請依貴公司實際系統、金流測試與法遵需求驗證（例如金流測試金額在本文標註為示例 / 需依讀者資料驗證）。

下一步（站內資源與聯絡）

• 若需進一步技術支援或範本，可參考我們的服務與表單頁面提出需求：服務頁面、案例或直接填表預約。

常見問答（FAQ）

Q：搬家後多久可以停止監控？
A：至少監控 30 天；前 2–3 週為密集期，常見修正與索引波動發生在此時。

Q：轉址一定要一對一嗎？
A：理想情況是一對一。將大量舊頁面一律導到首頁會喪失權重傳遞，且可能延長恢復時間。

Q：舊站可以立即關閉嗎？
A：不建議；建議保留至少 30 天以便救回遺漏的 URL。

Q：若搬家後超過 8 週仍未回穩，可能原因？
A：常見為轉址表遺漏、一對多轉址、不當的 robots 或 sitemap 設定，需逐項檢查。

Q：要如何加速特定外部連結頁的索引？
A：可逐頁使用 Search Console 的網址檢查並提交索引（注意不要重複提交過度頻繁）。

關於作者與審稿（原始紀錄）

• 本文改寫自冠誠數位行銷（GuanCheng Martech）一筆 2025 年 5 月某週末的實務搬家紀錄，文內數字與事件以原始工作群組訊息與檢查紀錄為基礎。若需原始審稿或更詳細的帳戶資料，請聯絡本公司以提供進一步驗證。

若需要套用到你公司情境，下一步建議：先用爬蟲匯出完整 URL 清單並產生初步轉址對照表，再依本文檢查表逐項確認。