WordPressの保守チェックリスト｜更新・バックアップ・動作確認と担当の決め方

WordPressの保守を始めるとき、「毎月プラグインを更新すればよい」と考えがちです。しかし、更新の完了表示だけでは、問い合わせが届くことや、問題が起きたときに元へ戻せることまでは確認できません。大切なのは、更新前の準備、更新後の動作、異常時の連絡先を一つの流れとして決めることです。

この記事は、会社サイトを担当する方や、制作会社への保守依頼を検討する方に向けた実務ガイドです。日常の通知確認、月次の点検、一定期間ごとの復元確認、契約更新の管理を整理し、そのまま社内の確認表へ移せる項目を用意しました。作業時間や点検間隔はサイトの機能と業務への影響によって変わるため、一律の所要時間や予防率は示しません。

WordPressの公式資料と、過去の不具合に対する公式の修正発表を参照しています。本文の記録例や仮の運用体制は説明用であり、実在の顧客で発生した事故や成果ではありません。個別のプラグイン整理、PHP更新、掲載情報の棚卸しは関連記事へつなぎ、ここでは保守全体の進め方を扱います。

1．保守のチェックリストは、サイトの役割と担当から作る

会社案内だけのサイトと、予約・購入・会員情報を扱うサイトでは、止まったときの影響も点検項目も異なります。チェックリストを使う前に、利用者がどの操作を完了できればよいかを整理しましょう。更新の件数より、必要な機能を維持できているかが判断の中心になります。

守りたい操作と情報を先に挙げる

企業サイトなら、サービスを読む、資料を開く、問い合わせる、採用へ応募する、といった操作が候補です。予約サイトなら空き状況の確認、申込、変更やキャンセルも加わります。それぞれについて、表示するページ、利用するプラグイン、外部サービス、受け取る担当者を結び付けます。

たとえば架空の教室サイトでは、トップページが表示されても予約通知が届かなければ業務は完了しません。「サイトが動く」を、ページ表示、申込記録、通知、担当者の確認に分けて定義します。実際に使っていない機能を大量に点検するより、必要な操作を漏らさず確かめる方が運用に合います。

定期点検と、通知を受けたときの対応を分ける

月次点検は確認漏れを拾う機会ですが、公開停止や重大な脆弱性の通知を次の点検日まで放置する理由にはなりません。日々受け取る更新・障害・期限の通知を誰が確認し、どの条件で保守担当へ連絡するかを先に決めます。営業時間外の扱いも、依頼先との契約内容に合わせて確認してください。

点検表には「毎月」「変更時」「通知時」のように実施のきっかけを書きます。料金改定やフォーム変更の後は関連画面を追加確認し、サーバー移行後はメールや定期処理も確認します。すべてを同じ日程に押し込むと、緊急性のある問題と改善の相談が混ざりやすくなります。

社内・制作会社・サーバー会社の分担を明確にする

サーバーの契約にバックアップ機能が含まれていても、WordPressの更新後にフォームを試験する担当まで含まれるとは限りません。サイトの内容を決める人、更新を実施する人、インフラを管理する人、異常時に判断する人を確認します。兼任でも構いませんが、連絡の順番が分かることが重要です。

WordPressのセキュリティ強化の公式ガイドは、対策をリスクの低減として説明し、ホスティング側とサイト運営側の責任範囲にも触れています。「このツールで完全に防げる」という説明に頼らず、自社と依頼先が実施する作業を具体的にしましょう。

2．更新前は、バックアップの取得と復元の準備を確認する

バックアップは、ファイルが存在することと、必要な状態へ戻せることを分けて確認します。取得が成功していても、必要なデータが含まれていない、保存先へ入れない、復元方法を知る人がいない状態では、障害時の対応に使いにくくなります。

ファイルとデータベースを組み合わせて保存する

WordPressのバックアップの公式資料では、一般的なサイトを完全に復元するために、ファイルとデータベースの両方が必要と説明されています。テーマや画像を保存しただけでは、投稿や設定を含むデータベースまで保存できたとは限りません。

取得対象、取得時刻、保存先、保持する世代、取り出し方を確認します。ファイルとデータベースの対応関係が分かる名前や記録を用意すると、別の日のデータを混ぜて復元する間違いを避けやすくなります。決済や外部予約の記録など、WordPress外にある情報は、別途どこで保存されているかを整理してください。

更新されるデータの量から、許容できる戻り幅を決める

毎日予約が入るサイトで一週間前のデータへ戻すと、その間の受付を別途照合する必要があります。一方、更新頻度が低い会社案内でも、公開直前の大きな原稿変更を保存していなければ作業が失われます。バックアップの間隔は、どの程度の新しいデータを失うと困るかから決めます。

