WordPress 維護窗口與事件回應紀錄｜更新、停機、回滾與溝通證據

WordPress 網站維護常被想成「找一個晚上更新外掛」。但對長期經營的內容站來說，真正重要的是：更新前誰知道、更新中怎麼觀察、更新後如何證明網站正常，以及如果有短暫停機或功能異常，如何回滾並把溝通留成紀錄。

這篇不是要建立很重的企業流程，而是整理一份小型網站也能採用的維護窗口與事件回應紀錄。它適合用在外掛更新、PHP 版本調整、快取/CDN 規則變更、主機搬遷前後，以及任何可能影響登入、發文、表單、付款或 SEO 的操作。

維護窗口要先寫清楚「影響」而不是只寫時間

只說「今晚 10 點維護」通常不夠。比較可用的公告，應該包含時間、影響範圍、預期症狀、聯絡窗口與回復方式。

Maintenance window
- time: 2026-08-20 22:00-22:40 Asia/Taipei
- scope: WordPress plugin updates + cache purge
- expected impact: admin may log out once,
  frontend may serve stale cache for a few minutes
- owner: site maintenance / content operations
- rollback: restore plugin versions and cache rule snapshot

如果是品牌網站或內容站，讀者不一定需要看到技術細節；但內部維護紀錄需要保留「這次變更可能影響哪些功能」。例如留言、表單、搜尋、會員登入、媒體上傳、購物車、文章預覽都應該被列出。

更新前先保存可以比較的基準

維護前的 baseline 不需要複雜，但要能在事後回答「到底是更新造成的，還是原本就壞了」。我通常會留四類證據：

版本與環境：WordPress、PHP、外掛、佈景、資料庫版本。
關鍵 URL：首頁、最新文章、分類頁、登入頁、表單頁、REST API。
管理端狀態：Site Health、更新頁、外掛清單、錯誤 log。
快取與回應標頭：status、content-type、cache-control、x-cache、cf-cache-status。

可以先用低風險指令建立觀察紀錄：

wp core version
wp plugin list --fields=name,status,version,update --format=table
wp theme list --fields=name,status,version,update --format=table

再用 curl 保存幾個代表性 URL：

curl -I https://example.com/
curl -I https://example.com/wp-json/
curl -I https://example.com/contact/

重點不是把所有輸出都貼到公開文章，而是留下維護前後能比較的欄位。若網站牽涉客戶或真實使用者資料，記錄時要遮蔽帳號、Email、token、cookie 與任何私密參數。

變更中用 observe / change / verify 分段

維護紀錄如果只寫「更新完成」，事後很難追查。比較好的格式，是把每個動作分成 observe、change、verify。

Observe 22:03
- wp plugin list shows 4 plugins with updates
- homepage: 200 text/html
- /wp-json/: 200 application/json

Change 22:08
- update SEO plugin 23.1 -> 23.2
- update form plugin 5.9.1 -> 5.9.2
- purge object cache after update

Verify 22:16
- homepage: 200 text/html
- latest post: 200 text/html
- contact form page renders
- no new fatal error in PHP log

這種寫法的好處是：就算中途出現問題，也能知道問題發生在哪個 change 之後。對外回報時可以簡化成「已完成外掛更新與快取清除；文章頁、表單頁與 REST API 驗證正常」，但內部仍保留可追蹤的細節。

事件回應不要先急著清快取或停外掛

維護後如果前台突然白頁、表單送不出去、文章預覽 404，第一個反應常是清快取或停外掛。但如果沒有先保存異常狀態，證據很快會被覆蓋。

我會先做三個最小觀察：

curl -I https://example.com/problem-page/
curl -I https://example.com/wp-json/
wp plugin list --fields=name,status,version --format=table

再補一段 log 範圍，而不是只貼最後一行：

Error log context
- time: 22:21-22:24
- request: /contact/
- symptom: 500 after form plugin update
- related path: wp-content/plugins/form-plugin/
- note: no database change executed yet

如果判斷需要回滾，先回滾最可能相關的一項，不要一次把所有外掛都停掉。每個 rollback 也要附 verify，避免「回滾了但其實問題還在」。

對外溝通要說狀態，不要說猜測

小型網站也會遇到需要通知站長、編輯或客戶的情境。這時候最重要的是把已知狀態和推測分開。

External update
- 22:20 observed contact page returned 500
- latest article and homepage remained 200
- suspected form plugin update conflict,
  not yet confirmed
- rollback started at 22:27
- next update at 22:40

不要把「可能是快取」寫成「快取造成」。除非已經用 header、log、外掛隔離或回滾結果證明，否則就標成假設。這會讓維護紀錄更可信，也能避免下次重複追錯方向。

維護後把證據整理成下次可重用的模板

維護結束後，最有價值的不是一堆散落的截圖，而是一份下次可以複製的紀錄格式。

Maintenance closeout
- window: 22:00-22:40
- actual finish: 22:34
- changed: 2 plugins, cache purge, no theme edit
- verified: homepage, latest post, category page,
  contact form, REST API, sitemap
- rollback used: no
- follow-up: monitor form submissions for 24 hours

如果真的發生事故，closeout 還應該加上：

影響了哪些頁面或功能。
從何時開始、何時恢復。
使用者是否需要補做任何動作。
下次如何避免，例如 staging smoke test、外掛分批更新、維護窗口加長。

給 UCAMC 內容站的維護原則

對內容品牌網站來說，維護不是工程部門的背景工作，而是網站可信度的一部分。文章能不能正常讀、封面圖能不能載入、搜尋引擎看到的 canonical 和 sitemap 是否一致，都會影響讀者與 SEO。

我會把每次維護都留成一份簡短但可驗證的紀錄：先公告影響範圍，變更前保存 baseline，變更中分段驗證，異常時先保存證據再回滾，最後把狀態、假設與決策拆開寫清楚。這樣網站不是「有人有空就修一下」，而是逐步累積成可交接、可追蹤、可長期經營的系統。

WordPress 維護窗口與事件回應紀錄：把更新、停機與回滾溝通留成證據