【最短5分】WordPressの画面が真っ白（WSOD）になった時の原因別切り分けと主要サーバー別復旧ガイド

WordPressでWebサイトやブログを運営している際、ある日突然ブラウザの画面が真っ白になり、エラーメッセージすら表示されずに何も操作できなくなってパニックになったことはありませんか？

この現象は、世界中のWordPressエンジニアやサイト運営者の間で「WSOD（White Screen of Death：死の白画面）」と呼ばれ、最も遭遇頻度が高く恐れられている代表的なクラッシュ現象の一つです。エラー文が一切画面に出力されないため「データが全消去されたのではないか」「ハッキングでサイトが破壊されたのでは」と焦ってしまいがちですが、決して絶望する必要はありません。適切な原因の切り分け手順と復旧手順さえ知っていれば、蓄積した投稿データや画像資産を失うことなく、最短5分〜15分程度で安全に復旧させることが可能です。

WordPressの画面が真っ白になる根本的な要因は、裏側でPHPの致命的なエラー（Fatal Error）や構文エラー（Parse Error）が発生し、HTMLを描画する処理が強制中断されたことにあります。具体的には、直前のfunctions.php等のプログラム編集ミス、プラグインやテーマの競合・不具合、PHPメモリ上限（memory_limit）の枯渇、PHPバージョンアップに伴う非互換などに集約されます。

本ガイドでは、緊急事態に直面しているWeb担当者やサイト管理者が迷わず最短でサイトを復旧できるよう、直前の行動から原因を5秒で判定する「症状別切り分けフローチャート」を冒頭に提示します。さらに、FTPソフトが手元にない初心者でもブラウザだけで解決できる国内4大レンタルサーバー別（エックスサーバー・ConoHa WING・さくらのレンタルサーバ・ロリポップ！）のファイルマネージャー復旧手順、基本の最短復旧5ステップ、WP_DEBUGを有効化しても画面が白いままの落とし穴解消法、phpMyAdminを使ったプラグイン強制停止の裏技、そして再発を防ぐ安全な運用体制まで徹底的に解説します。

【最短診断】WordPress画面真っ白（WSOD）の症状別切り分けフローチャート

画面が真っ白になった直後は、焦ってあれこれ設定を変更すると二次障害を引き起こし、復旧が困難になるリスクがあります。まずは深呼吸をして、「サイトがどのような状態で真っ白になっているか」と「真っ白になる直前に何をしたか」を整理してください。

以下のマトリクス判定表を参照することで、今あなたが取るべき最短の復旧アクションが一目で分かります。

現在の症状	直前の操作・トリガー	最も疑われる原因と最短復旧アクション
公開側・管理画面の両方が真っ白	functions.php、style.css、テーマのテンプレート等を直接編集・保存した	【コード記述ミス（構文エラー）】全角スペースの混入、セミコロン抜け、PHP閉じタグ（`?>`）後の不要改行などが原因です。FTPまたはファイルマネージャーで当該ファイルを開き、直前の修正箇所を元に戻すかバックアップで上書きします。（後述の「基本ステップ2」へ）
公開側・管理画面の両方が真っ白	プラグインを新規追加・有効化した、または既存プラグインを一括更新した	【プラグイン競合・致命的エラー】追加・更新したプラグインが他プラグインやテーマと競合しています。FTPまたはファイルマネージャーで `wp-content/plugins` フォルダを一時リネームして全停止させるか、当該プラグイン単体のフォルダをリネームして無効化します。（後述の「基本ステップ3」へ）
公開側・管理画面の両方が真っ白	サーバーパネルでPHPバージョンを切り替えた（PHP 8.1 / 8.2 / 8.3等へ変更）	【PHPバージョン非互換】利用中のテーマや古いプラグインが新しいPHPの厳格な文法に対応しておらずFatal Errorが発生しています。サーバーパネルで元のPHPバージョンへ一旦差し戻すか、メモリ上限引き上げ（後述の「基本ステップ5」）を実施します。
管理画面（/wp-admin/）だけが真っ白（公開サイトは正常に閲覧可能）	ログインしようとした、管理画面で設定変更した、何もしていない	【管理画面メモリ枯渇・認証Cookie不整合・セキュリティプラグイン】ブラウザのCookie・キャッシュ削除（シークレットウィンドウ確認）、WordPressリカバリーモードのメール確認、または `wp-config.php` での `WP_MAX_MEMORY_LIMIT` の引き上げ（512M）を実施します。（後述の「管理画面専用対処法」へ）
公開側だけが真っ白（管理画面には正常にログイン可能）	テーマを切り替えた、ウィジェットを編集した、プラグインを更新した	【フロントエンド描画処理の停止】管理画面の「プラグイン一覧」から直近更新したプラグインを1つずつ無効化してリロードするか、「外観」＞「テーマ」で公式デフォルトテーマ（Twenty Twenty-Four等）へ一時切り替えを行います。
何も変更していないのに突然真っ白	直前にサイトの変更や編集作業は一切行っていない	【自動更新失敗・サーバー障害・ディスク容量超過】 WordPress本体・プラグインのバックグラウンド自動更新中の通信切断、サーバー会社の緊急メンテナンス・障害、またはサーバーのディスク容量100%枯渇が疑われます。サーバーの稼働状況を確認し、エラーログを確認します。

