WordPressのエラーをログに残す方法｜WP_DEBUGとdebug.log、使い終わったら戻す
WordPressで、画面に出ないエラーの原因を調べたい時は、wp-config.php に3つの設定を書くと、エラーをwp-content/debug.logに記録できます。画面にはエラーを出さず、ファイルに残すのがこの設定の狙いです。公式のドキュメントは、これらのデバッグ機能は公開中のサイトで使うことは勧められないとも書いています。
この記事では、WordPress公式の「Debugging in WordPress」と「Editing wp-config.php」にもとづいて、設定の書き方と、使い終わった後に戻す手順をまとめます。
（確認：WordPress公式ドキュメント Advanced Administration Handbook「Debugging in WordPress」「Editing wp-config.php」。日本語は筆者の訳です。確認日：2026年10月6日）
書く3つの設定
公式の例は、次のとおりです。wp-config.php の「That's all, stop editing! Happy blogging.」というコメントより前に書きます。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );| 定数 | 意味 |
|---|---|
WP_DEBUG |
デバッグモードを有効にする。標準では false。有効にすると、PHPのエラー・警告・通知が対象になり、廃止予定の関数の通知も出る |
WP_DEBUG_LOG |
エラーをファイルにも保存する。true なら wp-content/debug.log。ファイルのパスを書くと、別の場所に保存できる。WP_DEBUG が true の時だけ働く |
WP_DEBUG_DISPLAY |
エラーを画面のHTMLに表示するか。標準は true。false にすると画面には出ない。WP_DEBUG_LOG とあわせて使う |
値は引用符で囲まないでください。公式のページには、'false' のように引用符で囲むと、文字列として扱われ、true と解釈されると書かれています。
ログの見方
- 設定を書いて保存し、問題が起きる操作をもう一度行う
- FTPソフトやサーバーのファイルマネージャーで、
wp-content/debug.logを開く - エラーの行にあるファイルのパス（例：
wp-content/plugins/○○/）で、どのプラグインやテーマが原因かを見分ける
WP-Cronの実行中や、画面を更新しない通信（Ajax）の最中に出るエラーは、画面には出ません。WP_DEBUG_LOG は、画面に出ない場所のエラーを後から見るために役立つと、公式のページにも書かれています（予約投稿が公開されない時の確認にも使えます）。
使い終わったら戻す
WP_DEBUGをfalseに戻す（またはその行を消す）- ログのファイルを削除する。
wp-config.phpの公式ページに、エラーログは公開された場所に置かれることが多く、他の人にも読まれるおそれがあるので、使い終わったら削除するよう書かれています - 公式のページは、
WP_DEBUGを含むデバッグ機能は、ローカル環境やステージング環境で使うものだとしています
編集の前には、バックアップを取るか、ステージング環境を使うよう、公式のページにも書かれています（WordPressのバックアップ）。wp-config.php の編集の注意はwp-config.phpの主な設定にまとめています。
プラグインを入れた直後に画面が真っ白になった時
PHPの致命的なエラーが出ると、画面が真っ白になったり、「このサイトで重大なエラーが発生し」という案内が出たりします。管理者のメールアドレスには、WordPressから、原因のプラグインやテーマを知らせる自動メールが届くことがあり、「リカバリーモード」で管理画面に入って、止める操作ができます（PHPのバージョンを上げる前の確認）。
まとめ
WP_DEBUG・WP_DEBUG_LOG・WP_DEBUG_DISPLAYの3つで、エラーを画面に出さずにログへ残せる- 値は引用符で囲まない。「stop editing」のコメントより前に書く
- 公開サイトでは、使い終わったら戻して、ログを削除する
本記事は設定の説明です。編集の前にはバックアップを取ってください。
