WordPressサイト運用・保守の実務ガイド

2026年10月8日にWordPressのhardening、backup、updating、upgrading、侵害FAQ、roles、performance、W3C Easy Checks、フォーム検証の必要範囲を再確認した。保守は権限・更新・信頼できる配布元・強い認証・バックアップ・ログを組み合わせ、通常の復元には整合するファイルとDBのセットを用意する。更新前のバックアップ、staging、互換性、侵害時の証拠保全・封じ込め・調査修復、担当作業に合う権限を分け、HTTP未測定の本文実読資料をGET200と扱わない。

更新通知が増えると、「更新して壊すこと」と「放置すること」の両方が不安になります。WordPressの保守は、更新回数をこなす作業ではなく、変化を把握し、必要な機能を確認し、問題が起きたときに戻せる状態を維持する仕事です。

30秒で要点

• 保守の優先順位は、脆弱性の緊急度、止まる業務、失えるデータから決める。
• ファイルとデータベースをそろえ、バックアップの保存成功と復元後の確認を分ける。
• 更新後は表示だけでなく、フォーム・予約など重要な操作と受け付け側まで確かめる。

どこから読むか — 自分の状況から選ぶ

この記事は運用と保守の考え方を扱います。基盤・認証・設計・制作手段はそれぞれ別の記事にあります。

安全側の設定を確認したい。 通信の基礎はSSLとTLSの基礎知識、入口の設計は認証と認可入門とWeb認証入門、二段階認証の限界はフィッシングに強い認証、メールの保証範囲はDMARCとは？。

基盤をどう置くか決めたい。 全体像はクラウドコンピューティング入門、運用を任せる選択はサーバーレス入門、環境を揃えるならコンテナ技術入門、分割の判断はマイクロサービス入門。

約束と限界を読み違えたくない。 稼働率の意味は99.9%は「止まらない約束」ではない、再送の設計はリトライ回数は「失敗のやり直し」ではないと冪等性とは？、日時の扱いは「UTCで保存すれば安全」ではない、データベースの既定値は分離レベルはDBごとに違う。

制作手段を選びたい。 CMSの判断軸はCMS選定：失敗しない判断軸、構成の比較はHeadless CMS比較、Next.jsを選ぶ基準は選ぶべき理由と判断基準、Wixなら向いている人・向いていない人と納品チェックリスト。

作り直しと改善の判断をしたい。 時期の判断はリニューアルは「いつ」判断するか、速度の提案はCore Web Vitals改善の提案、作って終わりにしない設計はAI時代のWeb制作、自動化の範囲はAIでWeb運用はどこまで自動化できるか、更新の前提はChromeが2週間ごとに更新される。

最初に、何を誰が管理しているかを把握する

WordPress本体だけを更新しても、サイト全体の管理が終わるわけではありません。見た目を作るテーマ、機能を追加するプラグイン、プログラムを実行するPHP、データベース、ホスティング、メール配信などが関係します。

保守を引き継ぐなら、まず実際の構成と連絡先を一覧にします。管理画面で分からない部分はホストや制作担当者へ確認し、「おそらく自動で更新される」と推測したままにしないでください。

表が収まらない場合は、横にスクロールできます

WordPressの公式資料は、セキュリティを完全な排除ではなくリスクの低減と説明し、ホスト側とサイト側の責任を確認するよう案内しています。管理者・編集者などの権限も、担当作業に合わせて分けます。プラグイン等で権限が変更される場合は、役割名だけで判断しません。Hardening WordPress、Roles and Capabilities

平常時の認証も整えます。管理用の認証情報は、使い回さない長く推測されにくいものを用い、利用できる2要素認証を検討します。端末紛失や担当者交代で入れなくならないよう、復旧手段と管理責任者も決めます。管理画面はHTTPSで接続し、ファイルを転送する場合は提供されるSFTPなどの暗号化された方法を使います。通信中の保護と、サイトの脆弱性や保存データの安全は別に管理します。公式の認証・通信保護の説明

バックアップは「どこまで戻すか」から設計する

通常のWordPressサイトを全体として戻すには、記事や設定などを持つデータベースと、テーマ・プラグイン・アップロード画像などのファイルが必要です。サイトのフォルダーをダウンロードしても、別の仕組みに保存されるデータベースが含まれるとは限りません。WordPressのバックアップ説明