自分の状況に当てはまる項目が見つかったら、該当する復旧ステップへ直接進んで作業を開始してください。原因の当たりがつかない場合は、次の「原因一覧」と「基本ステップ1（WP_DEBUG有効化）」から順番に進めることで確実に解決できます。

WordPressの画面が真っ白（WSOD）になる主な原因一覧

Webサイトがブラウザ上に表示される際、WordPressはサーバー上でPHPプログラムを実行し、データベースから記事データを取得してHTMLを組み立てて出力します。しかし、このプログラム実行の途中で「これ以上処理を継続できない致命的なエラー（PHP Fatal Error / Parse Error）」が発生すると、PHPエンジンの処理が強制中断されます。

一般的な開発環境であればエラーメッセージ（スタックトレース）が画面上に赤字で表示されますが、WordPressはセキュリティ保護のため（サーバー内部パスやDB構造などの機密情報を第三者に漏洩させないため）、本番環境ではデフォルトでエラー表示を抑制（非表示）にする仕様になっています。その結果、何もHTMLが出力されず、ブラウザには真っ白な画面だけが返されるのです。

WSODを引き起こす代表的な6大原因と発生メカニズムを整理しました。

主な原因	具体的な発生状況・トリガー	影響範囲とエラーのメカニズム
1. functions.php・テーマの構文ミス	管理画面のテーマファイルエディターやFTPでの直接コード編集、全角スペース、構文ミス	PHPの文法チェックで即座に中断（Parse Error / Syntax Error）。コード保存の瞬間に即時発症し、管理画面・公開側の両方が落ちることが多い。
2. プラグイン同士の競合・不具合	新規プラグイン有効化、複数プラグインの一括更新、同一機能プラグインの重複	同一の関数名やクラス名が二重定義される競合（Cannot redeclare error）や、未定義関数の呼び出し（Call to undefined function）でFatal Errorが発生。
3. PHPメモリ上限（memory_limit）不足	大量プラグインの同時稼働、Elementor等の高機能ビルダー、画像一括リサイズ、バックアップ実行時	PHPに割り当てられたメモリ上限（例: 128MB）を超過した瞬間に `Allowed memory size of ... bytes exhausted` エラーでプロセスが強制停止。
4. PHPバージョンアップに伴う非互換	サーバー管理画面でPHP 7.4/8.0からPHP 8.2/8.3等へバージョンアップした直後	PHP 8系で廃止・非推奨（Deprecated）となった古い関数や引数の型チェック厳格化により、未改修の古いプラグイン・テーマがFatal Errorを引き起こす。
5. 自動更新失敗によるコアファイル破損	本体・プラグインの自動更新実行中にサーバー負荷や通信遮断、タイムアウトが発生	更新処理が中途半端に中断され、必須ファイルが欠落または0バイト化して `require_once` で読み込めずクラッシュ。
6. WAF（Web Application Firewall）による遮断	サーバーパネルでのセキュリティ機能有効化、特定リクエストの誤検知	プラグインの設定変更やPOST通信がSQLインジェクションやXSSと誤判定され、サーバー側で通信が遮断されて白画面または403/500応答となる。

特に近年増加しているのが、PHP 8.2および8.3へのアップデートに伴うWSODトラブルです。従来のPHP 7系では警告（NoticeやWarning）として処理が継続されていたコードが、PHP 8系では厳格なエラー判定によりFatal Errorへ昇格し、突然サイト全体が真っ白になる事例が多発しています。また、レンタルサーバー標準のWAFによる誤検知も増えています。

【主要サーバー別】管理画面・ファイルマネージャーからのWSOD緊急復旧手順

WordPressの画面が真っ白になると、「FTPクライアントソフト（FileZillaなど）をダウンロードしてサーバーに接続しなければならない」と思い込んでいる方が非常に多くいらっしゃいます。しかし、FTPソフトの操作に不慣れな場合、接続設定でつまずいて余計に時間を消費してしまいます。

