WordPressが真っ白になった原因と対処法｜安全な復旧手順

WordPressを開いても文字が出ず、真っ白な画面だけになる場合、PHPの処理が致命的なエラーで止まっている可能性があります。ただし、原因はプラグインだけとは限りません。テーマのコード、PHPバージョン、メモリ不足、キャッシュ、サーバー障害でも似た症状が起こります。

慌てて再インストールしたり、データベースを初期化したりする必要はありません。まず証拠を残して戻せる状態を作り、影響の小さい確認から順に進めます。この記事では、公開側と管理画面の状態、直前の操作、ログを手がかりに、WordPressの真っ白画面を安全に復旧する流れを説明します。

WordPressが真っ白になった直後にすること

最初に行うのは、変更を増やすことではなく、現在の状態を記録して復旧点を確保することです。真っ白な画面を何度も再読み込みする前に、発生時刻、開いたURL、直前に行った更新や編集、表示された文言を控えます。

次の順で初動を進めてください。

1. 公開側と管理画面を別々に開き、影響範囲を確認する
2. シークレットウィンドウや別端末でも同じか確かめる
3. サーバーの障害・メンテナンス情報を見る
4. 復旧メールとPHPエラーログを保存する
5. 現在のファイルとデータベースを退避する
6. 直前に変更したものから一つずつ戻す

バックアップは、正常だった時点へ戻すためだけではありません。調査前の状態を保存しておけば、フォルダー名や設定を誤って変えたときにもやり直せます。取得範囲と復元方法は「バックアップからの復元」で確認できます。

EC、予約、会員サイトでは、障害発生後にも注文や登録が入っている可能性があります。古いバックアップをすぐ上書きすると、その間のデータを失います。復元前に現在のデータベースも退避し、書き込みの扱いを決めてください。

真っ白画面の症状を切り分ける

同じ「真っ白」でも、発生する場所とタイミングで調べる順序が変わります。最初に次の表で症状を整理します。

症状	優先して確認する対象	補足
公開側だけ真っ白	有効テーマ、表示時だけ動くプラグイン、ページキャッシュ	管理画面から停止や切替を試せる
管理画面だけ真っ白	管理画面用プラグイン、権限、管理画面キャッシュ	別の管理者や直接URLでも確認する
公開側も管理画面も真っ白	PHP致命的エラー、メモリ、サーバー設定	復旧メールとログを優先する
特定ページだけ真っ白	テンプレート、ショートコード、該当データ	正常なURLとの違いを比べる
更新直後から発生	更新した本体、テーマ、プラグイン、PHP	更新名と版を記録する
ときどき発生	負荷、接続上限、外部API、キャッシュ	発生時刻とサーバーログを照合する

HTTPステータスも手がかりです。500番台ならサーバー側の処理失敗、403ならアクセス制限、503なら一時停止や過負荷の可能性があります。ただし、CDNやセキュリティ製品が独自画面を返すこともあるため、番号だけで原因を確定しません。

ブラウザに「このサイトで重大なエラーが発生しました」と出る場合、WordPressが致命的なPHPエラーを検知しています。完全な白画面と表示は違っても、調査対象が共通することがあります。ほかの代表的な症状との見分け方は「エラー全般の切り分け」で整理できます。

WordPressが真っ白になる主な原因

真っ白画面は、WordPressがページのHTMLを最後まで生成できなかった結果です。画面だけから原因を決めず、直前操作とログを組み合わせます。

主な原因は次のとおりです。

• 更新・新規導入したプラグインのPHPエラー
• 有効テーマやfunctions.phpの構文エラー
• WordPress、テーマ、プラグインとPHPの非互換
• PHPメモリ上限の超過
• wp-config.phpや.htaccessの誤記
• キャッシュに残った古いコードや不完全な生成物
• 更新中断によるファイル不足
• ファイル権限や所有者の不整合
• ホスティング側の障害や資源不足

データベースへ接続できない場合は、通常は専用のエラーメッセージが出ます。何も表示されない場合でも、ログに接続失敗が残ることはあるため除外はできません。まずは、プラグイン更新後、PHP変更後、コード編集後など、時間的に近い変更から確認します。

リカバリーモードで原因を確認する

WordPressのリカバリーモードは、通常のページ読み込みで致命的なPHPエラーを検知したとき、問題のあるプラグインやテーマを管理者の復旧セッションだけで一時停止し、管理画面へ入れるようにする機能です。WordPress 5.2から搭載されています。

