
WordPressエディタが真っ白になる原因と直し方
管理画面のブロックエディタを開いた際に編集エリアが完全に白紙になる主な原因は、プラグインやテーマの競合、または PHP の致命的エラーだ。まず標準テーマへの切り替えと全プラグインの無効化で原因を特定し、それでも解決しない場合はデバッグモードでエラーログを確認する。
エディタ画面が真っ白になる根本的な原因

WordPress のブロックエディタ(Gutenberg)で編集画面を開いたときに真っ白なページしか表示されない現象は、大きく分けて 2 つの原因で発生する。1 つはプラグインやテーマの競合、もう 1 つは PHP の致命的エラー(「このサイトで重大なエラーが発生しました」と表示される類のもの)だ。
ブロックエディタは JavaScript を多用する高度な画面であり、複数のプラグインが読み込むスクリプト同士で競合が起きると、画面の描画が完全に停止してしまう。またテーマが古い jQuery や独自のエディタ拡張をロードしている場合も、エディタの初期化処理と衝突して空白画面を引き起こす。
PHP の致命的エラーが原因の場合は、エディタ画面そのものが生成される前に処理が中断されている状態だ。たとえばメモリ不足や、特定のプラグインが要求する PHP 拡張機能の不足、あるいは functions.php に記述された独自コードの文法ミスなどが該当する。こうしたエラーは管理画面全体に影響する場合もあるが、投稿編集画面だけが重い処理を要求するタイミングで発覚することも多い。
複数のプラグインやテーマが読み込むスクリプトが衝突し、エディタの初期化が止まる
メモリ不足・プラグインの不具合・functions.php の記述ミスなどで画面生成前に停止
セキュリティプラグインやサーバー設定が WordPress の REST API 通信を遮断している
プラグインとテーマの競合を切り分ける手順

まず最初に試すべきは、プラグインの全無効化と標準テーマへの切り替えだ。この手順だけで多くの白紙エディタ問題は解決する。管理画面にアクセスできる状態であれば、以下の流れで原因を特定できる。
Health Check プラグインで訪問者に影響を与えずに調査する
本番サイトでプラグインを一括無効化すると、訪問者に見えているサイトのレイアウトが一時的に崩れるリスクがある。プラグイン「Health Check & Troubleshooting」を導入すれば、自分がログインしている間だけプラグイン無効化とテーマ切り替えが適用され、一般の訪問者には通常通りの表示が保たれる。
「Health Check & Troubleshooting」は WordPress.org の公式プラグインディレクトリから無料でインストールできる。有効化後に「トラブルシューティング」タブを開き「トラブルシューティングモードを有効にする」ボタンを押すだけで、安全に調査を開始できる。特定のプラグインだけを個別に再有効化しながら編集画面の挙動を確認できるため、競合元の絞り込みに非常に有効だ。
テーマの functions.php が原因になるケース
標準テーマに切り替えた途端にエディタが正常化した場合、それまで使っていたテーマ(あるいは子テーマ)の functions.php に問題がある可能性が高い。よくあるのは、エディタ向けのカスタムスタイルやブロック追加のコードが WordPress のバージョンアップ後に非推奨の関数を使い続けているケースだ。
functions.php の中で add_action('enqueue_block_editor_assets', ...) や add_filter('block_editor_settings_all', ...) を使ってエディタに介入している箇所があれば、それらを一旦コメントアウトして様子を見ると原因の切り分けになる。
デバッグモードでエラーログを取得する

