WordPress のプラグイン更新後に突然 500 Internal Server Error が表示されると、サイト運営者は一瞬で身動きが取れなくなります。しかし実際には、500 が発生する場面にはある程度の“型”があり、状況ごとに最適な手順が存在します。復旧のポイントは「何が起きたか」を推測しながら、最短ルートで WordPress を操作できる状態に戻すことです。
ここでは、現場で実際によく起きる 4つの典型ケース を想定しながら、実際にどの順序で操作すればよいかを具体的にまとめます。
◆ ケース1：プラグイン更新ボタンを押した直後に画面が真っ白に
最も多いパターンがこれです。更新処理の途中で PHP がエラーを起こし、WordPress が強制停止した状態と言えます。
▶ 実際にやること（最短ルート）
- FTP または サーバーファイルマネージャにログイン
/wp-content/plugins/を開く- 更新したプラグインのフォルダを見つける
- フォルダ名を
plugin-name_disabledにリネーム - サイトを再読み込み
→ ほぼこの段階でサイトか管理画面が復帰します。
▶ 復帰後にやること
- 管理画面に入れたら、該当プラグインを削除して再インストール
ツール > サイトヘルス > 情報で PHP バージョンや互換性を確認
▶ このケースの背景
更新中にファイルが壊れた、あるいは PHP の互換性に問題が出た可能性が高いです。
◆ ケース2：更新は完了したが、数分後に管理画面だけ 500 になる
このパターンは「バックグラウンドでプラグインが動いた結果、競合が発生した」場合に多く見られます。
▶ 実際にやること
- 同じくプラグインフォルダを一つずつ一時停止する
（怪しそうなキャッシュ系・最適化系から順番に） - 停止した瞬間にダッシュボードが復帰すれば“犯人”が特定できる
▶ このケースで特に疑うべきプラグイン
- キャッシュ系（LiteSpeed Cache / W3TC / WP Super Cache）
- 最適化系（Autoptimize / Fast Velocity Minify）
- セキュリティ系（Wordfence など）
▶ 復帰後にやること
- キャッシュを完全削除
- 設定を一旦デフォルトに戻す
- プラグインの最新版の安定性を調べる（過去24時間のサポートフォーラムが参考になります）
◆ ケース3：更新後に商品ページだけ 500（ECサイトで多発）
WooCommerce や EC プラグインの更新後に部分的な 500 が出るのは定番です。
▶ 実際にやること
- WooCommerce のアドオン（支払い、送料、拡張プラグイン）を一つずつ停止
- テーマ互換性の確認
woocommerce/templatesのオーバーライドが古くないか確認
▶ よくある原因
- 古いテーマが新しい WooCommerce テンプレートに対応していない
- PHP8.2 で非推奨関数を使っているアドオンが落ちる
- カート系の JS 最適化でスクリプトが壊れる
◆ ケース4：更新後、サイト全体の 500 がランダムに発生する
これは メモリ不足 が非常に疑わしいです。
▶ 実際にやること
wp-config.phpに追加define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );- サーバー側の PHP メモリ制限を確認（Xserver/ConoHa 等は管理画面から変更可）
- キャッシュを削除し、プラグインを再アクティブ化して負荷がかからないかチェック
▶ ランダム 500 が出る背景
メモリがギリギリの場合、ページによって処理量が変わるため、状況によって落ちたり動いたりを繰り返します。
◆ 全ケース共通：復旧後に絶対やるべき再発防止策
① キャッシュプラグインは 1 種類にする
複数共存は 500 の温床。
② 更新前に PHP バージョン互換性を確認
古いプラグインは PHP8 に弱い。
③ 自動更新はむやみに ON にしない
深夜に 500 → 朝まで気づかないケース、多いです。
④ 週1回は error_log を確認
前兆がほぼ必ず残ります。
