WordPressで重大なエラーが発生した時の原因と復旧手順

WordPressで重大なエラーが発生した時の原因と復旧手順

WordPressで重大なエラーが発生した時の原因と復旧手順

WordPressで「このサイトで重大なエラーが発生しました」と表示され管理画面にもログインできない場合、まず試すべきはサーバーのエラーログ確認と、FTPを使った原因プラグインの強制停止だ。管理用メールが届かなくても、手動の切り分け作業でサイトを復旧できる。

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

なぜ「このサイトで重大なエラーが発生しました」と表示されログイン不能になるのか

あのメッセージが表示されるとき、WordPress内部ではPHPの「致命的エラー(Fatal Error)」が起きている。プログラムの処理がそこで停止してしまい、画面表示が途中で終わる。テーマやプラグインの更新失敗、PHPバージョンの非互換、サーバーのメモリ上限超過、あるいはコアファイルの破損など原因は多岐にわたる。

WordPress 5.2以降、致命的エラーが起きると管理画面へのログインも止められる設計になった。これは「壊れかけのサイトを操作し続けて被害を拡大させない」ための安全措置だ。通常なら「サイトに技術的な問題が発生しました。復旧手順のリンクを管理者メールアドレスに送信しました」という案内とともに「回復モード」用のリンクがメールで届く仕組みになっている。

ただ、このメールが届かないケースは実際には非常に多い。メールサーバーの設定不備や、そもそも通知を受け取る管理者アドレスが存在しないサイトもある。つまり「メールが届かない=打つ手がない」わけではない。手動での復旧手順を覚えておけば、すぐに対処できる。

管理用メールが届かなくてもエラーの原因を特定する手順

管理用メールが届かなくてもエラーの原因を特定する手順

原因を特定できないまま闇雲に操作すると、状況をさらに悪化させかねない。まずは「一体どのファイルの何行目で止まっているのか」という技術情報を掴む必要がある。

サーバーのエラーログを最優先で確認する

「重大なエラー」の原因は、ほとんどの場合サーバー上の「エラーログ」に明瞭に記録されている。エックスサーバー、ConoHa WING、さくらのレンタルサーバなど国内の主要レンタルサーバーなら、コントロールパネル内の「エラーログ」や「アクセスログ」といったメニューから確認可能だ。cPanel系であれば「Errors」アイコンから辿れる。

  • ログには「PHP Fatal error」という文言と、問題が起きたファイルのパス(/home/…/plugins/xxxx/xxxx.php on line 123 など)が刻まれている
  • ここでプラグイン名が明記されていれば原因はほぼ特定できたも同然だ
  • もしログの見方が分からない場合は、「エラーログをダウンロードして全文をテキストエディタで開き、Fatal で検索する」とよい

wp-config.php で WP_DEBUG を有効にしてエラーを画面表示させる

エラーログがすぐに見つからない・もしくはより直感的に原因を掴みたい場合は、WordPressのデバッグモードを有効にする。FTPソフト(FileZillaなど)か、サーバーのファイルマネージャーで WordPress インストールディレクトリ直下の wp-config.php ファイルに以下の行を追加する。

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

この設定でエラー情報は /wp-content/debug.log に書き出される。ブラウザ上でサイトを再読込し、その後このログファイルを開けば、先ほどと同じように原因ファイルを特定できる。WP_DEBUG_DISPLAYtrue にすると画面に直接エラーが表示されるが、一般の訪問者にも見えてしまうので本番環境での使用は推奨しない。問題を解決したあとは false に戻すか、行ごと削除すること。

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

FTPやファイルマネージャーで原因のプラグインやテーマを強制停止する

原因が特定のプラグインやテーマだと判明したら、管理画面に戻らなくても手動で無効化できる。管理画面を経由せず、ファイル名の変更で読み込ませないようにする手法だ。これでサイトの表示や管理画面へのアクセスが復活する。

STEP 1 サーバーのエラーログを確認する
STEP 2 wp-config.php に WP_DEBUG 設定を追記する
STEP 3 エラーメッセージから原因プラグインを特定する
STEP 4 該当プラグインをリネームして無効化する

原因プラグインのフォルダをリネームする

FTPソフトまたはレンタルサーバーのファイルマネージャーで、WordPress のインストール先に移動し、/wp-content/plugins/ ディレクトリを開く。エラーログに書かれていたプラグイン名と一致するフォルダを見つけて、名前を変更する。末尾に「_deactivated」や「_bk」などを付け足せばよい。

  • 変更前: problem-plugin
  • 変更後: problem-plugin_deactivated

