直到客人打电话，才知道旅宿官网停止运作。预订页面的失效链接放了好几天。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缓慢原因的方法。与其承诺「不会停止的网站」，更实际的是朝「停止时能及早发现、安全应对的旅宿」努力。
