WordPressの重大なエラーを調査して復旧した事例
WordPressサイトを開いたときに、
「このサイトで重大なエラーが発生しました。」
と表示され、ホームページだけでなくWordPressの管理画面にも入れなくなることがあります。
管理画面を開けないと、通常の方法ではプラグインの停止や設定変更ができません。
今回は、実際にWordPressサイトで発生した重大なエラーについて、レンタルサーバー側から調査し、原因となっていたプラグインを特定して復旧した事例を紹介します。
なお、サイト名やURLなど、クライアントを特定できる情報は掲載していません。
今回のサイトでは、公開ページとWordPress管理画面の両方に「このサイトで重大なエラーが発生しました。」と表示されていました。
WordPressの管理画面に入れれば、プラグインを一つずつ停止しながら原因を確認できます。
しかし、今回は管理画面そのものが利用できなかったため、レンタルサーバーの管理画面からWordPressの状態を調査する必要がありました。

1.発生していた症状を確認
最初に、サイト全体の表示状況を確認しました。
発生していた主な症状は次のとおりです。
- ホームページを表示できない
- WordPressの管理画面に入れない
- 「このサイトで重大なエラーが発生しました。」と表示される

公開ページと管理画面の両方でエラーが発生していたため、WordPress内部で処理を停止させるエラーが起きている可能性が考えられました。
2.サーバー側からWordPressの状態を確認
原因を確認するために、まず次の項目を調査しました。
- サーバーのエラーログ
- WordPressのファイル
- インストールされているプラグイン
- WordPressやプラグインの更新状況
管理画面に入れない状態だったため、サーバー側からWordPressのファイルやログを確認しながら原因を切り分けていきました。
サーバー側のログだけで原因が分からない場合は、WordPressのデバッグ機能を利用すると、より詳しいエラーを確認できることがあります。
3.WordPressのデバッグログを一時的に有効化
WordPressには、内部で発生しているエラーを記録するデバッグ機能があります。
今回は、サーバー上にある wp-config.php を事前にバックアップしたうえで、デバッグ機能を一時的に有効化しました。
画面上にはエラーの詳細を表示させず、サーバー内の debug.log にだけ記録されるように設定しています。
これは、公開中のサイトにファイルの場所や内部情報などを表示させないためです。
デバッグログを確認したところ、次のエラーが記録されていました。
PHP Fatal error: Cannot redeclare is_sitemap()

これは、is_sitemap() という同じ名前の機能が重複して定義され、WordPressの処理が停止していることを示すエラーです。
4.原因となっていたプラグインを特定
debug.log などを確認したところ、特定のプラグインに関係するエラーが記録されていることを確認しました。
ただし、このプラグインを利用すると必ず重大なエラーが発生するという意味ではありません。
WordPress本体やテーマ、ほかのプラグインとの組み合わせ、更新状況などによって問題が発生することがあります。
今回はログの内容やサイトの状態を確認したうえで、原因となっている可能性が高いプラグインを特定しました。
5.サーバー側からプラグインを停止
通常、プラグインはWordPressの管理画面から停止します。
しかし、今回は管理画面に入れなかったため、サーバー上のプラグインフォルダを一時的に変更し、WordPressから読み込まれない状態にしました。
原因となっていたプラグインのフォルダ名を変更することで、WordPressから読み込まれなくなり、停止した状態になります。

停止後に確認したところ、
- ホームページ
- エラーが表示されていたページ
- WordPressの管理画面
のすべてが正常に表示されるようになりました。
これにより、今回の重大なエラーは、該当プラグインの読み込みによって発生していたことを確認できました。
6.停止したプラグインの機能を別の方法で補う
サイトの表示は復旧しましたが、原因となったプラグインはXMLサイトマップを作成するために使用されていました。
そのため、プラグインを停止しただけでは、これまで使用していたXMLサイトマップも表示されなくなります。
XMLサイトマップは、サイト内にどのようなページがあるのかをGoogleなどの検索エンジンへ伝えるためのファイルです。
今回のサイトでは、SWELLの設定によってWordPress標準のXMLサイトマップが停止されていました。
そこで、プラグインによるサイトマップの代わりに、WordPress標準のXMLサイトマップを有効化しました。
設定後は、次の形式のURLでXMLサイトマップが正常に表示されることを確認しています。
https://ドメイン名/wp-sitemap.xml
プラグインを停止するときは、そのプラグインが担当していた機能まで失われていないか確認することが大切です。
7.復旧後にデバッグ機能を元へ戻す
原因の特定と復旧確認が完了した後は、一時的に有効化していたWordPressのデバッグ機能を無効に戻しました。
デバッグ機能は原因調査に役立ちますが、通常の運用中に常時有効化しておく必要はありません。
今回は、PHPの設定変更は行わず、原因となっていたプラグインの停止とXMLサイトマップの再設定によって復旧しています。
最後に、公開ページ・管理画面・XMLサイトマップを改めて確認し、正常に利用できる状態になっていることを確認しました。
WordPressの管理画面に入れないときはサーバー側から調査できる
WordPressで重大なエラーが発生しても、必ずしもホームページのデータが消えているわけではありません。
プラグインやテーマなどの処理で致命的なエラーが発生し、WordPressがページを表示できなくなっている場合があります。
管理画面に入れない場合でも、サーバー側からプラグインを停止したり、デバッグログを確認したりすることで、原因を特定できる可能性があります。
ただし、wp-config.php やプラグインフォルダの操作を誤ると、別の不具合につながることがあります。
作業前には必ずバックアップを取り、自分での操作が難しい場合は、レンタルサーバーのサポートやWordPressに詳しい制作者へ相談しましょう。
まとめ
今回の重大なエラーは、XMLサイトマップを生成するプラグインとWordPressとの互換性が原因と考えられる不具合でした。
実施した対応は次のとおりです。
- 公開ページと管理画面の状態を確認
- サーバーのログやWordPressファイルを調査
- WordPressのデバッグログを一時的に有効化
- エラーを起こしているプラグインを特定
- サーバー側からプラグインを停止
- 公開ページと管理画面の復旧を確認
- WordPress標準のXMLサイトマップを有効化
- デバッグ機能を無効に戻して最終確認
WordPress本体だけを自動更新している場合でも、古いプラグインとの互換性によって突然エラーが発生することがあります。
長期間更新されていないプラグインが残っていないか定期的に確認し、更新前にはバックアップを取っておくことが大切です。
