WordPressに「このサイトで重大なエラーが発生しました」と表示されたら、まず発生日時、直前の変更、管理者への通知メールを確認します。表示された文言だけでは、原因のプラグインやテーマまでは分かりません。
復旧では、エラーの発生箇所を調べる作業と、サイトを動かすための一時対応を分けます。やみくもな削除や全体復元を避け、現在のデータを保全してから進めましょう。
最初に行う3つの確認
- 公開ページと管理画面のどちらでエラーが出るかを記録する。
- 直前に更新・追加・編集したものを時系列で整理する。
- サーバーの障害情報と、WordPressからの管理者向け通知を確認する。
直前の変更には、プラグイン更新、テーマ更新、PHPの切り替え、子テーマのコード編集などがあります。複数をまとめて変更した場合は、変更前のバージョンと時刻も控えてください。
エラーが出てからも注文や投稿などのデータが増えている可能性があります。復元へ進む前に、現在のファイルとデータベースを保存し、どの時点まで戻すかを決める必要があります。バックアップの範囲はWordPressのバックアップ・復元方法で確認できます。
リカバリーモードのメールが届いている場合
WordPressは、通常のページ読み込み時に致命的なPHPエラーを検出すると、管理者へ復旧用のリンクを通知する場合があります。リカバリーモードは、問題のあるテーマやプラグインを管理者のセッションで一時停止し、調査するための機能です。すべてのエラーやバックグラウンド処理で同じように使えるわけではありません。WordPress公式：Recovery Mode
- 対象サイトからの通知であることを確かめ、メールのエラー概要を読む。
- 自分のサイトのドメインであることを確認して、復旧用リンクからログインする。
- 管理画面の通知で、問題として示されているプラグイン・テーマ・ファイルを確認する。
- 直前の変更と一致するかを調べ、修正または対象機能の一時停止を検討する。
- 対応後はリカバリーモードを終了し、通常アクセスでも確認する。
リカバリーモードで管理画面を開けたことと、一般の訪問者向けページが直ったことは別です。ログアウトした状態や別ブラウザーでも、元の問題が起きたURLを確認してください。
通知メールが届かない場合は、サーバーログを確認する
メールが届かなくても、エラーが起きていないとは判断できません。まず迷惑メールと登録アドレスを確認し、次にサーバーの管理画面でPHPのエラーログを探します。画面の名称や保存先は契約サーバーによって異なります。
ログは発生時刻に近い記録から確認します。何日も前の警告を見て、その場の障害原因と決めつけないでください。PHPのFatal error、例外名、ファイルパス、行番号などを、発生した操作と組み合わせて読みます。
| ログに出る情報 | 読み取れること | 断定しないこと |
|---|---|---|
| プラグイン内のファイルパス | その処理で停止した手掛かり | そのプラグイン単独の欠陥とは限らない |
| メモリ不足を示すエラー | 処理中に利用可能なメモリを使い切った | 上限を増やせば必ず解決するとは限らない |
| 関数やクラスが見つからない | 依存関係やファイル不足の調査が必要 | 表示された行を削除すれば直るわけではない |
| 構文エラーと行番号 | コード編集や互換性を調べる手掛かり | その行だけで原因が完結するとは限らない |
パスやエラー文には、サーバーの内部情報が含まれることがあります。公開画面へ表示させず、必要な範囲をサポートへ共有します。
WordPressのデバッグログを使う場合
サーバーログだけで情報が足りなければ、検証環境でWordPressのデバッグ機能を利用できます。公式にはWP_DEBUG、WP_DEBUG_LOG、WP_DEBUG_DISPLAYが案内されており、記録と画面表示を分けて扱います。通常の本番運用で常時有効にしておくための設定ではありません。WordPress公式：デバッグの設定
設定を編集する前に、現在のwp-config.phpを保存します。同じ定数を重ねて定義せず、既存の記述と設置環境に合う方法を確認してください。ログに書き出す場合も、保存先への外部アクセスや個人情報の記録に注意します。
具体的な設定と読み方は、エラーを画面に出さずにログで調べる方法を参照してください。必要な記録を取得した後は、調査用の設定を元へ戻します。
プラグインを停止するか、コードを戻すかを判断する
停止する対象は、エラーの発生箇所と直前の変更を根拠に選びます。たとえば、子テーマの編集直後にそのファイルの構文エラーが記録されているなら、変更前のコードとの差分が第一の確認先です。
プラグイン更新直後に止まった場合は、提供元の対応版・既知の問題・依存するプラグインの条件を調べます。停止することで決済やフォームなどの機能も止まる場合があるため、どの業務に影響するかを把握してから行います。
管理画面を開けない場合、公式資料にはサーバー上で対象プラグインのフォルダー名を一時変更する方法もあります。ただし、全プラグインを無差別に扱わず、対象・元の名前・戻し方を確認して実施します。ファイルを削除することと、一時的に読み込ませないことは区別してください。
原因を絞るために1つ変更したら、同じURL・同じ操作で結果を確認します。複数の設定を同時に変えると、復旧しても原因が分からず、後から元へ戻しにくくなります。
バックアップ復元が必要なケース
変更箇所が広い、ファイルやデータが壊れている、修正より確実な復旧手段があると判断した場合は、バックアップからの復元を検討します。その際は次を確認します。
- バックアップは障害発生より前のものか。
- ファイルとデータベースの対象・日時が対応しているか。
- 保存後に追加された注文、会員登録、問い合わせ、記事をどう保全するか。
- 検証環境で復元できるか、必要なアカウントへアクセスできるか。
- 復元後に同じ更新が再実行されないよう、原因を把握できているか。
画面が戻ることだけを優先して、更新後の業務データを上書きしてはいけません。注文が発生するサイトでは、受付の扱いと差分の保全を決めてから、担当者と復元範囲を調整します。
復旧後は管理画面以外も確認する
元のエラーが消えたら、トップページ、記事、検索、画像、フォーム、ログイン、投稿保存を確認します。通販や会員サイトなら、決済・会員向け機能・外部連携も対象です。
一時停止した機能を戻すときも1つずつ確認し、新しいエラーが出ていないかログを見ます。使わなくなった調査用ファイルやログは、運用上必要な保存期間とアクセス権限を決めて扱ってください。
よくある質問
「重大なエラー」はメモリ不足のことですか？
原因は1つに決まりません。PHPの処理が停止した状況を、メールやログで確認します。メモリ不足の記録がなければ、メモリ上限だけを変更しても調査が進まない可能性があります。
古いWordPressへ戻せば直りますか？
古い本体ファイルを上書きするだけでは、データベースやプラグインとの整合性が戻るとは限りません。更新に関係する場合は、WordPress本体の更新失敗から復旧する手順で、修復・更新・復元の違いを確認してください。
原因が分からない場合は、エラー文と発生日時、直前の変更を揃えてWordPressの不具合対応サービスへご相談ください。
