WordPressサイトは、公開した時点で完成ではありません。公開後も、ページが正しく表示されるか、問い合わせが届くか、バックアップが取れているか、更新が滞っていないかを定期的に確認する必要があります。見た目に変化がなくても、プラグインの更新停止、サーバー容量の不足、フォームの不達、ユーザー権限の放置などが少しずつリスクになります。
一方で、毎月すべてを専門業者へ任せなければならないわけでもありません。管理画面を開いて状態を確認する作業、実際にページやフォームを試す作業、記録を残す作業は、初心者でも手順を決めれば対応できます。重要なのは、確認と変更を分け、分からない状態で本番環境を触り続けないことです。
この記事では、WordPressサイト公開後の月次保守を、確認する順番に沿って整理します。自分でできる範囲、作業前に準備すべきこと、制作会社や保守会社へ相談した方がよい状態まで解説します。
- WordPressの月次保守で目指す状態
- 最初に確認と変更を分ける
- 主要ページと重要機能を実際に試す
- バックアップは実行結果と復元可能性を確認する
- WordPress本体・テーマ・プラグインの更新状況を見る
- ユーザー・コメント・セキュリティの異常を確認する
- サイトヘルスの重大な問題から確認する
- 容量・速度・エラーログの変化を見る
- Search Consoleとアクセス解析は傾向を見る
- 公開情報とコンテンツの期限を確認する
- 月次保守の記録を一枚にまとめる
- 初心者向けの月次保守の進め方
- 自分で行うか外注するかの判断基準
- 保守会社や制作会社を比較するときのポイント
- 依頼前に整理すると相談が早くなる情報
- 月次保守で避けたい失敗
- 見つけた問題を緊急度で仕分ける
- 保守契約後に確認したい運用ルール
- よくある質問
- WordPress公開後は確認できる仕組みを作る
- 参考にした公式情報
WordPressの月次保守で目指す状態
月次保守の目的は、毎月たくさんの設定を変更することではありません。サイトの現在地を確認し、小さな異常を早めに見つけ、必要な対応を安全に選べる状態を保つことです。
最低限、訪問者が主要ページを閲覧できること、問い合わせなどの重要機能が動くこと、復旧に使えるバックアップがあること、更新やセキュリティ上の警告を把握していることを確認します。そのうえで、検索流入や表示速度などの変化を見て、急な悪化がないかを判断します。
WordPress公式のSite Healthは、サイトが最新の状態か、推奨されるPHP環境か、セキュリティや設定に問題がないかを点検するための機能です。公式ドキュメントでも定期的な確認が案内されています。月次保守では、管理画面の「ツール」から「サイトヘルス」を開き、重大な問題と改善項目を確認する習慣をつけるとよいでしょう。
最初に確認と変更を分ける
月次保守で起きやすい失敗は、警告を見つけた直後に、その場で更新や削除を始めてしまうことです。確認作業と変更作業が混ざると、問題が起きたときに原因を特定しにくくなります。
まずは表示、フォーム、バックアップ、更新通知、サイトヘルス、容量、検索状態を確認し、対応が必要な項目を一覧にします。次に、影響が小さい作業と大きい作業を分けます。コメント承認や不要な下書き整理と、WordPress本体・テーマ・プラグインの更新では、必要な準備が異なります。
更新や設定変更は、バックアップの完了と復元手段を確認してから実施します。EC、会員、予約、決済、多言語、外部システム連携があるサイトでは、変更前にステージング環境で試すか、構築を担当した事業者へ相談する方が安全です。
主要ページと重要機能を実際に試す
管理画面に警告がなくても、公開ページで表示崩れや機能停止が起きていることがあります。月次保守の最初は、訪問者と同じようにサイトを開く確認から始めます。ログイン中のブラウザだけでなく、シークレットウィンドウや別の端末も使うと、キャッシュや管理者権限に隠れた問題を見つけやすくなります。
優先して見るページ
- トップページ
- 主要なサービス・商品・会社案内ページ
- 問い合わせ、資料請求、予約などの入口
- 新しく公開または更新した記事
- アクセスが多いページや売上につながるページ
パソコンとスマートフォンの両方で、文字や画像の重なり、メニューの開閉、ボタンの押しやすさ、リンク先、画像の欠落を確認します。すべてのページを毎月見るのが難しい場合は、重要ページを固定し、その他のページは月ごとに対象を入れ替えます。
フォームは送信完了まで確認する
問い合わせフォームは、画面が表示されるだけでは十分ではありません。テスト用の内容を入力し、送信完了画面が出るか、管理者に通知が届くか、入力者への自動返信が届くかまで確認します。迷惑メールフォルダも確認し、テスト日時と使用した宛先を記録します。
フォームの不具合は商談機会の損失につながります。送信できない、通知だけ届かない、突然迷惑メールが増えたという状態は、単なる表示不具合より優先度が高い問題です。メール認証やSMTP、DNSの調整が必要になりそうな場合は、設定を推測で変更せず、サーバーやドメインを含めて確認できる担当者へ相談します。
バックアップは実行結果と復元可能性を確認する
バックアップ機能を導入していても、保存に失敗していたり、保存先の容量が不足していたりすることがあります。月次保守では「設定済み」ではなく、直近のバックアップが正常に完了したことを確認します。
WordPressの復旧には、一般にファイルとデータベースの両方が必要です。画像、テーマ、プラグインだけでなく、投稿、固定ページ、各種設定、フォームのデータなどがデータベース側に保存されているためです。サイトの構成によって必要な対象は異なるので、利用しているバックアップ方法の対象範囲を確認してください。
月次で残したい確認記録
- 最後に成功した日時
- ファイルとデータベースの保存有無
- 保存先と保管世代
- エラー通知の有無
- 復元手順と操作できる担当者
本番サーバー内だけにバックアップを置くと、サーバー障害や契約トラブルの際に同時に失う可能性があります。外部ストレージや手元の安全な場所など、サイト本体とは別の保存先があるかも確認します。
毎月の本番復元テストは影響が大きいため、むやみに行うべきではありません。ただし、一度も復元したことがなく、手順や必要権限が分からない状態も危険です。ステージング環境での復元確認や、保守事業者による復元手順の整備を定期的に計画してください。
WordPress本体・テーマ・プラグインの更新状況を見る
WordPress管理画面の「更新」を開き、WordPress本体、テーマ、プラグインに未適用の更新がないか確認します。更新にはセキュリティ修正や不具合修正が含まれるため、長期間の放置は避ける必要があります。
ただし、更新通知があるものを一括で適用することが安全とは限りません。サイトのバックアップ、更新内容、現在のWordPressやPHPとの互換性、重要機能への影響を確認してから進めます。WordPress公式の更新手順でも、開始前のバックアップが案内されています。
自分で更新しやすい条件
- 更新前のバックアップが成功している
- 復元方法と管理権限が分かっている
- 重要機能が少なく、更新後の確認項目を把握している
- 構築時の独自改修や古いプラグインがない
- 問題が起きた場合に作業を止められる時間帯を選べる
専門家へ相談したい条件
- 更新すると表示や機能が崩れた経験がある
- テーマやプラグインに独自のコード変更がある
- EC、会員、予約、決済など停止の影響が大きい
- PHPやデータベースの更新も求められている
- 何年も更新しておらず、一度に多くの更新が必要
自動更新を使っている場合も、確認が不要になるわけではありません。WordPress公式はプラグインとテーマを最新に保つことを勧めていますが、自動更新後にサイトが正常か、通知メールに失敗がないかを確認する運用が必要です。
ユーザー・コメント・セキュリティの異常を確認する
管理画面のユーザー一覧を開き、退職者、過去の制作担当者、不要になったテストアカウントが残っていないかを確認します。特に管理者権限は必要最小限にし、共同作業者には役割に合った権限を設定します。
見覚えのないユーザー、身に覚えのない記事、設定変更、急増した迷惑コメントなどがあれば、通常の月次作業を続ける前に状況を保全します。パスワード変更だけで終わらせず、アクセスログ、ユーザー作成日時、更新履歴、バックアップの状態を確認できる担当者へ相談してください。
毎月の確認項目
- 管理者ユーザーが必要な人だけか
- 長期間使っていないアカウントがないか
- 予期しない投稿や固定ページがないか
- 迷惑コメントやフォームスパムが急増していないか
- セキュリティ機能から重大な通知が来ていないか
- SSL証明書や管理画面への接続に警告がないか
CloudSecure WP Securityから「攻撃をブロックしました」と届いた場合
CloudSecure WP Securityを利用していると、「クロスサイトスクリプティングの攻撃をブロックしました」といったメールが届くことがあります。
初めて見ると「サイトが攻撃されたのでは？」と不安になりますが、「攻撃をブロックしました」という通知だけで、サイトにも異常がない場合は、基本的に毎回対応する必要はありません。
WordPressサイトを公開していると、自動化されたボットなどから脆弱性を探る不審なアクセスを受けることがあります。私が管理しているWordPressサイトでも、同様のブロック通知が定期的に届いています。
月次保守では、次のような変化がないかを確認しましょう。
- 通知の件数が突然大幅に増えていないか
- 身に覚えのない管理者ユーザーやプラグインが追加されていないか
- サイトの表示や管理画面に異常がないか
- 見覚えのないページや転送が発生していないか
普段と同じ程度の通知でサイトにも異常がなければ、セキュリティ機能が正常に働いていると考えてよいでしょう。
一方で、通知が急増したり、サイト側にも不審な変化が見られたりする場合は、むやみに設定変更やファイル削除をせず、まず状況を記録しましょう。
エラーや異常が表示されている画面はスクリーンショットを撮り、発生した日時や直前に行った操作もメモしておきます。CloudSecure WP Securityの通知メールも削除せずに残しておくと、サーバー事業者や保守担当者へ相談するときに原因を調べやすくなります。
サイトヘルスの重大な問題から確認する
「ツール」から「サイトヘルス」を開くと、状態と情報の画面があります。状態画面では、重大な問題、改善をおすすめする項目、問題のないテストを分けて確認できます。情報画面では、WordPressのバージョン、テーマ、プラグイン、サーバー、データベース、ファイル権限などの技術情報を確認できます。
公式のSite Health画面の解説では、バックグラウンド更新、WordPress.orgとの通信、デバッグ表示、ループバック、PHP、プラグイン更新などが確認対象として示されています。
点数だけを上げることを目的にせず、重大な問題の内容とサイトへの影響を読みます。同じ警告でも、利用中のサーバーやプラグイン構成によって対応が異なります。説明を読んでも意味が分からない項目や、サーバー設定・PHP・データベースに関わる項目は、そのまま画面情報を担当者へ共有すると相談しやすくなります。
容量・速度・エラーログの変化を見る
サーバー容量が上限に近づくと、画像をアップロードできない、バックアップが失敗する、更新が止まるといった問題につながります。サーバー管理画面やバックアップ画面で、ディスク使用量が急増していないかを確認します。
容量が増えた原因としては、大きな画像、古いバックアップ、ログ、キャッシュ、不要な複製ファイルなどが考えられます。ただし、名前だけで不要と判断してサーバー上のファイルを削除するのは危険です。保存元と利用中の機能を特定してから整理します。
表示速度は単月の点数だけで判断せず、同じページを同じ条件で継続的に観察します。急な悪化があれば、その前に行った更新、追加した画像、埋め込み、広告、外部計測タグなどを振り返ります。同日の速度関連記事と役割を分け、月次保守では改善作業よりも「変化の発見」と「原因候補の記録」を優先します。
サーバーのエラーログを確認できる場合は、重大なエラーが繰り返されていないかを見ます。ログには専門用語や機密情報が含まれるため、全文を公開の相談場所へ貼らず、日時、対象URL、直前の操作とともに安全な方法で担当者へ共有します。
Search Consoleとアクセス解析は傾向を見る
検索流入やアクセス数は自然に上下するため、一日だけの増減で設定を変える必要はありません。月次では、前月や前年の同時期と比べ、急な落ち込み、特定ページだけの変化、検索エラーの増加などを確認します。
Googleは、検索パフォーマンスの確認にはSearch Console、サイト内での利用行動の確認にはGoogle Analyticsをそれぞれ情報源として使う考え方を案内しています。詳しくはSearch ConsoleとGoogle Analyticsデータの使い分けを参照してください。
月次で見る項目
- 検索クリック数と表示回数の大きな変化
- 重要ページや主要検索語の変化
- インデックス登録やクロールに関する新しい問題
- フォーム送信や購入など重要な成果の変化
- 流入が多いページでの離脱やエンゲージメントの変化
数字が下がった場合は、計測タグの不具合、サイトの表示問題、検索需要の季節変動、順位変動、ページ内容の陳腐化などを分けて考えます。アクセス解析だけで原因を断定せず、サイトの変更履歴とSearch Consoleの状態を照合します。
公開情報とコンテンツの期限を確認する
サイトが技術的に動いていても、営業時間、料金、担当者、キャンペーン、採用情報、取引条件などが古ければ、訪問者の信頼を損ねます。毎月、期限のある情報と問い合わせにつながるページを優先して確認します。
記事については、すべてを毎月書き直す必要はありません。閲覧が多い記事、商品やサービス選びに影響する記事、制度やツールの仕様など変化しやすい情報を優先します。更新日だけを変えるのではなく、内容と根拠を確認し、実際に修正した場合のみ更新として扱います。
リンク切れ、古い画像、終了したサービスへの案内、存在しない問い合わせ先も確認対象です。外部リンクを一括で自動修正する前に、代替ページが本当に同じ内容かを人が判断してください。
月次保守の記録を一枚にまとめる
保守は、実施したことよりも、何を確認し、何を変更し、結果がどうだったかを後から追えることが重要です。記録があれば、表示崩れやエラーが発生したときに、直前の更新との関係を調べやすくなります。
記録する内容
- 確認日と担当者
- バックアップの成功日時と保存先
- 更新したWordPress本体・テーマ・プラグイン
- 更新前後に確認したページと機能
- サイトヘルスやサーバーで見つけた警告
- アクセスや検索状態の大きな変化
- 保留した項目、理由、次の担当者
画面のスクリーンショットだけでは、検索や比較が難しくなります。日付、対象、結果を文字でも残し、必要に応じて画像を添えます。複数人が関わる場合は、完了、要対応、保留を区別します。
初心者向けの月次保守の進め方
次の流れは、小規模な情報発信サイトを想定した一例です。サイトの機能や更新頻度に応じて調整してください。
- 前回の記録と未対応項目を確認する
- 主要ページとフォームを訪問者目線で試す
- バックアップの完了と保存先を確認する
- 更新通知、ユーザー、コメント、サイトヘルスを確認する
- 容量、速度、エラー、検索状態の変化を見る
- 対応する項目と相談する項目を分ける
- 必要な更新を一つずつ実施し、その都度確認する
- 実施内容と結果を記録する
WordPress公式のサイトメンテナンスの案内でも、更新、リンク確認、スパム整理、バックアップ、コンテンツ見直しなどを定期的な予定に入れる考え方が示されています。自社のサイトで重要な項目に絞り、継続できるチェックリストにすることが大切です。
自分で行うか外注するかの判断基準
外注の判断は、管理画面を操作できるかだけで決めません。問題が起きたときの影響、復旧手段、独自改修の有無、社内で確保できる時間と技術を合わせて判断します。
自分で担当しやすい範囲
- 主要ページの表示確認
- フォームのテスト送信
- 更新通知とサイトヘルスの確認
- ユーザーやコメントの目視確認
- Search Consoleとアクセス解析の定点観測
- 月次記録の作成
外注を検討したい範囲
- 更新前のステージング確認と本番反映
- バックアップ設計と復元テスト
- PHP、データベース、サーバー設定の変更
- 不正アクセスやマルウェアの調査
- 独自テーマや独自プラグインの互換性対応
- EC、予約、会員、決済、外部連携の動作保証
社内担当者が確認を行い、技術的な変更だけを外注する分担も可能です。すべてを丸投げするか、すべてを内製するかの二択ではなく、一次確認、判断、変更、緊急対応を誰が担当するか決めます。
保守会社や制作会社を比較するときのポイント
WordPress保守の費用は、サイト規模だけでなく、含まれる作業、対応時間、バックアップ方式、障害時の復旧範囲によって変わります。金額だけを比べると、必要な作業が契約外だったという失敗が起きやすくなります。
見積もりで確認したい範囲
- WordPress本体・テーマ・プラグイン更新の対象
- 更新前のバックアップと更新後の確認方法
- ステージング環境を使うか
- バックアップの保存先、頻度、世代数、復元作業
- 監視の内容と通知後の対応
- 問い合わせフォームや決済など重要機能の確認
- 障害時の受付時間、初動、復旧作業の契約範囲
- 軽微修正や記事更新を含むか
- 月次報告の内容
「更新対応」と書かれていても、通知だけか、実際の更新まで含むか、表示確認まで行うかで内容が違います。「バックアップ」も、取得だけか、外部保存か、復元まで対応するかを確認します。
既存の制作会社が保守を提供している場合は、構築内容を理解している利点があります。一方、別の保守会社へ依頼する場合は、使用テーマ、プラグイン、独自改修、サーバー、ドメイン、外部サービスの情報を引き継げるかが重要です。
依頼前に整理すると相談が早くなる情報
- サイトURLとサイトの目的
- WordPress、テーマ、主要プラグインの構成
- サーバーとドメインの管理会社
- 問い合わせ、予約、決済など重要機能
- 過去の障害や更新時の不具合
- 現在のバックアップ方法
- 希望する対応時間と緊急度
- 社内で担当できる作業
相談時に認証情報をメール本文へ直接書く必要はありません。契約と作業範囲を確認し、必要な権限だけを安全な方法で共有します。共用の管理者アカウントを渡し続けるのではなく、作業者ごとのアカウントを用意し、契約終了時に停止できる状態が望ましいです。
月次保守で避けたい失敗
バックアップ確認前に一括更新する
更新数をゼロにすることを優先し、復元手段がないまま一括更新すると、どの変更で問題が起きたか分かりにくくなります。影響の大きいサイトでは、更新を分け、更新後に主要機能を確認します。
警告を消すためだけに設定を変える
サイトヘルスやセキュリティ機能の警告は重要ですが、意味を理解せず設定を変えると別の機能を止めることがあります。重大度、原因、推奨内容を読み、サーバーやプラグイン固有の条件を確認します。
自動化したため確認をやめる
自動バックアップ、自動更新、監視サービスは負担を減らしますが、失敗通知の見落としや設定の期限切れは起こり得ます。自動化した項目ほど、結果の確認先と異常時の担当者を決めておきます。
記録を残さない
前回何を更新したか分からないと、不具合の原因調査に時間がかかります。短くても、日付、対象、結果、保留事項を毎回残します。
すべての問題を同じ優先度で扱う
問い合わせ不達、決済停止、不審な管理者、サイト全体の表示不能は優先度が高い問題です。軽微なデザイン調整や改善提案とは分け、事業への影響と緊急度で順番を決めます。
見つけた問題を緊急度で仕分ける
月次点検で複数の問題が見つかったときは、表示された警告の数ではなく、訪問者と事業への影響で優先順位を決めます。担当者の感覚だけに頼らず、緊急、早めに対応、計画対応、経過観察のように区分すると、社内と外部担当者で認識を合わせやすくなります。
緊急対応に回す状態
サイト全体を閲覧できない、決済や予約が完了しない、問い合わせが届かない、管理画面へ入れない、見覚えのない管理者や改ざんがある、個人情報の漏えいが疑われる状態です。通常の月次作業を中断し、影響範囲を広げないことを優先します。むやみに更新、初期化、ログ削除を行わず、発生日時と症状を記録して緊急連絡先へ共有します。
早めに対応する状態
一部ページの表示崩れ、更新失敗、バックアップ失敗、容量の急増、サイトヘルスの重大な問題、SSLやセキュリティ機能の警告などです。直ちに事業が停止していなくても、放置すると大きな障害へつながる可能性があります。期限と担当者を決め、対応後に主要機能を再確認します。
計画して対応する状態
古いコンテンツの見直し、軽微な速度改善、使っていない機能の整理、PHPやサーバープランの将来的な変更などです。月次点検中にその場で実施せず、影響調査、バックアップ、テスト環境、作業日時を含む別の作業として計画します。
経過観察にする状態
単月だけの小さなアクセス変動や、原因が確定していない軽微な警告は、記録して次回と比較します。ただし、経過観察には確認期限が必要です。「いつ、何が起きたら対応へ切り替えるか」を残さなければ、単なる放置になってしまいます。
保守契約後に確認したい運用ルール
保守会社を決めた後も、契約書があるだけでは安定した運用になりません。誰が異常を発見し、どの連絡先へ、どの情報を添えて報告するかを決めます。営業時間外の障害、担当者不在、サーバーやドメイン会社からの通知を誰も見ていない状態も想定します。
権限と認証情報の管理
WordPress、サーバー、ドメイン、アクセス解析、Search Consoleは、それぞれ必要な人だけが操作できるようにします。個人のメールアドレスだけに所有権や請求情報が集中すると、退職や引き継ぎで管理不能になる可能性があります。組織として管理できるアカウントと連絡先を決め、二段階認証や復旧手段も確認します。
月次報告の読み方
「異常なし」だけでは、何を確認したのか判断できません。バックアップの成功、更新対象と結果、主要機能の確認、警告、容量や検索状態の変化、次回までの課題が分かる報告を求めます。一方で、技術情報の羅列だけでも判断しにくいため、事業への影響と推奨対応が簡潔に示されているかを確認します。
契約外作業が発生したとき
不具合修正、改ざん復旧、サーバー移転、大規模更新などが月額保守に含まれない場合があります。契約外であること自体が問題なのではなく、どの段階で追加見積もりになり、作業開始に誰の承認が必要かが明確であることが重要です。緊急時に承認者へ連絡が取れない場合の上限や一次対応も決めておくと、対応の遅れを減らせます。
よくある質問
月次保守は必ず毎月必要ですか
更新頻度、機能、事業への影響によって適切な間隔は異なります。ただし、問い合わせや売上につながるサイトを長期間確認しない状態は避けるべきです。まずは毎月の定点確認を基本にし、バックアップや監視などはサイトの更新頻度と重要度に応じてより短い間隔も検討します。
更新通知がなければ何もしなくてよいですか
更新通知がなくても、フォーム、バックアップ、ユーザー、容量、検索状態、公開情報は確認が必要です。月次保守はソフトウェア更新だけではありません。
保守契約があれば自社の確認は不要ですか
契約範囲によります。技術保守にコンテンツの期限確認や問い合わせ対応まで含まれないことは珍しくありません。事業側でしか判断できない情報と、保守会社が担当する技術作業を分けてください。
不具合を見つけたら最初に何を伝えればよいですか
制作会社やサーバー事業者へ相談するときは、「昨日エラーが出た」「何か更新したあとからおかしい」といった情報だけでは、原因を特定するのが難しい場合があります。
分かる範囲で、次の情報を残して相談時に伝えましょう。
- エラーや異常が表示された画面のスクリーンショット
- エラーが発生した日時
- 問題が起きたページのURL
- 使用していた端末とブラウザ
- エラーが出る直前に行った操作
- WordPress本体・テーマ・プラグインを更新したか
- 表示されたエラーメッセージ
- 同じ操作をすると再び問題が起きるか
特にスクリーンショットは、エラー画面を閉じたり再読み込みしたりすると表示が消えてしまうこともあるため、その場で残しておくと原因調査に役立ちます。
ただし、パスワードや個人情報、サーバーの認証情報などが画面に表示されている場合は、そのまま公開の場所へ掲載しないよう注意してください。
WordPress公開後は確認できる仕組みを作る
WordPressの月次保守は、毎月大がかりな作業をすることではありません。主要ページとフォームを試し、バックアップ、更新、ユーザー、サイトヘルス、容量、検索状態を同じ順番で確認し、変化を記録することが基本です。
自分でできる確認と、専門知識が必要な変更を分けると、無理なく続けられます。復旧方法が分からない、独自改修がある、決済や予約が止まる影響が大きい、セキュリティ上の異常が疑われる場合は、作業を進める前に制作会社や保守会社へ相談してください。
まずはこの記事の項目から、自社サイトに必要なものだけを月次チェックリストにします。担当者、確認日、異常時の連絡先まで決めておけば、公開後のWordPressサイトを「誰かが気づくまで放置される状態」から守りやすくなります。
チェックリストは一度作って終わりではありません。サイトにフォームや予約機能を追加したとき、担当者やサーバーを変更したとき、実際に障害が起きたときは項目と連絡手順を見直し、次回の確認に反映してください。
