Webサイトのお助け隊

管理者宛のメールに「あなたのサイトで技術的な問題が発生しています」という件名のメールが届いて、サイトを開くと「重大なエラーが発生しました。」の1行だけが表示される。この状態になったとき、あのメールは邪魔な通知ではなく、いちばん情報量の多い手がかりです。プラグインの名前、エラーメッセージ、ファイルのパスと行番号まで書かれています。読む順番さえ決まっていれば、原因の当たりは数分で付きます。実際に復旧を請けた案件をもとに、メールのどこを見て、次に何を確認するかを順番に並べます。

あのメールは何をしているのか

WordPress 5.2以降には、致命的なエラーを検知したときにサイト全体を落とさないための仕組みが入っています。エラーの原因になったプラグインやテーマを一時的に止め、管理者のメールアドレス宛に通知を送る。訪問者には「重大なエラーが発生しました。」とだけ表示され、内部の情報は出ません。表に出ない代わりに、その中身がメールへ回っていると考えると分かりやすいはずです。

メールに載っているのは、問題が起きたプラグインまたはテーマの名前、エラーの種類とメッセージ、エラーが起きたファイルのパスと行番号、そしてリカバリーモードへ入るためのリンクです。このリンクからは、原因のプラグインが止まった状態で管理画面に入れます。リンクには有効期限があり、既定では1日で切れます。同じ原因について何通も届かないよう送信も制限されているので、「1通しか来ていないから1回しか起きていない」とは限りません。

逆に、メールに書かれていないのが「なぜそうなったか」です。更新したのか、PHPのバージョンが変わったのか、誰かがファイルを編集したのか。ここは自分で埋めるしかなく、しかも原因の切り分けに一番効く情報でもあります。

最初に読むのはファイルのパス

エラーメッセージより先に、ファイルのパスを見ます。wp-content/plugins/ の下ならプラグイン、wp-content/themes/ の下ならテーマ、wp-includes/ や wp-admin/ の下ならWordPress本体です。本体のファイルは普通は壊れませんから、ここが出ている時点で、ファイルの置き間違いか改ざんを疑う段階に入ります。

もう一つ、パスに出るディレクトリ名は内部の名前で、管理画面に表示されている名前とは一致しません。js_composer というディレクトリ名を見て、管理画面のプラグイン一覧から「js_composer」を探しても見つからない。実際の表示名は「WPBakery Visual Composer」です。この対応関係を知らないと、報告を受けた側も「そんなプラグインは入っていない」と答えてしまいます。ログに出るのはディレクトリ名だと覚えておくだけで、無駄なやり取りが消えます。

メッセージ本文は、種類を見分ける程度で十分です。syntax error, unexpected は書き間違い、Call to undefined function は呼ばれている関数が存在しない状態、Allowed memory size of ... exhausted はメモリ不足、must be of the type string, null given のような型に関する記述はPHPのバージョン差で出やすい種類です。行番号まで分かっているので、そのファイルの該当行を開けば、たいていは何が起きたか見当が付きます。ログをどう出して何を読むかは、エラーログの見方と手順の側にまとめています。

直前に何をしたかで、原因はほぼ決まる

プラグインを更新している最中に落ちた

いちばん多いパターンです。管理画面にも入れなくなるので、リカバリーモードのリンクが使えれば話は早いのですが、メールが届いていない場合はFTPで直接止めます。wp-content/plugins/ の中にある該当プラグインのディレクトリ名を、先頭にアンダースコアを付けるなどして変えるだけで、WordPressはそのプラグインを見つけられなくなり、強制的に無効化された状態になります。これが最速の復旧手段です。

夜間に「プラグインを更新したらサイトが表示されなくなった」と連絡を受けた案件では、この方法で1時間ほどで表示が戻りました。どのプラグインが原因かが分からない場合は、plugins ディレクトリごとリネームすれば全プラグインが一度に無効化されます。表示が戻ることを確認してから、元の名前に戻し、1つずつ有効化して犯人を特定します。更新中に落ちたのであれば、そのとき更新していた1つを見れば済みます。

復旧したあとに考えるべきなのは、そのプラグインが本当に必要かどうかです。この案件で止めたのはアクセス計測系のプラグインでしたが、依頼元は検索からの集客をほとんど使っていない業種でした。使っていない機能のために障害の可能性を1つ抱えることになるので、入れ直さずそのままにしています。入れておいて損はない、という判断が常に正しいわけではありません。

PHPのバージョンを上げた、サーバーを移した

白い画面や500エラーとセットで出る場合、直前にPHPのバージョンが上がっていないかを疑います。古いプラグインやテーマが新しいPHPに対応しておらず、読み込まれた時点で落ちる。エラーログとPHPのバージョン、そしてプラグインの最終更新日を突き合わせれば、大半は特定できます。ページビルダー系とバックアップ系のように、単体では動くのに組み合わせると処理が競合して落ちる例もあります。

