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