旅宿的網站突然無法顯示。按下預約按鈕也無法繼續。WordPress管理畫面出現「嚴重錯誤」——營業期間遇到這些情況，急著修好的心情容易讓人接連嘗試更新、重新啟動和停用外掛。
然而，故障剛發生時，重要的並不只有修復速度。先維持與有意住宿的客人之間的聯繫、記錄症狀並防止進一步損害，再交由相關人員調查原因，才是關鍵。
本文依時間順序說明，不熟悉IT的旅宿經營者如何使用Codex或Claude Code作為輔助，在最初30分鐘進行初步應變。
結論：最初30分鐘要「維持營業、記錄、停止、聯絡」
故障應變的優先順序如下。
0〜5分鐘 確保預約、詢問的替代管道
5〜10分鐘 記錄症狀及發生時間
10〜20分鐘 停止追加變更，確認影響範圍
20〜30分鐘 將必要資訊交給負責人，決定恢復方針
這不代表必須在這30分鐘內恢復服務。目標是避免因慌張而增加問題，讓維護人員能安全調查。
0〜5分鐘：維持預約、詢問的入口
首先要確認的不是WordPress管理畫面，而是客人是否能與旅宿聯絡。
- 電話是否接得通
- OTA上的旅宿頁面與預約受理是否正常
- 自家預約系統是否能獨立於WordPress開啟
- 是否能透過官方SNS發布通知
- 是否能聯絡已有預約的客人
如果只有WordPress停止運作，而OTA或外部預約系統仍正常，可以暫時引導客人使用這些預約管道。反之，若預約系統或付款也停止，不要憑推測告知空房或價格，應改成先透過電話受理、確認後再回電的作法。
暫時通知範例
目前官方網站顯示發生異常。
預約及詢問暫請使用［電話號碼／目前可用的預約管道］。
恢復情況將在本通知更新。
原因、預計恢復時間、是否有個人資料外洩，都不能在確認前斷言。在尚無依據時，也不要使用「網路攻擊」「資料遺失」等措辭。
5〜10分鐘：記錄畫面與時間
故障畫面是調查原因的線索。請在重新載入或變更設定導致畫面消失前記錄。
要記錄的內容
- 發現日期與時間
- 發生問題的URL
- 使用的是電腦或智慧型手機
- 確認時使用的網路，例如Wi-Fi或行動網路
- 畫面上的簡短錯誤訊息及編號
- 登入與登出狀態的差異
- 剛才進行的更新或設定變更
- 最後一次正常運作的日期與時間
- 預約、詢問及管理畫面的狀態
螢幕截圖可能包含管理畫面URL、使用者名稱、電子郵件地址、預約編號、瀏覽器分頁等。在交給外部人員或AI之前，只裁切必要部分，並遮蔽秘密資訊和個人資料。
使用另一部裝置也只確認一次
釐清問題只發生在自己的瀏覽器，還是一般客人也會遇到。
- 使用無痕視窗開啟
- 使用智慧型手機的行動網路開啟
- 直接開啟發生問題的URL
反覆提交表單或進行預約操作，可能產生重複詢問或暫時預約。功能測試應先確認方法再進行。
10〜20分鐘：停止追加變更，區分影響範圍
以下操作先暫停。
- 追加更新WordPress、佈景主題或外掛
- 一次停用所有外掛
- 切換正式網站的佈景主題
- 修復、替換或還原資料庫
- 重新啟動伺服器
- 同時清除快取和變更設定
- 只為隱藏錯誤而新增程式碼
- 刪除舊備份或紀錄檔
若有已開始的作業，請記錄「做了什麼」「何時」「從哪個畫面」執行。某些處理中途強制停止會引起其他問題，因此要將目前狀態告知維護人員。
將影響範圍分成四個階段
| 階段 | 範例 | 初步應變的思考方式 |
|---|---|---|
| 部分顯示 | 只有圖片或裝飾版面異常 | 記錄並確認預約動線，再進行調查 |
| 部分功能 | 預約、表單或選單無法運作 | 告知替代管道，優先調查 |
| 整個網站 | 白畫面、嚴重錯誤、500等 | 停止追加變更，聯絡負責人 |
| 多個服務 | 電子郵件、預約及伺服器也停止 | 包括服務商的故障資訊在內，緊急聯絡 |
若是外觀版面異常，可以接著參考佈景主題、外掛與快取的問題排查。整個網站停止時，不要直接認定只是顯示問題。
20〜30分鐘：決定將什麼資訊交給誰
使用的伺服器服務不同，聯絡對象也不同。
虛擬主機、託管式WordPress
- 確認主機公司的故障及維護資訊
- 聯絡管理畫面的客服窗口
- 確認契約持有人及支援範圍
- 確認是否提供還原服務，以及可還原至哪個時間點
VPS、雲端
- 聯絡WordPress維護人員或伺服器管理員
- 以唯讀方式確認伺服器、Web、PHP及資料庫的運作狀態
- 重新啟動或還原前，決定影響範圍及回復方法
- 確認對預約、電子郵件等同機服務的影響
主機公司可能不支援WordPress內部修正，而網站製作公司可能無法存取主機服務帳號。平時就記錄各方負責範圍很重要。
什麼是WordPress的復原模式
WordPress在偵測到佈景主題或外掛等造成致命PHP錯誤時，有時會將復原模式連結寄到管理員信箱。這是一種透過特殊管理工作階段確認問題元件的機制。
收到郵件後，請確認以下內容。
- 收件地址是否為WordPress登記的管理員信箱
- URL的網域是否為自己的網站
- 是否沒有可疑附件
- 畫面列出的佈景主題、外掛名稱
復原模式不是所有故障都會啟動，也不是永久修復。不要因為沒收到郵件，就慌忙變更管理員地址，或從搜尋結果開啟可疑連結。請向主機公司或維護人員諮詢。
交給AI的是狀況整理與安全調查計畫
AI在初步應變時能協助以下工作。
- 將記錄內容整理成時間軸
- 列出受影響的URL與功能
- 建立不變更正式環境的確認項目
- 比對更新紀錄與發生時間
- 根據錯誤訊息尋找應查閱的官方資料
- 撰寫給主機公司、維護人員的詢問內容
- 建立恢復後的檢查清單
- 建立故障紀錄範本
另一方面，不要在故障剛發生時，把重新啟動、資料庫還原、停用全部外掛、權限變更或刪除檔案全權交給AI。
可複製使用的初步應變提示詞
最初的狀況整理
旅宿的WordPress發生故障。請先不要修正。
發現日期與時間: ［日期與時間］
發生問題的URL: ［URL］
症狀: ［簡短錯誤訊息、顯示狀態］
剛才的作業: ［更新或設定變更］
目前可用的預約管道: ［電話、OTA等］
一開始只進行唯讀調查及狀況整理，
請區分營業影響、已確認事實、可能原因、未確認事項，
以及接下來需要由人確認的項目。
請不要執行更新、停用、重新啟動、還原、刪除或設定變更。
撰寫給客服的詢問內容
請針對以下WordPress故障，撰寫要寄給主機公司或維護人員的
詢問內容。
［發生日期與時間、URL、症狀、剛才的變更、確認裝置、受影響功能、已完成的確認］
不要斷定原因，請簡潔說明緊急程度及希望確認的內容。
不要包含密碼、私密金鑰、內部路徑、顧客或預約資訊。
比較恢復方案
透過唯讀調查，已確認以下事實。
［已確認的事實］
請先不要執行。
請比較修正、暫時停用元件、回復舊版及從備份還原的
影響範圍、可能遺失的資料、所需時間、回復原狀的方法，
以及恢復後的確認。
請明確指出需要由人核准的操作。
不要急著決定是修復還是還原
回到故障前狀態的方法有多種。
- 只回復有問題的設定
- 將更新過的佈景主題、外掛回復至已驗證版本
- 暫時停用造成問題的元件
- 只回復檔案
- 從備份還原，包括資料庫
若將整個資料庫還原到較早時間點，備份取得後的文章、詢問、預約及設定可能遺失。先確認哪裡損壞、需要回復到什麼範圍。備份狀態也可參考還原演練文章。
恢復後要確認的事項
不要只因「首頁打得開」就結束。
- 電腦與智慧型手機都能開啟主要頁面
- 預約按鈕及外部預約目的地正確
- 價格、方案及空房資訊正確
- 已安全確認詢問表單
- 合法管理員能登入管理畫面
- 圖片、CSS及JavaScript沒有缺漏
- 已確認郵件寄送正常
- 監控及備份已重新開始
- 暫時通知已更新為恢復通知
- 已記錄原因、處理、所需時間及防止再次發生的措施
更新前後的畫面比對可使用Playwright自動比對。
平時準備的「故障應變卡」
為避免故障時四處尋找資訊，請將以下內容整理在紙上或安全的共用位置。
- 公開網站與預約頁面的URL
- 電話、OTA、SNS等替代聯絡方式
- 主機公司與契約持有人
- WordPress維護、網站製作及預約系統的聯絡方式
- 哪些人能發布暫時通知
- 最後一份已驗證備份的確認方法
- 故障紀錄的儲存位置
- 能核准重新啟動、還原及刪除的人員
不要將密碼或私密金鑰直接寫在卡片上，只記載如何前往組織指定的安全管理位置。
旅宿經營者檢查清單
- [ ] 已確認電話、OTA等替代預約管道
- [ ] 已發布給客人的暫時通知
- [ ] 已記錄發生時間、URL及畫面
- [ ] 已使用另一部裝置、另一種網路確認一次
- [ ] 已停止追加更新及臨時拼湊的修正
- [ ] 已區分顯示、預約、電子郵件及管理畫面的影響
- [ ] 已聯絡主機公司或維護人員
- [ ] 已先請AI進行唯讀調查
- [ ] 還原前已確認可能遺失的資料
- [ ] 恢復後已由人確認預約及詢問
參考的官方資訊
總結
WordPress故障後的最初30分鐘，不是盲目修復的時間。這段時間應維持客人的預約與詢問管道，記錄症狀、停止追加變更，並將資訊交給適當的負責人。
AI能協助整理時間軸、分類影響範圍、撰寫詢問內容及建立確認表。旅宿經營者負責營業優先順序、對外通知、變更核准，以及價格與預約的最後確認。平時先確定這些分工，發生故障時就比較不會困惑於「該從哪裡開始」。
