WordPressのホワイトスクリーン・オブ・デス（真っ白な画面）を修復する

WordPressのホワイトスクリーン・オブ・デスとは、エラー表示が無効化された状態で発生したPHPの致命的エラー（fatal error）です。HTMLを1行も出力する前にコードがクラッシュし、さらにWordPressはファイルパスやサーバー情報が訪問者に漏れないようエラーメッセージを隠しています。

プラグインを更新してサイトを再読み込みしたら、フロントエンドが真っ白になった——多くの場合、wp-adminも同様です。エラーもスタックトレースも、クリックできるものも何もありません。手当たり次第に無効化していきたくなりますが、メッセージはすでに存在しています。ただ、あなたに表示されていないだけです。以下の手順はすべてSFTPまたはホスティング事業者のファイルマネージャーで実行でき、ファイルアクセスは提供されないがphpMyAdminは使えるという環境向けのデータベース経由のルートも紹介します。

WordPressのホワイトスクリーン・オブ・デスとは何か

真っ白な画面は、ページをレンダリングする前にPHPが致命的エラーに遭遇したことを意味します。WordPressは本番サイトでエラーテキストを意図的に抑制しており、これはパスやバージョン、その他の内部情報が露出しうるためです。サイトのファイルとデータベースは無傷で、1つのコンポーネントがリクエストをクラッシュさせただけです。

何かに手を付ける前に、管理者メールの受信箱を確認してください。バージョン5.2以降、WordPressは致命的エラーが発生すると管理者にメールを送り、問題のプラグインまたはテーマ名を伝え、リカバリーモードに入るリンクを含めます。リカバリーモードとは、壊れたコンポーネントが一時停止され、ダッシュボードにアクセスしてそれを無効化できる状態です。このリンクにはシークレットキーが含まれており、リカバリーモードのURLを手打ちしてもアクセスは得られません。メールが届かない場合（スパムフィルターに食われることがあり、またこのメールはwp-login.phpや管理画面など保護されたエンドポイントでエラーが発生した場合にのみ送信され、フロントエンドのページやcronジョブでは送信されません）は、以下を続けてください。

表示ではなく、ログを有効にする

SFTPまたはホスティング事業者のファイルマネージャーで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-content/debug.logにあるログを開きます。WordPressのデバッグドキュメントによると、WP_DEBUG_LOGはWP_DEBUGがtrueでなければ効果がなく、WP_DEBUG_DISPLAYのデフォルトはtrueです。だからこそ上記のスニペットでは明示的にfalseを設定しています。稼働中のサイトでエラーをページに出力してはいけません。訪問者全員にサーバーパスやコードの詳細が見えてしまいます。サイトが復旧したら、4行すべてを削除してください。

エラーを読む：パスが原因を名指しする

ログにはファイルと行番号が記録され、そのパスに含まれるディレクトリがどのコンポーネントで失敗したかを教えてくれます。実際のエントリは次のようになります。

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

パスはwp-content/plugins/acme-slider/配下にあるため、原因はAcme Sliderプラグインであり、そのフォルダー1つをリネームすればサイトは即座に復旧します。一般的なルールとしては次の通りです。

ログにメモリエラーが記録されている場合は次のセクションを読んでください。ログが空の場合にのみ、二分探索の手順にフォールバックします。

WordPressのメモリ枯渇エラーはどう修復するか

Allowed memory size of X bytes exhaustedで始まるエラーは、リクエスト処理の途中でPHPがメモリ上限に達したことを意味します。wp-config.phpでWordPressの上限を引き上げます。

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

WordPressはWP_MEMORY_LIMITのデフォルトを単一サイトで40M、マルチサイトで64Mとしており、PHPの上限を引き上げることはあっても、決して引き下げることはありません。この定数はホスティング事業者がサーバーレベルで課している上限までしか機能しません。256Mにしても何も変わらないなら、制限はこの設定ではなくホスティングプラン側にあるため、事業者に引き上げを依頼する必要があります。

wp-adminなしで問題のプラグインを無効化する方法

ログがプラグインを名指ししている場合は、wp-content/plugins/内のそのプラグインのフォルダーだけをリネームします。ログが空の場合は二分探索します。wp-content/pluginsをplugins.holdにリネームし、/wp-admin/plugins.phpを読み込んでWordPressに存在しないプラグインを無効化として記録させ、フォルダー名を元に戻し、その後プラグインを1つずつ有効化して、そのたびにサイトを再読み込みし、壊れる箇所を特定します。すべてのプラグインを手作業で再有効化する手間がこのルートの代償ですが、各プラグインが保存していた設定はそのまま残ります。

