WordPressサイトを開いた瞬間、コンテンツの代わりに「このサイトで重大なエラーが発生しました」という素っ気ない一文だけが表示される。管理画面（/wp-admin/）に入ろうとしても同じ画面で止まる。多くのWeb担当者が、この瞬間に「サイトが完全に壊れたのではないか」と強い不安を感じます。

ただ、結論から言うと、この画面は「壊れた結果」ではなく「WordPressが自分を守るために出している案内」です。WordPress 5.2で導入された致命的エラー保護（リカバリーモード）が、PHPの致命的エラーを検知して、被害が広がらないように処理を止めている状態を指します。

つまり、闇雲にファイルを消したりインストールし直したりするのは逆効果です。逆に、確認順序を固定すれば、非エンジニアでも「自力で直せる範囲」と「ここから先は依頼すべき範囲」を切り分けられます。

この記事のゴールは、次の2つです。

  • 表示された画面の意味を正しく理解し、順番どおりに復旧を進められる
  • 自力対応の限界ラインを持ち、必要時に素早く専門家へ引き継げる

なお、画面が「真っ白で何も表示されない」場合は、原因は重なりますが切り分けの入口が少し異なります。あわせてWordPress管理画面が真っ白になる原因と対処法も参照してください。

「重大なエラー」画面とは何か（仕組み解説）

WordPress 5.2の「致命的エラー保護」が出している画面

WordPressは、ページを表示するたびにPHPプログラムを実行しています。このとき、プラグインやテーマのコードがPHPの致命的エラー（fatal error） を起こすと、本来はそこで処理が止まり、何も表示されない「真っ白画面（WSOD）」になっていました。

WordPress 5.2では、この状況を改善するためにリカバリーモード（Recovery Mode） が導入されました。開発ノートでは「Fatal Error Recovery Mode」、5.2のリリース情報では「PHP Error Protection」とも表記されますが、いずれも同じ仕組みを指します。致命的エラーを検知すると、真っ白画面の代わりに案内画面を出し、管理者がログインして原因を切り分けられるようにする機能です。

要点を1つに絞ると、この画面の意味は次のとおりです。

WordPress（または、その上で動くプラグイン・テーマ・カスタムコード）が、表示処理の途中で致命的なPHPエラーを起こして停止した

表示される文言の違い

WordPressの標準（英語）では、状況によって表示が変わります。

表示場面 標準の英語文言（要約）
一般の訪問者向け There has been a critical error on this website.
管理者対応が必要な場合 There has been a critical error on this website. Please check your site admin email inbox for instructions.
リカバリーモード起動中 There has been a critical error on this website, putting it in recovery mode.

日本語環境では、概ね次のように表示されます（翻訳のため細部が更新される場合があります）。

  • フロント側: 「このサイトで重大なエラーが発生しました。」
  • 管理者向け: 「このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。」

つまり、「サイト管理者のメール受信ボックスを確認してください」と書かれている場合、WordPressはあなた宛に復旧用のメールを送ろうとしています。まずはそのメールを探すのが最短ルートです。

真っ白画面（WSOD）との違い

従来のWSODは「何も表示されず、原因の手がかりも出ない」状態でした。リカバリーモードは、その代わりに案内画面とメール通知を出し、管理者だけが安全に管理画面へ入って原因を切り分けられる点が大きな違いです。両者は原因（プラグイン・テーマ・PHP）が重なるため、対処の考え方も近くなります。

緊急時の最初の5分で確認すること

調査の前に「状況固定」を行います。ここを飛ばすと、原因切り分けが崩れます。

1. フロントと管理画面の両方を確認する

  • トップページだけでなく https://あなたのドメイン/wp-admin/ も開く
  • どちらも同じ「重大なエラー」なら、サイト全体に影響する原因の可能性が高い
  • 特定ページだけで出るなら、そのページ固有の処理（特定プラグインの機能など）を疑う

2. 直前の変更を思い出す

このエラーは「何もしていないのに突然」起きることもありますが、多くは直前の操作が引き金です。

  • プラグインの新規インストール・更新
  • テーマの更新・カスタマイズ（特に functions.php の編集）
  • WordPress本体の更新
  • サーバー側でのPHPバージョン変更

「いつ・何を変えた直後に出たか」を1行メモするだけで、原因の8割は絞り込めます。

なお、「本当に誰も触っていないのに出た」という場合は、自動更新（オートアップデート）が裏で走ったケースを疑ってください。WordPressはプラグイン・テーマ・本体を自動更新できる仕組みを持ち、管理画面やレンタルサーバー側の設定で有効になっていると、担当者の操作なしにバージョンが上がります。深夜や休日に突然エラーが出たときは、更新履歴（プラグイン一覧の「最終更新」やサーバーの更新ログ）を確認すると、引き金になった更新が見つかることがあります。