WordPress はフォルダ名が一致しないプラグインを読み込まなくなる。結果、致命的エラーの原因が取り除かれ、サイトは無事に表示されるようになる。管理画面にも再びログイン可能になる。

すべてのプラグインを一括で疑う場合の方法

エラーログ上でプラグイン名が特定できないが、何らかのプラグインが原因であることは間違いない場合、/wp-content/plugins/ フォルダそのものをリネームしてしまう手もある。たとえば pluginsplugins_stop に変更すれば、すべてのプラグインが一括で無効化される。その状態で管理画面にログインできれば、原因はやはりプラグインなので、フォルダ名を元に戻し、管理画面から一つずつ有効化していく。テーマが原因と疑われる場合は、/wp-content/themes/ 以下の現在のテーマフォルダをリネームする。WordPress はテーマが存在しないとデフォルトテーマ(Twenty Twenty-Five など)に自動で切り替わる。

復旧後に必ずやっておくべき再発防止策

復旧後に必ずやっておくべき再発防止策

サイトが無事に表示され管理画面にも入れたら、そのまま運用を再開するのではなく、必ず以下の3つをチェックする。これで同じエラーが二度と起きにくくなる。

WordPress本体、テーマ、プラグインをすべて最新にする

致命的エラーは「古いソフトウェア」と「最新のPHPバージョン」の組み合わせで起きやすい。更新が止まっている長期放置プラグインが混ざっているなら、代替のメンテナンスされているプラグインへの移行を検討する。

PHPバージョンをサーバー管理画面で上げる

WordPress の推奨する PHP バージョンは常に上がっている。サーバーのコントロールパネルで PHP 8.1 以上に設定変更できるか確認する。変更後はサイト全体の動作確認を必ず行う。

WP_DEBUG の設定を本番環境で必ず解除する

wp-config.php にデバッグ設定を追加していた場合、必ず define( 'WP_DEBUG', false ); に戻すか、該当行を削除する。ログ出力を有効にしたまま運用すると、サーバーのディスク容量を圧迫し、別のトラブルを引き起こす。

よくある質問

管理画面の「回復モード」リンクがメールで届かない理由は

主な原因はサイトのメール送信機能そのものが正常に動いていないことだ。特に共用サーバーでは PHP の mail() 関数が制限されているか、WordPress の送信メールが迷惑メールフォルダに分類されている。SMTPプラグインなどで送信経路を信頼性の高いものに変えれば、次回以降の通知は確実に届くようになる。

WordPressログイン画面自体が表示されない場合の対処法は

管理画面へのアクセスすら致命的エラーで遮断されているという状態だ。まず前述の FTP を使ったプラグイン一括停止を試す。それでも改善しないなら、.htaccess ファイルの破損も疑って、ファイル名を .htaccess_bk に変更し、WordPress 管理画面の「設定」→「パーマリンク」で再生成させる。

FTPパスワードがわからないが復旧できるか

レンタルサーバーのコントロールパネルにログインできれば、多くの場合ブラウザ上で操作できる「ファイルマネージャー」が利用可能だ。FTPアカウントの情報が不明でも、ファイルマネージャーさえ使えれば全く同じ手順でプラグインフォルダのリネームができる。

すべてのプラグインを停止してもエラーが消えない

テーマが原因の可能性が高い。FTPで /wp-content/themes/ 以下の現在のテーマフォルダをリネームする。また、WordPress のコアファイルが破損していることもある。「ダッシュボード」→「更新」から WordPress の「再インストール」を実行すれば、コアファイルが上書き修復される。

WP_DEBUG を設定したが debug.log に何も記録されない

サーバー側で PHP エラーログの出力先が別に固定されているケースだ。その場合、レンタルサーバーのコントロールパネルに用意されている「エラーログ」機能に、より詳細な情報が出ている。そこを確認すれば解決の糸口がつかみやすい。また、wp-config.php の記述場所が /* That's all, stop editing! */ より上にあるかも確認する。

この記事のポイント

  • 「重大なエラー」はPHPの致命的エラーが原因で起こる
  • メールが届かなくてもサーバーのエラーログで原因を特定できる
  • FTPやファイルマネージャーでプラグインフォルダをリネームして停止する
  • 復旧後はPHPバージョンの確認とWP_DEBUGの解除が必須
佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化 ・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門 ・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標 ・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意 ・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

メッセージを残す