白い画面を戻す最初の操作は、プラグインを全部止めることです。管理画面に入れなければ plugins フォルダの名前を変えます。

公式の Common WordPress Errors は、白い画面の原因としてプラグイン、テーマの順に挙げています。日本語版の 一般的なエラー では「死の真っ白画面」という見出しになっています。

ファイルの名前を変える作業は元に戻せますが、削除や wp-config.php の書き換えは戻せません。サーバーの自動バックアップが何日分あるかを、触る前に見ておきます。ログイン画面は出るのにパスワードで止まるなら、管理画面にログインできないの手順に進みます。

Recovery Mode は WordPress 5.2 で入った機能です。通常のページ表示中に致命的なPHPエラーを検知すると、訪問者には技術的な問題が起きているという画面（英語版では "There has been a critical error on this website."）を出し、同時に管理者のメールアドレスへ、ログイン用のリンクとエラーの詳細を送ります。

1. メールのリンクを開き、ログインします。ログイン画面の上にリカバリーモードの案内が出ます。
2. ダッシュボードに、どのプラグインかテーマが止まったかの通知が出ます。問題の部品は、このログイン中だけ一時停止されています。
3. 「プラグイン」から該当のプラグインを停止します。テーマなら「外観」→「テーマ」で別のテーマに替えます。
4. 管理バーにある、リカバリーモードを終える操作（英語版は Exit Recovery Mode）を押し、公開ページが開くかを見ます。

このメールが届かない例も、公式に書かれています。メールの送り方を変えるプラグイン（SMTPプラグインなど）が読み込まれる前にエラーが起きると、メールはWebサーバーから直接送られ、迷惑メール扱いや配送拒否で届かないおそれがあるためです。届いていなければ、次のフォルダ改名に進みます。

管理画面に入れるなら、「プラグイン」の一覧で全部にチェックを入れ、まとめて「無効化」します。画面が戻ったら1つずつ「有効化」し、また白くなったものが原因です。

管理画面も白いなら、ファイルの側で止めます。

1. FTPソフトか、サーバーのファイルマネージャでサイトのフォルダを開きます。
2. wp-content の中の plugins を plugins_old に改名します。これで全部のプラグインが止まります。
3. 公開ページと /wp-admin が開くかを見ます。
4. 開いたら、フォルダ名を plugins に戻します。プラグインは無効のままなので、「プラグイン」から1つずつ有効化します。

原因の見当が付いているなら、そのプラグインのフォルダ（例: wp-content/plugins/hello-dolly）だけを改名しても止まります。公式のリカバリーモードの記事もこの方法を載せています。

公式は、新しいテーマを有効にした直後に白くなったらテーマを疑うよう書いています。管理画面に入れるなら、「外観」→「テーマ」で WordPress に同梱された Twenty で始まるテーマを有効にします。公式の例は Twenty Twenty-One です。Twenty Twenty-Two は WordPress 5.9 以上でないと動かない、と注記されています。

入れない場合は、wp-content/themes の中の、いま有効なテーマのフォルダ名を変えます。フォルダ名を元に戻しても、そのテーマは自動では有効になりません。直したあと「外観」→「テーマ」で選び直します。

白い画面のままでは、どこで止まったかが見えません。 Debugging in WordPress の定数を wp-config.php に書くと、エラーの内容が記録されます。書く位置は、編集をここで止めるよう書いたコメント行（英語版では That's all, stop editing!）より上です。

true と false は引用符で囲みません。公式によると、'false' と書くと true として扱われます。

公式は、デバッグを本番サイトで使わず、テスト環境で使うよう勧めています。公開中のサイトで使うなら、原因を読むあいだだけにします。wp-content はブラウザから開ける場所にあるので、debug.log は外から読まれるおそれがあります。読み終えたら定数を元に戻し、ログのファイルを消します。

ログにプラグインやテーマのフォルダ名が出ていれば、それを止めます。Allowed memory size of ... bytes exhausted と出ているなら、PHPのメモリが足りていません。Editing wp-config.php によると、WordPress は単一サイトで 40MB、マルチサイトで 64MB までメモリを上げようとします。WP_MEMORY_LIMIT を '96M' などにすると上限を変えられ、管理画面の作業には WP_MAX_MEMORY_LIMIT（例は '128M'）が使われます。ホストによっては自動で上げられないので、そのときはサーバー会社に頼みます。

PHPの版が古いことも、新しいプラグインが止まる原因の一つです。WordPress の動作環境は PHP 8.3 以上を推奨しています。PHP 7.4 以上でも動きますが、サポートが終わった版だと注記されています。

公式のWordPress Backupsによると、サイトを元に戻すにはファイルとデータベースの両方が要り、戻す順番はファイルが先、データベースが後です。

エックスサーバーは、Web・メールのデータとMySQLのデータベースを毎日自動で保存し、過去14日分を残しています（機能一覧、2026年11月1日時点）。白くなった日が15日以上前なら、この自動分では戻れません。復元の操作画面は、サーバー会社のマニュアルに従います。

戻したあとは、白くなる直前に更新したプラグインやテーマを、すぐには更新し直しません。1つずつ上げる順番はテーマ・プラグインを安全に更新するに書きました。

メンテナンス中の文（英語版は "Briefly unavailable for scheduled maintenance. Please check back in a minute."）が消えないのは、更新の途中で作られた .maintenance ファイルが残っているからです。公式は、FTPでサイトの一番上の階層からこのファイルを削除するよう案内しています。

Internal Server Error の原因として、公式は壊れた .htaccess を最初に挙げています。FTPで .htaccess を .htaccess_old に改名して、サイトを開き直します。開いたら、管理画面の「設定」→「パーマリンク設定」で保存すると、新しい .htaccess が作られます。

データベース接続確立エラーは、たいてい wp-config.php の誤りだと公式は書いています。データベース名、ユーザー名、パスワード、ホストの4つが、サーバーで作ったデータベースと一致しているかを見ます。設定が正しいなら、データベースの容量超過やサーバーの停止をサーバー会社に問い合わせます。

直ったと言えるのは、公開ページに本文が出て、/wp-admin にログインでき、原因の部品が止まったままになっていて、デバッグの定数を元に戻した状態です。