復元前には、バックアップ後に増えた投稿、問い合わせ、予約などがあるかを確認します。「不具合が出たから全部戻す」という操作で、新しい受付まで上書きしないようにするためです。戻す範囲と、後から照合する情報を保守担当へ相談し、業務の再開条件も共有します。

復元の練習は、本番に影響しない場所で確かめる

可能であれば、契約上利用できる検証環境へ復元し、ページ、管理画面、必要な設定が揃うか確認します。作成した検証環境は公開範囲を制限し、メールの実送信、決済、外部連携が本番の相手へ動かないよう、試験方法を先に決めてください。顧客情報を含む複製の扱いも担当者間で合意します。

練習では、復元を開始できたかだけでなく、どのバックアップを使ったか、何が確認できたか、手順で止まった箇所を記録します。問題があれば手順や保存方法を直します。実際に試していない復旧時間を、顧客向けの保証時間として記載しないようにしましょう。

3．WordPress・テーマ・プラグインは、変更内容を見て更新する

更新はセキュリティや互換性を保つうえで重要ですが、何が変わるかを見ずに操作すると、不具合が出たときに原因を絞りにくくなります。現在の構成、更新内容、影響を受ける操作を確認し、適用と検証をセットで進めます。

現在のバージョンと、更新内容を記録する

更新前に本体、使用中のテーマ、対象プラグインの名称とバージョンを記録し、公式の変更履歴や対応条件を読みます。セキュリティ修正なのか、機能や画面が変わるのか、データの移行を伴うのかを確認します。有料製品なら、契約やライセンスの状態により更新を取得できるかも確認が必要です。

WordPressの更新手順の公式資料は、事前のバックアップや更新方法、更新後の確認を案内しています。古い状態から大きく更新する場合は、現在の環境との互換性も含めて計画しましょう。手順書に書かれた操作を、対象が違う環境へそのまま実行することは避けます。

影響を確認できる単位で適用し、変化を照合する

関連のない変更を一度に大量に入れると、どの変更で問題が起きたか分かりにくくなります。検証できる単位に区切り、対象の更新後に関連機能を確認してから次へ進みます。ただし、親テーマと関連機能など依存関係があるものは、製品の案内に従って組み合わせと順序を決めます。

フォーム関連の更新なら入力、エラー、完了表示、通知を確認し、表示を変えるテーマならPCとスマートフォンの主要画面を見ます。更新前から存在した不具合を新しい変更のせいにしないため、代表画面や操作結果を先に記録しておくと比較しやすくなります。

自動更新は、通知・復元・動作確認まで設計する

WordPressのプラグインとテーマの自動更新ガイドでは、対象ごとの設定、通知、復元への備え、スケジュールが動かない場合の確認が説明されています。管理画面の自動更新設定だけで、更新後の業務確認まで完了するわけではありません。

自動更新する対象、結果を受け取るアドレス、失敗時の連絡、更新後に確認する操作を決めます。サーバーや他の設定で動作が変わることもあるので、「標準ではこうだから」と推測せず、実際の履歴を確認してください。自動化を停止する場合も、その間の更新通知を誰が受け取り、いつ判断するかを残します。

4．更新後は、利用者の操作と裏側の処理を点検する

画面にエラーがないことは確認の一部です。サイトの役割に合わせて、表示、入力、保存、通知、担当者への受け渡しを順に確かめます。複雑な機能がある場合は、試験用のデータと実施場所を用意し、実際の顧客への影響を避けます。

主要ページは、PCとスマートフォンで実際に開く

トップ、主力サービス、料金、問い合わせ、採用など、重要なページを選びます。文字や画像の欠落、メニューの開閉、ボタン、資料のダウンロードを確認し、更新前の状態と比べます。管理者でログインした画面と、一般の訪問者が見る画面で表示が異なる場合にも注意してください。

キャッシュを使うサイトでは、編集画面に新しい内容があっても公開表示が古い場合があります。表示が違うときは、確認したURL、端末、ログインの有無、時刻を記録します。むやみに全体の設定を変える前に、どの条件で違いが出るかを整理すると相談しやすくなります。

フォームは、完了表示とメール到着を分けて確認する

入力できること、エラーが分かること、送信後の完了画面が出ること、必要な記録が残ること、担当者へ通知が届くことは別の確認項目です。メールの送信処理についても、WordPressのwp_mailの公式仕様は、成功を示す戻り値が受信者への到着を保証しないと説明しています。

試験を行うときは、宛先、入力するデータ、受付記録の扱い、試験後の整理を決めます。決済や予約の本番登録まで進む機能は、用意された試験環境や事前に合意した手順を使います。受付メールの文面や未着の切り分けは、自動返信メールの運用ガイドも参考にしてください。