ファイルアクセスはないがphpMyAdminは使える場合は、wp_optionsテーブル（プレフィックスはwp_でないこともあります）を開き、option_nameがactive_pluginsである行を見つけ、現在のoption_valueを安全な場所にコピーまたはエクスポートしてください。その後、値をシリアライズされた空配列a:0:{}に置き換えると、すべてのプラグインを一度に無効化できます。元のリストが必要になったら、保存しておいた値を後で復元します。

壊れたテーマを無効化する方法

ログがwp-content/themes/を指している場合は、有効なテーマのフォルダーだけをリネームします（例：mythemeをmytheme.holdに）。同梱のデフォルトテーマがインストールされていれば、WordPressはそれにフォールバックします。1つもない場合は、まずファイルマネージャー経由でインストールしてください。よくある原因はfunctions.phpで、ログはすでに正確な行を教えてくれています。多くの場合、構文エラーを含む最近の編集箇所です。その行を修正して、フォルダー名を元に戻します。

それでも真っ白？キャッシュ、パーミッション、PHPバージョン

結果を信用する前に、あらゆるキャッシュをパージしてください。プラグインのページキャッシュ、サーバーキャッシュ、そしてブラウザのキャッシュです。キャッシュされた空白ページは修復済みのサイトを壊れているように見せ、キャッシュされた正常なページは進行中のエラーを隠してしまいます。次にファイルパーミッションを確認します。共用ホスティングでは通常、ディレクトリが755、ファイルが644です。そしてPHPバージョンを確認しましょう。WordPressが推奨する基準は8.3以降です。7.4のサイトでも読み込みはできますが、そのブランチは数年前にセキュリティ修正の提供が終了しています。

本記事の対象範囲外となるケースが3つあります。バックアップからの復元（ホスティング事業者のバックアップツールを使用。スナップショット以降の変更はすべて失われる点に注意）、コアファイルの破損（wp-contentとwp-config.phpを除くすべてに、新しくダウンロードしたWordPressを上書きコピー）、そしてマルウェア（ホスティング事業者のハッキング被害サイト復旧手順に従う）です。

まとめ

真っ白なWordPressページは抑制されたエラーメッセージであり、謎ではありません。そして最速の解決策は常に、推測で回り道をするのではなく、そのメッセージを読むことです。今すぐwp-config.phpに4行のデバッグ設定を追加し、一度再読み込みして、wp-content/debug.logのパスにどのフォルダーをリネームすべきかを正確に教えてもらいましょう。

よくある質問

ホワイトスクリーン・オブ・デスと「このサイトで重大なエラーが発生しました」というメッセージの違いは何ですか？

WordPress 5.2以降、組み込みの致命的エラーハンドラーがほとんどのPHP致命的エラーを捕捉し、空白ページの代わりに重大なエラーのメッセージを表示します。完全に真っ白な画面は、そのハンドラーが実行される前にPHPが停止したことを意味し、多くはメモリ枯渇、あるいはwp-config.php内部のようなロード処理のごく初期段階でのエラーが原因です。どちらもPHPの致命的エラーに起因し、デバッグ手順は同一です。

WP_DEBUGを有効にしているのに、wp-content/debug.logが空なのはなぜですか？

よくある原因は、デバッグ定数が効く前にエラーが発生している場合（wp-config.php自体の構文ミスなど）、またはwp-contentディレクトリにWebサーバーの書き込み権限がなく、WordPressがファイルを作成できない場合です。定数がstop-editingのコメントより上にあることを確認し、その上でホスティング事業者にサーバーレベルのPHPエラーログを問い合わせてください。こちらはWordPressの設定に関係なく致命的エラーを記録します。

一部のページだけ真っ白になり、他のページは正常なのはなぜですか？

致命的エラーが、それらのリクエストでのみ実行されるコードの中にあるからです。テーマのテンプレートファイルでのクラッシュはフロントエンドを空白にしますが、管理画面はフロントエンドのテンプレートをレンダリングしないためwp-adminは動作し続けます。管理画面専用のプラグインコードでのクラッシュはその逆になります。デバッグログを有効にして壊れているページを1つ読み込めば、記録されたエラー内のファイルパスが問題のコンポーネントを特定してくれます。

サイトを修復した後もWP_DEBUGとWP_DEBUG_LOGを有効にしたままにしても安全ですか？

いいえ。ログのデフォルトはwp-content/debug.logで、これは予測可能かつWebからアクセスできるパスであり、多くのホスティング事業者はこれをブロックしていません。そのためそのURLをリクエストした誰もがファイルパス、エラーの詳細、プラグインの内部情報を読めてしまい、さらにファイルはローテーションなしに肥大化していきます。サイトが正常に動いたらwp-config.phpからデバッグ行を削除するか、WP_DEBUG_LOGに公開Webルート外のカスタムファイルパスを設定してください。