WordPressサイトの運用で確認すべきことは、「止まっていないか」「戻せるか」「更新で壊れないか」「侵入されていないか」の4つに集約できます。この記事では、それぞれを毎日・毎週・毎月・年1回の頻度に振り分けたチェックリストと、各項目を何で確認し、異常があったときにどう判断するかを説明します。手作業を減らすため、自動化できる項目は監視ツールやWP-CLIに任せる前提で組み立てています。
チェックリストの全体像
頻度ごとの項目は次のとおりです。自社の体制に合わせて、担当者と確認日をあらかじめ決めておくと抜けが減ります。
- 毎日（自動通知を受けて確認）：死活監視、バックアップの成否、フォームの送信
- 毎週：更新の確認と適用、エラーログ、ディスク容量
- 毎月：ユーザーと権限、不要なプラグイン、改ざんの検査、表示速度、Search Console
- 年1回（または半年ごと）：リストアの訓練、PHPのバージョン、ドメインとSSL証明書、契約の棚卸し
毎日：止まっていないかを自動で知る
死活監視
サイトが表示されなくなったことに、利用者からの連絡で気づくのでは遅すぎます。UptimeRobot などの外部監視サービスで、トップページと主要なページを数分おきに監視し、応答が無いときにメールやチャットへ通知が届くようにします。監視するURLには、キャッシュされにくいページ（お問い合わせページなど）も1つ含めておくと、PHPやデータベースの停止に気づきやすくなります。
毎日の作業は「通知が来ていないかを見る」だけで済むようにしておくのが理想です。
バックアップの成否
バックアッププラグインやサーバーの自動バックアップが、前日分を正常に取得できたかを確認します。失敗の通知をメールで受け取れる設定にしておきます。バックアップの保存先がサイトと同じサーバーだけだと、サーバー障害のときに一緒に失われるため、外部ストレージにも保存されているかを確認してください。
フォームの送信
お問い合わせフォームのメールが届かない障害は、サイトが表示されている限り気づかれにくいものです。毎日でなくても、少なくとも週に1回はテスト送信するか、フォームの送信履歴をデータベースに残すプラグインで受信数の急な減少に気づけるようにします。送信元ドメインのSPF・DKIMが未設定だと、受信側で迷惑メールに振り分けられることがあります。
毎週：更新と異常の早期発見
更新の確認と適用
WordPress本体、プラグイン、テーマの更新を確認します。WP-CLIが使える環境なら、次のコマンドで一覧できます。
wp core check-update
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version更新の進め方の目安は次のとおりです。
- セキュリティ修正を含むマイナーアップデート（6.x.y の y が上がるもの）は、早めに適用する
- メジャーアップデートや、大きくバージョンが上がるプラグインは、ステージング環境で表示とフォームを確認してから本番に適用する
- 更新前にバックアップがあることを確認する。更新後は、トップページ、記事ページ、フォーム、管理画面の表示を確認する
自動更新を使う場合も、どのプラグインを自動にしているかを把握し、更新の通知メールに目を通します。
エラーログ
PHPのエラーログ（サーバーのログ、または wp-config.php で WP_DEBUG_LOG を有効にした場合の wp-content/debug.log）を確認します。本番で WP_DEBUG_DISPLAY を有効にしてエラーを画面に出すのは、内部情報が漏れるため避けてください。debug.log はそのままだと外部から読める場所にあることがあるため、出力先を公開ディレクトリの外に変えるか、アクセスを制限します。
同じ警告が大量に出ている場合は、更新で互換性が崩れたプラグインが原因であることが多く、放置するとログがディスクを圧迫します。
ディスク容量
サーバーのディスク使用率と、データベースのサイズを確認します。
df -h /
wp db size --tables --size_format=mb使用率が80%を超えていたら、古いバックアップファイル、ログ、不要なメディアの整理を検討します。容量が尽きるとバックアップやデータベースの書き込みが失敗し、サイトが止まることがあります。
毎月：安全性と品質の点検
ユーザーと権限
管理者権限を持つユーザーを一覧し、退職者や作業の終わった外部業者のアカウントが残っていないかを確認します。
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered心当たりのない管理者がいる場合は、不正侵入の可能性があります。すぐに削除するのではなく、まずバックアップを取ってから調査してください。記事を書くだけのユーザーは「編集者」や「投稿者」に権限を下げ、管理者には二要素認証を設定します。
不要なプラグインとテーマ
無効化したまま使っていないプラグインやテーマも、ファイルが残っていれば脆弱性の対象になります。使わないものは削除します。長期間更新されていないプラグインは、代わりを探す候補として記録しておきます。
改ざんの検査
WordPress.org で配布されている本体とプラグインのファイルが改変されていないかを、WP-CLIで検査できます。
wp core verify-checksums
wp plugin verify-checksums --all有料プラグインなど WordPress.org で配布されていないものは検査できない旨が表示されます。それ以外で差分が見つかった場合は、改ざんを疑い、ファイルの中身を確認します。
表示速度とSearch Console
PageSpeed Insights で主要なページを測定し、前月から大きく悪化していないかを見ます。Google Search Console では、ページのインデックス登録の状況、ウェブに関する主な指標（Core Web Vitals）、セキュリティの問題、手動による対策の通知を確認します。急にインデックスされないページが増えた場合は、テーマやSEOプラグインの更新で noindex や canonical の出力が変わっていないかを疑います。
管理画面の「ツール」→「サイトヘルス」も月に1回は開き、「重大な問題」が出ていないかを確認します。
年1回：前提条件の見直し
リストアの訓練
バックアップは、戻せることを確かめて初めて意味を持ちます。年に1回は、バックアップからステージング環境や別のサーバーにサイトを復元し、表示とログインができるか、復元に何分かかるかを記録します。手順書を最新の状態に更新する機会にもなります。
PHPのバージョン
サーバーのPHPがサポート期間内かを確認します。PHPの各バージョンには公式のサポート期限があり、たとえば PHP 8.2 のセキュリティサポートは2026年末で終了する予定です（2026年10月現在）。WordPressの推奨バージョンは公式サイトの要件ページで確認できます。PHPを上げる前には、ステージング環境でプラグインとテーマの動作を確認してください。
ドメインとSSL証明書
ドメインの有効期限と自動更新の設定、SSL証明書の自動更新が機能しているかを確認します。支払いに使っているクレジットカードの期限切れで自動更新が失敗する例があります。Let's Encrypt などの無料証明書は有効期間が短く自動更新が前提なので、更新に失敗したときに通知が来るかを確かめておきます。
契約と連絡先の棚卸し
サーバー、ドメイン、有料プラグイン、外部サービスの契約者・支払い方法・ログイン情報の管理者を一覧にし、担当者の異動で分からなくなっていないかを確認します。障害時の連絡先と、サーバー会社の問い合わせ窓口も一緒に記録しておきます。
運用を続けるための工夫
チェックリストは、項目が多すぎると形骸化します。最初は「死活監視」「バックアップの成否」「週1回の更新」「月1回の管理者確認」の4つから始め、慣れてから項目を増やすのが現実的です。確認した日付と結果を共有のスプレッドシートやタスク管理ツールに残しておくと、障害が起きたときに「いつから異常だったか」をさかのぼれます。
まとめ
- 運用の確認は「止まっていないか」「戻せるか」「更新で壊れないか」「侵入されていないか」の4つに集約できる
- 毎日の確認は死活監視とバックアップの通知に任せ、人が見るのは異常の通知だけにする
- 毎週は更新の確認と適用、エラーログ、ディスク容量。大きな更新はステージングで確認してから本番に入れる
- 毎月は管理者ユーザー、不要なプラグイン、改ざんの検査、Search Console とサイトヘルスを点検する
- 年1回はリストアの訓練、PHPのサポート期限、ドメインとSSL証明書、契約の棚卸しを行う