国内の主要レンタルサーバー（エックスサーバー、ConoHa WING、さくらのレンタルサーバ、ロリポップ！）であれば、Webブラウザ上の管理画面（コントロールパネル）に標準搭載されている「ファイルマネージャー機能」を使うだけで、FTPソフトを一切使わずに最短3分で復旧作業が完了します。

ここでは、各社サーバーごとの「ファイルマネージャーでのプラグイン強制停止（フォルダリネーム）」「php.iniでのメモリ上限引き上げ」「エラーログ（error.log）の確認場所」を画像なしでも迷わないステップ形式で解説します。

エックスサーバー：ファイルマネージャでのプラグイン停止・php.ini編集とエラーログ確認

エックスサーバーは、ブラウザ専用の「ファイルマネージャ（WebFTP）」が非常に使いやすく整備されています。

1. ファイルマネージャで全プラグインを一括強制停止する手順

エックスサーバーの「サーバーパネル」にログインします。
トップページの右上または「ファイル」項目にある「ファイルマネージャ」をクリックして別タブで起動します。
フォルダ一覧から、該当サイトの「対象ドメイン名フォルダ」＞「public_html」＞「wp-content」の順にダブルクリックして開きます。
一覧の中にある「plugins」フォルダにチェックを入れ、画面上部メニューの「ファイル名の変更（リネーム）」をクリックします。
フォルダ名を plugins_backup に変更して決定します。これでWordPress上の全プラグインが強制停止され、サイトや管理画面が即座に表示されるようになります。
管理画面に入れたら、ファイルマネージャでフォルダ名を plugins に戻し、管理画面から1個ずつプラグインを有効化して原因を特定します。

2. サーバーパネルから php.ini の memory_limit を引き上げる手順

サーバーパネルの「PHP」カテゴリにある「php.ini設定」をクリックします。
対象ドメインを選択し、「php.ini設定変更」タブを選択します。
「その他の設定」または項目一覧から memory_limit を探し、標準値（128Mなど）から 256M または 512M に書き換えて「確認画面へ進む」＞「設定する」をクリックします。

3. エラーログ（error.log）を確認してクラッシュ原因を特定する手順

サーバーパネルの「アクセスログ」＞「ログファイル」をクリックします。
対象ドメインを選択し、「エラーログ」のダウンロードボタンをクリックします。
ダウンロードした ドメイン名.error_log をテキストエディタで開き、末尾の行を確認します。PHP Fatal error: ... in /home/.../wp-content/plugins/... と書かれた行があれば、それが白画面を引き起こした直接の原因ファイルです。

ConoHa WING：ファイルマネージャーでのフォルダリネームとWAF除外・ログ確認

ConoHa WING（コノハウィング）は、直感的なUIのファイルマネージャーと強力なセキュリティ機能（WAF）が特徴です。

1. ファイルマネージャーでプラグインフォルダをリネームする手順

ConoHaコントロールパネルにログインし、左側メニューの「サイト管理」をクリックします。
左側のサブメニューから「ファイルマネージャー」をクリックして起動します。
左側ツリーから 「public_html」＞「対象ドメイン」＞「wp-content」 と展開します。
「plugins」フォルダを右クリックし、「名前変更（リネーム）」を選択します。
フォルダ名を plugins_temp などに変更して保存します。これでサイトが復旧します。

2. WAFの誤検知ブロックを確認して除外する手順

ConoHa WINGでは、プラグインの設定更新やカスタマイズ保存時にWAF（Webアプリケーションファイアウォール）が攻撃と誤認して遮断し、画面が真っ白（または403エラー）になるケースが非常に多いです。

コントロールパネル「サイト管理」＞「サイトセキュリティ」を開きます。
「WAF」タブを選択します。
「ログ」一覧を確認し、画面が真っ白になった時刻と一致する検知ログ（攻撃種別: SQLiやXSS等）があるか確認します。
一致するログがある場合は、右側の「除外」ボタンをクリックします。これで当該プラグインの処理が遮断されなくなり、正常動作するようになります。

3. ConoHa WINGでのエラーログ確認手順

「サイト管理」＞「サイト設定」＞「ログ使用状況」を開きます。
「エラーログ」の右側にあるダウンロードアイコンをクリックしてログファイルを取得し、直前のFatal Error行を確認します。

さくらのレンタルサーバ：ファイルマネージャーでの復旧とphp.iniのmemory_limit設定

さくらのレンタルサーバ（新コントロールパネル）でも、ブラウザ上で全ファイルの管理とphp.iniの自由記述が可能です。

1. ファイルマネージャーでプラグインフォルダをリネームする手順

