WordPress 主題更新通常是小事一件，按下按鈕等幾秒就完成。但每隔一段時間，就會有人在論壇貼出截圖——首頁版型崩亂、側邊欄消失、客製化設定重置。這不是個別意外，而是跳過相容性確認這個環節的必然代價。

真正讓主題更新變得安全的，不是「信任開發商的更新品質」，而是在按下更新前完成幾個可驗證的動作。備份、讀 changelog（更新日誌）、在測試站跑一遍——這三件事任何一步都不複雜。但缺少其中一步，風險就從可控變成賭博。

更新前先把現有環境存起來

備份要存三個東西，缺一都不完整。

資料庫是最要緊的一份。主題版本切換時，若新版呼叫了不存在的資料庫欄位，或刪除了舊版自訂資料表，就算把主題檔案回復也救不回資料。備份資料庫的方式，可以直接在主機控制台（cPanel 或 Plesk）的 phpMyAdmin 匯出 .sql，也可以裝 UpdraftPlus 之類的備份外掛排程自動執行。

主題資料夾同樣要存下來。在 WordPress 後台的外觀主題管理頁面沒有「下載現有主題」按鈕，所以要透過 FTP 連線到主機，把 wp-content/themes/<主題名稱>/ 整個資料夾壓縮後下載到本機。若用的是子主題（Child Theme）架構，父子兩個資料夾都要備份。

客製化設定是另一個容易遺漏的細節。不少主題使用自己的選項面板（Options Panel）或主題設定頁面儲存自訂 CSS、排版選擇、色票。這些設定通常存在資料庫的 wp_options 資料表裡，資料庫備份理論上會包含。但若主題新版更改了選項的儲存鍵值（option key），備份是有了，設定卻不會自動遷移——這也是後面要讀 changelog 的原因之一。

備份完成後，把檔案放到本機硬碟或雲端儲存空間，確認可以開啟，而不是備份後就放著不管。

changelog 裡值得花五分鐘讀的地方

主題開發商通常會在 WordPress 外掛目錄（若是免費主題）或官網文件區列出 changelog。很多人會直接略過這份文件，其實它的資訊密度高於預期。五分鐘能讀出很多東西。

重點看以下幾類條目。

PHP 版本要求異動：若新版把最低 PHP 要求從 7.4 升到 8.1，而主機目前跑的是 7.4，更新後 WordPress 後台可能會顯示白畫面或錯誤訊息。可以在後台「工具 > 網站健康（Site Health）」確認目前 PHP 版本，再對比 changelog 的要求。

WordPress 核心版本相容性：changelog 通常會標「Tested up to: 6.x」，若目前 WordPress 核心版本比這個數字新很多，代表開發商尚未在最新環境下完整測試。這時要多留意運作狀況。

移除或重新命名的功能：「Removed deprecated X」「Renamed function Y to Z」這類條目直接影響子主題或已寫在 functions.php 裡的客製化程式碼。若曾在子主題呼叫父主題的函數，函數名稱被改掉就會觸發 PHP 錯誤。

資料庫結構異動：「Migration script required」或「Added new option key」這類標記代表更新後需要手動或自動跑移轉腳本。才能把舊資料格式轉成新格式。若跳過，設定頁面可能顯示空白或使用預設值。

樣式表（CSS）架構調整：若新版重構了 CSS 類別名稱（class name），之前在「外觀 > 客製化（Customizer）」或額外 CSS 欄位寫的自訂樣式就會失效，需要逐條核對。

讀完 changelog 後，把對目前站台有影響的條目記下來。三五個就夠，之後在測試站比對時當作核查清單用。

在測試站環境先跑一遍

把確認動作放到正式站之前，是主題更新流程中回報效益最高的環節。不需要每次都架一台全新主機，有幾個層次可以選。

用暫存站（Staging）功能複製正式站

現在多數主機商（SiteGround、Kinsta、Cloudways 這類）在控制台內建了暫存站按鈕。一鍵複製正式站到測試環境，兩者獨立運作，互不影響。流程大致是在主機後台開啟暫存站複本，在測試環境執行主題更新，確認版面與功能正常後，再把暫存站「推送到正式環境（Push to Live）」。

若主機不提供暫存站功能，可以在同一台主機的子目錄（例如 yourdomain.com/staging/）手動安裝一個 WordPress 副本，把正式站的備份還原進去使用。工具面，WP Staging 外掛能自動完成這件事。

在測試站應驗的核查項目

更新主題後，按照以下項目逐一確認，不要只瀏覽首頁就收工。

• 版面完整性：首頁、文章頁、頁面、分類頁、搜尋結果頁各開一次，確認頁首（Header）、頁尾（Footer）、側邊欄位置正常。
• 客製化設定保留：進「外觀 > 客製化」，確認之前設定的色彩、字型、Logo 都還在。
• 外掛衝突：若正式站有安裝頁面建構器（Page Builder）或特定功能外掛，在測試站同步啟用相同外掛清單，確認互動正常。
• PHP 錯誤紀錄：若有主機後台存取權，或在 wp-config.php 開啟了 WP_DEBUG，確認錯誤紀錄沒有新增的 notice 或 warning，尤其是函數呼叫失敗的訊息。
• 表單與轉換功能：聯絡表單、結帳流程、電子報訂閱這類涉及資料送出的功能，要實際走一遍，而不是只看外觀是否正常。

測試通過後再更新正式站

測試站確認沒問題，就可以回到正式站執行更新。操作建議在流量低峰時段進行，更新完成後的前十五分鐘保持在後台，確認首頁正常載入。再用手機確認行動版（Mobile）也沒跑版。

若更新後正式站出現問題，而備份是完整的，還原路徑很清楚。從 FTP 把備份的主題資料夾上傳覆蓋，再從資料庫備份還原——整個流程通常在三十分鐘以內可以完成。這也是備份環節不能省的最直接理由。

主題更新本身的複雜度很低。讓更新變得不確定的，幾乎都是環境準備不足。把備份、changelog 核查、測試站驗證當作標準前置步驟，這樣更新就不會是一場需要提心吊膽的操作。