WordPressの画面が真っ白(White Screen of Death)になった原因と復旧手順|WP_DEBUG活用とエラー解消の実務ガイド

WordPressでWebサイトを運用している際、突然画面が何も表示されず「真っ白」になってしまう現象は、Web制作やサイト運用の現場で最も慌てるトラブルの1つです。この現象はWeb業界において「White Screen of Death(WSOD)」と呼ばれ、主にPHPコードの実行時に致命的なエラー(Fatal Error)が発生し、HTMLの表示処理が途中で強制終了したことが原因で起こります。

結論から申し上げますと、WordPressの画面が真っ白になった場合は、無闇に設定変更やファイルの削除を行わず、まずFTP接続やサーバーのファイルマネージャーを用いて「wp-config.php」ファイルを修正し、デバッグモード(WP_DEBUG)を有効化してエラーの原因箇所(不具合を起こしているプラグインやテーマ、コードの行数)を特定することが最優先の復旧手順となります。原因を特定したうえで、該当するプラグインの停止やテーマの切り替え、コードの修正を行うことで、サイトを安全かつ迅速に正常な状態へ復元可能です。

本記事では、WordPressの画面が真っ白になる具体的な原因から、エラーログを出力して問題を特定する手順、原因別の緊急対処法、そして将来的な再発を防ぐ保守運用のポイントまで、実務担当者やWebサイト管理者向けに分かりやすく解説します。

WordPressの画面が真っ白(WSOD)になる主な5つの原因

WordPressの画面が真っ白になる現象は、サーバー側でPHPプログラムが処理を実行する際、修復不可能なエラーが発生して処理が中断されることで生じます。通常、WordPressはデータベースや多数のPHPファイルが連携して動的にページを生成しているため、一部の記述や処理に不整合が生じると画面全体の表示が停止します。主な発生要因は以下の5つです。

1. PHP構文エラー(Syntax Error)や関数の不整合

サイトのカスタマイズ時に「functions.php」やテーマのテンプレートファイルを直接編集した際、セミコロンのつけ忘れ、カッコの閉じ忘れ、全角スペースの混入といったごくわずかな記述ミスによってPHP構文エラーが発生します。また、存在しない関数を呼び出した場合や、同じ関数名を重複して定義した場合にも致命的なエラー(Fatal Error)となり、画面が真っ白になります。

2. プラグイン同士の競合・バージョン不互換

新規プラグインの有効化や、既存プラグインの一括アップデートを行った直後に画面が真っ白になるケースは非常に多く見られます。複数のプラグインが同一処理で衝突した場合や、サーバーのPHPバージョンに対してプラグインのコードが古すぎる(または新しすぎる)場合に互換性エラーが発生し、システム全体が停止します。

3. テーマの不具合やプログラムの破損

使用しているWordPressテーマ内のプログラムにエラーが含まれている場合や、テーマの自動更新中に通信が切断されてファイルが破損した場合に画面が不通となります。親テーマと子テーマの連携設定の誤りや、推奨されるPHPバージョンとテーマの仕様不一致も要因となります。

4. PHPメモリ上限(Memory Limit)の到達

WordPressや導入されているプラグインが処理を実行するために必要なメモリ量が、サーバー環境で割り当てられている上限値(memory_limit)を超過した場合、処理が途中で打ち切られて画面が真っ白になります。高機能プラグインの併用や、画像の一括処理時に発生しやすい傾向があります。

5. サーバーのPHPバージョンアップによる非推奨コードの停止

レンタルサーバーの管理画面でPHPのバージョンをアップグレードした際、古いプラグインやテーマで使用されていた過去のPHP関数が廃止(Deprecated/Removed)されたことで、システムが停止するパターンです。

緊急時にまず行うべき初期対応と二次被害の防止

サイトが真っ白になった際、焦って管理画面やサーバー設定をむやみに変更すると、エラーの原因が複雑化したり、データベースを破損させたりする二次被害につながる恐れがあります。復旧作業に入る前に、以下の初期対応を行ってください。