両者を整合する一組として記録します。取得時刻だけでなく、取得対象、保存先、成功・失敗、保持する世代、復元に使う手順が分かるようにします。書き込みが続くサイトでは、単に順番にコピーするだけで整合が取れるとは限りません。ホストやバックアップ方式が、処理中の注文・予約をどう扱うかを確認してください。

頻度は、失って困る更新から決める

週1回や月1回という一般的な予定表から始めると、頻繁に注文が入るサイトでは大きな空白ができます。最後に戻せる時点から障害までに、どれだけの情報が変わり、それを別の記録から再構成できるかを先に考えます。

次の図は架空の事故例です。12:00時点の整合したバックアップには注文120件があり、13:40の障害直前には127件になっていたとします。その間の7件を保存した別の記録がなければ、12:00へ戻すだけでは7件が欠けます。

この例の保存後の空白は100分です。14:20に機能確認まで終えて再開できたと仮定すれば、停止は13:40からの40分です。データをどこまで戻せるかと、いつ業務を再開できるかは違う問いです。復元が速くても古い情報しか戻らないことがあります。

保存先と復元の準備を分けて点検する

稼働サーバーと同じ障害で失われない保存先を用意し、そこへのアクセス権限や暗号化の鍵も管理します。保存期間が短ければ、改ざんに気づいたときには正常時の世代が消えていることがあります。バックアップ内にも個人情報や秘密情報が含まれるため、誰でも取得できる場所には置きません。

保守の記録には、直近のバックアップ成功だけでなく、最後に復元を試した日時と結果を残します。復元試験は、本番データを不用意に公開しない隔離環境で、メール送信・決済・外部通知などの実処理を止めるかテスト先へ向けて実施します。

確認するのは、管理画面へ入れること、画像や記事がそろうこと、主要な機能が使えること、想定した時点の件数や設定であることです。件数一致は内容全体の正しさを保証しないので、重要な記録を抽出して中身も照合します。復元できないときは、保存済みのバックアップを上書きせず、原因と不足している手順を残します。

更新を「定期作業」と「緊急対応」に分ける

予定した保守日は通常の変更を整理するためのものです。悪用され得る脆弱性が判明したときに、次の月次作業まで何もしなくてよいという意味ではありません。影響を受ける版か、外部から使える機能か、更新・機能停止などの対処が用意されているかを、公式情報と提供元で確認します。

表が収まらない場合は、横にスクロールできます

緊急時も、戻す準備や最低限の機能確認をなくすのではなく、被害の大きい機能から優先します。即時の更新が難しい場合は、担当者やホストと、公開範囲を狭めるなどの暫定対策と解消期限を決めます。

自動更新の対象を、実際の設定で確認する

本体・テーマ・プラグインでは設定が異なり、導入時期、管理者による設定、ホストの管理機能でも挙動が変わります。「小さい更新は自動、大きい更新は手動」と一律には決められません。現在の設定と更新結果を確認し、通知を受ける人を決めます。自動更新の種類と設定

自動化は更新漏れの対策になりますが、設定を有効にしただけでサイトが安全になったり、業務の正常動作が確認されたりはしません。逆に、問題が怖いという理由だけで自動更新をすべて止め、代わりの確認担当も置かない運用は避けます。

更新前・更新後に何を確かめるか

ここでは通常の変更の進め方を示します。利用するホストや拡張の公式手順を優先し、古いサイトの大きな移行を同じ手順で扱わないでください。

1. 変更を記録する：対象、現在版、変更内容、依存関係、実施担当、停止の必要性を確認する。
2. 戻す準備をする：更新前のファイルとDBをそろえ、保存先から取り出せることと、既に試した復元手順を確認する。
3. 検証用環境で試す：本番との差を記録し、表示、管理操作、重要機能を確認する。外部への本番送信は行わない。
4. 本番へ適用する：連携する変更は組として管理し、それ以外は原因を追える単位で行う。影響の少ない時間と連絡体制を選ぶ。
5. 結果を確かめる：表示、フォーム入力とエラー修正、受け付け側、予約などを確認し、変更前後と異常の有無を残す。

バックアップの存在・利用可能性の確認はWordPress公式の更新手順でも重視されています。更新手順、詳細な更新手順

「画面が表示された」だけで終えないことが重要です。フォームの成功画面が出ても、メールが担当者に届いていない場合があります。検索、管理者・編集者の操作、予約完了など、実際に必要な経路を担当者と決めて検査します。フォームの入力条件とエラー説明も確認対象です。W3Cの入力検証ガイド

