真っ白な画面は「情報が無い」のではなく、エラーを表示しない設定になっているだけです。まずエラーを見えるようにするのが最短の道です。
define('WP_DEBUG', true); // デバッグモードをオン
define('WP_DEBUG_DISPLAY', true); // 画面に表示する（開発中）
define('WP_DEBUG_LOG', true); // wp-content/debug.logにも記録これで、画面にこんなメッセージが出るようになります。
Fatal error: Uncaught Error: Call to undefined function my_helper()
in /wp-content/themes/mytheme/functions.php on line 42ファイル名と行番号が出るので、あとはそこを見に行くだけです。
debug.logの読み方
WP_DEBUG_LOGをオンにすると、wp-content/debug.logにエラーが追記されます。
- 見るのはいちばん下（最新）。日時が先頭に付いています
Fatal error——致命的。ここでページが止まる。まずこれを直すWarning/Notice/Deprecated——動くが問題あり。あとで直す
自分のコードから任意のメッセージを書きこむこともできます。var_dump()を画面に出せない場面（Ajax・フック内・管理画面の保存処理）で重宝します。
error_log('ここまで来た');
error_log(print_r($some_array, true)); // 配列は文字列にして渡す症状別の切り分け
真っ白（何も表示されない）
WP_DEBUGをオンにしてエラー文を読む- エラーが出ないなら、直前に編集したファイルを疑う（PHPの
;忘れ・?>の後の空白・全角スペース混入） - 管理画面にも入れないなら、次の「復旧手順」へ
「このサイトで重大なエラーが発生しました」
PHPの致命的エラーです。管理者メールに復旧用のリンク（リカバリーモード）が届いていれば、そこから原因のプラグイン・テーマを無効化できます。メールが届かない環境では、下の復旧手順で対応します。
500エラー（Internal Server Error）
サーバー側で処理が止まっています。.htaccessの記述ミス、PHPのメモリ不足、プラグインの競合が典型です。
define('WP_MEMORY_LIMIT', '256M');.htaccessが疑わしいときは、ファイル名を.htaccess-bakに変えて表示を確認し、直ったら管理画面の「設定」→「パーマリンク」を保存して作り直します。
管理画面だけ真っ白／崩れる
ブラウザの開発者ツールのConsoleを見ます。JavaScriptのエラーが原因のことが多く、プラグインの競合が疑われます。
べんりワザ開発者ツールの使い方入門開発者ツールでエラーを見る方法はこちら管理画面に入れないときの復旧手順
FTPやレンタルサーバーのファイルマネージャーから操作します。順番が大事です。
- プラグインを全部止める——
wp-content/pluginsをplugins-offにリネームする。表示が戻れば、いずれかのプラグインが原因 - 1つずつ戻す——名前を元に戻し、プラグインを1つずつ有効化して原因を特定する
- テーマを疑う——
wp-content/themes/使用中のテーマをリネームすると、標準テーマに自動で切り替わる。これで戻ればテーマが原因 - 直前の編集を戻す——
functions.phpを編集した直後なら、その変更を取り消す
開発中のデバッグに使える道具
var_dump($value); // 型まで分かる
print_r($array); // 配列を見やすく
wp_die('<pre>' . print_r($v, true) . '</pre>'); // ここで止めて表示
error_log(print_r($v, true)); // ログに出す（画面を壊さない）WordPress特有の値を見たいときは、この2つが便利です。
global $template;
error_log('template: ' . $template); // 使用中のテンプレート
error_log(print_r(get_post_meta(get_the_ID()), true)); // その投稿のメタ全部SQLやフックまで追いたいとき
WordPressには、実行されたクエリ・使われたテンプレート・フックの一覧を管理バーから見られるデバッグ用プラグインがあります（Query Monitorが定番）。「なぜ遅いのか」「どのフックが効いているのか」を調べる段階になったら導入を検討する価値があります。
開発中はさらにこの2つも便利です。
define('SCRIPT_DEBUG', true); // 圧縮前のCSS・JSを読みこむ
define('SAVEQUERIES', true); // 実行SQLを記録（デバッグ用プラグインと併用）どちらも本番ではオフにします。
まとめ
- まず
wp-config.phpでWP_DEBUGをオン——ファイル名と行番号が分かればほぼ解決 - 公開サイトでは表示オフ・ログオン。
wp-content/debug.logの最新行を読む - 管理画面に入れないときはpluginsフォルダをリネームして全無効化→1つずつ戻す
- 画面に出せない場所のデバッグは
error_log()。調べ終わったら設定を戻す
原因の切り分け手順を持っていれば、真っ白な画面もこわくありません。