管理者メールアドレスに届く「サイトで技術的な問題が発生しています」といった通知を探し、本文にある専用リンクからログインします。差出人だけで判断せず、リンク先が自分のサイトの正しいドメインか確認してください。ログイン後は通知に示されたコンポーネントを確認し、停止、更新、または安全な版への差し戻しを行います。

リカバリーモードで入れたら、次を記録します。

• エラーを起こしたプラグインまたはテーマ名
• エラーファイルのパスと行番号
• PHPエラーの種類とメッセージ
• 障害直前の更新版と変更時刻

修正後は公開側と管理画面を確認し、管理バーからリカバリーモードを終了します。専用リンクが期限切れ、メールが届かない、背景処理のエラーでモードが起動しない場合は、ファイル管理とログによる調査へ進みます。原因確認中に訪問者へ一時案内を出す考え方は「メンテナンスモードでの一時退避」で確認できます。

プラグイン・テーマを停止して復旧する

管理画面へ入れるなら、直前に更新・有効化したプラグインを一つ停止し、同じURLを確認します。すべてを一度に停止すると、どれが原因だったか分からなくなるため、候補が分かる場合は一つずつ試します。

管理画面へ入れない場合は、ホスティングのファイルマネージャーまたはSFTPで対象フォルダー名を一時変更します。たとえば、問題が疑われるプラグインのフォルダーだけに末尾を付け、WordPressから読み込まれない状態にします。全プラグインを調べる必要があるときは、pluginsフォルダー全体を一時的に改名して動作を確認し、元の名前へ戻してから個別に有効化します。

テーマが疑わしい場合は、有効テーマのフォルダー名を変える前に、利用できる標準テーマがインストール済みか確認します。代替テーマがなければ、自動切替できず別のエラーになる可能性があります。独自テーマの修正では、壊れたファイルだけを手元の正常な版またはバージョン管理の内容と比較します。

停止して表示が戻っても、それは原因候補を絞れた段階です。古い脆弱な版へ戻したまま運用せず、開発元の修正版、互換性、変更履歴を確認します。設定値を保持したい場合は、アンインストールではなく停止から始めてください。

PHPバージョン変更後に真っ白になった場合

PHPを変更した直後なら、WordPress本体が動作可能でも、古いテーマやプラグインのコードが新しいPHPでエラーになった可能性があります。サーバー管理画面で変更前のPHPへ戻せるなら、まず元の値へ戻して表示を回復させます。

復旧後は本番で再挑戦せず、ステージング環境で次を確認します。

1. WordPress本体、テーマ、プラグインを対応版へ更新する
2. 使用中の製品が更新先PHPをサポートするか公式情報で確認する
3. エラーログと非推奨警告を調べる
4. 表示、投稿、フォーム、決済、定期処理をテストする
5. 戻すPHPと手順を残してから本番を切り替える

PHP番号だけでなく、拡張モジュール、memory_limit、実行方式が変わっていないかも確認します。ホスティングによっては、ドメイン単位ではなくアカウント内の複数サイトへ変更が及びます。サーバー別の操作と確認項目は「PHPバージョンの戻し方」で詳しく確認できます。

functions.php・wp-config.php・.htaccess編集後の対処

ファイル編集の直後なら、編集前のコピーとの差分を戻すのが最短です。管理画面のテーマファイルエディターへ入れない場合でも、SFTPやファイルマネージャーから修正できます。

functions.phpでは、括弧やセミコロンの不足、関数名の重複、PHP開始タグの位置を確認します。コードを追加した位置だけでなく、エラーが指す行の直前も見ます。独自処理を丸ごと削除する前に、編集前ファイルを保存してください。

wp-config.phpでは、定数の引用符、真偽値、追記位置を確認します。デバッグを使う場合は、本番画面へエラーを表示せずログへ記録します。WordPress公式は、WP_DEBUGとWP_DEBUG_LOGを有効にし、WP_DEBUG_DISPLAYを無効にする構成を案内しています。調査後はデバッグを無効へ戻し、debug.logを公開状態で放置しません。

.htaccessを編集した直後なら、変更部分を戻します。WordPressが標準のパーマリンク規則を書き直せる環境では、管理画面のパーマリンク設定を保存し直す方法もあります。ただし、Basic認証、リダイレクト、セキュリティ制限など独自設定を上書きしないよう、必ず元ファイルを保存してから行います。