戻す操作にも条件がある

更新後に受け付けた注文を含むDBを、更新前のDBでそのまま上書きすると、新しい記録が失われます。ファイルだけを旧版へ戻すと、変更済みのDB構造と合わない場合もあります。問題が起きたら、まず影響と直近の変更を記録し、受付の一時停止が必要かを判断します。

戻す対象と、その間のデータをどう保全するかを決めてから実施します。旧版への復帰は、脆弱性を再び持ち込む場合もあるため、最終解決とは限りません。公式もDB互換性とセキュリティ上の留保を示しています。旧版へ戻す場合の注意

検証用環境が合格しても、本番だけのアクセス量、メールや外部連携、保存データの違いは残ります。どこを再確認するかを先に決めることが、本番での見落としを減らします。

プラグインは、数よりも役割と依存関係で選ぶ

インストール数、評価、更新日、「動作確認済み」の表示は調査の入口です。それだけで自分の環境との互換性や安全性は分かりません。次の観点を一つの機能ごとに記録します。

• 何の用事を実現し、どのページやデータが依存しているか。
• 配布元が信頼でき、更新情報や問題時の連絡先を追えるか。
• どの権限や外部通信を使い、どんなデータを保存するか。
• 現在の本体、テーマ、他の拡張、PHPとの組み合わせで必要な機能が動くか。
• 契約、ライセンス更新、利用停止・削除・移行時のデータはどう扱われるか。

不要なプラグインは、依存とデータを確かめてから整理します。テーマについても、使用中の子テーマが必要とする親テーマなどを不用意に消さないようにします。「15個以下だから安全」「有名だから追加すればよい」とは判断しません。

速度が気になる場合は、遅いページと操作を特定し、同じ測定条件で比較します。画像、外部サービス、テーマ、プラグイン、ホストのどこに時間がかかるかを調べます。キャッシュは生成済みの内容を再利用する仕組みですが、利用者ごとに変わる画面では扱いに注意が必要です。WordPressの性能要因と計測

改ざんが疑われるときは、見た目の復元で終えない

知らない管理者、意図しない転送、見覚えのないファイルなどを見つけたら、発見時刻、症状、直前の作業を記録します。ホストや対応担当者に連絡し、影響を抑えるための公開制限と、ログや現状の保全を並行して進めます。見た目が元に戻っても、侵入経路や不正なアクセス権が残っている可能性があります。

調査の手掛かりを消す無計画な削除や、正常と確認していないバックアップの上書き復元は避けます。認証情報と有効なアクセスを見直し、侵入経路の対処、汚染された箇所の修復、必要な更新、再開前の検査へ進みます。認証情報は安全な端末から扱い、修復後にも再確認します。WordPressの侵害対応ガイド

ログインURLの変更やセキュリティ用プラグインは、更新・権限・認証・復旧の代わりにはなりません。個別の被害調査や通知の要否は状況によるため、保守担当だけで判断できない場合の連絡先も契約に含めます。

保守契約は、作業名より「どこまで終えるか」で比べる

「更新」「バックアップ」「監視」という同じ項目でも、完了の意味は異なります。固定の月額相場を当てはめるより、自社に必要な範囲を書いてから見積もりを比較します。

表が収まらない場合は、横にスクロールできます

担当者が作業できる時間だけでなく、異常を見つけた後に判断して復旧まで進められるかで自社対応を考えます。外注しても、掲載内容や受注への影響を判断する事業側の人は必要です。

次の保守日に、一つの復元記録を残す

本番へ変更を加える前に、使うバックアップ一組の識別名、対象時点、ファイル・DBの範囲、保存先、取り出す担当、復元手順を一枚に書きます。次に、許可された隔離環境で復元と機能確認を行い、開始・完了時刻、照合内容、失敗箇所を記録します。

実際に試していなければ「手順あり・復元未確認」と残します。記録があれば、保守会社へ何を依頼すべきか、更新前にどこが不足しているかを具体的に相談できます。

セキュリティの基礎はセキュリティ入門と認証・認可、仕組みそのものの変更はCMS選定で扱っています。運用方法を見直すなら、AI時代のサイト制作、Web運用の自動化、Wixが合う条件も、担当範囲を比べる材料になります。