↗付きの用語リンクは、別タブで説明を開きます。
WordPressに「このサイトで重大なエラーが発生しました」と出たら、焦ってプラグインをまとめて止めたくなるかもしれません。まず公開画面と管理画面の状態、発生時刻、直前に変えたことを残しましょう。
この記事では、リカバリーモード、直前の変更、PHPやWordPressのログを使って原因を絞る方法を紹介します。たとえば更新直後に発生したなら、対象の変更を一項目ずつ戻して表示を確かめます。作業前にバックアップと復旧手段を確認し、原因が未確定の段階では決めつけないようにします。
重大なエラーは何を示しているのか
この表示は、WordPressの処理中にPHPの致命的エラーが発生した場合などに表示される一般的な案内です。プラグイン、テーマ、独自コード、PHPバージョン、メモリ、ファイル破損など複数の原因が考えられるため、メッセージだけで原因を断定できません。
最初に記録すること
| 記録項目 | 確認内容 |
|---|---|
| 発生日時 | サーバーのPHP・エラーログと照合できる時刻 |
| 発生範囲 | 公開画面、管理画面、特定ページ、特定操作のどこで起きるか |
| 直前の変更 | WordPress本体、プラグイン、テーマ、PHP、コードの更新 |
| 通知メール | 管理者メールへリカバリーモードの案内が届いているか |
| 復旧手段 | バックアップ、サーバーのファイル管理、FTP、ステージングの有無 |
手順1：リカバリーモードを確認する
WordPressには、致命的なPHPエラーを検出した際に管理者だけが問題を切り分けられるリカバリーモードがあります。管理者メールに届く専用リンクからログインすると、問題が発生したプラグインやテーマが管理者セッション内で一時停止され、管理画面へ入れる場合があります。
WordPress公式のリカバリーモード解説を確認し、案内された原因候補とファイルを記録します。メールが届かない場合でも、迷惑メール、管理者メールアドレス、サーバーのメールログを確認してから次の手順へ進みます。
手順2：直前の変更を一項目ずつ戻す
エラー直前に更新や編集を行っている場合は、最も新しい変更から確認します。ただし、本番サイトで複数のプラグインを同時に停止したり、ファイルを削除したりしないでください。
- 更新したプラグイン・テーマの名称とバージョンを確認する
- 独自コードを編集した場合は変更差分を確認する
- PHPバージョンを変更した場合は利用テーマ・プラグインの要件と照合する
- 戻す前に現状のファイルとデータベースを保存する
- 一項目戻すたびに公開画面・管理画面・主要機能を確認する
手順3：PHP・WordPressのログを確認する
サーバーのエラーログで、発生時刻と一致するFatal errorやUncaught Errorを確認します。ファイルパス、プラグイン名、関数名、PHPバージョンなどが原因候補を示すことがあります。ログにはサーバーパスや個人情報が含まれる場合があるため、そのまま公開しないでください。
デバッグ設定を使う場合は、公開画面へエラーを表示せずログへ保存し、確認後は設定を元に戻します。WordPress公式の一般的なエラーの確認手順も参照できます。
管理画面へ入れない場合の対応
リカバリーモードでもログインできない場合は、サーバーのファイルマネージャーやFTPを使った切り分けが必要になることがあります。フォルダ名を変更してプラグインを一時停止する方法はありますが、対象を特定せず全体を変更すると決済・フォーム・セキュリティ機能へ影響します。ログで原因候補を確認し、バックアップと復旧手順を用意したうえで最小範囲だけ操作します。
復旧後に必ず確認する項目
| 確認場所 | 確認内容 |
|---|---|
| 公開ページ | トップ、記事、商品、問い合わせなど主要画面が表示される |
| 管理画面 | ログイン、保存、更新が正常に動作する |
| EC機能 | カート、決済、注文、メール、在庫連携に異常がない |
| ログ | 同じ致命的エラーが再発していない |
| 運用記録 | 原因、変更内容、復旧方法、確認結果を記録した |
再発を減らす運用
WordPress本体、テーマ、プラグイン、PHPの更新は、変更前バックアップ、更新対象の記録、ステージング確認、更新後の主要機能テストを一つの手順にします。自動更新を使う場合も、失敗通知と復旧方法を決めておくと停止時間を短くできます。
まとめ
重大なエラーが表示されたときは、表示を消すことより、発生時刻と直前の変更を記録し、リカバリーモードとログで原因候補を確認することが先です。変更を一項目ずつ行い、復旧後にEC機能まで確認することで、別の障害を生むリスクを抑えられます。
