WordPress のホワイトスクリーン（真っ白な画面）

このエラーの意味と見分け方

• WordPress のフロントエンド、管理画面、またはその両方が、エラーメッセージのない完全に真っ白なページになる。
• サイト全体に影響する場合もあれば、特定の管理画面、テンプレート、ショートコード、ブロック、URL だけに影響する場合もある。
• プラグインやテーマのインストールまたは更新直後に、真っ白なページが表示されることがある。
• ホスティング事業者がサイトの PHP バージョンを変更した後に、問題が始まることがある。
• PHP のエラーを引き起こしているプラグイン、テーマ、メモリ問題、互換性問題、または破損ファイルに対処するまで、影響を受けたリクエストは真っ白なままになる。

可能性の高い順の主な原因

1. プラグインの PHP 致命的エラー — プラグインのインストールや更新後に問題が始まった場合、またはプラグイン関連のページだけが失敗する場合に、最も可能性が高い原因です。
2. 有効化中のテーマのエラー — テーマまたはその functions.php の問題により、多数のページやサイト全体に影響が及ぶことがあります。
3. PHP メモリの枯渇 — リクエストが設定された memory_limit を超えることがあります。ログには通常 Allowed memory size exhausted と記録されます。
4. PHP バージョンの非互換性 — プラグインやテーマに、ホストで現在使用されている PHP バージョンでは動作しないコードが含まれている可能性があります。
5. 破損した WordPress コアファイル — 更新が中断された、または不完全だった場合にコアファイルが破損することがあります。ただし、問題がプラグインやテーマの変更直後に明確に発生した場合は、可能性は低くなります。

修正方法

1. サイトを保護し、失敗したリクエストを特定する

ホスティングのツールでバックアップを作成できる場合は、ファイルを編集する前に作成してください。真っ白なページがフロントエンド、管理画面、または特定の URL だけに影響しているかを確認します。SFTP またはホスティングパネルのファイルマネージャーへのアクセスと、wp-config.php を編集する権限が必要です。

2. 訪問者にエラーを表示せず、デバッグログを有効にする

wp-config.php を開き、各定数が一度だけ記述されるように、次の設定を追加または更新します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

本番サイトでは WP_DEBUG_DISPLAY を false に設定したままにします。ホワイトスクリーンが表示される正確な URL を再読み込みし、wp-content/debug.log を確認します。致命的エラー、ファイルパス、行番号を探してください。WordPress のログが作成されない場合や、該当するイベントが含まれていない場合は、ホストにアカウントの PHP エラーログを確認してもらいます。

3. ログで特定されたプラグインを無効にする

エラーにプラグイン名が示されている場合は、SFTP またはホスティングのファイルマネージャーで wp-content/plugins/ を開きます。該当するプラグインのフォルダー名に、-disabled などのサフィックスを追加して変更します。フォルダー名を変更すると、ファイルと設定を保持したまま、WordPress がプラグインを読み込めなくなります。

失敗した URL を再読み込みします。正常に表示される場合、そのプラグインが直接の原因です。サイトの WordPress および PHP バージョンと互換性のある更新がないか確認し、適切な更新が存在しない場合はプラグイン開発者に問い合わせます。フォルダー名の変更でサイトが復旧したからといって、互換性のないプラグインや古いプラグインを有効なままにしないでください。

4. 有効化中のテーマをテストする

ログが有効化中のテーマを指している場合、または特定したプラグインを無効にしても改善しない場合は、wp-content/themes/ 内でそのテーマのフォルダー名を変更します。WordPress は利用可能なデフォルトテーマにフォールバックするはずです。

サイトが復旧した場合は、ログに示されたファイルと行を確認します。特に functions.php に注意してください。利用可能なフォールバックテーマがインストールされていない場合は、テスト後に元のフォルダー名へ戻し、それ以上変更する前にテーマ提供元またはホストへ問い合わせます。

5. メモリ枯渇エラーを解決する

ログに Allowed memory size exhausted と記録されている場合、失敗したリクエストが設定済みの PHP メモリ制限を超えています。サイトのホスティングまたは WordPress 管理手順に従って安全に制限を引き上げ、プラグイン、テーマ、または特定のリクエストが過剰なメモリを消費していないか調査します。

承認された設定変更を行った後、同じ URL を再読み込みし、同一の致命的エラーが再び記録されなくなったことを確認します。制限を引き上げるだけでは、非効率または互換性のないコンポーネントの問題を隠してしまう可能性があります。エラーが再発する場合は、引き続き調査してください。

6. PHP バージョンの互換性を確認する

PHP バージョンの変更後にホワイトスクリーンが始まった場合は、ログに示されたプラグインまたはテーマとの時系列を比較します。その拡張機能を一時的に無効にすると、関連性の確認に役立ちます。

プラグインやテーマを更新、交換、修正するまでの間、一時的な PHP バージョンのロールバックが可能かホストに確認します。ロールバックは診断または一時的な対策として扱い、恒久的な互換性解決策にはしないでください。

7. 根拠がある場合にのみコアファイルを復元する

プラグイン、テーマ、PHP、メモリのいずれの変更でも問題を説明できず、ログにも拡張機能が示されていない場合は、WordPress コアファイルの破損が考えられます。公式 WordPress の新しいダウンロードから、対応する WordPress コアファイルを SFTP 経由で再アップロードします。

wp-content や wp-config.php を上書きしないでください。 コアファイルとサイトのコンテンツおよび設定を確実に区別できない場合は、作業を中止し、ホストまたは WordPress の専門家に相談してください。

8. 復旧を確認し、後片付けを行う

真っ白だった正確なフロントエンド URL または管理画面を再読み込みします。同じプラグイン、テーマ、ショートコード、またはブロックを使用する関連ページもテストします。wp-content/debug.log を確認し、同じ致命的エラーが再発していないことを確認します。

原因が確認できたら、一時的なデバッグ設定を無効にするか、ログを残す場合は公開アクセスから保護されていることを確認します。

予防と修正確認

• WordPress、プラグイン、テーマ、またはホスティング環境の PHP バージョンを更新する前に、サイトをバックアップします。
• 問題に関連する変更を特定できるよう、プラグインとテーマは一度に 1 つずつ更新します。
• WordPress、PHP、テーマ、プラグインに大きな変更を加える前に、ステージング環境のコピーでテストします。
• 本番サイトでは WP_DEBUG_DISPLAY を無効にし、デバッグログへのアクセスを制限します。
• 利用可能な PHP メモリを監視し、設定された制限に繰り返し近づくコンポーネントを調査します。
• 各修正後に、正確なエラー URL を再読み込みし、同じ致命的エラーが再発していないかログを確認します。

よくある質問