WordPressで画面が真っ白になったり、「このサイトで重大なエラーが発生しました」と表示されたりしたとき、原因は多くの場合、PHPのエラーとして記録できます。WordPressのデバッグモードを有効にすると、PHPのエラーや警告、非推奨の関数の呼び出しなどを、画面やログファイルに出せるようになります。
この記事では、wp-config.php での設定方法と、公開中のサイトで訪問者にエラーを見せずにログだけを取る方法を説明します。定数の動きは、2026年10月時点の WordPress のソースコード（wp-includes/default-constants.php と wp-includes/load.php）で確かめています。
デバッグ用の定数
| 定数 | 既定値 | 内容 |
|---|---|---|
WP_DEBUG |
false |
true でデバッグモードを有効にし、すべての種類のPHPエラーを報告する |
WP_DEBUG_LOG |
false |
true で wp-content/debug.log に記録する。ファイルのパスを文字列で指定すると、その場所に記録する |
WP_DEBUG_DISPLAY |
true |
true でエラーを画面に表示する。false で表示しない |
SCRIPT_DEBUG |
false |
true でWordPress本体のCSSとJavaScriptを圧縮前のファイルで読み込む |
SAVEQUERIES |
未定義 | true で実行したデータベースのクエリを記録する（負荷が増える） |
WP_DEBUG_LOG と WP_DEBUG_DISPLAY は、WP_DEBUG が true のときだけ働きます。また、WP_DEBUG_DISPLAY の既定値は true なので、WP_DEBUG だけを true にすると、エラーがそのまま画面に表示されます。
手順1: wp-config.php をバックアップする
wp-config.php は、WordPressをインストールしたディレクトリ（wp-admin や wp-content と同じ階層）にあります。書き間違えるとサイト全体が表示されなくなるので、編集前にコピーを取ります。
cd /var/www/html
cp -p wp-config.php wp-config.php.bakレンタルサーバーでは、サーバー会社のファイルマネージャーかSFTPでダウンロードしておきます。
手順2: デバッグの設定を書く
wp-config.php には、最初から次の行があります。
define( 'WP_DEBUG', false );この行を、次の内容に置き換えます。公開中のサイトで原因を調べる場合の設定で、エラーは画面に出さず、ログファイルにだけ記録します。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );- 書く場所は、
/* That's all, stop editing! Happy publishing. */（日本語版では「編集が必要なのはここまでです」で始まる行）より上です。この行より下に書くと、WordPressの読み込みが始まったあとになるため効きません define( 'WP_DEBUG', ... )を2回書くと、「Constant WP_DEBUG already defined」という警告が出ます。既存の行を書き換えてください@ini_set( 'display_errors', 0 );は、WordPressが読み込まれる前に起きたエラーも画面に出さないためのものです
開発環境やテスト用のサイトで、エラーを画面で見ながら作業したい場合は、WP_DEBUG_DISPLAY を true にします（または書かずに既定値のままにします）。訪問者がいる公開中のサイトでは、ファイルのパスなどが表示されてしまうので、画面表示は使いません。
WP-CLI で切り替える
WP-CLI が使えるサーバーでは、ファイルを開かずに定数を書き換えられます。--raw は、値を文字列ではなくPHPの値（true / false）として書くための指定です。
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config get WP_DEBUGwp config set は、定数が無ければ追加し、あれば値を書き換えます。
手順3: エラーを起こしてログを確認する
設定を保存したら、問題が起きる操作（そのページを開く、プラグインを有効化するなど）をもう一度行います。エラーが記録されると、wp-content/debug.log が作られます。
tail -n 50 /var/www/html/wp-content/debug.log操作しながら新しい行を見たい場合は tail -f を使い、終わったら Ctrl+C で止めます。ログは次のような形式です（例）。
[10-Nov-2026 06:12:31 UTC] PHP Fatal error: Uncaught Error: Call to undefined function my_func() in /var/www/html/wp-content/themes/mytheme/functions.php:25
[10-Nov-2026 06:12:40 UTC] PHP Warning: Undefined variable $title in /var/www/html/wp-content/plugins/sample-plugin/sample.php on line 88見るべきところは、エラーの種類（Fatal error はページが止まる重大なもの、Warning や Deprecated は処理が続くもの）と、ファイルのパスです。パスに plugins/プラグイン名 や themes/テーマ名 が含まれていれば、そのプラグインやテーマが原因の候補になります。
debug.log が作られないとき
| 原因 | 確認と対処 |
|---|---|
| エラーがまだ起きていない | 問題の操作をもう一度行う。エラーが無ければファイルは作られない |
| 設定が効いていない | 「That's all, stop editing!」の行より下に書いていないか、定数の名前の綴りを確認する |
| PHPが書き込めない | wp-content に、PHPを動かしているユーザーの書き込み権限があるか確認する |
| 別の場所に出ている | WP_DEBUG_LOG にパスを書いていないか確認する |
書き込み権限が無い場合でも、wp-content 以下を chmod -R 755 や chmod -R 777 でまとめて変えるのはやめてください。ファイルに実行権限や書き込み権限が付いてしまいます。次の節のように、ログ専用のディレクトリを作って、そこだけに書き込み権限を与えるのが安全です。
debug.log を外から見られないようにする
既定の wp-content/debug.log は公開ディレクトリの中にあるため、https://example.com/wp-content/debug.log で誰でも開けてしまうことがあります。ログにはサーバー上のパスやプラグイン名、場合によっては入力値が含まれます。次のどちらかで防ぎます。
方法1: 公開ディレクトリの外に記録する
WP_DEBUG_LOG にファイルのパスを書くと、その場所に記録されます。Debian・Ubuntu で、PHPが www-data ユーザーで動いている場合の例です。
sudo mkdir -p /var/log/wordpress
sudo chown www-data:www-data /var/log/wordpress
sudo chmod 750 /var/log/wordpressdefine( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );PHPを動かしているユーザーは環境によって違います（apache、nginx、サーバー会社のアカウント名など）。ps aux | grep -E 'php-fpm|apache2|httpd' などで確認してください。レンタルサーバーでは、ホームディレクトリの中の公開されていない場所を指定します。
方法2: Webサーバーでアクセスを拒否する
Apache 2.4 では、wp-content/.htaccess に次の内容を書きます（ファイルが無ければ作ります）。
<Files "debug.log">
Require all denied
</Files>Nginx では、サーバーの設定の server ブロックに次の内容を加え、設定を再読み込みします。
location = /wp-content/debug.log {
deny all;
}どちらも、ブラウザか次のコマンドで、403 が返ることを確認します。
curl -I https://example.com/wp-content/debug.logそのほかのデバッグ設定
SCRIPT_DEBUG
ブロックエディターや管理画面のJavaScriptのエラーを調べるときに、本体のCSSとJavaScriptを圧縮前のファイルで読み込みます。ブラウザの開発者ツールで、エラーの場所が読みやすくなります。
define( 'SCRIPT_DEBUG', true );SAVEQUERIES
ページの表示中に実行されたデータベースのクエリを、$wpdb->queries に記録します。表示が遅い原因を調べるときに使いますが、記録のぶん負荷が増えるので、調べ終わったら外します。クエリやフックを画面で確認するなら、Query Monitorを使ったWordPressのデバッグ のようにプラグインを使うほうが手軽です。
環境の種類（WP_ENVIRONMENT_TYPE）
WP_ENVIRONMENT_TYPE に local、development、staging、production のどれかを設定できます。WP_DEBUG を書いていない場合、local か development のときは WP_DEBUG が自動で true になります。
define( 'WP_ENVIRONMENT_TYPE', 'development' );本番サイトの wp-config.php を開発環境からコピーしたときに、この値が残っていないか確認してください。
「重大なエラー」とリカバリーモード
致命的なエラーが起きると、WordPressは真っ白な画面の代わりに「このサイトで重大なエラーが発生しました」と表示し、管理者のメールアドレスにエラーの内容と「リカバリーモード」のリンクを送ります。リカバリーモードでログインすると、原因のプラグインやテーマを止めた状態で管理画面に入れるので、そこで無効化や更新ができます。
メールが届かない場合や、管理画面に入れない場合は、デバッグモードのログでファイルのパスを確認し、SFTPなどで wp-content/plugins の中の該当するプラグインのフォルダー名を変えると、そのプラグインを止められます。白い画面の切り分け方は WordPressの白い画面をデバッグする方法 で詳しく説明しています。
調べ終わったら元に戻す
原因が分かって直したら、デバッグの設定を戻します。
define( 'WP_DEBUG', false );WP_DEBUG_LOG などの行は削除するか、WP_DEBUG を false にすれば働きません。WP-CLI では wp config set WP_DEBUG false --raw です。ログファイルは使い終わったら削除します。
rm /var/www/html/wp-content/debug.logWP_DEBUG を true のままにしておくと、ログファイルが大きくなり続け、Deprecated などの記録で負荷もかかります。本番環境での設定の考え方は wp-config.phpのデバッグ設定を本番環境でオフにする重要性と正しい書き方 を参照してください。
まとめ
wp-config.phpの既存のdefine( 'WP_DEBUG', false );を書き換え、「That's all, stop editing!」の行より上に設定を書く- 公開中のサイトでは
WP_DEBUG_LOGを有効、WP_DEBUG_DISPLAYをfalseにして、ログにだけ記録する - ログは
wp-content/debug.log。外から見られないよう、公開ディレクトリの外に出すか、Webサーバーで拒否する - 権限は
wp-content全体を変えず、ログの置き場所だけに書き込み権限を与える - 調べ終わったら
WP_DEBUGをfalseに戻し、ログを削除する
関連記事: