直到客人打電話，才知道旅宿官網停止運作。預約頁面的失效連結放了好幾天。SSL憑證問題讓瀏覽器出現警告——這些問題，可能只靠每月查看一次管理畫面無法發現。
這時派得上用場的是從旅宿外部定期存取公開頁面，確認是否回傳正常回應的外部監控。AI能協助整理監控對象、設定建議、通知分類及每月報告。
本文為不熟悉IT的旅宿經營者，以入門方式說明要監控什麼、監控到什麼程度。
結論：一開始只從外部確認四項
不需要一開始就監控所有頁面或伺服器內部。先從與旅宿營業密切相關的四項開始。
- 首頁能開啟
- 預約說明或預約頁面能開啟
- 詢問頁面能開啟
- 能透過HTTPS安全連線
監控是「通知異常的機制」，不是自動修復。即使收到異常通知，也應設計成不讓AI自行重新啟動、清除快取、停用外掛或還原。
什麼是外部監控
外部監控是像客人一樣從網際網路端存取URL，定期確認頁面是否回應的方法。
外部監控位置
↓ 定期存取
旅宿的公開頁面
↓ 回應時間、狀態、內容
正常則記錄 / 異常則通知
這與查看伺服器內部CPU或容量的監控，角色不同。即使內部正常，只要DNS、HTTPS、Web伺服器或WordPress其中一處有問題，客人仍可能無法開啟頁面。反過來說，只靠外部監控，也無法知道容量不足或備份失敗。
入門理解HTTP狀態碼
瀏覽器存取頁面時，伺服器會回傳表示狀態的編號。
| 範圍 | 大致意義 | 範例 |
|---|---|---|
| 200系列 | 成功 | 成功取得頁面 |
| 300系列 | 轉向另一個URL | HTTP轉HTTPS、舊URL轉新URL |
| 400系列 | 所要求頁面方面的問題 | 404表示找不到頁面 |
| 500系列 | 伺服器方面的問題 | 500、502、503等 |
多數公開頁面會監控最終到達200 OK的狀態。不過，像預約按鈕正確轉向外部服務等預期的重新導向，不是異常。可以請AI調查目前目的地，再由人確認是不是正確的預約服務。
回傳200也不一定正常
WordPress也可能以200回傳錯誤畫面或維護通知。因此，除了回應編號，也要確認頁面「應有的內容」。
首頁
- 顯示旅宿名稱
- 有預約說明的連結
- 沒有變成錯誤訊息或維護畫面
預約說明
- 預約按鈕存在
- 前往預期的預約服務
- 沒有「停止受理」等非預期顯示
詢問
- 顯示表單或聯絡方式
- 輸入欄位沒有因版面錯亂而跑到畫面外
若保存整個內文進行比對，可能連價格、個人資料或動態空房資訊也被記錄。監控只使用公開頁面上的簡短固定文字或元素，不保存超過必要範圍的內容。
預約要區分「頁面顯示」與「預約成立」
不要讓自動監控反覆建立真實預約。預約動線應分階段處理。
| 階段 | 自動監控範例 | 由人確認的事項 |
|---|---|---|
| 入口 | 預約說明頁面能開啟 | 價格與注意事項是否正確 |
| 連結 | 預約按鈕的目的地正確 | 是否為簽約使用的預約服務 |
| 預約畫面 | 外部預約畫面有顯示 | 目標方案與日期是否正確 |
| 輸入、確認 | 原則上不自動執行 | 向預約公司確認測試方法 |
避免監控工具占用預約名額，或大量寄送通知郵件。包含付款的操作，應使用服務提供的測試環境或正式確認方法。
不提交也能監控詢問表單
日常監控可確認頁面能開啟，以及表單主要欄位和提交按鈕存在。但光是這樣，不代表郵件一定會送達。
表單提交確認，作為每月檢查或更新後確認，由人事先指定測試內容和收件地址再進行。若要自動提交，先設計以下事項。
- 能辨識為測試的主旨
- 不會與真實預約混淆的內容
- 不含個人資料的輸入
- 提交頻率上限
- 確認收信的負責人
- 對自動回覆及外部整合的影響
短時間內反覆提交表單，可能觸發垃圾訊息防護。
SSL、HTTPS要監控什麼
HTTPS是將旅宿與客人的通訊加密，並確認連線對象的機制。憑證若有問題，瀏覽器會顯示警告，客人可能在預約前離開。
確認項目如下。
- 能透過HTTPS連線
- 憑證尚在有效期限內
- 對旅宿的網域有效
- 憑證鏈沒有問題
- HTTP依預期轉向HTTPS
- 到期前能收到確認更新的通知
即使設定自動更新，也可能因DNS、驗證、容量或Web伺服器設定等原因失敗。不要認為「自動就不必確認」。
與WordPress網站狀態檢查的差異
WordPress管理畫面的「工具 → 網站狀態」可確認WordPress、佈景主題、外掛、PHP、HTTPS及背景更新等問題。
| 確認方法 | 擅長的事項 | 不擅長的事項 |
|---|---|---|
| 外部監控 | 從客人的角度確認頁面能否開啟 | WordPress內部詳細組態 |
| 網站狀態檢查 | WordPress內部建議及組態 | 整個網站停止時無法確認 |
| 伺服器監控 | CPU、記憶體、容量、程序 | 預約內容與外觀是否正確 |
| 人工確認 | 價格、預約、易用性 | 難以持續反覆執行 |
不是用其中一種取代全部，而是結合各自角色。網站狀態資訊包含技術架構與內部資訊，不要直接公開，或貼到與AI的公開對話。
決定最初的監控對象
旅宿經營者只要先建立以下表格即可。
| 優先 | 對象 | 正常條件 | 異常時聯絡對象 |
|---|---|---|---|
| 1 | 首頁 | 200、有旅宿名稱 | 網站負責人 |
| 1 | 預約說明 | 200、有預約按鈕 | 預約負責人 |
| 1 | HTTPS | 憑證有效 | 伺服器負責人 |
| 2 | 詢問 | 200、有表單 | 網站負責人 |
| 2 | 交通 | 200、有地圖說明 | 網站負責人 |
監控對象不要加入管理畫面URL、預覽URL、預約管理URL或顧客頁面。只使用公開頁面，不要輕率地將驗證資訊交給監控服務。
決定通知對象與頻率
通知太多，就容易連重要異常也不再閱讀。
- 是否一次失敗就緊急通知
- 是否連續失敗數次才通知
- 恢復時是否也通知
- 夜間聯絡對象是誰
- 要聯絡主機公司還是製作公司
- 是否合併同一故障的通知
預約頁面完全停止，會希望盡早知道；暫時的通訊延遲，則可再次確認後才通知。依營業影響區分優先順序。
可以交給AI的工作
Codex或Claude Code可協助以下事項。
- 從公開頁面整理監控候選對象
- 依與預約的關聯程度排序優先順序
- 記錄正常時的HTTP狀態及重新導向
- 提出固定文字或元素的確認條件
- 整理SSL憑證確認項目
- 依重複情況及緊急程度彙整監控通知
- 建立故障應變卡的聯絡表
- 摘要每月成功率與故障時間
- 將監控紀錄提供給故障後檢討
不要讓AI只因收到通知就自動變更正式環境。先透過多個位置、另一種網路，以及主機公司的故障資訊等確認事實。
可複製使用的AI委託內容
決定監控對象
請為旅宿的公開網站選出要從外部定期確認的URL。
候選對象包括首頁、客房與價格、預約說明、詢問及交通，
請依營業影響與監控頻率排出優先順序。
只針對公開頁面，請排除管理畫面、顧客頁面、預覽、
預約管理畫面，以及需要驗證的URL。
請先不要簽約監控服務或變更設定。
建立正常條件
請針對以下公開URL建立外部監控的正常條件。
［URL清單］
請區分HTTP狀態、預期的重新導向、固定文字或元素、
HTTPS憑證及回應時間。
不要將價格、空房、個人資料或動態日期時間作為固定條件。
不要執行預約或表單提交，只確認入口與連結。
將異常通知交由調查
網站監控收到以下異常通知。請先不要修正。
［目標URL、時間、HTTP狀態、持續時間］
請針對暫時通訊問題、整個網站、WordPress、預約服務及HTTPS，
建立應確認哪個部分的唯讀調查順序。
不要執行重新啟動、更新、停用、還原或清除快取。
請區分已確認事實、可能原因及未確認事項。
建立每月報告
請將一個月的外部監控結果摘要成旅宿經營者能閱讀的報告。
整理正常期間、異常日期與時間、目標URL、持續時間、誤報及處理結果，
並提出下個月要檢討的監控條件。
不要包含訪客資訊、IP位址、內部架構或驗證資訊。
選擇監控服務的比較項目
不要只依特定服務名稱或價格決定，請比較以下內容。
- HTTP、HTTPS的URL監控
- 文字、元素確認
- SSL到期通知
- 監控間隔
- 從多個位置確認
- 電子郵件、電話、聊天等通知方式
- 新增負責人及離職時的交接
- 紀錄保存期間
- 日文管理畫面與支援
- 保存的資料及使用地區
- 契約名義及付款管理
不要以個人的帳號管理旅宿服務，而要使用可交接的旅宿名義聯絡方式。即使從免費方案試用，也應確認官方說明中的監控數量、間隔、通知方式及歷史保存期間，是否符合旅宿用途。
減少誤報
正常卻被判定異常，也可能有以下原因。
- 暫時的網路延遲
- 快取或CDN造成位置差異
- 針對監控來源存取的垃圾訊息防護
- 動態庫存、日期或輪播內容
- 維護排程
- 重新導向目的地變更
出現誤報時，不要馬上停止監控，先縮小條件。例如確認固定標題而非日期或空房數，或失敗一次後再次確認。
不應監控的項目
- 自動登入WordPress管理畫面
- 顧客、預約管理頁面
- 一路操作到付款完成的自動流程
- 含個人資料的詢問結果
- 將Basic驗證或管理員密碼交給外部的設定
- 高頻率提交表單
- 異常時自動重新啟動或自動還原
即使技術人員設計合成監控，也應先確認測試環境、專用帳號、權限、資料刪除及外部服務條款。
旅宿經營者檢查清單
- [ ] 已將首頁、預約、詢問及HTTPS列為候選對象
- [ ] 只針對公開頁面
- [ ] 不只確認HTTP狀態，也確認固定元素
- [ ] 日常監控不包含確認預約或表單提交
- [ ] 已決定SSL到期通知對象
- [ ] 也另外確認網域契約續約期限與付款
- [ ] 異常與恢復都會通知
- [ ] 已決定包括夜間在內的聯絡對象
- [ ] AI只調查，不進行自動修復
- [ ] 每月檢討一次誤報與監控遺漏
- [ ] 契約及通知對象可用旅宿名義交接
網域契約與憑證更新管理，可參考避免旅宿網站網域與SSL到期的方法。若要一併調查網站內外連結及最終目的地，請參考使用AI檢查旅宿網站失效連結的方法。收到故障通知後的行動，請參考WordPress故障後的最初30分鐘；檢討請參考與AI建立防止再次發生的報告；畫面自動比對請參考Playwright入門。
參考資訊
總結
旅宿網站的監控，不一定要從困難的伺服器管理開始。先從外部確認首頁、預約、詢問及HTTPS，建立異常時能通知負責人的機制。
AI可整理監控對象、正常條件、通知分類及每月報告。旅宿經營者決定預約與價格是否正確、通知優先順序、聯絡對象，以及不應自動化的操作。若顯示速度持續不佳，可接著參考與AI排查WordPress緩慢原因的方法。與其承諾「不會停止的網站」，更實際的是朝「停止時能及早發現、安全應變的旅宿」努力。