さくらのレンタルサーバ「コントロールパネル」にログインします。
左メニューの「Webサイト/ドメイン」＞「ファイルマネージャー」をクリックします。
サイトの公開ディレクトリ（通常は /home/ユーザー名/www/ またはサブフォルダ）に移動し、wp-content フォルダを開きます。
plugins フォルダを右クリック（またはチェックを入れて「操作」）し、「名前の変更」で plugins_bk に変更します。

2. php.ini設定で memory_limit を引き上げる手順

コントロールパネルの左メニュー「スクリプト設定」＞「php.ini設定」をクリックします。
テキスト入力エリアに、以下の1行を追記（すでに記述がある場合は数値を修正）します。

memory_limit = 256M

「保存する」ボタンをクリックすれば、即座にPHP実行メモリ上限が256MBに引き上げられます。

3. エラーログの確認手順

コントロールパネルの「アクセスログ閲覧」＞「エラーログ」から直近のエラーログを閲覧・ダウンロードできます。さくらではルート上の /home/ユーザー名/log/ 配下に php_error.log やウェブサーバーエラーログが出力されます。

ロリポップ！：ロリポップ！FTPでの緊急処置とPHP設定

ロリポップ！では、専用Webファイル管理ツール「ロリポップ！FTP」が標準装備されています。

1. ロリポップ！FTPでのプラグイン強制停止手順

ロリポップ！の「ユーザー専用ページ」にログインします。
左メニューの「サーバーの管理・設定」＞「ロリポップ！FTP」をクリックします。
WordPressをインストールしている公開フォルダ（ドメイン設定で指定した公開アップロードフォルダ）を開き、「wp-content」フォルダに入ります。
「plugins」フォルダの行にある鉛筆アイコン（編集）またはフォルダ名をクリックします。
フォルダ名を plugins_disabled に書き換えて「保存する」をクリックします。

2. PHP設定とphp.iniの調整手順

ユーザー専用ページの左メニュー「サーバーの管理・設定」＞「PHP設定」をクリックします。
対象ドメインの「設定」ボタンをクリックします。
php.iniの項目一覧が表示されるので、display_errors を「On」に一時変更してエラー内容を画面に出すか、memory_limit を標準の128Mから 256M または 512M にプルダウン変更し、「保存する」をクリックします。

【最短復旧】真っ白になった画面を直す基本の5ステップ

レンタルサーバーのファイルマネージャー、またはFTPソフト（FileZilla等）を用いて、実際に真っ白な画面を復旧させるための基本5ステップを順を追って解説します。1ステップ進めるごとにブラウザをリロード（再読み込み）し、サイトが復旧した時点で以降の作業は不要です。

なお、画面が真っ白ではなく「このサイトで重大なエラーが発生しました」というメッセージが表示されている場合は、同様にPHPエラーが発生しています。詳しい手順はWordPress「このサイトで重大なエラーが発生しました」の原因特定と直し方完全ガイドもあわせてご覧ください。

ステップ1：デバッグモード（WP_DEBUG）を有効にしてエラーログを確認

真っ白な画面を直す上で最優先に行うべきは、「何が原因でPHPがクラッシュしているのか」をエラーメッセージとして可視化することです。WordPressには標準でデバッグ機能が搭載されており、設定ファイルである wp-config.php を編集するだけでエラーの詳細が判明します。

FTPソフトまたはサーバーのファイルマネージャーで、WordPressのルートディレクトリ（public_htmlなど）にアクセスします。
ルート直下にある wp-config.php をローカルにダウンロードしてバックアップを取ります。
テキストエディタで wp-config.php を開き、define('WP_DEBUG', false); と書かれている行を探します。
以下のようにコードを書き換えて保存し、サーバーへ上書きアップロードします。

// デバッグモードを有効化（エラーを画面に表示し、debug.logファイルにも保存する設定）
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors', 1);

/* 編集が必要なのはここまでです ! WordPress でのコーディングをお楽しみください。 */

【超重要注意点】記述位置について
このデバッグ用コードは、必ず wp-config.php の下部にある /* 編集が必要なのはここまでです ! ... */（または /* That's all, stop editing! Happy publishing. */）および require_once ABSPATH . 'wp-settings.php'; よりも上に記述してください。これらの記述より下に書いた場合、定数が読み込まれずデバッグ機能が作動しません。

アップロード後に再度サイトや管理画面をリロードすると、真っ白だった画面に エラーメッセージ（Fatal errorやParse error） が表示されるか、wp-content/debug.log というファイルにエラー内容が記録されます。

エラー文の末尾にあるファイルパス（例: /wp-content/plugins/contact-form-7/... on line 125）を確認することで、「どのプラグインの何行目」「どのテーマのファイル」が原因なのかが一撃で判明します。なお、HTTP 500番台のエラーレスポンスが返っている場合は、【図解】WordPressの500エラー（Internal Server Error）原因と直し方も併せて参考にしてください。

