WordPress のエラーログはどこにあり、どう読むか

公開 2026.09.07 更新 2026.09.03 約5分で読めます CloudHonu 編集部

「エラーログを見てください」と言われたものの、そのログがどこにあるのか分からない。サーバーの管理画面を開いてみたが、それらしいものが複数あってどれのことか判断できない——という状況で読まれることを想定した記事です。

先に結論

「エラーログ」と一口に言っても、WordPress サイトには性質の違うログが3つあります。混乱の原因はここです。

WordPress 自身が書き出すログです。プラグインやテーマの中で起きたエラーが、どのファイルの何行目かまで記録されます。原因のプラグインを特定したいときは、まずこれです。

ただし既定では無効です。何も設定していないサイトでは、このログは存在しません。「ログが無い」のではなく「まだ取っていない」状態です。

PHP が実行中に出したエラーを、サーバー側が記録するものです。WordPress が起動する前に落ちた場合や、メモリ不足で強制終了した場合は、WordPress のログには何も残らず、こちらにだけ出ます。

場所はサーバーによって違います。多くのレンタルサーバーでは管理画面に「エラーログ」「PHP ログ」といった項目があり、そこから閲覧またはダウンロードできます。ファイルとして置かれる場合は、公開ディレクトリの外に置かれているのが普通です。

どの IP アドレスから、いつ、どの URL に、どんな結果（200・403・404・500 など）を返したかの記録です。「表示されない」「アクセスできない」が本当に起きているのかを確かめるときや、不審なアクセスを調べるときに使います。

wp-config.php の、/* 編集が必要なのはここまでです */ というコメントより上に次の3行を書きます。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

これで wp-content/debug.log に記録が始まります。すでに WP_DEBUG の行がある場合は、値を書き換えてください。同じ定義を2回書くと後ろが無視されます。

🚨 3行目を true にしないでください。エラーの内容が訪問者の画面にそのまま出ます。ファイルの場所や使っているソフトウェアの構成が読めてしまい、攻撃の手がかりになります。

wp-content/debug.log は公開領域に置かれます。URL を直接指定すれば、誰でも読める状態になりえます。ログにはファイルの絶対パスや、場合によってはデータベースの問い合わせ内容まで残ります。

調査が終わったら、3行を削除し、debug.log も削除してください。「あとで消そう」と思って何年も残っているサイトは珍しくありません。

行の先頭に日時、次にエラーの種類が書かれています。種類によって深刻さが違います。

Fatal error の行には、必ずファイルのパスと行番号が付いています。パスの中に wp-content/plugins/○○/ とあれば、その ○○ が原因のプラグインです。wp-content/themes/○○/ ならテーマです。

その下に続く「Stack trace」は、そこに至るまでの呼び出しの経路です。上ほど直接の発生箇所、下ほど大元の呼び出し元です。原因を知るだけなら一番上の行で足ります。

ログは「異常が起きた瞬間の記録」です。後から取ろうとしても、過ぎたことは記録されていません。継続的に取っておくか、再現できるうちに取るか。更新をどう当てるかを決めるときも、この記録があるかどうかで判断の確かさが変わります。