予約投稿や自動処理は、予定と実行結果を照合する

WordPressのWP-Cronの公式説明では、ページの読み込みをきっかけに、実行時刻を迎えた処理を確認するとされています。標準的な仕組みでは、常時動くサーバーのスケジューラーと同じ時刻精度を前提にはできません。

予約投稿、バックアップ、同期などがある場合は、予定が登録されているだけでなく、実行結果と時刻を確認します。別の仕組みで定期実行しているサイトは、その設定と管理担当を確認してください。遅れを見つけても、理由を調べず同じ処理を重複実行すると、通知や登録が二重になる可能性があるため、先に実行状況を照合します。

5．月次点検は、結果と未対応事項が分かる記録にする

月に一度の点検を行うなら、作業した事実と、問題が残っている場所が分かる記録を残します。以下は一般的な企業サイトを想定した確認表です。点検間隔や対象は、サイトの構成、更新頻度、契約範囲に合わせて調整してください。

毎回見る項目を、実際の確認方法まで決める

表の各行に一律のチェックを入れるのではなく、未確認、問題なし、要対応、対象外を分けます。対象外にした理由も簡潔に残すと、機能が追加されたときに点検範囲を見直せます。通知がない場合も、通知の受信設定が正しいかを別の機会に確かめます。

自動診断の表示だけで、業務上の合格にしない

サイトヘルスなどの診断は、技術的な問題を見つける手掛かりになります。ただし、診断に大きな警告がないことと、料金の説明が正しいこと、フォームの通知先を担当者が読めることは別です。自動で調べられる項目と、人が使って判断する項目を組み合わせます。

スキャン結果で不審なファイルが見つかった場合も、内容を理解せず一括削除しないでください。正規の変更か、侵害の可能性があるかを保守担当へ確認し、必要な記録を残します。スキャンに検出されなかったことを、すべての不正が存在しない証明として説明するのも避けます。

未対応の項目には、理由・担当・次回判断日を付ける

「プラグイン更新は保留」だけでは、そのまま忘れられやすくなります。「対応テーマの確認待ち」「検証環境で申込処理が止まるため調査中」のように理由を書き、誰が次に何を調べるかを決めます。保留中に影響を抑える方法が必要かも、問題の性質に応じて相談します。

報告書では、実施した作業、問題なく確認できた操作、残っている課題を分けます。完了件数が多くても、主力サービスの申込が未確認なら、その事実を目立つ場所へ記載してください。点検表を埋めることより、次の判断が止まらない記録にすることが大切です。

6．一定期間ごとに、構成・復元手順・契約を見直す

日々の点検に加え、事業やサイトの構成に合わせて保守そのものを見直す時間を設けます。四半期や年次という区切りは管理上の例であり、重要な変更や期限があれば、その時点で確認します。期限のある対応を年末まで待つ運用にはしないでください。

プラグインと保存データは、用途を確認して整理する

無効化されているプラグインにも、将来の作業で必要なものや、過去データの確認に関係するものがあります。更新日が古い、機能が似ているという理由だけで削除や統合を決めず、使っている場所、依存関係、保存する情報を確認します。整理の手順は不要プラグインの見直しガイドで詳しく扱います。

データベースの容量が増えていても、必要な受付履歴や編集履歴が含まれる場合があります。最適化ツールの推奨項目をそのまま実行せず、対象、保持する理由、復元方法を確認してください。「削除した件数」を成果にするのではなく、必要な情報を維持したうえで、実際の負荷や操作に問題があるかを評価します。

PHPやサーバー環境は、サポートと互換性で判断する

PHPの更新先は、記事に書かれた固定の推奨番号だけで決めません。公式のサポート状況、サーバーで選べるバージョン、テーマやプラグインの対応をその時点で確認します。サポート終了が迫っている場合は、検証や修正に必要な期間も含めて計画します。

バージョンの変更は、表示だけでなく、管理画面、フォーム、外部通信、定期処理などへ影響することがあります。対応条件と復旧の判断をまとめたPHP更新ガイドへ確認範囲を引き継ぎ、通常の月次作業に無条件で混ぜないようにします。

期限・権限・掲載情報を、担当変更とともに点検する

ドメイン、サーバー、有料製品、証明書について、契約先、更新日、通知先、支払い担当を確認します。自動更新が設定されていても、支払い方法や受信先の変更が反映されているかは別の確認です。具体的な更新期間や復旧条件は、利用中サービスの現在の契約内容で確かめます。