ステップ2：直前に編集した functions.php やテーマファイルの復元・修正

「管理画面のテーマエディターで functions.php を編集して保存ボタンを押した瞬間に画面が真っ白になった」というケースは、WSODの典型例です。PHPは文法エラー（Parse Error / Syntax Error）に対して非常に厳格なため、わずか1文字のミスでもページ全体の描画を即座に停止させます。

よくあるミスの例と修正ポイントは以下の通りです。

全角スペースの混入: コードのインデントや空行に全角スペースが含まれていると構文エラーになります。テキストエディタの不可視文字表示機能を有効にして全角スペースを半角スペースまたはタブに置換してください。
セミコロン（;）やカッコの閉じ忘れ: 行末のセミコロン抜けや、波括弧 {}、丸括弧 () のペアが一致していない箇所を確認します。
末尾のPHP閉じタグ（?>）による不要な余白: functions.php の末尾に ?> を記述していると、その直後に意図しない改行や空白（BOM）が混入し、ヘッダー送信エラーや白画面の原因になります。WordPressのPHPファイルでは、ファイル末尾の ?> は書かずに省略するのが公式コーディング規約のベストプラクティスです。

【復元手順】
FTPまたはファイルマネージャーで /wp-content/themes/【利用中のテーマ名】/functions.php を開き、直前に追加したコードを丸ごと削除するか、編集前のバックアップファイルで上書き保存してください。これだけで即座に画面が表示されるようになります。

ステップ3：全プラグインの一括無効化（FTPまたはファイルマネージャー経由）

「テーマファイルは編集していないのに突然真っ白になった」「プラグインをアップデートしたら動かなくなった」という場合は、プラグインの不具合や競合が最も疑われます。

管理画面にログインできない状態でも、サーバー上のフォルダ名を変更することで、全プラグインを一括で安全に強制停止できます。

FTPソフトまたはファイルマネージャーで /wp-content/ ディレクトリに移動します。
plugins というフォルダ名を、一時的に plugins_backup（または plugins_old）に変更します。
ブラウザでサイトや管理画面（/wp-admin/）にアクセスします。WordPressはフォルダが見つからないプラグインを自動的に全件無効化するため、プラグイン起因のエラーであれば即座に画面が表示されるようになります。
フォルダ名を元の plugins に戻します。この時点では、各プラグインはデータベース上で「停止状態（無効化）」のまま保持されます。
管理画面の「プラグイン」＞「インストール済みプラグイン」を開き、プラグインを 1つずつ順番に「有効化」 していき、どのプラグインを有効にした瞬間に画面が真っ白になるかを特定します。

原因のプラグインが特定できたら、そのプラグインを無効化したまま代替プラグインを探すか、プラグイン作者へ不具合報告を行う、または前バージョンの安定版プラグインへロールバック（切り戻し）を行います。

ステップ4：デフォルトテーマ（Twenty Twenty-Four等）への一時切り替え

プラグインを全て停止しても真っ白な画面が改善しない場合は、現在有効化されているテーマ自体（または親テーマ・子テーマ）に深刻なエラーが存在しています。

FTPやファイルマネージャーを使ってテーマをWordPress公式のデフォルトテーマ（Twenty Twenty-FourやTwenty Twenty-Threeなど）に一時的に強制切り替えします。

/wp-content/themes/ にアクセスします。
現在使用している有効テーマのフォルダ名（例: my-theme）を、my-theme_disabled などにリネームします。
WordPressは現在のテーマが見つからない場合、同ディレクトリ内にある公式デフォルトテーマ（Twenty Twenty-Four等）へ自動的にフォールバック（切り替え）します。
サイトを再読み込みし、画面が表示されればテーマ内のプログラム（テンプレートファイルやstyle.cssの読み込みエラー等）が原因と確定できます。子テーマを使っている場合は親テーマの更新不具合も疑ってください。

ステップ5：PHPメモリ上限（memory_limit）の引き上げ

「特定の大規模プラグイン（WooCommerceやElementor、バックアッププラグイン等）を有効化すると真っ白になる」「特定の固定ページや管理画面の重いページだけ真っ白になる」という場合、PHPのメモリ上限（memory_limit）の枯渇が原因です。

WordPressの初期設定ではメモリ上限が40MB〜64MB程度に制限されていることがあり、高機能テーマやプラグインが増えると簡単に上限を突破してしまいます。また、PHPバージョンとの兼ね合いもありますので、詳しくはWordPressの推奨PHPバージョンと確認・変更手順も確認してください。