3. 管理者メールの受信ボックスを確認する

画面に「メール受信ボックスを確認してください」と出ている場合、WordPressがサイト管理者アドレス宛にリカバリーモードのログインリンクを送っています。メールの件名は、英語環境では「Your Site is Experiencing a Technical Issue」、日本語環境では「サイトで技術的な問題が発生しています」のような表現になり（先頭にサイト名が付きます）、「重大なエラー」という語は件名に入りません。送信元はWordPress（サイトの管理者メールアドレス）なので、迷惑メールフォルダも含め、エラー発生時刻の前後に届いたWordPressからのメールを探してください。

4. 作業ログを残す

復旧中は、短い作業ログを残すと後の引き継ぎが楽になります。ポイントは、「日時・確認したこと・操作したこと・その結果」を1行ずつ時系列で残すことです。これがあるだけで、自力で続ける場合も専門家へ引き継ぐ場合も、同じ確認を二度繰り返さずに済みます。

例えば、2026年6月4日に発生したケースなら、次のように記録します。

2026/06/04 10:05  トップと /wp-admin/ の両方で「重大なエラー」を確認
2026/06/04 10:08  直前の操作: 10:00頃にプラグイン「Contact Form 7」を更新していた
2026/06/04 10:12  管理者メールを確認 → リカバリーモードのリンクは届いていない（迷惑メールにもなし）
2026/06/04 10:15  FTPで wp-content/plugins を plugins_off にリネーム
2026/06/04 10:16  サイト表示が復帰 → 原因はプラグイン側と判断
2026/06/04 10:22  plugins に戻し、Contact Form 7 のみ _off にして再発しないことを確認
2026/06/04 10:25  該当プラグインを最新版へ再更新し、正常表示を最終確認

日付まで入れておくと、「いつから止まっていたか」「どの更新が引き金か」が後から正確に追えます。サーバーのログやバックアップ世代と突き合わせるときも、時刻が揃っていると調査が一気に速くなります。

リカバリーモードで原因を特定する

メールが届いている場合、これが最も安全で速い方法です。

リカバリーモードでできること

メール内のリンクを開くと、通常のログイン画面に進み、ログイン後は管理画面に入れるようになります。このとき、エラーの原因となっているプラグインやテーマは、「いまログインしているあなたのセッションに対してだけ」一時停止されます。サイト全体を止めるわけではないため、原因箇所を確認しながら無効化・更新・削除を判断できます。

リカバリーモードの管理画面では、「プラグイン」や「テーマ」の画面に、停止された対象と簡単なエラー内容が表示されます。まずはそこを確認し、原因と思われるプラグイン/テーマを無効化してから、リカバリーモードを終了します。

リンクの有効期限に注意

リカバリーモードのログインリンクには有効期限があります。WordPress標準では、リンクの有効期限はおおむね1日（24時間） です。一方、リカバリーモードに入った後のセッション（クッキー）の有効期間は約1週間で、これは別物です。

リンクが古いと無効になります。期限切れの場合は、再度サイトを開き直すと新しいメールが送られる場合があります（送信間隔の制限により、すぐには再送されないこともあります）。

メールが届かない場合の対処（FTPでの切り分け）

実務でつまずきやすいのが、「メール受信ボックスを確認してください」と出ているのに、そのメールが届かないケースです。

なぜメールが届かないことがあるのか

WordPressのメール送信は、標準ではサーバーのPHPメール機能（mail() 相当）を使います。これは「送信処理をした」ことは確認できても、相手に届いたことまでは保証しません。

さらに重要なのは、SMTP送信プラグインを入れていても、致命的エラーがそのプラグインの読み込みより前で起きると、メールはサーバーから直接送られてしまう点です。その結果、送信元アドレスやサーバーのIP評価によっては、迷惑メール扱いや不達になることがあります。

メールに頼らず無効化する手順

メールが届かない場合は、FTP（またはサーバーのファイルマネージャ）でフォルダ名を変更して、プラグイン・テーマを物理的に無効化します。これはWordPress公式でも案内されている正規の手順です。

A. プラグインを一括で無効化する

  1. FTP/ファイルマネージャで wp-content/plugins/ を開く
  2. フォルダ名を plugins → plugins_off のように変更する
  3. サイトを再読み込みする
  4. 復帰したら、原因はプラグインのどれか。plugins に戻し、フォルダを1つずつ _off にして犯人を特定する

プラグインフォルダ名を戻すと、WordPress上ではプラグインが「停止状態」で残ります。設定やデータが消えるわけではないので、落ち着いて1つずつ切り分けてください。

