WordPress の更新後に Fatal error が出ると、つい「原因を完全に直すこと」だけに意識が向きます。もちろん最終的にはそこまで必要です。ただ、実際の運用では順番を間違えると、調査しているあいだずっとサイトが見られないままになります。
まず守るべきなのは、原因の完全解明より先に、サイトを閲覧できる状態へ戻すことです。公開サイトである以上、最初の判断軸は「何が壊れたか」だけではなく、「利用者が今もサイトを見られるか」であるべきです。
Fatal error への対応は、
1. まず閲覧不能の時間を短くする
2. 次に原因を切り分ける
3. 最後に恒久対応する
の順で考えると、現場で迷いにくくなります。
Fatal error は「原因」ではなく「結果」
WordPress で Fatal error が出たとき、画面に見えているのはあくまで結果です。原因はさまざまで、たとえば次のようなものがあります。
- PHP バージョンとプラグインの互換性不一致
- 更新後のプラグイン同士の衝突
- テーマや独自コードが古い関数を呼び出している
- メモリ不足や依存ライブラリの読み込み失敗
- 更新途中のファイル不整合
この時点で「どれが原因か」をすぐに断定できるとは限りません。ログを見れば候補は絞れますが、調査には時間がかかることもあります。
そのあいだ、サイト全体が白画面のままでよいかというと、もちろん違います。だからこそ、障害対応では「完全に直す」と「まず見られるようにする」を分けて考える必要があります。
最初に守るべきは、サイトの閲覧可能性
企業サイトや店舗サイトでは、WordPress は単なる管理画面ではありません。問い合わせ導線、サービス説明、採用情報、営業時間、地図、実績紹介など、外部との接点そのものです。
Fatal error の原因追及を優先しすぎると、技術的には真面目でも、事業上は損失が広がります。
たとえば、更新直後に特定プラグインが Fatal error を起こした場合、状況によってはファイルをすべて元に戻すより、まずそのプラグインを停止してフロント側の表示を回復させるほうが合理的です。フォームや一部機能が一時的に使えなくなるとしても、サイト全体が見られない状態よりは被害を小さくできます。
ここで大切なのは、「正常か異常か」の二択ではなく、何を優先して守るかを決めることです。
| 状態 | 優先する判断 |
|---|---|
| サイト全体が Fatal error で見られない | まず表示復旧を優先 |
| 一部機能だけ異常 | 影響範囲を見て継続可否を判断 |
| 管理画面だけ異常 | フロント表示と更新作業への影響を分けて確認 |
| 原因が特定済み | 恒久対応まで進める |
まず止める、戻す、どちらを選ぶか
Fatal error が更新直後に出たとき、現場では大きく2つの選択肢があります。
1. 問題を起こしたプラグインを止める
どのプラグインが原因か分かっている、または更新直後の1件に絞れているなら、まず停止してサイトを見られる状態へ戻す判断があります。
wp plugin deactivate plugin-slugこの方法の利点は速さです。特定機能は一時停止しますが、サイト全体の閲覧不能を短くできます。特に、原因プラグインの旧バージョンがすぐに用意できない場合や、更新前バージョンが不明な場合には現実的です。
2. 更新したファイルを戻す
更新前バージョンを把握できていて、問題の起きた対象が明確なら、旧バージョンへ戻すほうがよい場面もあります。
wp plugin install plugin-slug --version=1.2.3 --forceこちらは機能を保ったまま復旧できる可能性があります。ただし、戻す対象を誤ると無関係な更新まで巻き戻したり、DB 側との整合性を崩したりするおそれがあります。
つまり、「停止」と「ロールバック」は優劣ではなく、状況に応じた使い分けです。
なぜ一括更新だと判断しづらくなるのか
ここで効いてくるのが、以前の記事でも触れた「ステップごと更新」です。
複数プラグインを一括更新したあとで Fatal error が出ると、どれが原因かを切り分けるところから始まります。一方、1件ずつ更新して、そのたびに HTTP チェックや表示確認を挟んでいれば、問題を起こした対象をかなり狭くできます。
この差は、障害時の対応速度にそのまま出ます。
- 原因候補が5件ある
- 原因候補が直前に更新した1件だけ
この2つでは、復旧までの迷いの量がまったく違います。
Fatal error 対応は、起きてからの技術力だけでなく、起きたときに迷わないように更新手順を設計していたかでかなり差がつきます。
HTTP 500 を見たら終わりではない
Fatal error が起きると HTTP 500 になることは多いですが、500 が返った瞬間に「はい異常」と記録して終わりでは不十分です。
確認したいのは、少なくとも次の4点です。
- どの更新の直後に起きたか
- フロントと管理画面のどちらに影響があるか
- 停止とロールバックのどちらが早く安全か
- 復旧後に、同じ条件で再発しないか
たとえば、更新前バージョンが分かるプラグインなら旧版へ戻す。分からないなら、まず wp plugin deactivate で閲覧可能性を回復させる。さらに復旧後は、単に HTTP 200 に戻っただけで安心せず、表示崩れや主要導線も見直す必要があります。
Fatal error は派手なので目立ちますが、復旧後の確認が雑だと「白画面ではないが壊れている」状態を残します。
現場で迷いにくい対応順
実務では、次の順番にしておくとかなり判断しやすくなります。
- 直前に何を更新したか確認する
- HTTP ステータスと画面表示を確認する
- 原因候補が1件に絞れているか見る
- 1件に絞れていれば、停止かロールバックかを選ぶ
- サイトが再び見られることを確認する
- 管理画面、主要ページ、問い合わせ導線を確認する
- その後で、恒久対応や再更新の方針を決める
この流れにしておくと、障害対応が「場当たり的な復旧」ではなく、記録できる保守作業になります。
完全復旧より先に、被害を広げない
Fatal error が起きたとき、技術者としては原因を突き止めたくなります。これは自然です。ただ、公開サイトの運用では、利用者から見れば「なぜ壊れたか」より「今見られるか」のほうが先です。
だからこそ、まず守るべきものはサイトの閲覧可能性です。そのうえで原因を切り分け、必要なら旧版へ戻し、再発防止まで進める。この順番を崩さないことが、WordPress 保守ではかなり大切です。
「完全に直す」力だけでなく、「どこまでを先に守るべきか」を決める力も、保守の品質の一部です。