メモリ上限を 256MBまたは512MB に引き上げるには、以下のいずれかの方法を実施します。

方法A：wp-config.php に追記する（最も確実・推奨）

// 一般ページのPHPメモリ上限を256MBに設定
define('WP_MEMORY_LIMIT', '256M');

// 管理画面のPHPメモリ上限を512MBに設定
define('WP_MAX_MEMORY_LIMIT', '512M');

※こちらも /* 編集が必要なのはここまでです ! ... */ より上に記述してください。

方法B：.htaccess に追記する（Apache環境の場合）

php_value memory_limit 256M

※サーバーのPHP動作モード（CGI版・PHP-FPM版など）によっては、.htaccess に php_value を書くと「500 Internal Server Error」が発生する場合があります。その場合は直ちに記述を削除し、方法Aまたは方法Cを採用してください。

方法C：レンタルサーバーのコントロールパネル（php.ini設定）で変更する
前述の「主要サーバー別手順」を参考に、エックスサーバーやConoHa WING、さくらのコントロールパネルから memory_limit = 256M（または512M）に設定変更してください。

WP_DEBUGを有効化してもエラーが出ない時の3つの落とし穴と対処法

「ステップ1に従って wp-config.php で define('WP_DEBUG', true); に書き換えたのに、画面が真っ白のままでエラーメッセージが何も表示されない！」というトラブルに直面する方は非常に多くいらっしゃいます。

デバッグモードが効かない・画面に出力されない代表的な3つの落とし穴と、その確実な解決策を解説します。

落とし穴1：サーバー側の display_errors がOffに強制固定されている

レンタルサーバーのセキュリティポリシーによって、Webサーバー全体のPHP設定で display_errors = Off が強制固定されており、WordPress側の ini_set('display_errors', 1); が無視されているケースです。

【解決策】
画面上にエラーを無理に表示させようとするのではなく、ログファイル出力（debug.log）を活用します。wp-config.php に以下を設定します。

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

この設定を保存してサイトを再度リロードすると、画面は白いままですが、サーバー上の /wp-content/debug.log というテキストファイルの中にすべてのエラー内容が詳細に追記・記録されます。ファイルマネージャーやFTPでこのファイルを開けば、クラッシュの原因行を正確に特定できます。

落とし穴2：サーバーキャッシュやCDN、ブラウザが白画面レスポンスを保持している

エックスサーバーの「Xアクセラレータ」やConoHa WINGの「コンテンツキャッシュ」、あるいはCloudflare等のCDN（Content Delivery Network）、そしてブラウザ自身の強力なキャッシュ機能が、「以前発生した真っ白なHTTPレスポンス」を静的キャッシュとして保持してしまい、サーバー側で修正した後も古い白画面を返し続けているケースです。

【解決策】

ブラウザキャッシュのバイパス: キーボードの Ctrl + F5（Macは Cmd + Shift + R）でスーパーリロードを実行するか、ブラウザの「シークレットウィンドウ（プライベートブラウズ）」でアクセスします。
サーバーキャッシュのクリア: サーバー管理画面（エックスサーバーなら「高速化」＞「Xアクセラレータ設定」のキャッシュ削除、ConoHaなら「サイト管理」＞「サイト設定」＞「応用設定」のコンテンツキャッシュクリア）から全キャッシュをパージ（削除）します。
URLパラメータを付与して確認: https://example.com/?test=1 のように末尾にランダムなクエリパラメータを付与してアクセスすると、キャッシュ層をバイパスして最新のサーバー処理結果を確認できます。

落とし穴3：wp-config.php の記述位置ミス（停止コメントより下に書いている）

最も初歩的でありながらエンジニアでも見落としがちなのが、wp-config.php 内の記述順序のミスです。

wp-config.php の下部には、必ず以下のような記述が存在します。

/* 編集が必要なのはここまでです ! WordPress でのコーディングをお楽しみください。 */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

最後の行にある require_once ABSPATH . 'wp-settings.php'; でWordPressのコア初期化処理がすべて実行されます。そのため、この行よりも下に define('WP_DEBUG', true); や define('WP_MEMORY_LIMIT', '256M'); を追記しても、WordPressの起動処理がすでに完了しているため完全に無視されます。

設定定数は、必ず /* 編集が必要なのはここまでです ! ... */ よりも上部に記述されているかを再確認してください。

【裏技】FTPが使えない時にphpMyAdminから全プラグインを強制停止する方法

「FTP接続情報が手元になく、ファイルマネージャーの操作権限もない」「サーバーのファイルシステムにアクセスできないが、データベース（phpMyAdmin）のログイン情報だけはある」という緊急事態に役立つ、データベース直接操作による全プラグイン強制停止の裏技を解説します。

