WordPressが真っ白になる原因（WSOD）と復旧までの流れ

WordPressの画面が突然真っ白になり、何も表示されなくなる現象はいわゆるWSOD（White Screen of Death）と呼ばれます。

私が初めてこの症状に遭遇したのは、テーマをカスタマイズした直後でした。

更新ボタンを押した瞬間に画面が真っ白になり、管理画面にも入れなくなりました。
この時の原因はPHPの記述ミスでした。

この記事では、WSODが発生する原因を一次情報ベースで整理し、実際に私が現場で行っている復旧手順を順序立てて解説します。

WSODとは何かを正しく理解する

経験者としてまずお伝えしたいのは、WSODは「表示できないほど重大なPHPエラー」が発生している状態だという点です。

私は当初、ブラウザの表示不具合だと思い込み、キャッシュ削除や別ブラウザ確認を繰り返しました。
しかし実際はサーバー側で致命的エラーが発生していました。
今振り返ると、「表示されない＝実行停止」と考えるべきでした。

WSODが発生する主な原因は以下です。

• PHPの構文エラー
• メモリ不足
• プラグインの競合
• テーマの不具合
• PHPバージョン非互換

WordPressはPHPで動作しています。

そのため、コードに致命的エラーがあると画面が出力されません。

エラーログには次のような記述が出ることがあります。

 PHP Parse error:syntax error, unexpected ';'

このようなログが出ている場合、構文エラーが確定します。
闇雲に触るのではなく、まずログを確認することが最優先です。

最初に行うべき安全な切り分け手順

私は現場では必ず「影響範囲が大きいものから止める」という順番で対応します。
一度に複数変更すると、どれが原因だったのか分からなくなるためです。

一つずつ検証することで原因の特定が迅速に行えます。

① プラグインを一括停止する

管理画面に入れない場合は、FTPで以下のフォルダ名を変更します。

 /wp-content/plugins → plugins_old

これで全プラグインが無効化されます。

表示が戻れば、原因はプラグインです。
その後フォルダ名を戻し、1つずつ有効化して原因を特定します。

私は過去に、バックアップ系プラグインの更新直後にWSODが発生しました。
そのため現在は必ず「最後に触った箇所」から疑って対応します。

② テーマをデフォルトへ切り替える

テーマのfunctions.phpに誤記述があると即座にWSODになります。

FTPでテーマフォルダ名を変更すると、自動でデフォルトテーマに切り替わります。
表示が戻れば、テーマに問題があります。

過去にエディタ設定の確認見落としにより、子テーマの記述を修正した際に全角スペースを混入させてしまったことがあります。
対策として現在は、コード編集時にUTF-8（BOMなし）を確認しています。

デバッグモードで原因を可視化する

WSODは情報が表示されないため、私は必ずデバッグモードを有効化します。

以前、ログを確認せずに推測で修正し、状況を悪化させたことがあります。
原因が見えない状態での修正は、判断を誤りやすいので気を付けてください。

wp-config.phpに以下を追記します。

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

これにより、/wp-content/debug.log にエラーが出力されます。
本番環境ではDISPLAYはfalseにすることが重要です。

メモリ不足への具体的対応

大規模テーマや重いプラグインを利用している場合、メモリ不足でWSODが発生します。

ECサイト構築時に画像処理でメモリを大量消費し、突然真っ白になる事例もあります。
対策として、wp-config.phpに以下を追加します。

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

それでも改善しない場合は、サーバー側上限を確認します。
phpinfoでmemory_limitの実効値を確認してください。

WordPress側だけ変更しても、サーバー側の制限で反映されていない場合があるので、設定値と実効値の違いを理解しておくことは大事です。

PHPバージョン非互換の確認

WordPressやテーマが最新でも、PHPバージョンが古いとWSODが起きます。

私は保守案件で、サーバー移転後にPHPバージョンが自動で変更されていたことに気づきませんでした。
変更履歴を確認していなかったことが原因です。それ以来、環境情報の記録を必ず残しています。