サーバーを移した直後に「固定ページだけが重大なエラーになり、ログインした状態では真っ白なページが出る」という相談を受けたことがあります。この症状の組み合わせ自体が、そのページのテンプレートで致命的エラーが出ているサインでした。PHP 8.0.30の環境に移したあと、テーマの page.php が非互換のまま残っていたのが原因です。しかも「固定ページが表示されない」のと「外観からメニューに固定ページを追加できない」という一見無関係な2つの症状が、どちらも同じ1ファイルに起因していました。症状を別々に追いかけず、共通して読まれるファイルを探すと一度に解けます。

この種の不具合は、移行のときにテーマ全体の構文チェックを一度かけておけば、公開後ではなく作業中に見つかります。php -l を全ファイルに回す程度でも、致命的な非互換はかなり拾えます。

functions.php を編集した直後

「functions.php を触ったら落ちた」という申告を受けたら、どちらの functions.php を触ったのかを最初に確認します。WordPress本体の wp-includes/functions.php と、テーマの functions.php は名前が同じで、FTPクライアントやサーバーのファイルマネージャーで階層を見誤ると簡単に取り違えます。実際に、本体側のファイルがテーマ用のコードで丸ごと上書きされていた案件がありました。

本体のファイルは正規版で上書きすれば復旧するので、原因の調査より先に差し替えを試すのが最短です。ちなみに、上書きされていた中身のコメントや関数名の接頭辞（hestia_ のような形）から、それがどのテーマのファイルだったかも判別できます。編集で落ちた場合の戻し方はfunctions.phpを編集して落ちたサイトを元に戻す方法にまとめてあります。

この案件では復旧の直後に「トップページの見た目が変わった」という指摘も出ました。上書きされる前のテーマ側の編集内容は失われているため、動くようになっても元の見た目とは違う、ということが起こります。障害対応に入る前に画面を撮っておくと、どこからが自分の作業の影響なのかを示せます。

症状から手を付ける順番

メールが届かない、リンクが切れている場合

通知の宛先は、設定の管理者メールアドレスです。担当が変わったまま古いアドレスが残っていると、誰も気づかないままサイトだけが止まります。サーバーからのメールがそもそも飛ばない環境もあります。この場合はメールを待たず、wp-config.php に WP_DEBUG と WP_DEBUG_LOG を有効にし、WP_DEBUG_DISPLAY を false にして、wp-content/debug.log にエラーを書き出させます。画面には出さずにログだけ残すのが、公開中のサイトでの安全なやり方です。

リカバリーモードのリンクが期限切れになっている場合は、もう一度そのページを開いてエラーを発生させれば、新しいリンクが送られます。なお、エラーの中身をそのまま画面に出したいときは WP_DISABLE_FATAL_ERROR_HANDLER を有効にすると、この保護機能そのものを止められます。調査中の一時的な設定として使い、終わったら必ず戻します。

同じことを繰り返さないために

プラグインの更新は、バックアップを取ってから1つずつ行う。これだけで、落ちたときに原因が確定します。まとめて10個更新して落ちると、切り分けからやり直しになります。自分で更新するのが不安であれば、更新作業ごと保守として預けてしまう方法もあります。

PHPのバージョンを上げるときは、上げてから様子を見るのではなく、先にテーマとプラグインの対応状況を確認します。使っていないプラグインを消しておくのも効きます。停止しているだけのプラグインもファイルは残り、更新の対象として残り続けます。応急処置で止めたまま放置すると、同じ原因で再発するという点も付け加えておきます。プラグインを止めて表示が戻った時点で終わりにせず、なぜ落ちたのかは別途片付けておくのが安全です。

よくある質問

リカバリーモードで止まったプラグインは、有効化して戻していいですか

原因が分かって直っているなら戻します。多いのは、そのプラグインの新しいバージョンが現在のPHPやWordPressのバージョンに合っていない場合で、この状態で有効化しても同じところで落ちます。開発元の更新を待つか、同じ機能の別の手段に置き換えるか、そもそもその機能が今も必要かを判断することになります。

「重大なエラー」と真っ白な画面は、別のものですか

原因は同じ致命的エラーであることがほとんどで、違いは保護機能が働いたかどうかです。エラーの発生場所によっては保護機能まで到達せず、何も出力されないまま白い画面になります。白い画面のときは通知も来ないので、ログを出す設定に切り替えて調べる手順に移ります。

何も操作していないのに突然出ました

自動更新が動いている可能性があります。WordPress本体のマイナーバージョンや、設定によってはプラグインも自動で更新されます。もう一つは、サーバー側でPHPのバージョンが切り替わった場合です。契約中のサーバーの管理画面で、PHPの設定変更の履歴やお知らせを確認すると、日付が一致することがあります。