WordPressは、有効化されているプラグインの一覧情報をデータベースの wp_options テーブル内にシリアライズ（配列化）された文字列として保持しています。このレコードを空の配列に書き換えることで、ファイル操作を一切行わずにデータベース側から安全に全プラグインを一括無効化できます。

なお、データベース接続そのものに失敗している場合は、【最短5分】WordPress「データベース接続確立エラー」の直し方を参照してください。

レンタルサーバーの管理パネルから「phpMyAdmin」にログインします。
左側のデータベース一覧から、対象サイトのWordPressデータベース名をクリックして展開します。
テーブル一覧から wp_options（プレフィックスが異なる場合は 〇〇_options）テーブルをクリックします。
上部メニューの「検索」タブをクリックし、option_name の入力欄に active_plugins と入力して「実行」をクリックします。
検索結果に表示された active_plugins の行の「編集」をクリックします。
option_value のテキストエリアに現在有効なプラグインの情報（例: a:4:{i:0;s:19:...}）が入っています。この文字列をすべてコピーして手元のメモ帳等に退避（バックアップ）します。
option_value の内容を、以下の空の配列を表す文字列に完全に書き換えます。

a:0:{}

「実行」ボタンをクリックして変更を保存します。
サイトや管理画面にアクセスします。すべてのプラグインが無効化された状態でWordPressが起動し、真っ白だった画面が即座に復旧します。

この方法は、ファイル名のリネームと同様にプラグインの設定データ（DBに保存された各設定値）を一切消去することなく安全に停止できるため、高度な緊急対応としてプロの間でも広く利用されています。

管理画面（/wp-admin/）だけが真っ白な場合の専用対処法

WSODのなかでも厄介なのが、「公開サイトは正常に表示されているのに、管理画面（/wp-admin/）やログイン画面（wp-login.php）だけが真っ白になる」というケースです。一般読者は問題なく閲覧できているため発見が遅れやすく、管理者が更新作業を行えなくなります。

ログイン自体が弾かれたりエラーが表示される場合は、【即時復旧】WordPressにログインできない原因と解決策も参考にしてください。白画面に特化した4大原因と復旧手順は以下の通りです。

1. WordPressリカバリーモード（致命的エラー通知メール）からの緊急ログイン

WordPress 5.2以降には、PHPの致命的エラーを検知した際に管理者メールアドレス宛へ自動的に緊急リカバリー用リンクを送信する「リカバリーモード」が標準搭載されています。

WordPressに登録している管理者メールアドレスの受信トレイ（および迷惑メールフォルダ）を確認します。
件名が「サイトで技術的な問題が発生しています」というメールが届いていないかチェックします。
メール本文内に「リカバリーモードでログインするためのリンク（ワンタイムURL）」と、エラーの原因となったプラグイン名・テーマ名が明記されています。
記載されたリンクからログインすると、問題のプラグインが一時停止された安全な状態でダッシュボードに入ることができ、管理画面から該当プラグインをワンクリックで無効化できます。

2. ブラウザのCookie・キャッシュ破損とセッション不整合

ブラウザ内に古いWordPressログイン認証Cookieやキャッシュデータが残っていると、認証処理のリダイレクトループが発生して処理がタイムアウトし、画面が真っ白になることがあります。

ブラウザの「シークレットウィンドウ（プライベートモード）」を起動し、管理画面（/wp-admin/）にアクセスしてみます。
シークレットウィンドウで正常にログイン画面が表示された場合は、通常利用しているブラウザのCookieと閲覧履歴（キャッシュ）を全削除することで解決します。

3. セキュリティプラグインや2段階認証プラグインの誤作動

Wordfence、SiteGuard WP Plugin、All-In-One Securityなどのセキュリティ系プラグインが、管理者自身のアクセスを不正アクセスと誤検知して管理画面への接続を遮断しているケースです。また、WAFによるアクセス遮断の可能性もあります。遮断された画面が403になる場合の対処法はWordPressの403 Forbiddenエラー原因と直し方完全ガイドでも解説しています。

【解決策】
ファイルマネージャーまたはFTPで /wp-content/plugins/ にアクセスし、該当のセキュリティプラグインフォルダ（例: siteguard や wordfence）の名前を一時的に siteguard_temp に変更して無効化します。その後ログインできるかを確認してください。

4. 管理画面用PHPメモリの不足（WP_MAX_MEMORY_LIMIT）

WordPressは、読者が閲覧する公開側と、管理者が操作するダッシュボード側で別々のメモリ上限値（WP_MEMORY_LIMIT と WP_MAX_MEMORY_LIMIT）を保持しています。