B. テーマをデフォルトに戻す

  1. プラグインで直らない場合は、wp-content/themes/ を開く
  2. 現在使用中のテーマフォルダ名を変更する（例: your-theme → your-theme_off）
  3. その状態で wp-admin（管理画面）にアクセスする。有効テーマが見つからない場合、WordPressは管理画面にアクセスした時点で twentytwentyfive（Twenty Twenty-Five）などの同梱デフォルトテーマへ自動的に切り替える（フロント表示を開くだけでは切り替わらないため、必ず管理画面を開くのがポイント）
  4. これで復帰すれば、原因はテーマ側（多くは functions.php の編集ミスや互換性）

functions.php を直接編集していた場合は、直前に追記したコードが原因のことが多いです。バックアップがあれば、まず編集前の状態に戻すのが確実です。

原因別の確認ポイント

WordPress公式が挙げる代表的な原因は、プラグイン・テーマ・カスタムコードです。加えて、現場では次の要因も切り分けの対象になります。

原因1: プラグインの不具合・競合

最も多いパターンです。更新直後や新規追加直後に発生したら、まずプラグインを疑います。上記の「plugins フォルダ一括リネーム」で復帰するかを確認するのが近道です。

原因2: テーマの不具合・編集ミス

functions.php への追記ミス（閉じ忘れ、関数の重複定義など）は、致命的エラーの典型です。テーマ更新直後の発生も同様に疑います。デフォルトテーマへの切り替えで復帰するかを確認します。

原因3: PHPバージョンの非互換

サーバー側でPHPのバージョンを上げた（または下げた）直後にエラーが出た場合、使用中のプラグイン・テーマがそのPHPに対応していない可能性があります。WordPressはバージョンごとに対応PHPが異なるため、「サイトで使っているWordPressが対応しているPHP系列」に合わせるのが切り分けの基本です。

参考として、2026年6月時点でPHP公式がサポートしている系列は 8.2 / 8.3 / 8.4 / 8.5 です。一方、WordPress側は本体・プラグイン・テーマの互換状況に左右されるため、最新PHPが必ず安全とは限りません。最新版へ一気に上げるのではなく、1段階ずつ切り替えて挙動を確認してください。

原因4: PHPメモリ上限の超過（可能性）

処理に必要なメモリが不足すると、致命的エラーにつながることがあります。WordPressのメモリ設定の既定値は次のとおりです。

定数 役割 既定値
WP_MEMORY_LIMIT フロント表示で使うメモリ要求値 40MB（マルチサイトは64MB）
WP_MAX_MEMORY_LIMIT 主に管理画面側で使う上限 256MB

PHP本体の memory_limit 既定値は128Mです。メモリ不足が疑われる場合は、wp-config.php に次の1行を追加して様子を見ます（末尾近くの区切りコメント — 英語版 /* That's all, stop editing! */、日本語版「編集が必要なのはここまでです !」 — より上に記述）。

define( 'WP_MEMORY_LIMIT', '256M' );

ただし、メモリを上げて直るのは「本当に一時的なメモリ不足」のときだけです。毎回同じ箇所で落ちる場合は、メモリ増設ではなく原因プラグイン/コードの特定を優先してください。

原因5: コアファイルの破損・改ざんの可能性

更新の失敗やアップロード不全でコアファイルが欠けると、必要な関数が読み込めず致命的エラーになることがあります。また、サイトが改ざん・マルウェア被害を受けている場合、不正なコードが原因で不安定になることもあります。

この画面が直接「改ざんのサイン」とは限りませんが、身に覚えのない管理者アカウント、見慣れないPHPファイル、不自然なリダイレクトなどを併発している場合は、セキュリティ事故を疑うべきです。その際は復旧より先に被害の封じ込めが必要なため、改ざん発覚時の初動対応を参照してください。

debug.log でエラーの正体を確認する

「どのファイルの何行目で落ちているか」を知りたい場合は、WordPressのデバッグログを使います。原因究明が一気に進みます。

wp-config.php 末尾近くの区切りコメント（英語版 /* That's all, stop editing! */、日本語版「編集が必要なのはここまでです !」）より上に、次を追記します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
  • WP_DEBUG を true にすることでデバッグが有効になります
  • WP_DEBUG_LOG を true にすると、ログが wp-content/debug.log に記録されます
  • WP_DEBUG_DISPLAY を false にすることで、エラー内容を画面に出さずログだけに残せます（訪問者にエラーを見せない）

サイトを再読み込みしてから wp-content/debug.log を開くと、PHP Fatal error: の行に、原因ファイルのパスと行番号が記録されています。ここに出ているプラグイン名・テーマ名が、ほぼそのまま原因です。

調査が終わったら、WP_DEBUG 関連の記述は元に戻す（false にする）か削除してください。デバッグ表示を有効なまま放置すると、情報露出の原因になります。

