.webp)
WordPressのエラーログは、最後の行だけで原因を決めず、「エラーが起きた時刻」「種類」「ファイルパス」「行番号」を一組で読みます。 Fatal errorなら表示停止の直接原因になりやすく、WarningやNoticeは手掛かりではあっても、単独でサイト停止を意味しません。
この記事では、サーバーパネルから対象ドメインのログを取得し、PHPエラーの一行を読み、プラグイン・テーマ・PHP・容量のどこへ戻るかを初心者向けに整理します。
アクセスログ・デバッグログとの役割の違い
| ログ | 記録するもの | 使う場面 |
|---|---|---|
| サーバーのエラーログ | PHPやWebサーバーのエラー | 500、白画面、処理失敗 |
| アクセスログ | URLへのリクエストと応答 | 404、急増、bot、発生時刻 |
| WordPress debug.log | WordPress側で有効にしたデバッグ情報 | 再現できる開発・検証 |
公開サイトでデバッグ表示を有効にして画面へエラーを出すと、ファイルパスなどを読者へ見せる危険があります。まずサーバー側の既存ログを読み、必要な時だけ安全な手順でデバッグログを使います。
エラーログとdebug.logは同じものだと思っていました。最初からwp-config.phpを編集しなくても、サーバーに記録が残っていることがあるんですね。
そうだよ。
すでにある記録で足りるなら、公開サイトの設定を増やさずに調べられるんだね。
画面へエラーを出せば簡単だと思ったんですけど、読者にもパスが見えるのは困ります。まだ少し、どのログを先に開くか迷いそうです。
500や白画面ならエラーログ、404やアクセス集中ならアクセスログからでいいよ。
現象で入口を選べば、読み始める場所がぶれにくいね。
サーバーパネルから取得する手順
- 障害が出た時刻と直前の操作をメモする。
- サーバーパネルの「エラーログ」を開く。
- 複数ドメインから対象サイトを選ぶ。
- 対象日を選び、表示またはダウンロードする。
- メモした時刻の前後を検索する。
-
Fatal error、Uncaught、Allowed memory sizeなどの種類を読む。 -
/plugins/名前/、/themes/名前/、wp-includesなどファイルパスを確認する。
エックスサーバーの公式案内ではドメイン単位でエラーログを表示・ダウンロードでき、保存期間設定を使ったログ生成も説明されています。契約先で保存期間や生成時刻が違うため、古い障害を後から探す場合は対象日が残っているか確認します。
一行を4つに分けて読む
PHP Fatal error: Uncaught TypeError ... in /home/example.com/public_html/wp-content/plugins/sample/sample.php on line 120
種類： Fatal error / Uncaught TypeError
場所： plugins/sample
ファイル： sample.php
行： 120
この例ではsampleプラグイン内で処理が止まった手掛かりがあります。ただし「sampleが悪い」と断定する前に、直前の更新、PHPバージョン、他プラグインとの組み合わせ、同時刻の最初のFatalを確認します。後続エラーは最初の停止から連鎖している場合があるためです。
エラー種類ごとの安全な次の一手
| 表示 | 意味の目安 | 最初の対応 |
|---|---|---|
| Fatal error | 処理継続不能 | 該当プラグイン・テーマと直前操作を照合 |
| Parse error | 構文の誤り | 直前に編集したファイルを元へ戻す |
| Allowed memory size | PHPメモリ不足 | 重い処理と上限を確認 |
| Permission denied | 権限や所有者 | パスを確認し、推奨権限へ戻す |
| Warning/Notice | 警告・注意 | 停止原因と決めつけず影響を確認 |
plugins/sampleと出ている行を見つけました。管理画面へ入れないので、FTPでsampleフォルダをすぐ削除してもいいですか？
削除より先に名前を変えて停止しようか。
元の名前をメモし、対象サイトのwp-content/pluginsにいることを確認すれば戻しやすいよ。
名前を変えて画面が戻らなかったら、別のフォルダも続けて変えたくなりそうです。どこまで試したか分からなくなりませんか？
一回に一つだけだよ。
変更、再読込、結果、元へ戻したかをメモしてから次へ進めば、原因を増やさずに済むね。
管理画面へ入れない時の復帰手順
- ログに出たプラグインまたはテーマの名称を正確に読む。
- サーバーのファイルマネージャーかSFTPで対象サイトへ入る。
-
対象フォルダ名の末尾へ
-disabledを付ける。 - 公開ページと管理画面を再読込する。
- 戻れば対象を停止したまま互換性と更新情報を確認する。
- 戻らなければ名前を元へ戻し、次の手掛かりへ進む。
テーマの場合、親テーマと子テーマを取り違えないようにします。WordPress本体ファイルや
wp-includes
を直接削除してはいけません。コアのパスが出ても、呼び出し元のプラグインが原因のことがあります。
ログ確認と復旧をしやすいサーバー
初心者が障害調査を続けるなら、ドメイン単位のログ取得、ファイルマネージャー、SFTP/SSH、サポートがまとまっている環境が安心です。すでに契約中で必要な機能が使えるなら、この記事だけを理由に乗り換える必要はありません。
エックスサーバー
ドメイン単位のエラーログとファイル操作手段を使い、障害時刻から復旧へ進みたい人の候補です。
向いている人： WordPressの障害対応を自分でも確認しつつ、サポートも利用したい人
利点： エラーログの表示・ダウンロード手順が公式マニュアルにある
注意点： ログ保存期間を過ぎると対象日を取得できない場合があります。障害後は早めに記録してください。
料金： スタンダード月額693円〜目安（キャンペーン・契約期間で変動）
エックスサーバーのエラーログ機能を見る広告・PRを含みます。料金・提供条件は公式ページで最新情報をご確認ください。
サポートへ伝える情報
- 対象ドメインと発生URL
- 発生日時とタイムゾーン
- 直前にした更新・編集
- 最初のFatal errorの種類とファイルパス
- フォルダ名変更で表示が変わったか
秘密鍵、管理者パスワード、ログ全体は送らず、サポートが求める範囲に限定します。
よくある質問
エラーログに何もないのに白画面です
対象ドメインと日付、ログ取得設定を確認します。ブラウザキャッシュ、CDN、PHPとは別のWebサーバーエラーもあるため、アクセスログの応答コードとサポート案内を照合してください。
古いWarningは全部直すべきですか？
大量発生して容量や性能へ影響する場合は対処しますが、今回の停止原因と混同しません。発生時刻と再現性、使用中の機能への影響を確認します。
ログを記事やSNSへ貼って質問してもいいですか？
ドメイン、サーバーパス、IP、メールアドレス、認証情報が含まれる可能性があります。公開せず、必要部分を伏せて公式サポートなど信頼できる窓口へ共有してください。
まとめ：ログは消さず、時刻と最初のFatalを探す
英語が並んだログを全部理解しないと直せないと思っていました。時刻、種類、ファイル、行番号に分けると、次に確認する場所が見えてきます。
必要な手掛かりを拾えるようになったね。
全部を訳すより、最初に処理が止まった一行を丁寧に読む方が役立つよ。
フォルダ名を変える時は、対象サイトと元の名前をメモします。それでも直らなければ、焦って何個も止めないようにします。
それで大丈夫だよ。
一つ変えて結果を見て、戻してから次へ進む。その順番なら、ログは怖い画面ではなく戻る道を示す地図になるからね。
エラーログは削除する対象ではなく、障害の時刻と場所を示す記録です。最初のFatalと直前操作を照合し、変更は一つずつ、戻せる形で行ってください。