管理画面はウィジェットの読み込みやプラグインの管理機能、更新チェックなどが一度に集中するため、公開ページよりもはるかに多くのPHPメモリを消費します。公開側はギリギリ足りていても、管理画面だけがメモリ上限を突破してWSODになるケースが頻発します。

wp-config.php に以下の設定を明記することで、管理画面専用のメモリ上限を512MBに引き上げて解決します。

// 管理画面専用のPHPメモリ上限を512MBに拡張
define('WP_MAX_MEMORY_LIMIT', '512M');

再発防止のためのバックアップ体制と安全な更新手順

画面が無事に復旧できたら、二度と同じトラブルでサイト停止やビジネス機会の損失を引き起こさないための恒久的な予防体制を整えておきましょう。

WordPressの安全なバックアップと復元の実践手順については、WordPress バックアップと復元の方法｜トラブル時に最速で戻すコツで網羅していますが、特にWSOD対策として必須の4つの運用ルールを再確認してください。

1. 自動・手動バックアップの徹底（日次バックアップと更新前バックアップ）

ファイル一式（wp-content フォルダ）とデータベース（MySQL）の両方を定期的に保存する仕組みを構築します。エックスサーバーやConoHa WINGが標準提供している「過去14日間の自動バックアップ機能」を確認しておくとともに、更新作業の直前にはプラグイン（UpdraftPlusやBackWPupなど）やファイルマネージャーで手動バックアップを取得する運用を徹底してください。

2. ステージング環境での事前検証

本番環境で直接プラグインを大量更新したり、PHPバージョンを一気に切り替えるのは非常に危険です。主要レンタルサーバーが提供しているワンクリックの「ステージング環境（テスト環境）」や、ローカル開発環境（Local by Flywheel等）を活用し、テスト環境で不具合や真っ白画面が発生しないことを確認してから本番に適用しましょう。

3. 復旧後のWP_DEBUG無効化（セキュリティリスク防止コード）

真っ白な画面が復旧したら、ステップ1で有効化したデバッグモードを必ず無効（false）に戻してください。デバッグモードを有効にしたまま放置すると、サーバーの絶対パスやデータベース構造、SQLクエリなどの機密情報が万が一のエラー時に第三者へ露出してしまい、不正アクセスの踏み台にされる深刻なリスクが生じます。

// 復旧作業完了後は必ずfalseに設定して保存する
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

4. 定期的なサイトヘルス診断とセキュリティチェック

WordPress管理画面の「ツール」＞「サイトヘルス」でPHPバージョンや推奨モジュールの導入状況、セキュリティ推奨設定を定期的に確認しましょう。また、プラグインやテーマに潜む未知の脆弱性や設定ミスを早期発見するために、外部の診断ツールの定期活用を強くおすすめします。

🔍 WordPressサイトの安全性・不具合リスクを今すぐ無料診断

「自社サイトのプラグインやテーマにクラッシュや脆弱性の火種が潜んでいないか心配」「突然の画面真っ白（WSOD）や重大なエラーの再発を未然に防ぎたい」というWeb担当者・サイト管理者の方は、URLを入力するだけでWordPressのセキュリティ状態を瞬時にチェックできる無料診断ツール「MozCheck」をぜひご活用ください。

面倒な会員登録やプラグインのインストールは一切不要。サイトURLを入力するだけで、わずか10秒で最新の脆弱性データベース（CVE）と照合したセキュリティ診断結果、放置された危険なプラグイン、改善すべき推奨設定を網羅したレポートを即座に確認できます。

まとめ：冷静な切り分けと主要サーバー別手順でWSODは必ず直せる

WordPressの画面が突然真っ白（WSOD）になると焦ってしまいがちですが、「PHPのエラーによってHTMLの描画が止まり、エラー表示が非表示になっているだけ」であり、データベースに蓄積された記事データや画像資産が消去されたわけではありません。

まずは症状別切り分けフローチャートで直前のアクションと症状を照合する
エックスサーバー・ConoHa・さくら・ロリポップ等のファイルマネージャーを活用し、ブラウザだけで安全にアクセスする
WP_DEBUGを有効化してエラーログ（debug.log）を特定する
直前に編集したfunctions.phpの復元、またはpluginsフォルダの一時リネームで原因を切り分ける
ファイル操作ができない場合はphpMyAdminの active_plugins 書き換えを活用する
復旧後はWP_DEBUGを必ずfalseに戻し、バックアップ体制を整備する

本ガイドで紹介した手順を一つずつ冷静に実践すれば、専門知識がなくても最短時間で安全にサイトを復旧できます。万が一のトラブルに備えて本記事をブックマークし、日頃のバックアップと安全な更新運用を心がけてください。