クライアントのWordPressサイトのアップタイム監視は、外部の監視サービスで「HTTPステータス」「ページ内のキーワード」「SSL証明書の期限」「ドメインの期限」の4点を見張り、通知の受け手と報告の形を先に決めておくことで、少ない手間で回せるようになります。この記事では、制作会社やフリーランスが保守契約の一部として監視を提供する前提で、ツールの選び方、監視項目の設定、誤報を減らすコツ、クライアントへの見せ方までを順に解説します。
アップタイム監視で何がわかり、何がわからないか
アップタイム監視（外形監視）は、サイトの外から一定間隔でURLにアクセスし、応答が正常かどうかを確認する仕組みです。サーバーの中に入らずに済むため、共用サーバーやマネージドホスティングのサイトでも導入できます。
一方で、わかるのは「外から見て応答しているか」までです。次のような問題は、アップタイム監視だけでは検知できないことがあります。
- 問い合わせフォームのメールが届かない
- 管理画面だけが表示されない、ログインできない
- WooCommerceの決済だけが失敗している
- 改ざんされているが、トップページは正常に表示されている
クライアントに「監視しているので安心です」と伝えると、こうした不具合まで見ている印象を与えがちです。監視の範囲は契約書や説明資料に書き、フォームの送信テストや更新後の動作確認など、別の作業でカバーする部分と分けて伝えておくと、後のトラブルを防げます。
監視ツールの選び方
選択肢は大きく3つあります。管理するサイトの数と、すでに使っている運用ツールで決めるのが現実的です。
外部の監視サービス
UptimeRobotやBetter Stackのような監視専門のサービスは、WordPress以外のサイトもまとめて監視でき、通知先の選択肢やステータスページ（公開用の稼働状況ページ）の機能が充実しています。無料プランでも基本的な監視は始められますが、監視間隔、監視できる数、通知手段、ステータスページの独自ドメイン対応などはプランによって変わり、内容も改定されます（2026年10月現在）。契約前に各サービスの料金ページで最新の条件を確認してください。
Jetpackのダウンタイム監視
Jetpackを入れているサイトなら、Jetpackのダウンタイム監視（Monitor）機能を有効にするだけで、サイトが応答しなくなったときにメールなどで通知を受けられます。設定の手間が少ない反面、通知先や監視項目の細かい調整はできないため、クライアントが自分で状況を知りたい小規模サイト向けと考えるとよいでしょう。
MainWP・ManageWPの稼働監視
複数サイトをMainWPやManageWPで一括管理しているなら、その稼働監視機能を使うと、更新作業とダウン通知を同じ画面で扱えます。どちらも監視機能の提供形態（本体機能か、拡張機能・有料アドオンか）がバージョンやプランで異なるため、導入時に公式ドキュメントで確認してください。両ツールの違いは、記事末尾の比較記事も参考になります。
プラグイン型・拡張機能型を選ぶ場合は、WordPress.orgやベンダーのページで最終更新日と対応バージョンを確認し、長く更新されていないものは避けます。また、監視をWordPress自身の中で完結させると、サーバーごと止まったときに通知も止まります。サイト外で動く仕組みを最低1つは持っておくのが基本です。
監視項目を設定する
1. HTTPステータス監視
トップページのURLを登録し、200番台以外の応答やタイムアウトを異常として扱います。リダイレクトが挟まる場合は、http:// ではなく最終的に表示される https:// のURL（www の有無も含めて）を登録すると、リダイレクトの挙動に左右されにくくなります。
2. キーワード監視
WordPressは、PHPの致命的なエラーでも画面上はメッセージを表示して応答を返すことがあり、キャッシュやCDNがエラー前のページを返し続けることもあります。そこで、ページ内に「フッターの会社名」など常に表示される文字列が含まれているかを確認するキーワード監視を併用します。
キーワードには、テーマのテキストのように変更されにくい文字列を選びます。トップページのキャッチコピーなど、クライアントが自分で書き換える箇所を使うと、更新のたびに誤報が出ます。
3. SSL証明書の期限監視
Let's Encryptなどの自動更新は便利ですが、DNSの変更やサーバー移転をきっかけに更新が失敗していても気づきにくい部分です。多くの監視サービスには、証明書の残り日数が一定以下になったら通知する機能があります。通知は期限の数週間前から段階的に出るように設定し、自動更新が止まっていても手動で対処できる余裕を確保します。
4. ドメインの期限監視
ドメインの期限切れはサイトもメールも同時に止まるうえ、復旧に時間と費用がかかります。監視サービスによってはドメインの有効期限も確認できますが、属性型JPドメインなど一部のドメインでは期限情報の取得方法が異なり、正しく監視できない場合があります。監視に頼るだけでなく、ドメインの契約者が誰か、自動更新が有効か、支払いに使うカードの期限は大丈夫かを保守台帳に記録しておくと安心です。
誤報を減らす設定
通知が多すぎると、本当の障害の通知が埋もれます。次の点を見直すと誤報を減らせます。
- 連続失敗で通知する: 1回の失敗ではなく、2〜3回続けて失敗したら通知する設定にする
- 複数地点から確認する: 1地点だけの失敗は経路の問題のことがあるため、複数地点で失敗したときに異常とみなす設定があれば使う
- タイムアウトを適切に: 応答が遅いサイトでタイムアウトを短くしすぎると、軽い負荷で誤報が出る
- メンテナンス中は一時停止: プラグイン更新やサーバー移転の作業中は、監視を一時停止するかメンテナンス時間として登録する
セキュリティプラグインやWAFが監視サービスのアクセスをボットとして遮断し、誤報が出ることもあります。誤報が続く場合は、サーバーのアクセスログで監視サービスからのリクエストへの応答コード（403など）を確認してください。
通知の受け手と対応の流れを決める
通知の設定で大切なのは「誰が受けて、何分以内に何をするか」を決めておくことです。
- 一次受け: 担当者のメールとSlackなど、普段見ている場所に送る。夜間・休日の扱いは契約内容に合わせる
- エスカレーション: 一定時間復旧しない場合は、責任者やサーバー担当にも通知する
- クライアントへの連絡: 監視の通知をクライアントに直接転送するかどうかは慎重に判断する。誤報や短時間の瞬断まで届くと不安を与えるため、制作側で状況を確認してから連絡するほうが多くの場合で適切です
障害が起きたときの初動は、「サーバー会社の障害情報を確認」「サーバーのエラーログを確認」「直前の更新作業の有無を確認」の順にしておくと、原因の切り分けが早くなります。
クライアントへの見せ方
監視の価値は、クライアントから見えなければ伝わりません。次の3つを組み合わせると、過度な期待を持たせずに安心感を伝えられます。
- ステータスページ: 監視サービスのステータスページ機能を使い、稼働状況をいつでも見られるURLを共有する。表示項目は「サイト」「SSL」程度に絞る
- 月次レポート: 稼働率、障害の件数と時間、SSL・ドメインの期限、実施した保守作業をまとめて送る
- 障害報告: 障害が起きたときは、発生時刻、影響範囲、原因、対応内容、再発防止策を短くまとめる
稼働率を報告するときは、計測しているのが外部からの応答であることと、監視間隔より短い停止は記録されない場合があることを添えておくと、数字の意味を正しく受け取ってもらえます。
まとめ
- アップタイム監視は外から見た応答の確認で、フォームや決済の不具合までは検知できない。監視範囲は契約や説明資料に明記する
- ツールは外部監視サービス、Jetpack、MainWP・ManageWPから、サイト数と既存の運用に合わせて選ぶ。サイト外で動く監視を最低1つ持つ
- 監視項目はHTTPステータス、キーワード、SSL期限、ドメイン期限の4つが基本
- 連続失敗での通知や作業中の一時停止で誤報を減らし、通知の受け手と初動を決めておく
- クライアントにはステータスページ、月次レポート、障害報告の形で見せる