WordPress の保守について説明するとき、「毎月、プラグインを更新しているのですか」と聞かれることがあります。
もちろん、WordPress 本体やプラグイン、テーマの更新は大切な作業です。ただ、更新ボタンを押すことだけが保守ではありません。
僕が WordPress の保守を考えるときに大切にしているのは、サイトを新しい状態にすることよりも、更新後もページが正しく表示され、重要な機能が正常に動き、問題が起きたときに戻せる状態を保つことです。
そのため、毎月の点検では、更新状況だけでなく、バックアップ、セキュリティ、問い合わせフォーム、WordPress の内部状態、サーバーなども確認します。
ただし、すべてのサイトで同じ項目を、同じ頻度で確認すれば良いわけではありません。ほとんど更新しない会社案内サイトと、毎日注文が入る EC サイトでは、守るべきデータも、障害が起きたときの影響も異なるからです。
この記事では、WordPress の月次保守で一般的に確認したい内容と、サイトに合わせて調整したいポイントを整理します。
月次保守は「月に1回だけ確認すること」ではない
最初に整理しておきたいのは、「月次保守」と「すべての作業を月に1回だけ行うこと」は同じではない、という点です。
保守の作業は、大きく3つのタイミングに分かれます。
| タイミング | 主な確認・作業 |
|---|---|
| 常時または高頻度 | サイトの稼働監視、バックアップ、障害通知、セキュリティ通知の確認 |
| 更新が必要になったとき | 更新内容の確認、更新前のバックアップ、WordPress 本体・プラグイン・テーマの更新、更新後の動作確認 |
| 月に1回 | 設定や稼働状況の点検、アカウントや容量の確認、ログの振り返り、月次報告 |
たとえば、サイトが表示できるかどうかを月に1回しか確認しないと、点検日の翌日に障害が起きても、次の点検まで気付けない可能性があります。反対に、ドメインの契約状況や不要な管理者アカウントの棚卸しは、毎日行う必要まではないでしょう。
また、セキュリティに関わる更新が公開された場合、次の月次作業日まで待つことが適切とは限りません。更新の内容と影響を確認し、必要に応じて予定を前倒しして対応します。
月次保守とは、高頻度の監視や必要時の更新を含む日々の運用を、月に1回まとめて点検・報告する仕組み、と考えると分かりやすいかもしれません。
WordPress の月次保守で確認する主な項目
サイトの構成や契約範囲によって違いはありますが、基本になるのは次の7項目です。
- WordPress 本体・プラグイン・テーマの更新
- バックアップの取得状況
- セキュリティとユーザーアカウント
- 主要ページと重要機能の動作
- WordPress の内部状態
- サーバー・ドメイン・SSL の状態
- 確認結果と今後の対応の報告
ここから、もう少し具体的に見ていきます。
1. WordPress 本体・プラグイン・テーマの更新
まず確認するのは、WordPress 本体、プラグイン、テーマ、翻訳データに更新があるかどうかです。
ただし、更新通知があるものをすべて一括で更新すれば終わり、というわけではありません。
- 何が更新対象になっているか
- セキュリティ修正を含むか
- 大きな仕様変更がないか
- 現在の WordPress や PHP に対応しているか
- 更新前のサイトが正常に動いているか
- 問題が起きたときに戻せるか
こうした点を確認してから更新します。
WordPress の公式ドキュメントでも、WordPress を最新バージョンへ更新することと、更新前にサイトをバックアップすることが案内されています。
更新後には、トップページを開くだけでなく、主要ページ、スマートフォン表示、お問い合わせフォームなど、サイトにとって重要な場所を確認します。管理画面に「更新しました」と表示されても、実際の表示や機能に問題がないことまでは保証されないからです。
更新を保留する場合は、その理由も残します。たとえば、利用中のテーマとの互換性が確認できない、ステージング環境で不具合が見つかった、といった場合です。
保留すること自体が問題なのではなく、理由も期限も分からないまま放置される状態を避けることが大切です。
自動更新は一律に有効化すれば良いわけではない
WordPress には、本体をバックグラウンドで更新する仕組みがあります。プラグインとテーマについても、管理画面から個別に自動更新を有効化できます (Plugin and themes auto-updates)。
自動更新は、更新の遅れを減らすために役立つ仕組みです。特に、メンテナンスやセキュリティを目的とした WordPress 本体の更新については、特別な理由がない限り、自動更新を止めない方が良いと考えています。
一方で、WordPress 本体の大きな更新や、プラグイン、テーマの自動更新を、すべてのサイトで一律に有効化すれば良いとは考えていません。
自動更新を有効にするかどうかは、主に次の点を見て判断します。
- 更新によって影響を受ける機能
- 問い合わせ、予約、購入など、止めたくない機能の有無
- 独自に改修したテーマやプラグインとの互換性
- 更新前のバックアップと復元方法
- 更新後の稼働監視や動作確認の体制
- 問題が起きたときに対応できる時間帯
たとえば、サイトの表示に直接関係しない小さなプラグインと、予約や決済を担当するプラグインでは、更新による影響が異なります。後者は、ステージング環境で確認してから本番環境を更新した方が良い場合もあります。
そのため、実際の保守では、次のように分けて考えます。
- WordPress 本体のメンテナンス・セキュリティ更新は、基本的に自動更新を維持する
- WordPress 本体の大きな更新は、サイトへの影響に応じて事前検証を検討する
- プラグインとテーマは、役割や影響を確認して個別に自動更新の可否を決める
- 予約、購入、会員機能などに関わるものは、更新後の確認方法まで決めておく
なお、自動更新を有効にしても、更新後の確認まで自動的に完了するわけではありません。
自動更新の結果を知らせるメール、サイトの稼働監視、主要ページやお問い合わせフォームの動作確認を組み合わせます。自動更新が失敗していないかだけでなく、更新後もサイトの役割を果たせているかを見ることが大切です。
WordPress 本体の自動更新は、インストール時期や設定、ホスティング環境などによって動作が異なる場合があります。まず現在の設定を確認し、理由が分からないまま有効・無効を切り替えないようにします (Configuring Automatic Background Updates)。
2. バックアップが正常に取れているか
バックアップは、設定して終わりではありません。
月次点検では、少なくとも次の点を確認します。
- 最新のバックアップ日時
- バックアップ処理の成否
- データベースとファイルの両方が含まれているか
- 何世代分を保存しているか
- 保存先の容量に余裕があるか
- WordPress が動いているサーバーとは別の場所にも保存しているか
- 誰が、どの手順で復元できるか
WordPress の公式資料では、一般的な WordPress サイトを完全に復元するには、データベースとファイルの両方が必要だと説明されています。投稿や設定などが入るデータベースと、画像、テーマ、プラグインなどのファイルは、保存場所が分かれているためです (Backups — Advanced Administration Handbook)。
個人的には、「バックアップファイルがある」と「必要なときに復元できる」は分けて考えたいところです。
自動バックアップが失敗している、保存容量が足りず古いデータしか残っていない、復元方法を知る人がいない、といった状態では、いざというときに使えません。サイトの重要度に応じて、ステージング環境などを使った復元テストも検討します。
3. セキュリティとユーザーアカウント
セキュリティの確認では、単にスキャン結果が「異常なし」になっているかだけを見るわけではありません。
- 既知の脆弱性に関する通知がないか
- WordPress 本体・プラグイン・テーマが古いままになっていないか
- 不審なログインやファイル変更が記録されていないか
- 覚えのない管理者ユーザーが追加されていないか
- 退職者や以前の制作会社のアカウントが残っていないか
- 必要以上に強い権限が付与されていないか
- セキュリティ通知の送信先が現在も使われているか
WordPress には、管理者、編集者、投稿者などの権限グループが用意されています。公式ドキュメントでも、それぞれ実行できる操作が異なることが説明されています (Roles and Capabilities)。
記事を投稿する担当者に、プラグインの追加やユーザー管理までできる管理者権限が本当に必要なのか。担当者が変わったあともアカウントが残っていないか。こうした点を定期的に見直します。
なお、更新やスキャンを行えば、セキュリティ上の問題を完全になくせるわけではありません。WordPress 公式のセキュリティ資料でも、更新、バックアップ、適切なアカウント管理、監視など、複数の対策を組み合わせる考え方が示されています (Hardening WordPress)。
4. 主要ページと重要機能が動いているか
サイトが表示できることと、サイトの役割を果たせていることは別です。
企業サイトであれば、次のような場所を確認します。
- トップページ
- 主要なサービスページ
- お知らせやブログの一覧・詳細ページ
- ナビゲーション
- PC とスマートフォンでの表示
- お問い合わせフォーム
- 管理者宛ての通知メール
- 問い合わせをした人への自動返信メール
- サイト内検索や資料ダウンロードなどの固有機能
お問い合わせフォームは、フォーム画面が表示されているだけでは十分ではありません。実際に送信し、管理者への通知と自動返信が届くところまで確認して初めて、ひとつの動作確認になります。
予約サイトなら、空き枠表示、予約登録、通知メールなどを確認します。EC サイトなら、商品表示、カート、注文メール、決済連携などが対象になります。
すべてのページを毎月細かく確認するのは現実的ではありません。問い合わせ、予約、購入など、「止まると困る機能」を先に決めておくことが大切です。
5. WordPress の内部状態
WordPress の管理画面にある「ツール → サイトヘルス」では、更新、PHP、HTTPS、REST API、ループバックリクエストなど、サイトの構成に関する情報を確認できます (Site Health screen)。
月次点検では、サイトヘルスに重大な問題が出ていないかを確認し、必要に応じて次のような状態も調べます。
- 自動更新が失敗していないか
- 予約投稿や定期処理が動いているか
- REST API やループバックリクエストに問題がないか
- PHP や JavaScript のエラーが増えていないか
- データベースやアップロードファイルが急に増えていないか
- キャッシュが正常に動いているか
- 使用していないプラグインやテーマが残っていないか
ここで注意したいのは、サイトヘルスをすべて「良好」にすること自体が目的ではない、という点です。
サーバーやサイトの構成によっては、すぐに対応する必要がない推奨項目もあります。表示された内容をそのまま消すのではなく、サイトへの影響を確認して、対応するかどうかを判断します。
6. サーバー・ドメイン・SSL の状態
WordPress が正常でも、その外側にあるサーバーやドメインに問題があれば、サイトは利用できなくなります。
- サーバーのディスク容量
- PHP やデータベースのバージョン
- PHP のエラーログ
- SSL 証明書の有効期限と自動更新
- ドメインの有効期限と自動更新
- サーバーや有料プラグインの契約・ライセンス期限
- DNS やメール設定の変更
特に、容量不足や契約更新の失敗は、WordPress の管理画面だけを見ていても気付けない場合があります。
どこまでを保守会社が管理し、どこからをサイト所有者やサーバー会社が管理するのかは、契約前に確認しておきたいところです。「WordPress の保守」と書かれていても、ドメイン、メール、DNS、サーバーの契約管理まで含まれるとは限りません。
7. 作業件数ではなく、結果と次の対応を報告する
月次保守では、確認した内容を報告書として残します。
ただ、「プラグインを10件更新しました」と書かれているだけでは、サイトが正常なのか、何か対応が必要なのかを判断しにくいでしょう。
たとえば、次のように結果まで分かる形にします。
プラグインを10件更新しました。更新後に主要ページとお問い合わせフォームを確認し、表示・送信ともに問題ありませんでした。PHP のエラーログに継続している警告があるため、来月まで経過を確認します。
月次報告に含めたいのは、主に次の内容です。
- 対象期間と点検日
- 実施した更新
- バックアップの状態
- 稼働状況と障害の有無
- 表示・機能テストの結果
- 見つかった問題と、その場で対応した内容
- 経過観察する内容
- サイト所有者の判断が必要な内容
問題がなかったことも大切な報告です。一方で、すぐに直す必要はないものの、将来の対応が必要な項目も残しておくと、突然大きな改修が必要になる状況を減らしやすくなります。
サイトの更新頻度によって保守内容は変わる
ここまで基本的な確認項目を紹介しましたが、実際の頻度や範囲は、サイトの使われ方によって調整します。
ほとんど更新しない会社案内サイト
ページの変更が少なければ、毎時間バックアップを取る必要性は高くないかもしれません。
一方で、管理画面を開く人が少ないため、更新の失敗、問い合わせフォームの不具合、契約期限切れ、古いアカウントなどに気付きにくい傾向があります。
この場合は、データの変化を細かく保存することより、放置状態を防ぐ確認が重要になります。
お知らせやブログを定期的に更新する事業サイト
投稿や画像が増えるサイトでは、バックアップの頻度、サーバー容量、公開ページの表示、更新担当者の権限なども確認します。
担当者が複数いる場合は、全員に管理者権限を付けるのではなく、役割に合った権限を設定することも検討したいところです。
問い合わせ、予約、注文が継続して入るサイト
ページをほとんど更新していなくても、問い合わせ、予約、注文、会員情報などが毎日増えるサイトは、データが頻繁に変化しています。
日次バックアップだけであれば、復旧時に最大で1日分のデータを失う可能性があります。どこまでのデータ損失を許容できるかを考え、バックアップ頻度や更新作業の時間帯を決める必要があります。
また、更新後にはトップページを見るだけでなく、予約や購入などの重要な流れを実際にテストします。必要に応じて、ステージング環境で事前に更新を検証します。
保守内容を決めるときは、単純なページ更新回数だけではなく、次の3点を見ると整理しやすくなります。
- サイト内で、1日にどれだけ重要なデータが増えるか
- サイトが停止したとき、事業にどの程度影響するか
- 問題が起きたとき、どの時点まで戻れれば良いか
更新頻度が低いから、保守も少なくて良いとは限りません。サイトの役割に合わせて確認項目と頻度を決めることが大切です。
自分でも確認できること
専門的な調査を行わなくても、サイト所有者が月に1回確認できることはあります。
- トップページと主要ページを PC・スマートフォンで開く
- お問い合わせフォームを実際に送信する
- 管理者宛ての通知メールと自動返信メールを確認する
- 「ダッシュボード → 更新」で更新通知の件数を見る
- 「ツール → サイトヘルス」で重大な問題が出ていないかを見る
- 「ユーザー」で覚えのないアカウントがないかを見る
- ドメイン、サーバー、有料プラグインの更新案内を確認する
ただし、意味が分からない警告を消すために、設定を手当たり次第に変更するのは避けましょう。まず画面のスクリーンショットや表示された文言を残し、影響を確認してから対応します。
専門家へ相談した方がよい状態
次のような状態では、いきなり本番サイトを更新したり設定を変更したりせず、制作会社や保守担当者へ相談した方が安全です。
- 何年も WordPress 本体やプラグインを更新していない
- 更新通知が大量に残っている
- バックアップの場所や復元方法が分からない
- サイトヘルスに重大な問題が表示されている
- 覚えのない管理者ユーザーやファイルがある
- サイトの表示が遅くなった、またはエラーが増えている
- 問い合わせメールが届かない
- サーバー容量が不足している
- 予約、購入、会員機能など、止まると影響が大きい機能がある
- 制作会社と連絡が取れず、サーバーやドメインの管理者が分からない
相談するときは、サイトの URL、利用しているサーバー、表示された警告、更新画面のスクリーンショット、最後に正常だった時期、止まると困る機能などをまとめておくと、状況を整理しやすくなります。
WordPress の保守は、使い続けられる状態を確認する仕事
WordPress の月次保守では、WordPress 本体・プラグイン・テーマを更新するだけでなく、バックアップ、セキュリティ、表示、問い合わせフォーム、WordPress の内部状態、サーバーなどを確認します。
そのうえで、確認結果を依頼者へ伝え、今すぐ対応すること、しばらく様子を見ること、将来検討したいことを分けます。
大切なのは、すべての項目に同じ頻度でチェックを入れることではありません。サイトで増えるデータ、停止したときの影響、重要な機能に合わせて、確認内容を調整することです。
保守サービスを検討している場合は、「毎月何件更新するか」だけでなく、更新前後の確認、バックアップの復元方法、フォームの送信テスト、障害時の対応範囲まで聞いてみると、サービスの違いを判断しやすくなると思います。
Olein Design では、WordPress の更新方針の整理、更新前後の確認、バックアップや不具合の切り分けなどを含む WordPress 運用・実装サポートを行っています。
「保守を依頼しているけれど、何を確認しているのか分からない」「自分のサイトには、どこまでの保守が必要なのか整理したい」という場合も、まずは現在の状態を確認するところからご相談いただけます。この記事が、WordPress の保守内容を考える参考になれば嬉しいです。
