WordPressの更新直後にサイトが表示されなくなったら、まず更新や設定変更を重ねず、障害の範囲と最後に行った操作を記録してください。原因はWordPress本体に限らず、プラグイン・テーマとの組み合わせ、サーバー環境、データベースなど複数考えられます。復旧を急ぐほど、どの状態へ戻せるかを先に把握することが重要です。
この記事では、企業のWeb担当者が初動で確認すること、自社で対応できる範囲、保守先へ渡す情報を整理します。特定の操作だけで必ず復旧するという手順ではありません。予約、購入、問い合わせを受け付けるサイトでは、障害中の取引や入力データへの影響も併せて確認してください。
最初に「何が使えないか」を分ける
「サイトが表示されない」と一言で言っても、状況によって次の対応は変わります。PCとスマートフォン、公開ページと管理画面を分けて確認しましょう。
- 公開サイト全体が表示されないのか、一部のページだけか
- 管理画面へログインできるか
- 画像やデザインだけが崩れているのか、ページ自体が開かないのか
- 問い合わせフォーム、予約、決済など重要な機能は使えるか
- 社内の特定端末だけか、別の回線でも再現するか
初動の記録を1枚にまとめる例
例えば「10月17日12:15、商品ページだけHTTP 500。トップと管理画面は開く。12:00に決済プラグインを更新。別回線でも再現。12:15以降に受注があるかは未確認」と記録します。ここまで分かれば、全面停止か一部機能かを切り分け、受注データを守りながら保守先へ調査を依頼できます。これは架空の例で、HTTP 500の原因を決済プラグインと断定するものではありません。
確認結果は、URL、発生時刻、表示されたエラー文、確認した端末・ブラウザとともに残します。エラー画面に顧客情報や管理情報が写っている場合、外部へそのまま共有しないでください。障害の範囲が分かれば、顧客向けのお知らせや社内連絡が必要かも判断しやすくなります。
更新と同時に発生したとしても、更新が原因と決めつけないことが大切です。サーバー障害、ドメイン・証明書、外部サービスの障害が重なった可能性もあります。
症状は、次のように伝えると保守担当者が調査の入口を決めやすくなります。
- 「重大なエラー」と表示される：画面の文言、管理者宛メールの有無、管理画面へ入れるかを記録する
- 白い画面やHTTP 500になる：対象URLと時刻、サーバー側のエラーログを確認できる担当者がいるかを整理する
- 「データベース接続確立エラー」と出る：DBの稼働状況や接続設定を保守先へ確認する。公開画面に設定値を貼り付けない
- ページは開くがデザインが崩れる：CSSや画像の読み込み状況、対象ページ、特定端末だけかを分ける
- 管理画面だけ開けない：公開ページへの影響と、ログイン画面・権限・サーバー側の状態を別々に確認する
これらは原因の確定ではなく、切り分けのための記録です。WordPress公式のトラブルシューティング案内も症状ごとに確認先を分けています。障害中に予約や注文を受け付け続けるサイトでは、公開ページが見える場合も裏側の処理を確認してください。
直前の変更と復元できる状態を確認する
次に、最後に行った変更を時系列で並べます。WordPress本体、テーマ、プラグインのどれを、誰が、いつ、どの順序で更新したかを確認します。自動更新を有効にしている場合は、管理画面の通知や管理者宛メールも手がかりになります。
併せて確認したいのはバックアップです。典型的なWordPressサイトを元の状態に戻すには、記事や設定を含むデータベースと、テーマ・プラグイン・アップロード画像などのファイルの両方が必要です。ファイルだけ、またはデータベースだけの保存では、完全に戻せない場合があります。これはWordPress公式のバックアップ案内でも説明されています。
バックアップが「存在する」ことと「必要な時点へ復元できる」ことは別です。保存日時、対象範囲、保存先、復元手順、復元テストの有無を確認してください。更新後に受け付けた注文や問い合わせがある場合、古いバックアップを戻すとそのデータを失う可能性があります。復元前に、障害発生後の新しいデータをどう保全するか決める必要があります。
管理画面に入れる場合と入れない場合を分ける
管理画面に入れる場合は、更新履歴、サイトヘルス、問題が発生した時刻を確認します。直前に更新した項目に注目できますが、複数のプラグインやテーマを一度に変更していると切り分けは難しくなります。利用中の機能や依存関係を把握せずに、すべてのプラグインを停止するのは避けましょう。表示が戻っても、フォームや決済など別の機能が止まる可能性があります。
管理画面にも入れず、WordPressから管理者宛に致命的エラーの通知が届いている場合は、通知の内容とRecovery Modeの公式説明を確認します。Recovery Modeは一部のPHP致命的エラー時に管理画面へ入るための機能ですが、どの障害でも起動するわけではありません。通知が届かない、リンクが使えない、管理者の権限がない場合は、契約しているサーバーの管理画面や保守先へ切り分けを依頼します。
ファイル名やプラグイン名がエラーに出ていても、原因の確定とは限りません。関連する別の更新やサーバー設定との組み合わせで表面化した可能性があります。特に本番ファイルやデータベースを直接変更する操作は、バックアップと復元方法を確認し、作業権限を持つ担当者が影響範囲を理解したうえで実施してください。
9時のバックアップへ戻す前に考えること
仮に正午の更新後に障害が発生し、9時時点のバックアップだけがあるとします。正午以降にも注文や問い合わせを受け付けていたなら、全面復元でその受付記録が消える可能性があります。復旧担当者には「どの時点のDB・ファイルを戻すか」と「その後に増えたデータをどう保存・再投入するか」を同時に確認してください。データ保全ができないまま、画面を戻す操作を急がないことが必要です。
復旧方法を選ぶ前に確認したい三つのこと
復旧には、設定の見直し、更新した項目の修正、バックアップからの復元など複数の選択肢があります。どれを選ぶかは次の三点で判断します。
1. 原因と変更範囲をどこまで特定できているか
原因が明確で、影響する機能を限定できるなら、変更箇所だけを戻したり修正したりできる場合があります。一方、原因不明のまま部分修正を重ねると、何が効いたのか分からなくなります。実施した操作と結果を時刻付きで記録してください。
2. 復元によって失うデータはないか
記事の更新、フォーム受付、予約、購入が障害発生後も続いていれば、バックアップ時点への全面復元は新しいデータに影響します。データベースとファイルで保存時刻がずれている場合も注意が必要です。復元対象と保存すべき最新データを先に確認します。
3. 本番以外で動作を確かめられるか
検証用環境があれば、候補となる修正や復元を先に試せます。ただし、本番データを複製する際は個人情報、送信メール、決済、計測タグが本番へ接続されないようにする必要があります。検証環境がない場合でも、作業前のバックアップと変更単位の記録を省かないでください。
復旧後の確認は「画面」と「受付処理」を分ける
架空のECサイトなら、トップが開く、商品が表示される、カートに入る、決済画面へ進める、管理画面で注文を確認できる、通知が届く、という順で確認対象を並べます。ただし本番の決済や問い合わせ送信を、承認なしに試すことはしません。テスト環境や承認済みの検証方法で、実際の顧客に影響を与えず確認します。復旧の合格条件を先に書いておくと「見た目は戻ったが注文が記録されない」を見逃しにくくなります。
表示が戻っても重要な機能を確認する
トップページが開いた時点では、復旧が完了したとは言えません。障害前に重要だったページと業務機能を確認します。
- 主要ページとスマートフォン表示
- ナビゲーション、画像、記事・商品ページ
- ログイン、問い合わせ、予約、購入など業務上必要な導線
- 管理画面での更新・編集
- エラーログと監視通知
フォームや決済の動作確認は、実際の問い合わせ・注文が発生する仕組みを理解した担当者が、承認済みの方法で行います。通常の顧客情報や本番注文を使って安易に試さないでください。復旧後に、どの更新が問題となったか、再現条件が分かったかも記録します。
更新を安全に続けるための運用を決める
更新を避け続けると、修正やセキュリティ対応が遅れます。一方、すべてを自動更新にしても、サイト固有のテーマやプラグインの組み合わせによる不具合を完全には防げません。WordPress公式の更新案内は更新前のバックアップを勧めており、プラグイン・テーマの自動更新案内も復元できるバックアップの重要性を示しています。
運用ルールとして、更新担当者、更新する時間帯、事前バックアップ、重要機能の確認項目、障害時の連絡先を決めましょう。サイトの更新頻度や業務への影響に応じて、検証環境を用意するか、どこまで自社で対応するかを判断します。費用だけでなく、復元・障害対応・追加改修が保守契約に含まれるかを確認することも大切です。
Webサイト全般の保守作業と費用の考え方は、Webサイト保守運用費の記事で整理しています。本記事は、WordPress更新後に不具合が出たときの初動に範囲を絞りました。
保守先に相談する前に整理しておく情報
相談時には、問題が起きたURLと時刻、公開サイト・管理画面・重要機能への影響、更新した項目、エラー表示、現在のバックアップ状況を伝えると、調査範囲を決めやすくなります。サーバー・ドメインの契約先、テーマ・プラグインの管理者、外部サービスの連携先が分かるとさらに役立ちます。
クラウドシードの公開実績にはWordPressを含むECサイトの保守事例があります。ただし、個別サイトの復旧可否や対応時間は、現在の構成と障害状況を確認して判断する必要があります。保守範囲が決まっていなくても、まず現状と困っていることを整理し、相談先へ伝えてください。
