ある日サイトを開くと、白い画面に「このサイトで重大なエラーが発生しました。」とだけ表示される——WordPressでよくあるトラブルです。多くの場合、原因はプラグインやテーマ、PHPの不具合で、直前に何をしたかをたどれば自分で復旧できるケースが少なくありません。さらにWordPress 5.2以降には、こうした致命的エラーから自動で復旧するための「復旧モード」が用意されています。まずは落ち着いて、上から順に確認していきましょう。
⚠️ あわてて
wp-config.phpやサーバーのファイルを書き換える前に、まず下の「まず確認」を上から進めてください。編集するファイルは必ずダウンロードしてバックアップしてから触ること。不安な場合は、無理に操作せず緊急復旧の相談へお進みください。
まず確認:今どの状態ですか
次のどれに当てはまるかで、対処の入り口が変わります。自分の状況に近いものを探してください。
- フロント(トップページ)だけ重大なエラーで、
/wp-adminには入れる → 管理画面からプラグイン・テーマを無効化できる(手順3・4が早道) - フロントも
/wp-adminも同じく重大なエラー → FTP/ファイルマネージャからの操作が必要(手順2以降) - 管理者あてに「サイトで技術的な問題が発生しています」というメールが届いた → そのメール内のリンクで「復旧モード」に入れる(最優先・後述)
- 直前にプラグイン/テーマを更新・追加した、PHPバージョンを変えた → その操作が原因の可能性が高い(手順1)
- 「データベース接続確立エラー」と表示される → これは別のエラーです。データベース接続確立エラーの対処ガイドを参照してください
「重大なエラー」とは(なぜ起きるのか)
「このサイトで重大なエラーが発生しました」は、WordPress本体やプラグイン・テーマのPHPコードで致命的エラー(PHP Fatal Error)が起きたときに表示される画面です。WordPress 5.2から導入された「フェイタルエラー保護」という仕組みが、真っ白な画面(ホワイトスクリーン)の代わりにこのメッセージを出し、同時に管理者メールアドレスへ復旧用のリンク付きメールを送ります。
原因は、頻度の高い順におおむね次の4つに分けられます。
| 原因 | 典型的なきっかけ | 主な対処 |
|---|---|---|
| プラグインの不具合・競合 | プラグインの更新・新規追加の直後 | 手順3(プラグイン無効化) |
| テーマの不具合 | テーマの更新、functions.php の編集ミス | 手順4(テーマを戻す) |
| PHPメモリ不足 | アクセス集中、重いプラグインの追加 | 手順5(メモリ上限引き上げ) |
| PHPバージョン非互換 | サーバーのPHPを新しい版に切り替えた直後 | 手順5(PHPバージョン見直し) |
以下の手順は、安全に試せて効果の高い順に並べています。/wp-admin に入れるかどうかで近道が変わるため、「まず確認」で把握した自分の状態に合わせて読み進めてください。
まず試す:管理者メールの「復旧モード」
WordPress 5.2以降では、重大なエラーが起きると管理者メールアドレス(管理画面 → 設定 → 一般 の「メールアドレス」)あてに、件名「あなたのサイトで技術的な問題が発生しています」というメールが届きます。本文に復旧モードへのログインリンクが含まれています。
このリンクからログインすると、エラーの原因になっているプラグインやテーマが一時停止された状態で管理画面に入れます。停止されている項目は「プラグイン」「外観 → テーマ」の画面に警告として表示されるので、
- メール内のリンクをクリックして復旧モードでログインする
- 警告に出ている該当のプラグイン/テーマを無効化(または削除)する
- 復旧モードを終了し、サイトを再読み込みして直ったか確認する
という流れが最短ルートです。メールが届いていればこの方法が最も安全で確実なので、まず受信トレイ(迷惑メールフォルダも)を確認してください。メールが届かない・管理者アドレスが古い場合は、以下の手順で対処します。
対処手順
手順1 直前の操作から原因を絞る
エラーは「直前に変えたもの」が原因であることがほとんどです。次を思い出してください。
- プラグインを更新・追加した → 手順3でそのプラグインを無効化
- テーマを更新した/
functions.phpを編集した → 手順4でテーマを戻す - サーバーのPHPバージョンを切り替えた → 手順5でバージョンを戻す
- 何もしていないのに突然 → アクセス集中によるメモリ不足(手順5)か、自動更新の影響を疑う
心当たりがあれば、その原因に対応する手順へ先に進んで構いません。心当たりがなければ、手順2でエラーの正体を特定します。
手順2 WP_DEBUG ログでエラーを特定する(★実設定)
何が原因か分からないときは、エラーの内容をログに出力させます。FTPまたはサーバーのファイルマネージャで wp-config.php を開き、「/* 編集が必要なのはここまでです ... */」と書かれた行の上に、次の3行を追記します。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // wp-content/debug.log に記録する
define( 'WP_DEBUG_DISPLAY', false ); // 画面にはエラーを表示しない(公開サイト向け)
すでに define( 'WP_DEBUG', false ); の行がある場合は、false を true に書き換え、残り2行を追記します。保存後にサイトを再読み込みすると、wp-content/debug.log というファイルにエラー内容が記録されます。これをダウンロードして開くと、たとえば次のような行が見つかります。
PHP Fatal error: Uncaught Error: Call to undefined function ...
in /home/.../wp-content/plugins/問題のプラグイン名/xxx.php on line 123
plugins/ や themes/ のどのフォルダ名がエラー行に含まれているかで、原因のプラグイン・テーマがほぼ特定できます。特定できたら、その対象を手順3・4で無効化します。
⚠️ 原因が特定できたら、
WP_DEBUGは必ず元のfalseに戻してください。trueのまま公開し続けると、エラー内容(サーバー内のパス等)が外部に漏れる可能性があります。
手順3 FTPでプラグインを一括無効化する(★再現可能チェックリスト)
/wp-admin に入れないときは、FTPまたはファイルマネージャからフォルダ名を変えるだけでプラグインを無効化できます。WordPressは指定の場所にプラグイン本体が見つからないと、そのプラグインを自動的に停止扱いにするためです。
- FTP/ファイルマネージャでサイトのドキュメントルートを開く(
public_htmlやwww直下など) wp-content/pluginsフォルダを探すpluginsをplugins_offなど別名にリネームする(これで全プラグインが一括停止)- サイトを再読み込みする
- 直った場合 → いずれかのプラグインが原因。
pluginsの名前を元に戻し、今度はプラグインのフォルダを1つずつリネームして、どれが原因かを特定する - 直らない場合 → プラグインが原因ではない。名前を
pluginsに戻し、手順4へ進む
- 直った場合 → いずれかのプラグインが原因。
原因のプラグインが分かったら、そのプラグインを更新する・代替に乗り換える・作者に問い合わせるなどで対応します。フォルダ名は必ず元に戻すこと(plugins 以外の名前のままだと全プラグインが停止したままになります)。
手順4 テーマをデフォルトに戻す
プラグインが原因でなければ、次はテーマを疑います。テーマもFTPからの操作で切り替えられます。
wp-content/themesフォルダを開くtwentytwentyfourやtwentytwentythreeなど、WordPress標準テーマのフォルダが残っているかを確認する(無ければWordPress公式テーマからダウンロードしてthemes内に置く)- 現在使っているテーマのフォルダを別名にリネームする
- サイトを再読み込みする。標準テーマに自動で切り替わり、エラーが消えればテーマが原因
functions.php を直接編集してエラーになった場合も、この方法でいったん標準テーマに戻し、編集箇所を見直してから戻します。子テーマを使っている場合は、子テーマ側の functions.php の編集が原因のことが多いです。
手順5 PHPメモリ上限・PHPバージョンを見直す
プラグインもテーマも原因でない、またはログに「Allowed memory size of … exhausted」と出ている場合は、PHPの設定が関係しています。
メモリ不足の場合は、wp-config.php の同じく「編集が必要なのはここまでです」の行の上に、次を追記します。
define( 'WP_MEMORY_LIMIT', '256M' );
WordPressの初期値はフロント側で40M(マルチサイトは64M)と小さいため、重いプラグインを入れると不足することがあります。なお管理画面側の上限は別の定数 WP_MAX_MEMORY_LIMIT(初期値256M)で管理されています。サーバー側で php.ini の memory_limit に上限がある場合は、レンタルサーバーの管理画面から引き上げます。
PHPバージョンが原因の場合(新しいPHPに切り替えた直後にエラーが出た、ログに Uncaught Error や非推奨関数のエラーが出ている)は、レンタルサーバーの管理画面でPHPバージョンをいったん元の版に戻すと復旧することがあります。WordPressはPHP 7.4以上が必須、8.1以上が推奨ですが、古いプラグイン・テーマが新しいPHPに対応していないと致命的エラーになります。バージョンを戻して動かしつつ、対応版への更新を進めるのが安全です。
直ったか確認する
トップページと /wp-admin の両方を再読み込みし、エラーが消えていれば復旧です。あわせて次を確認してください。
- 手順2で追記した
WP_DEBUGをfalseに戻したか - 手順3・4でリネームしたフォルダ名を元に戻したか(
plugins/ 各テーマ名) - 編集前に
wp-config.phpのバックアップを取ってあるか(次回のために残しておくと安心です)
原因になったプラグイン・テーマは、無効化したまま放置せず、対応版への更新や代替への移行まで済ませておくと再発を防げます。
よくある質問
「データベース接続確立エラー」と表示される場合も同じ対処ですか?
別のエラーです。「データベース接続確立エラー(Error establishing a database connection)」はデータベースに繋がらないことが原因で、対処がまったく異なります。詳しくはデータベース接続確立エラーの完全対処ガイドをご覧ください。
復旧モードのメールが届きません
管理者メールアドレスが古い・受信できないアドレスになっていると届きません。その場合は、本ページの手順2(WP_DEBUGでエラー特定)→手順3・4(FTPでの無効化)で対処してください。復旧後に 設定 → 一般 で受信できるメールアドレスへ更新しておくと、次回からは復旧モードが使えます。
「500エラー」とは違うのですか?
500エラー(Internal Server Error)はサーバー内部エラーの総称で、.htaccess の不備やPHPの設定など原因はさまざまです。一方「このサイトで重大なエラーが発生しました」はWordPressのフェイタルエラー保護が出す画面で、プラグイン・テーマ・PHP起因の可能性が高いのが特徴です。本ページの手順は後者向けですが、ログ(手順2)でエラーの中身を見れば、どちらの原因かを切り分けられます。
触るのが怖い・原因が特定できません
wp-config.php やサーバーのファイル操作は、誤るとサイトのデータを失うリスクがあります。「さっきまで動いていたのに」「お客様に見せている最中」といった一刻を争う場面では、無理に操作せず、専門家による一次診断をおすすめします。当社では最短即日での復旧サポートを行っています。