メモリ・キャッシュ・サーバー障害を確認する

真っ白画面が断続的に出る、重い処理だけ失敗する、更新後しばらくして再発する場合は、PHPメモリ、キャッシュ、サーバー資源を調べます。エラーログにAllowed memory size exhaustedがあればメモリ上限超過です。数値を無制限に増やすのではなく、どの処理が消費しているかを特定します。

キャッシュは複数層にあります。ブラウザ、WordPressのキャッシュプラグイン、サーバーキャッシュ、CDNを順に確認します。削除後に直るなら、更新時の自動パージや除外設定を見直します。キャッシュ削除そのものが原因修正になるとは限りません。

ホスティング側では、次の情報を同じ時刻で照合します。

• PHPエラーログとWebサーバーログ
• CPU、メモリ、プロセス数、ディスク容量
• PHP-FPMやWebサーバーの再起動履歴
• WAFやアクセス制限の記録
• 障害・メンテナンスのお知らせ

複数サイトが同時に開けない場合や、サーバー管理画面も不安定な場合は、WordPress内の変更を増やさずホスティングへ確認します。停止時間が売上や受付へ直結するサイトでは「緊急対応・保守サービス」に相談するための情報を先にそろえると、調査の重複を減らせます。

バックアップから復元する判断基準

復元は、原因調査より早い場合がありますが、復元時点より後のデータを失う可能性があります。次の条件がそろうかを確認して判断します。

判断項目	確認内容
正常時点	どの日時のバックアップなら障害前か
復元範囲	ファイル、DB、uploads、設定のどこを戻すか
差分	障害後の投稿、注文、会員、問い合わせをどう保全するか
原因	戻した後に同じ自動更新が再実行されないか
検証	復元前に別環境で展開して確認できるか

プラグインの一ファイルだけが壊れたなら、サイト全体を古い状態へ戻す必要はありません。反対に、更新が途中で止まり複数ファイルの整合性が崩れた、改ざんの範囲が分からない、変更履歴が追えない場合は、正常性を確認した保存世代へ戻す方法が適します。

復元前には現在の状態も保存します。原因を後から調べられ、障害後に増えたデータを取り出せるためです。復元後は表示だけでなく、ログイン、投稿、フォーム、定期処理、更新機能まで確認します。

自力で解決できない場合に伝える情報

ホスティングや保守担当へ連絡するときは、「真っ白です」だけでなく、再現条件と変更履歴を渡します。パスワードや秘密鍵をメール本文へ直接書かず、事業者が指定する安全な共有方法を使います。

伝える情報は次のとおりです。

• サイトURLと影響する画面
• 初回発生日時と現在も継続するか
• 公開側、管理画面、特定ページのどこで起こるか
• 直前に変更した本体、テーマ、プラグイン、PHP
• HTTPステータスとエラーメッセージ
• 該当時刻前後のログ
• 試した操作と、その前後で変わったこと
• 利用できるバックアップの日時と範囲

再現前にログを削除したり、複数の設定を同時に変えたりすると調査が難しくなります。実施した変更は時刻とともに残し、戻した操作も記録してください。

真っ白画面を防ぐための予防策

完全に防ぐことはできませんが、変更を小さく分けて戻せる状態にすると停止時間を短くできます。運用では次を習慣にします。

• ファイルとデータベースを定期的にバックアップする
• 復元テストを行い、保持期間と保存先を確認する
• 更新前にステージングで互換性を試す
• WordPress本体、テーマ、プラグイン、PHPを保守対象にする
• 一度に複数の大型変更を実施しない
• PHPエラーログと稼働監視を確認できるようにする
• 独自コードをバージョン管理し、本番で直接編集しない
• 不要なテーマとプラグインを整理する

自動更新を使う場合も、失敗通知、更新後の監視、戻し方が必要です。バックアップがあることと短時間で復旧できることは別なので、担当者と連絡経路も決めておきます。

よくある質問

まとめ

WordPressが真っ白になったら、最初に影響範囲、発生時刻、直前操作を記録し、現状のファイルとデータベースを退避します。続いて復旧メールとログを確認し、直前に変えたプラグイン、テーマ、PHP、コードを一つずつ戻すと、原因を絞りながら安全に復旧できます。

表示が戻っただけで終わらせず、原因となった製品の更新、互換性試験、監視、復元手順まで見直してください。古いバックアップの全面復元は差分データを失う可能性があるため、復元範囲と障害後の書き込みを確認してから実行します。