WordPressの真っ白画面（White Screen of Death）を徹底解説
真っ白画面（White Screen of Death）は、目に見えないPHPの致命的エラーです。WordPressがレンダリング中に回復不能なエラーに遭遇してPHPが停止し、エラー表示がオフになっているため、原因が表示されず白紙のページが返ってきます。
公開
真っ白画面（White Screen of Death）は、目に見えないPHPの致命的エラーです。WordPressがレンダリング中に回復不能なエラーに遭遇してPHPが停止し、本番サーバーではエラー表示がオフになっているため、原因が表示されずに白紙のページが返ってきます。この修正は、当てずっぽうで進める必要はほとんどありません。デバッグログを有効にして wp-content/debug.log を開き、最後の致命的エラーの行を読むだけです。その行には問題のファイル名が正確に記されており、ほぼ確実にプラグインかテーマです。そしてその1行が、修正のすべてです。
なぜ画面が真っ白になるのか
PHPには display_errors という設定があります。開発マシンでは通常オンになっているので、致命的エラーが発生するとスタックトレースが画面に表示されます。一方、本番のホスティング環境ではデフォルトでオフです。ファイルパスやエラーを訪問者に漏らすのはセキュリティ上の問題だからです。そのため、致命的エラーが発生したとき——存在しなくなった関数の呼び出し、読み込まれていないクラス、プラグイン更新に混入した構文エラーなど——PHPは処理を止め、何も返しません。ブラウザは空のドキュメントを表示します。これが「真っ白画面」です。
WordPress 5.2以降には、こうしたエラーを捕捉しようとする致命的エラーハンドラー（WP_Fatal_Error_Handler）が備わっています。うまく機能すれば、白紙のページではなく「このサイトで重大なエラーが発生しました」というメッセージが表示され、さらに管理者アドレス宛てに、多くの場合、実際のエラー内容とリカバリーモードへのリンクを含んだメールが届きます。完全に真っ白な画面が出る場合は、たいていハンドラーが動く前にエラーが発生しています。パース／構文エラー（コンパイル時に検出される）、壊れたmust-useプラグイン、あるいは有効化中のテーマの functions.php 内の致命的エラーなどです。いずれにせよ、原因はどこかに記録されています。あなたはただ、その記録機能をオンにするだけです。
順を追って直す
1. ログを有効にする。 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_DEBUG_DISPLAY を false にすることで公開ページにエラーを表示させないようにし、WP_DEBUG_LOG によってエラーが wp-content/debug.log に書き込まれます。壊れたページを一度リロードして、新しいログエントリを生成させましょう。
2. 最後の致命的エラーを読む。 wp-content/debug.log を開いて、末尾を確認します。
tail -n 30 wp-content/debug.log探しているのは、次のような行です。
[14-Jul-2026 09:12:44 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88このパスが原因を指し示しています。plugins/some-addon です。これが答えです。トレースが長かったり、メッセージが難解だったり（Allowed memory size exhausted、Cannot redeclare、見覚えのないクラス名など）する場合は、エラーログデコーダーに貼り付けてください。ノイズを取り除き、パスがどのプラグインやテーマを指しているのかを教え、その特定のエラータイプが何を意味するのかを説明してくれます。
3. 名指しされたコンポーネントを無効化する。 /wp-admin にアクセスできないので、SFTP経由で行います。問題のプラグインのフォルダ名を変更します。たとえば some-addon → some-addon.off のように。WordPressは見つからないフォルダを読み込めないので、そのプラグインは無効化され、サイトが復旧します。ログがテーマを指している場合は、有効化中のテーマフォルダの名前を変更してデフォルトテーマに切り替えます。WordPressは同梱の twentytwentysomething にフォールバックします。
4. ログが書き込まれない場合、wp-content に書き込み権限がないか、エラーがサーバーレベルで発生しています。代わりにホストのPHPエラーログを確認しましょう。
find . -name "error_log" -newermt "-1 hour"同じ情報が、別のファイルに記録されています。cPanel／Apache構成では、サイトのルートや問題のディレクトリに error_log が出力されることがよくあります。
やってはいけないこと
単にメモリ上限を上げるだけにしない。 ネット上で最も繰り返されるアドバイスは、WP_MEMORY_LIMIT を256Mや512Mに引き上げるというものです。これは、ログに実際に Allowed memory size of N bytes exhausted と書かれている場合にのみWSODを解消します。エラーが Call to undefined function なら、メモリを増やしても何も変わりません。設定を当てずっぽうにいじっただけで、画面はまだ真っ白なままです。まずログを読み、メモリが原因だと明記されている場合にのみメモリを増やしましょう。
キャッシュを消しただけで原因究明した気にならない。 真っ白画面は、HTMLが1文字も生成される前に、サーバー上でPHPが停止している状態です。古いキャッシュ済みアセットが空のドキュメントを引き起こすことはありません。（壊れたキャッシュプラグインなら引き起こし得ますが——その場合はログがそれを名指しします。それが要点です。）
WordPressコアを編集したり再インストールしたりしない。 致命的エラーが wp-includes や wp-admin にあることはほとんどありません。原因はログが指し示すプラグインかテーマにあります。コアの再インストールは時間がかかり、リスクも高く、まだ確認できてもいない症状に対処しているだけです。
すべてのプラグインを無効化して、当てずっぽうで1つずつ有効化し直さない。 二分探索は有効ですが、遠回りです。ログなら、問題のフォルダを一発で正確に教えてくれます。「全部オフにする」方式に頼るのは、読めるエラーがまったく残っていない場合だけにしましょう。
本番環境で display_errors をオンのままにしない。 サイトが復旧したら、デバッグ用の定義を削除する（または WP_DEBUG を false に戻す）こと。訪問者に表示されるエラーは、あなたのパスを露出させます。
それでも解決しないときは
ログがプラグインを名指ししているのに、それを無効化しても画面が直らない場合、最初のエラーの下にもう1つ致命的エラーが潜んでいます。もう一度ログを有効にして、新しい最後の行を読んでください。致命的エラーは積み重なります。メッセージそのものが壁になっているなら、エラーログデコーダーに投入して、エラータイプとファイルパスを翻訳してもらいましょう。真っ白画面が謎のままなのは、ログをオフにしている間だけです。