プラグインとテーマの切り分けでも解決しない場合、PHP の致命的エラーが発生している可能性が高い。画面には何も表示されないが、裏側でエラーが起きている。そこで WordPress のデバッグモードを有効にして、エラーログをファイルに記録させる。
wp-config.php にデバッグ定数を追加する
FTP やレンタルサーバーのファイルマネージャーでサーバーに接続し、WordPress のルートディレクトリにある wp-config.php を編集する。ファイル末尾の /* That's all, stop editing! */ よりも手前に、以下の 3 行を追加または上書きする。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG を true にするとデバッグモードが有効になる。WP_DEBUG_LOG を true にすると、エラーの内容が /wp-content/debug.log ファイルに出力される。WP_DEBUG_DISPLAY を false にしておけば、エラーが画面に表示されず、訪問者にも影響が出ない。
設定後に問題のエディタ画面を再度開き、その後 /wp-content/debug.log をテキストエディタで開く。PHP のエラーメッセージが記録されていれば、どのファイルの何行目で問題が起きているかが具体的にわかる。たとえば「Allowed memory size of 〜 bytes exhausted」ならメモリ不足、「Call to undefined function 〜」なら関数の未定義が原因だと絞り込める。
「Allowed memory size of 〜 bytes exhausted」→ wp-config.php で
define('WP_MEMORY_LIMIT', '256M'); を追加「Call to undefined function 〜」→ 該当のプラグイン/テーマを最新版に更新するか無効化
debug.log が空、または Notice/Warning のみ → PHP エラーは原因ではない
ブラウザの開発者ツールで JavaScript エラーを確認する

PHP のエラーログに何も記録されていない場合、JavaScript の実行時エラーが原因でエディタが空白になっている可能性が高い。この場合はブラウザの開発者ツールを使う。
Chrome の場合、編集画面を開いた状態でキーボードの F12 キーを押して開発者ツールを起動し、「Console」タブを選択する。赤いエラーメッセージが表示されていれば、それがエディタの読み込みを止めている原因だ。Uncaught TypeError や Uncaught ReferenceError のようなエラーが出ていれば、特定のスクリプトが正しく動作していないことを示している。
エラーの内容にプラグイン名やテーマ名が含まれていることが多いため、そのプラグインを無効化すれば問題が解決する。コンソールにエラーが一切出ていない場合は、REST API の通信が遮断されているケースが疑われる。開発者ツールの「Network」タブで、wp-json を含むリクエストが赤く表示されていないか確認する。401(認証エラー)や 403(禁止)が返っている場合は、セキュリティプラグインやサーバー側の WAF(Web アプリケーションファイアウォール)が REST API をブロックしている可能性が高い。
よくある質問
プラグインを無効化する管理画面すら真っ白で開けない場合はどうするのか
FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリにアクセスし、プラグインフォルダを一時的に別の名前にリネームする。たとえば plugin-name を _plugin-name に変更すれば、WordPress はそのプラグインを認識しなくなり、管理画面にアクセスできるようになる。
特定のページだけエディタが真っ白になるのはなぜか
特定のページに埋め込まれたショートコードやブロックが、対応するプラグインの JavaScript エラーを引き起こしている可能性が高い。またページのリビジョン数が極端に多い場合も、エディタの読み込みが重くなりタイムアウトすることがある。リビジョンを整理するか、該当ページを複製して編集し直すと改善する場合がある。
ブラウザを変えても同じ症状か確認したほうがよいか
確認する価値はある。まれにブラウザの拡張機能(特に広告ブロッカーやセキュリティ系)がブロックエディタのスクリプトを遮断しているケースがある。シークレットウィンドウや別のブラウザでログインして編集画面を開き、同じ症状が出るかどうかを見ると、ブラウザ側の要因かどうかを切り分けられる。
WordPress 本体の再インストールは効果があるか
コアファイルの破損が疑われる場合に限り効果がある。管理画面の「ダッシュボード」→「更新」から「WordPress を再インストール」を選ぶと、コアファイルだけがクリーンな状態に置き換わる。テーマやプラグイン、データベースには影響しないため、手軽に試せる。ただしプラグインの競合や PHP エラーが原因の場合は再インストールしても改善しない。
編集画面が真っ白な状態で記事を更新する応急的な方法はあるか
ブロックエディタが使えない場合の回避策として、クラシックエディタプラグインを有効化する方法がある。旧式の編集画面に切り替わるため、JavaScript の競合の影響を受けにくい。根本解決ではないが、急ぎの更新作業が必要な場合の一時的な回避策として使える。また「QuickPost」のような外部ツールを使う方法もあるが、環境に依存するため万能ではない。
この記事のポイント
- エディタの白紙はプラグイン/テーマ競合か PHP エラーが主因
- 全プラグイン無効化と標準テーマ有効化で原因を切り分ける
- Health Check プラグインで訪問者に影響なく調査できる
- wp-config.php のデバッグ設定でエラーログを取得する
- ブラウザの開発者ツールで JavaScript エラーも確認する

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