確認手順は次の通りです。

• サーバー管理画面でPHPバージョン確認
• WordPress推奨環境と照合
• テーマ・プラグイン要件確認

切り替え後は反映まで数分待ちます。

変更後、即時反映されないので、反映されていないからと何度も繰り返さないように注意しましょう。

.htaccessとファイル権限の確認

私はWSODの切り分けで、プラグインやテーマに問題が見当たらない場合、.htaccessとファイル権限を確認します。

まずは.htaccessを一時的にリネームします。

 .htaccess → .htaccess_old

これで表示が戻る場合、.htaccessの内容が原因です。

WordPressの基本記述は以下です。

# BEGIN WordPress
RewriteEngine On RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L] # END WordPress

管理画面に入れる場合は、パーマリンク設定を保存し直すことで再生成されます。

また、ファイル権限が不適切な場合もWSODが発生します。
一般的な推奨値は以下です。

• ディレクトリ：755
• ファイル：644

私は一度、FTPソフトの設定ミスで権限を777に変更してしまいました。
表示は復旧しましたが、セキュリティリスクが高い状態でした。

なぜ777にしたかというと「とりあえず動けばよい」と考えたからです。
しかし本質的な原因を確認していなかったことが問題でした。

現在は必ず推奨値へ戻し、原因を別で特定する方針にしています。

コアファイル破損と再アップロード手順

WordPress本体ファイルが破損している場合もWSODが発生します。

私はサーバー移行作業中に転送エラーが発生し、一部ファイルが欠損した状態で公開してしまった経験があります。
原因はコアファイル読み込みエラーでした。以降、ファイル数の照合は必ず行っております。

対応手順は以下です。

• 公式サイトから同バージョンのWordPressをダウンロード
• wp-contentフォルダとwp-config.php以外を上書きアップロード
• 再表示確認

この方法で、データベースやメディアは保持したままコアのみ再構築できます。

私は最初、全削除して再インストールしようと考えました。
しかしデータ消失リスクを考え直し、上書き方式を選びました。

今ではデータを触らず構造だけ修復するという判断を優先しています。

サーバーエラーログの具体的な読み方

WSOD対応で最も重要なのはエラーログです。

私は以前、ログの意味を深く理解せず表面的に読んでいましたが、結果として本質的な原因を見逃していました。

現在は必ずエラー種別を分類してから対応します。

代表的なエラー例

 PHP Fatal error: Call to undefined function

→ 関数が存在しないため、プラグインまたはPHPバージョン非互換の可能性があります。

 Allowed memory size exhausted

→ メモリ不足です。

 Cannot redeclare function

→ 関数の重複定義です。

ログを見る際の判断軸は以下です。

• Fatal errorかWarningか
• どのファイルで発生しているか
• 直前の変更内容と一致しているか

エラー文だけに反応するのではなく、エラー前後数行などから文脈を読むことが重要です。

FAQ

Q1. 管理画面だけ真っ白になります。

テーマではなくプラグインの可能性が高いです。
特に管理画面拡張系を疑います。FTPで個別フォルダをリネームして確認してください。

Q2. フロントだけ真っ白です。

テーマのfunctions.phpやテンプレートファイルを確認します。
直前に追加したコードをコメントアウトしてください。コード単位で確認する姿勢が重要です。

Q3. バックアップがありません。

まず現状を保全してください。不用意な削除は避けます。
ログ取得とフォルダ複製を行ってから作業をしましょう。焦って上書きすると復元不能になる場合があります。

まとめ

WSODは突然発生しますが、必ず原因があります。
私は現在、次の順序で対応します。

• エラーログ確認
• プラグイン停止
• テーマ確認
• メモリ・PHP確認
• .htaccess確認
• コア上書き

重要なのは一度に複数箇所を変更しないことです。

WSODは恐ろしい現象に見えますが、冷静に切り分ければ必ず復旧できます。
まずはログを確認し、直前の変更を洗い出してください。そして一つずつ検証してください。

それが最短で確実な復旧への道です。