1. ブラウザキャッシュの削除と別環境での表示確認

まず、表示不良が自分自身のブラウザキャッシュに起因するものでないかを確認します。ブラウザのシークレットモードでサイトにアクセスするか、別のデバイスや別回線からアクセスして、本当にサーバー側でエラーが発生しているかを確認してください。

2. バックアップデータの有無の確認

復旧作業を行う前に、最新のバックアップ(WordPressの全ファイルおよびデータベース)が存在するか確認します。作業手順を誤った場合でも、バックアップがあれば元の状態に戻せます。自社でバックアップを保存していない場合でも、レンタルサーバー会社の自動バックアップ機能が稼働しているかを確認しましょう。

バックアップの適切な保管方法や緊急時の復旧体制については、以下の解説記事も併せて参考にしてください。

WordPressサイトのバックアップ手順と復元方法|障害・改ざんに備える安全なデータ管理ガイド

3. 直前に行った変更作業の洗い出し

画面が真っ白になる直前に「どのような操作を行ったか」を正確に記録します。「プラグインを更新した」「functions.phpに追記した」「PHPのバージョンを変更した」などの直前操作を明確にすることで、復旧への最短ルートを特定できます。

デバッグモード(WP_DEBUG)を用いたエラー特定の具体手順

WordPressには、画面上に通常非表示となっているエラー内容を表示させたり、ログファイルに出力させたりするための「デバッグモード」が標準で用意されています。画面が真っ白な状態では原因が視覚的に判断できないため、まずはこのデバッグモードを有効化します。

1. FTPソフトまたはサーバーのファイルマネージャーで接続

FTPクライアント(FileZilla等)またはレンタルサーバーのコントロールパネル内にある「ファイルマネージャー」機能を使用し、WordPressがインストールされているルートディレクトリへアクセスします。

2. wp-config.php ファイルのダウンロードとバックアップ

ルートディレクトリに存在する「wp-config.php」ファイルをローカル環境に保存(バックアップ)した上で、テキストエディタで開きます。

3. WP_DEBUGの記述変更

ファイル内に以下のような記述があるか検索します。

define('WP_DEBUG', false);

この記述を次のように「true」へ変更します。記述が存在しない場合は、「/* 編集が必要なのはここまでです */」という行より上に追記します。

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

  • WP_DEBUG: デバッグモードを有効化(true)。
  • WP_DEBUG_LOG: エラー内容を /wp-content/debug.log に出力。
  • WP_DEBUG_DISPLAY: 画面上に直接エラーメッセージを表示。

4. エラーメッセージの読み解き

wp-config.phpを上書き保存してアップロードした後、再度ブラウザで真っ白になったページを再読み込みします。デバッグモードが有効であれば、画面または /wp-content/debug.log に以下のようなエラー文言が記録されます。

Fatal error: Uncaught Error: Call to undefined function... in /home/site/public_html/wp-content/plugins/sample-plugin/sample.php on line 42

この記述から、「Fatal error(致命的エラー)」「対象ファイル(sample-plugin)」「該当行数(42行目)」が明確に特定できます。

原因別の具体的な復旧手順と対処法

デバッグモードで特定した原因に応じて、以下の適切な復旧手順を実行します。

対処法1:プラグイン起因の場合(FTP経由での無効化)

特定したエラーの原因が特定のプラグインにある場合、WordPressの管理画面が開けなくてもFTP経由で該当プラグインを停止させることができます。

  1. FTPソフトで /wp-content/plugins/ ディレクトリへ移動します。
  2. エラーを出している対象プラグインのフォルダ名を探します(例: sample-plugin)。
  3. 対象フォルダの名前を変更します(例: sample-plugin_off)。
  4. 名前を変更すると、WordPressはそのプラグインを自動的に停止状態と判定します。
  5. サイトトップページにアクセスし、表示が解消されたか確認します。

どのプラグインが原因かわからない場合は、/wp-content/plugins フォルダ自体の名前を一時的に plugins_old に変更することで、全プラグインを一括で強制停止できます。

