「このサイトで重大なエラーが発生しました」とはどういう意味ですか？

ページを生成している途中で PHP が致命的なエラーを起こし、真っ白な画面になる前に WordPress がそれを受け止めた、という意味です。訪問者にファイルパスやコードを見せないよう、メッセージはわざと曖昧にしてあります。ファイル名と行番号を含む本当のエラーは、サーバー上のログに書き出されています。

WordPress の重大なエラーのログはどこにありますか？

wp-config.php で WP_DEBUG と WP_DEBUG_LOG を true にしていれば、wp-content/debug.log に書き出されます。オフの場合でもエラー自体はサーバーの PHP エラーログに残っており、多くはホスティングの管理画面の「ログ」や「エラーログ」から見られます。何も記録されていないと決めつける前に、両方を確認してください。

WordPress のリカバリーモードのメールが届かないのはなぜですか？

メールの宛先はログイン用のアドレスではなく、設定に登録されたサイト管理者アドレスです。しかも送信するのは、たった今クラッシュした同じ PHP なので、そもそも届かないことがよくあります。共有サーバーでは SMTP なしの送信がブロックされている場合もあります。迷惑メールを確認したら、メールは諦めて SFTP でプラグインを無効化するほうが早いです。

wp-admin にログインできない場合、重大なエラーはどう直せばいいですか？

SFTP かホスティングのファイルマネージャーで接続し、wp-content/plugins フォルダーの名前を plugins-off などに変更します。これで全プラグインが一括で停止し、ほとんどの場合は管理画面に入れるようになります。名前を戻したら、プラグインを 1 つずつ有効化していき、エラーが再発したところが犯人です。

PHP のバージョンアップで WordPress に重大なエラーが起きることはありますか？

あります。むしろ最も多い原因のひとつです。ホスティング側が PHP を自動で上げると、廃止された書き方を使っている古いプラグインやテーマのコードは即座に落ちます。ログには wp-content 配下の具体的なファイル名が出るはずです。管理画面で PHP のバージョンを戻すと診断の裏付けになりますが、あくまで一時しのぎです。

重大なエラーが出たらサイトが改ざんされたということですか？

たいていは違います。圧倒的多数は、PHP バージョンと合わないプラグインやテーマの更新か、メモリ不足です。マルウェアが致命的エラーを起こすこともありますが、その場合はログが見覚えのないファイルや難読化されたコードを指します。改ざんを疑う前に、まずログを読んでください。

「このサイトで重大なエラーが発生しました」の意味と直し方

このメッセージは、ページを生成する途中で PHP が致命的なエラーを起こし、真っ白な画面になる前に WordPress がそれを受け止めた、ということを表しています。エラーは実在し、内容も特定されていて、記録もされています。ただ、公開ページにスタックトレースを出せば誰にでもファイルパスやコードが見えてしまうため、ブラウザーには表示していないだけです。

だから対処は当てずっぽうである必要がありません。本当のエラーを読む。書いてあるとおりに手を打つ。それだけです。

内部で起きていること

WordPress 5.2 以降、コアには致命的エラーのハンドラーが組み込まれています。リクエストの途中で PHP が停止すると、ハンドラーがクラッシュの出力を差し替えて例のあたりさわりのない一文を表示し、原因のプラグインやテーマを特定できた場合は、リカバリーモードへのリンクをサイト管理者にメールしようとします。

昔の真っ白な画面（ホワイトスクリーン）ではなくこの画面が出るのは、そのためです。改善ではあるのですが、裏を返せば診断に必要な情報が初期状態では隠されている、ということでもあります。メッセージには 2 種類あります。

表示される内容	出る場所	わかること
「このサイトで重大なエラーが発生しました。」	フロント側、ログアウト状態	致命的エラーが起きた。それ以上の詳細は出ない
同じ一文に加えて「WordPress のトラブルシューティングについてはこちらをご覧ください」	フロント側または wp-admin	エラーは同じ。ハンドブックのページを案内している
「…サイト管理者のメールで手順をご確認ください。」	フロント側	ハンドラーが復旧メールを送信したと判断した

3 つめが役に立ちます。これは WordPress がクラッシュの原因を特定のプラグインかテーマに結び付け、入口を渡そうとしたという意味だからです。

ステップ 1: リカバリーモードのメールを確認する

WordPress は復旧リンクを サイト管理者のメールアドレス（設定 → 一般に入っているもの）に送ります。ログインに使っているアドレスとは違うことがよくあります。そちらの受信箱と、迷惑メールフォルダーを見てください。

メールには ?action=enter_recovery_mode のような文字列で終わる長いリンクが入っています。開くとリカバリーモードで wp-admin にログインでき、問題のプラグインやテーマは一時停止された状態で、画面上部に赤い通知として表示されます。あとは通常どおり無効化すれば済みます。

正直に言っておくべき注意点が 2 つあります。ひとつ目は、このメールを作っているのは、たった今クラッシュした当の PHP プロセスであり、そもそもメール送信の仕組みがまともに動いていないサーバーも珍しくないということ。届かないのはよくあることで、届かないこと自体はエラーについて何も語りません。ふたつ目は、復旧リンクには有効期限がある（既定でおよそ 1 日）ことです。受信箱に残っている古いメールは単に期限切れかもしれません。サイトを再読み込みしてもう一度クラッシュさせ、新しいメールを待ってください。

