WordPressのPHPエラーを画面に表示せず調べるには、wp-config.phpでデバッグログを有効にし、エラー表示を無効にします。標準の保存先は通常 wp-content/debug.log です。この記事では設定の貼り付け位置、ログの読み方、ファイルが作られない場合の確認順を説明します。
対象はPHP側のエラー調査です。CSSが反映されない、スライダーのボタンが動かないといった症状では、ブラウザ側の確認も必要です。まず下の表で調べる場所を選んでください。
症状から調べる場所を選ぶ
| 症状 | 最初の確認 |
|---|---|
| 重大なエラー・白い画面・500エラー | 直前の変更と発生時刻を記録。PHPログ、サーバーのエラーログを確認します。 |
| CSSだけ反映されない・見た目が崩れる | ブラウザの開発者ツールでCSSの読み込み、セレクター、上書き、キャッシュを確認します。 |
| ボタン・開閉・スライダーが動かない | 開発者ツールのConsoleとNetworkでJavaScriptエラーや読み込み失敗を確認します。 |
| Ajax・REST APIの処理が失敗する | NetworkのHTTPステータス・応答と、同じ時刻のPHPログを照合します。 |
| 管理画面にも入れない | サーバー管理画面やSFTPから変更を戻せるか確認します。WordPress内の編集画面だけに頼らないでください。 |
編集前にwp-config.phpを保存する
先にバックアップと復元方法を確認し、編集前のwp-config.phpを手元に保存します。このファイルにはデータベースの接続情報などが含まれるため、記事・掲示板・公開フォルダーへコピーを置かないでください。サーバーのファイル管理機能またはSFTPで、編集したファイルを元に戻せる状態にします。
調査は検証用サイトで行うことを基本にします。WordPress公式も、デバッグ機能はローカル・ステージング環境で使うことを推奨しています。本番固有の症状を一時的に調べる場合も、ログの保存先と非公開化、調査を終える時刻を決めてから設定します。
画面に表示せずdebug.logへ記録する設定
wp-config.php内の WP_DEBUG、WP_DEBUG_LOG、WP_DEBUG_DISPLAY を検索します。すでに定義があれば、その行を書き換えます。同じ定数の定義を末尾へ追加しても、先に定義された値を変更できません。
定義がない場合は「編集が必要なのはここまでです」または That’s all, stop editing! のコメントより前に追加します。少なくとも wp-settings.php を読み込む行より前に置きます。functions.phpやCode Snippetsへ貼る設定ではありません。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );既存のPHPコード内に入れるため、上の例にPHP開始タグは含めていません。true と false に引用符を付けないでください。文字列の 'false' は真として扱われ、意図と逆の設定になります。
WP_DEBUG はデバッグ報告、WP_DEBUG_LOG はログの保存先、WP_DEBUG_DISPLAY は画面表示を制御します。@ini_set も実行時の表示設定を変更しますが、サーバー側の固定設定や、この行が実行される前のエラーまで隠せる保証にはなりません。@ 自体がサイト全体のエラーを抑えるものでもありません。
設定の根拠：WordPress公式のデバッグ手順、PHP公式のエラー表示・ログ設定。本番のPHP設定では、サーバー側でもエラーの画面表示を無効にしておきます。
エラーログの場所と非公開の保存先
WP_DEBUG_LOG を true にすると、通常はWordPressの wp-content/debug.log に記録されます。wp-contentの場所を変更した環境では、そのディレクトリ内を確認します。記録対象が発生し、PHPに書き込み権限がある場合にファイルが作成されます。設定するだけで必ず空のファイルができるわけではありません。
debug.logにはファイルパスや個人情報が含まれることがあります。Webから直接読める場所へ無防備に残さず、可能なら公開ディレクトリの外に保存します。次の例はLinux系サーバーの仮のパスです。実在する非公開ディレクトリと、PHPが書き込める権限を確認して置き換えてください。
// 前の WP_DEBUG_LOG の行を置き換えます。重複して追加しません。
define( 'WP_DEBUG_LOG', '/home/ACCOUNT/private-logs/wordpress-debug.log' );親ディレクトリを自動作成する設定ではありません。保存先が分からない場合は契約サーバーへ確認します。ログはSFTPやサーバー管理画面から取得し、公開URLを調査用の共有先にしないでください。保存先の扱いはWordPressの実装でも確認できます。
公開領域にログを置く場合のApache設定
公開領域外へ保存できない場合は、サーバー側でログファイルの取得を拒否します。
次の例はApache 2.4用で、WordPressのwp-content内の.htaccessに置きます。
既存ファイルを保存し、同じ設定がないか確認してから追記してください。
Requireを.htaccessで使える許可設定（AllowOverride AuthConfigなど）が必要です。
Nginxには適用できないため、ホストのアクセス制限機能を使います。
500エラーになった場合は追加部分を戻してサーバーログを確認します。
隔離したApache 2.4.69では、WP_DEBUG_DISPLAY=falseでも標準ログのURLは200で読めました。
この拒否設定を加えると403になりました。
設置後は認証していないGET要求でログURLを確認し、本文を取得できないことを確かめます。
調査後もログが公開領域に残る間は拒否設定を維持してください。
参照：ApacheのFiles、Require。
<Files "debug.log">
Require all denied
</Files>
再現操作とログの読み方
- 発生したページ・操作・時刻と、直前に変更したテーマやプラグインを記録します。
- 検証環境で同じ操作を1回行い、ログの更新日時を確認します。キャッシュ済み画面を表示しただけではPHP処理が実行されない場合があります。
- 時刻が近い行から、エラー種別・メッセージ・ファイル名・行番号を読みます。ログのタイムゾーンと手元の時計の違いにも注意します。
- 直前の変更を1つずつ戻して再確認します。ログに出たファイル名だけで原因を断定せず、呼び出し元や入力値も調べます。
以下は読み方を説明するための架空のログです。WAZAで発生した障害の記録ではありません。
[30-Sep-2026 01:00:00 UTC] PHP Warning: Undefined array key "label" in /example/wp-content/plugins/example-plugin/example.php on line 42この例は、example.phpの42行目で配列のlabelというキーが見つからなかったことを示します。その行を削除するのではなく、値が入る想定と未入力時の処理を確認します。Fatal errorは処理停止につながるエラー、Warningは警告、Deprecatedは非推奨機能の通知です。警告と現在の画面不具合が同じ原因とは限りません。
debug.logが作られない・更新されない場合
- WP_DEBUGがtrueになっているか、同じ定数を2回定義していないか、wp-settings.phpの読み込みより前に置いたかを確認します。
- 独自の保存先を指定していないか、正しいサイトのwp-config.phpを編集したかを確認します。
- 問題の処理が実際に実行されたか確認します。JavaScriptだけのエラーやCSSの競合は、このPHPログの対象ではありません。
- 保存先の親ディレクトリ、PHPの書き込み権限、サーバーの空き容量を確認します。原因不明のまま権限を777へ変更しないでください。
- wp-config.php自体の構文エラーなど、WordPressのログ設定が動く前に停止していないか、サーバー側のPHP・Webサーバーログを確認します。
ログが空でも「不具合がない」とは判断できません。別のログ出力先を使うプラグインや、独自のエラー処理を行うコードもあります。500エラーだけでは原因を特定できないため、発生時刻とサーバーログを照合してください。
調査後は設定を戻し、古いログも整理する
調査前の設定がある場合は、それに戻します。一般的なデバッグ無効の構成へ戻す例は次のとおりです。調査用の定義を下記に置き換え、重複して追加しないでください。
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );設定を無効にしても既存のdebug.logは消えません。必要な調査記録を非公開の場所へ保存したうえで、公開領域に残ったログを整理します。サーバー側の通常のエラーログまで停止する設定ではありません。復旧後はトップページ、問題が起きた操作、管理画面を確認します。
管理画面に入れなくなった場合は、SFTPやサーバーのファイル管理機能から編集前のwp-config.phpへ戻します。バックアップ全体の復元は記事や注文なども上書きし得るため、まず変更したファイルだけを戻せるか確認してください。
次に確認する手順
検証環境からの反映は本番反映の注意点、変更前の保全はバックアップ・復元ガイドへ進んでください。実装方式や貼り付け先を調べ直す場合はSWELLカスタマイズまとめから該当記事を探せます。
動作確認：2026年10月3日。
隔離環境のPHP 8.2.29で、WordPress 7.1.2のログ初期化処理と掲載の定数設定を実行しました。
警告が画面へ出ず標準・非公開の保存先へ記録されること、保存先の親ディレクトリが自動作成されないこと、デバッグ無効でもサーバー側のログは残ることを確認しています。
本番設定やプラグイン固有のログ出力は変更・検証していません。