対処法2:テーマ起因の場合(デフォルトテーマへの切り替え)

使用中のテーマ内でエラーが発生している場合、テーマを標準の「Twenty Twenty-Four」などのデフォルトテーマに強制切り替えすることでサイトを表示させます。

  1. FTPソフトで /wp-content/themes/ ディレクトリへ移動します。
  2. 現在アクティブになっている使用中のテーマフォルダ名を変更します(例: my-theme_off)。
  3. WordPressはアクティブテーマが見つからない場合、自動的に存在するデフォルトテーマを読み込みます。
  4. サイトにアクセスし、表示が回復したか確認します。

対処法3:PHPメモリ上限不足の場合(Memory Limit緩和)

「Fatal error: Allowed memory size of xxx bytes exhausted」というエラーが出ている場合は、「wp-config.php」の「/* 編集が必要なのはここまでです */」の上あたりに、以下のコードを追加して上限を引き上げます。

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

サーバーの設定により反映されない場合は、サーバー管理画面から「PHP memory_limit」の値を増やすか、.htaccess ファイルに php_value memory_limit 256M と追記します。

対処法4:functions.php等のコード編集ミスの場合

「functions.php」の編集直後に真っ白になった場合は、FTP経由で該当ファイルをローカルに保存し、追加した記述を削除するか編集前のコードに戻して上書きアップロードします。管理画面の「テーマファイルエディター」での直接編集はわずかな記述ミスで即座にアクセス不能となるため、FTP経由での作業を推奨します。

対処法5:PHPバージョン互換性エラーの場合

サーバーのPHPバージョンを変更した直後に画面が真っ白になった場合は、レンタルサーバーの管理画面から元のPHPバージョンに戻すことで即座に復旧します。復旧後、古いプラグインの代替を探すか、テーマの改修を行ってから再度PHPをアップグレードします。

PHPバージョンの安全な変更手順と互換性確認の実務については、以下の記事で詳しく解説しています。

WordPressのPHPバージョンアップ手順と互換性エラー対策|安全な移行とトラブルを防ぐ手順をプロが解説

原因別対処法の一覧比較表

WordPressの画面が真っ白になった際の原因、主な発生タイミング、優先して実施すべき対処法、および復旧難易度を一覧表にまとめました。

原因・事象 主な発生タイミング 優先対処法 復旧難易度
プラグインの競合・エラー プラグインの追加・更新直後 FTPで該当プラグインフォルダ名を変更し強制停止 低
PHP構文エラー(Syntax Error) functions.php等のファイル編集直後 FTPでファイルを修正前の元の状態へ戻す 低〜中
テーマの不具合 テーマ更新・カスタマイズ直後 FTPでテーマ名を変更しデフォルトテーマへ切替 中
PHPメモリ上限超過 高機能プラグイン追加・画像処理時 wp-config.php等でWP_MEMORY_LIMITを引き上げ 中
PHPバージョン非互換 サーバーのPHPバージョン変更後 サーバー管理画面でPHPバージョンを一時的に差し戻す 低

今後の再発を防ぐためのWordPress保守運用ルール

無事に画面の真っ白(WSOD)が解消しサイトが復旧した後は、同様のトラブルが再発しないよう、日常の運用体制を見直すことが重要です。

1. WP_DEBUGの無効化(戻し忘れの防止)

復旧作業が完了したら、必ず「wp-config.php」の設定を元に戻します。

define('WP_DEBUG', false);

WP_DEBUGが true のまま放置されると、訪問者にサーバー内部のパスやエラー情報が表示されてしまい、セキュリティ上の脆弱性につながるため必ず false に戻してください。

2. テスト環境(検証環境)の構築と事前検証

本番環境で直接プラグインの更新やテーマコードの編集を行う運用は危険です。本番サイトと同一のデータを持つ「テスト環境(検証環境)」を用意し、プラグインのアップデートやコード変更は事前にテスト環境で実施してエラーがないことを確認してから本番に反映するフローを徹底します。

本番環境を守るテスト環境の活用手順については、以下の実務ガイドを参照してください。

ホームページ公開前のテスト環境(検証環境)確認方法とチェックリストをプロが解説

3. 自動バックアップ体制の確立と復元テスト

定期的なデータベースおよびファイルの全自動バックアップを設定しておきます。また、定期的に実際に別環境へデータを復元できるかテストを行うことが実務上重要です。

4. 不要なプラグインの整理と管理画面の定期メンテナンス

使っていないプラグインが多数放置されているサイトは、競合リスクや脆弱性のリスクが高まります。定期的にプラグインの見直しを行い、稼働していないプラグインは停止・削除してください。

管理画面の負荷軽減や定期メンテナンスの実務については、以下の記事を参考にしてください。

WordPress管理画面が重い・遅い原因と高速化手順|admin-ajax.phpやHeartbeat APIの負荷を軽減する実務対策

よくある質問

Q1. 管理画面(/wp-admin/)すら開けない場合はどうすればよいですか?

WordPressの画面真っ白障害が発生した場合、管理画面も同様にアクセスできないケースが多くあります。管理画面上からの操作は不可能ですので、レンタルサーバーのファイルマネージャー機能またはFTPソフト(FileZilla等)を用いて直接サーバー内のファイルを操作して復旧作業を行います。

Q2. FTP情報やサーバー情報が手元にない場合はどう対応すべきですか?

FTPのログイン情報が分からない場合は、ドメインやサーバーを契約しているレンタルサーバー会社(エックスサーバー等)の管理画面ログイン情報を確認してください。コントロールパネルにログインできれば、標準機能の「ファイルマネージャー」を使ってブラウザ上でファイル編集やプラグインフォルダ名の変更が可能です。情報が見当たらない場合は、サイトを構築した制作会社へ問い合わせてください。

Q3. WP_DEBUGをtrueのまま運用するリスクは何ですか?

WP_DEBUGを有効(true)にしたまま運用を続けると、小さな警告が発生した際にも画面上にサーバーの内部パスが表示され、悪意ある第三者に攻撃のヒントを与えるセキュリティリスクが生じます。また、debug.logファイルが蓄積され容量を圧迫することもあります。復旧後は必ず `define(‘WP_DEBUG’, false);` に戻してください。

Q4. 自社での復旧が難しい場合、どのような点に注意して外部へ依頼すべきですか?

自社内に技術者がいない場合やエラー原因が複雑で特定できない場合は無理に操作せず、Web制作会社や保守運用会社へスポット依頼することを推奨します。依頼時には「トラブル発生日時」「直前に行った操作(プラグイン更新など)」「利用中のサーバー名」の3点を伝えるとスムーズです。

まとめ

WordPressの画面が突然真っ白になる「White Screen of Death(WSOD)」は、主にPHP Fatal Error、プラグインの競合、テーマの記述ミス、PHPメモリ上限の不足などによって発生します。

トラブル発生時は以下の手順で対処します。

  1. むやみに設定を変更せず、直前の操作履歴を確認する
  2. FTPやファイルマネージャーで「wp-config.php」を開き、デバッグモード(WP_DEBUG)を有効化する
  3. エラーログ(debug.log)や画面表示から原因ファイルを特定する
  4. 原因に応じた対処(プラグイン停止、テーマ切替、コード修正、メモリ拡張)を実施する
  5. 復旧後はデバッグモードを無効化(false)に戻し、再発防止策を整える

イノベートスコープ株式会社では、大阪市中央区を中心に中小企業様のWordPressサイト制作・保守運用・緊急トラブルの復旧支援・セキュリティ対策をトータルでサポートしております。自社での復旧が困難な際はお気軽にご相談ください。

CONTACT

Web制作・SEO・AIOについてお気軽にご相談ください

ホームページ制作・リニューアル、WordPress、SEO・AIO対策、 ECサイト、Web集客、保守・セキュリティなど、 Webに関するご相談を承っています。 「何から相談すればよいかわからない」という段階でもお気軽にお問い合わせください。

お問い合わせフォーム