自分が必ず見るアドレスに届かせたい場合は、wp-config.php で明示的に指定できます。

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

ステップ 2: 本当のエラーを読む

壊れたサイトが 5 分で直る仕事に変わるのは、この工程です。wp-config.php の「編集を終わり」と書かれた行より上に、次の行を追加します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY を false にしているのが重要です。エラーをブラウザーに出さないままディスクには書き出せるので、調査中に訪問者へサーバーのパスをさらさずに済みます。

壊れているページを一度だけ再読み込みしてから、wp-content/debug.log を開きます。最後の行はだいたいこんな形です。

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

答えはファイルパスです。wp-content/plugins/ の下を指していれば、そのプラグインが原因。wp-content/themes/ の下ならテーマで、functions.php に最近貼り付けたコードであることが非常に多いです。

debug.log が現れない場合は、ディレクトリーに書き込み権限がないか、セキュリティ系プラグインがログの出力先を変えている可能性があります。その場合はホスティングの PHP エラーログを見てください。たいていの管理画面には「エラーログ」や「ログ」の項目があり、同じ致命的エラーがタイムスタンプ付きで残っています。

その行を WordPress エラーログ解読ツールに貼り付ければ、PHP の言い回しが実際に何を意味するのか、まずどのファイルを見ればいいのかがわかります。

調査が終わったらデバッグ用の行は削除してください。 本番で WP_DEBUG を入れっぱなしにするとディスクが埋まりますし、WP_DEBUG_DISPLAY がどこかで true に戻れば、サーバーのパスが公開されてしまいます。

ステップ 3: wp-admin に戻る

wp-admin も死んでいて復旧メールも来ない場合は、ファイルシステムのレベルで全プラグインを止めます。SFTP（またはホスティングのファイルマネージャー）で接続し、フォルダー名をひとつ変更するだけです。

mv wp-content/plugins wp-content/plugins-off

WordPress はプラグインを見つけられなくなるので全部を無効化し、ほぼ確実に管理画面へのアクセスが戻ります。そのあとは、

フォルダー名を plugins に戻します。すべて無効のままです。WordPress が非有効として記録しているためです。
プラグインを 1 つずつ有効化し、そのたびにフロント側を読み込みます。
エラーが再発したものが犯人です。

全プラグインを止めてもサイトが壊れたままなら、疑うべきはテーマです。wp-content/themes/ にある有効なテーマのフォルダー名を変更すれば、既定テーマが入っていれば WordPress はそちらに切り替わります。

知っておく価値のある 3 つの原因

プラグインやテーマの更新で落ちるケース。 圧倒的に多いパターンです。ログがファイル名を直接教えてくれます。そのプラグインだけ前のバージョンに戻すか、無効のままにして、ログの行を添えて開発者に連絡してください。

PHP のバージョン不一致。 ホスティング側は決まったスケジュールで PHP を上げます。予告があまりないこともあります。古い PHP 向けに書かれたコードは、新しいバージョンでは構文解析すら通らなくなることがあります。手掛かりは「自分は何も変えていないのに全部が同時に壊れた」という点です。管理画面で PHP をひとつ前のマイナーバージョンに戻すのは診断として有効ですが、これは解決ではなく時間稼ぎだと考えてください。古い PHP はセキュリティ修正の提供が止まります。

メモリ不足。 ログに「Allowed memory size of X bytes exhausted」と出ます。wp-config.php で上限を上げるのは妥当な対応です。

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

ただし何をしているかは正直に理解しておくべきです。これは天井を取り払うだけで、1 ページ描画するのに 256MB を食っている原因そのものは直しません。上限を上げ続けなければならないなら、本当の問題は別にあります。多くはインポート処理、ページビルダー、あるいは出来の悪いクエリです。

気にしなくていいアドバイス

「とりあえずメモリ上限を上げましょう」 ログに実際にメモリ不足と書いてある場合にだけ意味があります。そうでなければ何も変わらず、エラーを読んでいないという事実を覆い隠すだけです。

「WordPress のコアを再インストールしましょう」 コアファイルが原因になることはめったにありません。入れ替えている時間があれば、ログを 1 行読んだほうが早いです。

「致命的エラーハンドラーを無効化しましょう」 それ用の定数は確かにありますが、結果として起きるのは、受け止められたメッセージの代わりに生のエラーが公開サイトに表示されることです。訪問者にファイルパスが見えてしまいます。代わりに WP_DEBUG_LOG を使い、WP_DEBUG_DISPLAY はオフにしてください。得られる情報は同じで、露出だけがなくなります。

「キャッシュを削除しましょう」 致命的エラーは、キャッシュ系プラグインが何かを返すより前に PHP の中で起きます。エラーページのキャッシュが配信されている場合、削除が役に立つのは原因を直したあとです。原因の代わりにはなりません。

それでも解決しない場合

ログが wp-content の中ではなくコアのファイルを指している場合、コアが壊れているというより、先に読み込まれたプラグインがコアの前提とする状態を壊した、という説明のほうが妥当です。フォルダーのリネームで全部を止め、サイトがきれいに読み込まれることを確認してから、1 つずつ戻してください。エラーが再発する直前に有効化したものが、ログの行を添えて報告すべき相手です。