担当者が変わったら、管理権限、共有先、通知先、復元手順を引き継ぎます。掲載情報の正しさも保守の対象に含めるなら、料金や採用条件を判断する社内担当を明確にします。WebとPDFの食い違いなどは、古い情報の棚卸しガイドへつなげて整理できます。

7．公式の修正事例から、異常時の調べ方を学ぶ

不具合の原因は、テーマやプラグインだけとは限りません。本体の変更やサーバー環境との組み合わせが関係することもあります。公開された修正情報は、原因を決め付けず、バージョンと症状を照合するための材料になります。

WordPress 6.4.1では、外部通信の不具合も修正対象になった

2023年11月のWordPress 6.4.1のリリース候補の発表には、6.4でのwp_remote_getとcURL error 28に関する問題が修正対象として記載されています。その後の正式な6.4.1の発表では、4件の不具合修正を含むメンテナンスリリースとして案内されています。

これは過去の具体的な修正事例です。現在の更新先として6.4.1を推奨するものではなく、同じエラーメッセージなら原因も同じと判断できるものでもありません。本文の参照先を読み、対象バージョン、症状、適用された修正を区別して確認する姿勢が、現在の保守にも役立ちます。

障害時は、現象・時刻・直前の変更を記録する

異常が出たら、どのページで、どの操作が、いつから失敗するかを記録します。管理者だけに出るのか、一般の訪問者でも再現するのか、すべての機能か一部だけかも確認します。直前の更新、設定変更、サーバー通知と合わせて保守担当へ共有してください。

エラーログや画面には、個人情報、認証情報、内部のパスが含まれることがあります。一般公開の相談先へ全文を貼らず、必要な範囲を選び、安全な共有方法を使います。原因が不明なまま設定を次々に変更すると経過が追いにくくなるため、実施する変更と結果を都度記録します。

戻す範囲と、再開を判断する条件を決める

一部の表示変更を戻すのか、プラグインを元へ戻すのか、サイト全体を復元するのかでは影響が違います。更新後に受け付けた情報を保持できるか、元へ戻すことで別の問題が再び生じないかを確認します。復旧の作業と、原因への恒久的な対応は分けて管理してください。

再開の判断には、必要な画面と操作が確認できたこと、受付記録の整合、関係する担当者への連絡などを含めます。見た目が戻っただけで対応を閉じず、残る制限があれば明示します。何を確認して再開したかを残すと、次の更新計画や依頼先との振り返りに使えます。

8．社内運用・外部委託で使える確認メモを作る

保守を外部へ任せる場合も、社内で担当する場合も、作業範囲と完了条件を共有することが重要です。見積もりでは月額だけを比べず、更新、確認、復元、連絡のどこまで含まれるかを確認しましょう。緊急対応や新機能の追加が別料金になるかも、契約前に整理します。

依頼前に、対象サイトと重要な機能を伝える

サイトURL、現在の管理者、更新している内容、問い合わせや予約の仕組み、過去に困ったことをまとめます。すべての技術情報を社内で調べ終える必要はありません。不明な項目を残したうえで、調査を依頼する範囲を決めれば、確認が必要な費用や日程を相談しやすくなります。

以下は架空の依頼メモです。自社の条件へ置き換えて使ってください。管理画面のパスワードをこの表へ直接記載する必要はありません。アクセスが必要な場合は、権限と共有方法を別途決めます。

保守報告では、何を確認できたかを読む

「すべて更新済み」という報告を受けたら、対象、更新前後の版、確認した操作、未対応事項が分かるかを確認します。バックアップについては取得と復元確認を区別し、フォームについては完了画面と通知の到着を分けます。実施していない確認まで完了したように読める報告は、範囲を確認し直してください。

毎回の報告を長くする必要はありません。前回から何が変わり、何が残り、誰が次に判断するかが分かれば運用に使えます。障害がなかった月も、期限や通知先、保留事項を確認しておくと、担当変更時に状況を引き継ぎやすくなります。

最初の一回は、更新前の状態を記録するところから

最初に、重要な操作、現在の構成、バックアップの範囲、連絡先を整理します。そのうえで一つの更新計画を立て、適用前後を比較し、残った課題を記録します。運用が定着してきたら、自動化する範囲と人が確認する範囲を見直しましょう。

Acquaでは、WordPressの保守・更新について、現状と必要な支援範囲からご相談いただけます。対象URLと困っていることを共有いただき、サイト保守・更新の対応内容をご確認ください。保守の実施、公開後の動作確認、集客への効果は、それぞれ分けて評価していきます。

一次資料の確認日：2026年9月9日。管理画面の表示、製品の対応条件、サーバーの契約内容は変更されることがあります。点検頻度と表の記入例は本記事の提案であり、WordPress公式が全サイトへ同じ運用を義務付けているという意味ではありません。