WordPress 維護怎樣交接：備份、更新與還原驗證要分開

先分清楚網站有哪些狀態

維護不只是更新外掛。企業應先知道哪些內容存在資料庫、哪些屬於主題或程式檔案、圖片放在哪裏，以及有哪些外部服務。這份清單不需要包含密碼或連線值；只記錄責任人、儲存位置識別與正式交接入口，已能幫助團隊判斷某次修改會影響甚麼。

對內容網站而言，一個程式版本可能配合一個持續變動的資料庫。文章、表單紀錄或訂單在備份後仍可能增加，因此「回到舊版本」必須說清楚回復的是程式、內容，還是兩者。不能看到 Git 有程式碼，就推斷所有營運資料都可復原。

檔案備份與資料庫備份要成套理解

WordPress 官方文件把典型網站備份分為檔案及資料庫兩部分。只下載網站資料夾，一般不會順便得到獨立資料庫的內容。採購維護服務時，應要求說明兩部分如何對應、備份時間、保留位置與可用性，而非只確認某個資料夾存在。

備份頻率要按內容變動和可接受資料損失決定；企業可以先問：若只能找回上一份備份，會失去哪些工作？再決定合適節奏。另需分清原始素材、主機公開圖片和程式碼清單，避免把備份、正式網站及版本紀錄混為同一份資產。

更新前先界定範圍與復原點

WordPress 的更新指引提醒先備份，並確認備份可使用。實際維護計劃還應列出本次要更新的元件、目前版本、相容性風險及驗收路徑。不要把多個互不相關的改動塞進一次更新，否則出現問題時較難判斷來源。

對主要表單、付款或會員功能，應先確認適合的測試方式、測試資料及授權邊界。沒有可用測試環境時，更要縮小改動並保存現況；這不代表可以省略驗收。涉及主機設定、權限、帳戶或認證的變更，應另按正式授權處理。

還原測試與正式更新是不同證據

「備份工作完成」只證明備份程序回報了某個結果；「還原可用」還需要在允許的目的地實際還原並檢查。可以在交接表中分開記錄備份時間、檔案完整性、測試還原日期、測試範圍及未覆蓋資料，避免把未測部分寫成已通過。

正式更新後也要分層讀回：目的地檔案是否正確、一般訪客網址是否顯示新內容、手機和桌面流程是否正常，以及表單或外部服務是否收到預期結果。主機快取可能讓訪客暫時看到舊頁，不能單以原始檔案已變更便宣稱畫面修復。

讓下一位維護者接得上

交接紀錄可包含網站用途、現行來源、每個元件的負責方、最近一次成功更新、已知問題、備份與復原方法，以及重大功能的驗收步驟。認證資料應留在公司核准的私密管理方式中，不要放入報告、聊天、公開 repo 或普通試算表。

每次改動保留原版本、實際修改清單、結果與限制。若寫入結果不明，先對同一個檔案或請求讀回，避免重複執行。這些做法能讓維護成為可承接的工作紀錄；它們不能保證永遠沒有事故，但可讓問題出現時有清楚的處理起點。

維護會議可以直接確認的問題

開始前可逐項問：哪一份資料是現行來源？誰能批准變更？若更新中斷，先讀回哪個物件？哪些公開流程需要人工驗收？哪些資料持續變動而不能直接覆蓋？把答案寫入本次工作單，比只約定「有問題再聯絡」更容易執行。

結案時請維護者列出實際完成與未完成的部分，連同對應版本、日期和證據位置。若某項能力尚未配置，例如指定信箱送達或測試還原，應明確保留，不能用其他檢查結果補成已通過。

交接清單

• 分列程式、主題、外掛、媒體、資料庫與外部服務的負責方。
• 記錄備份組的時間、完整性與可接受資料損失範圍。
• 更新前保存復原點，更新後讀回公開頁面及主要流程。
• 將備份完成、還原測試、部署完成及訪客驗收分開記錄。

常見問題

網站檔案已備份，文章是否一定包含在內？

典型 WordPress 的文章資料存在資料庫，單靠檔案備份一般不足以還原。應確認同一套備份是否包含相應資料庫。

所有網站都要每日備份嗎？

頻率應按內容變動、業務需要與可接受資料損失決定。不要直接把其他公司的節奏當成自己的要求。

更新程式成功後，還需要看一般網址嗎？

需要。程式更新、快取回應、頁面渲染及外部服務可分別出現問題，應按本次改動驗收受影響路徑。