多數討論網站改版的文章，焦點幾乎都放在新版型好不好看、排名會不會掉，很少有人回頭盤點一件更基本的事，就是舊網站上有哪些資料得在動工前先備份下來。等到新版上線，才發現某支外掛的授權碼不見了、某個頁面手動調過的 meta description 被系統預設值整批蓋掉，通常已經來不及回頭補救。
網站改版舊資料備份，指的不只是把資料庫匯出成一個檔案這麼簡單。它涵蓋文章與頁面之外的外掛設定、媒體庫原始檔、累積多年的 SEO 優化紀錄，還有網域與金鑰這類存取權限。任何一塊漏掉，都可能在上線之後才浮現，而且多半補不回來。
先從最容易被誤解的一塊講起，資料庫裡裝的東西，遠比內建匯出功能能帶走的還多。
資料庫備份，只匯出文章和頁面就足夠嗎？
資料庫裡存放的不只是文章與頁面，還包括外掛與佈景主題寫入的各種設定值，例如選單結構、自訂欄位資料、外掛的授權碼。這些內容不會出現在單純的「匯出文章」功能裡，新網站上線後才發現要重新設定一次。WordPress 官方的備份說明明確指出，資料庫裡存放著網站上的每一篇文章、每一則留言與連結，是網站內容真正的核心資料。這是網站改版舊資料備份最容易被低估的一步，多數人以為資料庫等於文章內容，其實還有一層外掛設定同樣得留住。如果原本就有線上商店，產品、庫存、訂單這些資料的遺失風險又是另一個等級。
文章、頁面、留言與外掛設定值
文章、頁面、留言分類這些內容都存在同一個資料庫裡，但 WordPress 後台內建的匯出功能，通常只帶得走文章與頁面本身，外掛寫入的設定值（像是選單結構、進階自訂欄位的資料、某些外掛的授權碼）並不在這個匯出範圍內。要留住這些設定，得靠完整的資料庫備份，或是外掛自己附的匯出、匯入功能。改版前先把有客製化設定的外掛一一確認過會不會有專屬的匯出方式，遠比上線後憑記憶重新設定一次要省事。
電商產品與訂單資料（如果原本就有線上商店）
若原本的網站就有線上商店，產品資料、庫存數量、訂單紀錄同樣存在資料庫裡，但備份的要求通常比一般內容頁更高。這類資料牽涉到金流對帳與客戶服務，漏了一筆訂單紀錄，影響的不只是網站好不好看。改版前，這塊要單獨跟系統開發方確認一次商店資料要用什麼方式搬到新系統，而不是假設它會跟著文章頁一起自動帶過去。
媒體檔案與表單紀錄，備份工具真的都涵蓋到了嗎？
備份工具容易漏掉兩個角落，第一是媒體庫的原始檔案，第二是聯絡表單與名單蒐集表單累積下來的送出紀錄。這兩塊都不在文章、頁面的匯出範圍裡，若沒有特別處理，改版後很可能整批消失。
WordPress 官方文件在說明備份範圍時，把「檔案」與「資料庫」列成缺一不可的兩塊。檔案指的是伺服器上 WordPress 目錄裡的內容，包含核心程式、佈景主題、外掛、上傳目錄、wp-config.php、.htaccess 等。上傳目錄裡的圖片、影片這些原始檔，正是屬於「檔案」而不是「資料庫」的部分，只備份資料庫並不會把它們一起留下來。
媒體庫的原始檔案
網站上看到的圖片，多半是上傳當下自動生成的縮圖版本，資料庫存放的只是這些檔案的路徑與描述文字，實體檔案本身放在伺服器的上傳目錄裡。只備份資料庫，等於把「這裡曾經有一張圖」的紀錄留下來，卻沒把那張圖本身留下來。只要備份時漏了這一步，圖片就留不下來。改版前要把整個上傳目錄的實體檔案另外打包留存，才算完整。
表單送出紀錄與名單資料
聯絡表單、電子報訂閱這類表單，很多外掛會把使用者送出的資料存進自己獨立建立的資料表，不在文章、頁面的匯出範圍內。累積下來的名單資料，如果改版時換了表單外掛或整套系統，很容易在沒人注意到的情況下直接消失。先確認這些送出紀錄能不能匯出成通用格式，例如逗號分隔的 CSV 檔，再決定要不要把它們搬進新系統，是比較穩妥的做法。
佈景主題與外掛的客製化設定，換了系統就必須重做
除了資料類的東西，還有一塊技術資產同樣重要，就是曾經客製化過的程式碼、外掛清單與版本、伺服器層級的設定檔。這些不會自動出現在新網站上，如果沒有事先記錄下來，換系統之後等於要從零猜測原本裝了什麼、改過什麼。
WordPress 官方文件把檔案備份的範圍列得很清楚，包含 WordPress 核心、佈景主題、外掛、wp-config.php、.htaccess 等項目，這幾樣剛好對應到改版時最容易被忽略的技術層面。
Child Theme 與客製化程式碼
如果曾經請人改過網站的樣式或功能，這些程式碼多半寫在 Child Theme 或 functions.php 裡。這類客製化的原始檔要單獨備份下來，不能只靠「網站現在看起來是這樣」去反推當初改了哪些地方，改版時很容易漏掉某個小功能，事後才發現某個表單驗證或某個排版規則不見了。
已安裝外掛清單與版本號
把目前用到的外掛名稱與版本整理成一份清單，是改版前最省力、也最容易被跳過的一步。有這份清單，新網站上線時才能對照哪些功能需要重新安裝、哪些外掛可能要找替代方案，而不是等到某個功能不見了才回頭想原本裝了什麼。
伺服器層級的設定檔
.htaccess 或主機控制台裡設定的轉址、快取、安全規則，換主機或換系統時很容易被整批清空。這些規則多半是網站營運過程中陸續加上去的，不會憑印象重建，改版前要先把現有的設定內容讀一份完整備份下來，才不用等出狀況了才想起某條規則曾經存在。
SEO 設定與追蹤數據，改版時最容易漏備份哪些？
這一塊處理的是排名相關、卻常被誤以為改版團隊會自動處理好的資料：每個頁面手動寫過的 title 與 meta description、既有的 301 轉址規則、GA4 與 Search Console 累積的歷史數據、反向連結清單。這些東西一旦沒有備份下來，改版後很難重建，也很難拿舊資料當作前後比較的基準。結構化資料（schema）設定同樣值得備份，AI 摘要工具與 Google 導入的 AI 搜尋功能，同樣是靠這些標記資料理解頁面內容，改版把它清空，等於讓這些工具對網站的理解回到原點。
Google 官方的搜尋中心文件，在說明網站搬遷時建議先建立一份舊網址與新網址的對照清單，並保留轉址規則，讓排名訊號完整轉移到新網址上。這份對照清單同時也是改版前該備份的資料之一，不是等搬完才動手整理。
每個頁面的 Title 與 Meta Description
多數網站的 title 與 meta description，不是一次寫完就沒再動過，而是依實際點擊率陸續調整過。改版時如果被新系統的預設規則整批重寫，等於把過去這段時間累積的優化白費。先把每個頁面現有的 title 與 meta description 整理成一份清單，是最基本、卻最容易被跳過的一步。
既有的 301 轉址規則
舊轉址跟改版要新增的轉址是兩件事。前者是網站已經走過一次搬遷或調整留下的規則，常在備份時被漏掉，被新系統的規則整批洗掉。Google 官方文件建議，網站搬遷時應該盡可能長時間保留轉址，一般建議至少一年，才能讓排名訊號有足夠時間轉移完成。這代表舊轉址不是可以隨新版上線一起丟掉的東西，得先完整記錄下來，跟新規則並存。
GA4、Search Console 歷史數據與反向連結清單
匯出這些歷史數據，目的是留一份改版前後的比較基準。沒有這份基準，事後很難判斷流量或排名的變化，是改版造成的還是本來就在波動。Google 官方文件在準備網址對照清單時，也建議一併整理一份連到舊網址的外部連結清單，方便日後追蹤這些連結有沒有正確導向新網址。
網域、憑證與第三方金鑰，這些存取權備份了嗎？
這一塊處理的是最容易被忽略、卻一旦出事影響最大的資料：網域註冊資訊與 DNS 紀錄（尤其是信箱收發用的 MX 紀錄）、SSL 憑證的到期與更新設定、串接第三方服務用的 API 金鑰。這些通常不算網站內容，很容易被排除在備份清單之外，卻直接關係到信箱收不收得到信、網站能不能正常連線。
Cloudflare 官方文件在說明 DNS 的 TTL（存活時間）機制時指出，TTL 設得越長，查詢速度越快，但紀錄變更後要花更久時間才會生效。換句話說，DNS 紀錄的變更不是按下確認鍵就立刻反映，而是要等舊的快取逐漸過期。這也是為什麼換主機前，要先把現有的 DNS 紀錄完整記錄下來，而不是等切換當下才臨時查。
網域註冊資訊與 DNS 紀錄
MX 紀錄（信箱收發用）是改版換主機時最容易被整批覆蓋的一項，一旦被覆蓋，公司信箱可能有一段時間收不到信，而且不會立刻發現。DNS 變更也需要時間才會生效，不是換完主機當下就馬上反映到所有使用者身上。改版前，把現有的 DNS 紀錄逐一截圖或匯出保存，是最基本的保險。
SSL 憑證與到期時間
憑證的簽發與更新方式，尤其是綁在舊主機自動續約的那種，要先確認清楚是怎麼運作的。換了主機或系統，如果沒有先接手憑證的續約流程，很可能出現憑證斷點，讓瀏覽器對訪客顯示不安全的警告。
第三方服務的串接金鑰
金流服務、電子報平台、CRM、地圖服務，這類第三方串接通常都需要一組 API 金鑰才能正常運作。這些金鑰多半存在外掛的設定畫面裡，不會出現在一般內容備份的範圍內。改版前把用到金鑰的服務列成一份清單，逐一確認金鑰放在哪裡、怎麼取得，能省下改版後這些功能突然失效才臨時求救的時間。
帳號權限與法遵頁面，改版後最容易被忘記重新設定
這一塊收在兩個容易被忽略的層面：誰能登入網站，以及網站上寫過的法規文字。現有的管理員與使用者帳號清單，加上各自的權限範圍，直接影響改版後誰還能登入、誰的權限被不小心留下。隱私權政策、服務條款這類頁面既有的文字內容，也容易在版型整批替換時被誤刪或漏搬，等到要對照舊版寫了什麼，才發現找不到原始文字。
把現有帳號清單與這些法遵頁面的文字內容，一起列進改版前的備份項目，是收尾這份清單時最容易漏掉、卻最基本的兩項。
備份這些資料花的時間，比起改版上線後才發現東西不見、要從頭拼湊回來的時間，通常划算得多。這也是為什麼一份完整的網站改版舊資料備份清單，該排進改版流程最前面的項目，而不是有空再處理的附加工作，新版上線時才不會一邊上線、一邊補救舊資料。