再発防止：この画面を出しにくくする運用

復旧後は、同じ事故を「運用で起こしにくくする」段階に入ります。

1. 更新は本番一発勝負にしない

  • プラグイン・テーマ・本体は、可能ならステージング環境で先に検証する
  • 一度に複数を更新せず、1つずつ更新して動作確認する
  • 更新前に必ずバックアップ（ファイル＋データベース）を取得する

2. バックアップとロールバック体制

  • 日次の自動バックアップを設定する
  • 月1回は復元テストを行い、「本当に戻せる」状態を確認する
  • 保存先は同一サーバー外にも持つ

3. functions.php を直接触らない

  • カスタムコードは子テーマやコードスニペット用プラグインで管理する
  • 編集前のバックアップを必ず残す

4. 自動更新は「止める」のではなく「制御する」

「誰も触っていないのにエラーが出た」の多くは、自動更新が引き金です。ただし、自動更新を全部オフにするのは危険です。セキュリティ修正まで止まり、今度は脆弱性を放置することになります。狙いは「全部止める」ではなく「壊れやすい更新だけ手動にする」ことです。

  • 本体のマイナー/セキュリティ更新は自動のまま残す（脆弱性対応のため重要）
  • 本体のメジャー更新は自動にしない（WordPressは既定でメジャー更新を自動化しないため、管理画面で「メジャー版を自動更新」をオンにしない）
  • プラグイン・テーマの自動更新はオフにし、バックアップ取得後に手動で更新（重要度の高いサイトほど推奨）
  • レンタルサーバー側の自動更新設定も確認する（管理画面側をオフにしても、ホスティング側で自動更新が有効なことがある）

設定例も挙げておきます。ポイントは、コア（本体）の制御は wp-config.php の定数、プラグイン/テーマの制御はフィルタ、と書く場所が分かれることです。

(1) 本体のメジャー更新だけ自動にしない（wp-config.php）

同じく区切りコメント（英語版 /* That's all, stop editing! */、日本語版「編集が必要なのはここまでです !」）より上に記述します。

// マイナー/セキュリティ更新だけ自動に保ち、メジャー更新は手動にする（既定値を明示）
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE の値の意味は次のとおりです。

値 挙動
'minor' マイナー/セキュリティ更新のみ自動（通常サイトの既定値）
true メジャー更新まで自動になる
false コアの自動更新を全停止（セキュリティ更新も止まるため非推奨）

つまり「メジャーだけ止めたい」なら 'minor' が正解です。false にすると脆弱性修正まで届かなくなるので避けてください。

(2) プラグイン・テーマの自動更新を止める（フィルタ）

プラグイン/テーマは定数ではなく auto_update_plugin / auto_update_theme フィルタで制御します。この add_filter() を wp-config.php に書いてはいけません（WordPress本体が読み込まれる前に実行され、WP-CLI などと競合します）。wp-content/mu-plugins/ 配下に .php ファイルを置くか、子テーマの functions.php に記述します。

// プラグイン・テーマの自動更新を一括で無効化する
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme',  '__return_false' );

なお、コア・プラグイン・テーマを含むすべての自動更新を止めたい場合は wp-config.php に define( 'AUTOMATIC_UPDATER_DISABLED', true ); を書く方法もありますが、これもセキュリティ更新まで止まるため、安易な全停止は避けてください。

更新の検証フローを持てない場合でも、「メジャー更新と多機能プラグインだけは手動」と決めておくだけで、突然の致命的エラーはかなり減らせます。

5. PHPバージョンは計画的に上げる

  • サーバー側のPHP自動更新の有無を把握する
  • 上げる前に、使用中プラグイン・テーマの対応状況を確認する

6. 運用保守を体制化する

社内で継続的に監視・検証しにくい場合は、復旧後の運用フェーズだけを外部化する方法も有効です。必要に応じて運用保守サービスのような定期保守を組み合わせると、更新事故の予防と早期検知を両立しやすくなります。

まとめ

「このサイトで重大なエラーが発生しました」の復旧で重要なのは、技術力よりも順番です。

  1. 最初の5分で状況固定（フロント/wp-admin/・直前の変更・管理者メール）
  2. メールが届けば、リカバリーモードで原因プラグイン/テーマを特定・無効化
  3. メールが届かなければ、FTPで plugins フォルダをリネームして一括無効化、次にテーマをデフォルトへ
  4. 原因が見えなければ debug.log でエラー行を確認
  5. 改ざんの兆候や復帰不能なら、早めに専門家へ切替

この画面は「終わり」ではなく「WordPressからの案内」です。慌てて操作を増やすより、順番を守ることが最短の復旧につながります。