WordPressで「重大なエラー」が出たとき、最初に確認する5項目

最終更新：2026年10月28日

対象：WordPress 5.2以降を想定

WordPress本体・プラグイン・テーマの更新後や、PHPのバージョン変更後に「このサイトで重大なエラーが発生しました」と表示されることがあります。

焦って設定やファイルを変更すると、原因の切り分けが難しくなり、元の状態へ戻しにくくなることがあります。まずは次の5項目を確認しましょう。

1. 直前の変更を整理する

WordPress本体、テーマ、プラグイン、PHPバージョン、サーバー設定など、エラー発生前の変更を書き出します。

「何もしていない」という場合も、プラグインの自動更新やレンタルサーバー側のPHP変更履歴を確認してください。複数の更新があるときは、日時も控えておきます。

2. 発生状況を記録する

エラーが発生した日時、対象URL、フロント画面と管理画面のどちらで出るか、毎回起きるかを記録します。画面が定型文だけでも、発生条件は切り分けの手がかりになります。

WordPress 5.2以降では、重大なエラーを検知すると管理者メールへリカバリーモードの案内が届く場合があります。メールには原因候補のプラグインやテーマ、ファイル、行番号などが含まれることがあります。届かない場合は迷惑メールフォルダとサーバーのメール送信状況も確認してください。復旧リンクや管理情報は第三者へ公開しないでください。

3. エラーログを確認する

サーバー管理画面のPHPエラーログを確認します。例えば、次のような記録が手がかりになります。

PHP Fatal error: Uncaught Error: Call to undefined function ...

PHP 8系への変更後は「TypeError」「ArgumentCountError」、メモリ不足では「Allowed memory size ... exhausted」などが出ることもあります。

WordPressでは、WP_DEBUG_LOGを有効にすると通常はwp-content/debug.logへ記録できます。ただし、公式情報でも本番サイトでのデバッグ機能の常時使用は推奨されていません。ログが外部から読める設定になっていないか注意し、調査後は無効化してください。ログ全文を公開するのも避けましょう。

4. バックアップを確認し、現状も保存する

正常だった時点のファイルとデータベースのバックアップを確認します。さらに、調査前の壊れた状態も別に保存しておくと、原因調査や作業の巻き戻しに役立ちます。

バックアップが確認できない状態で、本番環境のファイルを直接削除・上書きするのは避けてください。

5. 影響範囲を確認する

全ページか特定ページだけか、管理画面へ入れるか、フォーム送信や決済などの重要機能が止まっていないかを確認します。緊急度と、先に止めるべき操作を判断しやすくなります。

確認後の進め方

リカバリーモードで原因候補のプラグインを一時停止する、直前に変更したPHPバージョンを戻すなどが代表的な対応です。ただし、バックアップや互換性を確認せずに行うと別の不具合につながるため、まず原因調査と修正作業を分けて考えます。

まとめ

最初に確認するのは、直前の変更、発生状況、エラーログ、バックアップ、影響範囲の5項目です。記録を残してから対応すると、安全に原因を切り分けやすくなります。

原因の切り分けが難しい場合は、出品中の「WordPress・PHPの不具合原因調査」で、確認済みの事実・原因候補・修正方針を整理してご報告します。修正作業は調査後の別見積もりです。