WordPress更新後、サイトが表示されない！まず何をすべき？
WordPressの更新はセキュリティ面で重要な部分ですが、更新直後に
真っ白（WSOD）・
「重大なエラー」・
500エラーなどでサイトが表示されなくなることがあります。焦って触り続けるほど状況が悪化しやすいので、
「影響範囲の確認 → ログの確保 → いったん復旧 → 原因特定」の順で進めるのが安全です。
- 先に復旧：プラグイン／テーマ停止、PHP調整、メンテナンスモード解除で表示を戻す
- あとで原因特定：どの更新が引き金だったか、再現条件を潰す
- 再発防止：バックアップ、ステージング、更新手順の標準化
よくある原因
- プラグインの競合／互換性：更新後に致命的エラー、管理画面にも入れないことがある
- テーマの互換性：特定ページだけ崩れる／真っ白になる／JSエラーが連鎖
- PHPバージョン不一致：古すぎても新しすぎても落ちる（特に古いテーマ・プラグイン）
- メモリ不足：更新をきっかけに「Allowed memory size…」などが出る
- 更新途中の中断・ファイル破損：通信不安定、権限、容量不足などでコアが不完全に
- メンテナンスモードが解除されない：更新中断で
.maintenance が残る
- キャッシュの悪さ：CDN／キャッシュ系プラグインで古い状態が残り直ってないように見える
最初にやる「切り分け」チェック
- 影響範囲：トップだけ？全ページ？管理画面（/wp-admin）も不可ですか？
- 表示されるエラー文：真っ白／重大なエラー／500／404 など（スクショ推奨）
- 直前にやった更新：WordPress本体／プラグイン／テーマ／PHP変更のどれか
- サーバー側の状態：ディスク容量、WAF、障害情報、エラーログ
- バックアップ有無：最終バックアップ日時（復元の判断が早くなる）
すぐ試す復旧手順
1) キャッシュとメンテナンスモードを確認
まずは「直っているのに見えていない」パターンを潰します。
- ブラウザキャッシュ：シークレットウィンドウで確認
- CDN/キャッシュ系：CDNやキャッシュプラグインのキャッシュ削除
- .maintenance：FTP/ファイルマネージャーでサイト直下に
.maintenance が残っていれば削除
2) 「リカバリーモード」のメールが来ていないか確認
WordPressは致命的エラー検知時に、管理者メールへ
リカバリーモード用リンクを送ることがあります。メールが来ていれば、リンクからログインして原因のプラグイン／テーマを停止できる可能性があります。
3) エラーの「証拠」を残す
原因特定の最短ルートはログです。表示が真っ白でも、ログには原因が出ていることが多いです。
- サーバーのエラーログ（管理画面やコントロールパネル）を確認
- WP_DEBUGは「画面表示」よりログ出力を推奨
※ログ出力先の定番は
/wp-content/debug.log です（設定により異なる場合あり）。
4) プラグインを一括停止
更新後トラブルの原因で最も多いのがプラグインです。管理画面に入れない場合でも、FTP/ファイルマネージャーから一括停止できます。
wp-content/plugins を plugins_old などにリネーム → 全プラグイン停止- 表示が戻ったら、フォルダ名を元に戻す
- 管理画面からプラグインを1つずつ有効化して原因を特定
5) テーマをデフォルトに切り替える
プラグイン停止で直らない場合は、テーマ互換性の可能性があります。FTPで現在のテーマフォルダ名を変更すると、WordPressがデフォルトテーマへ切り替わることがあります。
wp-content/themes/使用中テーマ をリネーム- デフォルトテーマ（例：Twenty Twenty-Four）が入っていることを確認
- 表示が戻れば、原因はテーマ側（functions.php の互換性や古い記述など）
6) PHPバージョンを調整
PHPが原因の場合、
「いったん一つ前のPHPへ」で復旧するケースが多いです。レンタルサーバーの管理画面でPHPを切り替え、表示を確認してください。
- 直前にPHPを上げた → いったん戻して表示確認
- PHPが古いまま → 推奨帯へ段階的に上げて確認
7) メモリ不足を疑う
更新を機に負荷が増え、メモリ上限に当たることがあります。ログにメモリ不足が出ている場合は、WordPress側（
WP_MEMORY_LIMIT）とサーバー側（PHPの
memory_limit）の両面で確認します。
8) コアファイルの再配置
更新途中で止まった形跡がある場合は、
WordPressコアの再配置で復旧することがあります。一般には
wp-admin と
wp-includes を正しいバージョンで上書きし、
wp-content は触らないのが基本です。
9) バックアップから復元
ここまでで解決しない／復旧優先度が高い場合は、
更新前バックアップへ復元が最も確実です。復元後に、ステージング環境で更新を再実施し、原因を潰してから本番へ反映する流れが安全です。
原因特定をラクにするコツ
- 更新履歴を残す：いつ・何を更新したか（本体/プラグイン/テーマ/PHP）
- プラグインは「一つずつ」戻す：一気に戻すと原因が特定できない
- Site Health（サイトヘルス）で環境の指摘を確認
- Health Check & Troubleshootingで安全に切り分け（本番ユーザーへの影響を最小化しやすい）
更新トラブルを未然に防ぐ恒久対策
定期バックアップ
本体・DB・アップロード・設定を含めたバックアップを自動化し、
復元テストも定期的に行いましょう。いざという時、復元できないバックアップは役に立ちません。
ステージング環境で更新テスト
本番前にテスト環境で更新し、表示・フォーム・決済・会員機能など
重要導線だけでも必ず確認します。これだけで事故率が大きく下がります。
更新の運用ルール化
- 更新は営業時間外・事前告知・担当者の立ち会いで実施
- 「更新前チェック（バックアップ/容量/ログ取得）」と「更新後チェック（表示/主要機能）」をテンプレ化
- 不要なプラグイン・停止中テーマは削除（攻撃面もトラブル要因も減る）
PHPは段階的に上げる
PHPは一気に最新へ上げず、
段階的に上げて検証するのが安全です。古いテーマ・プラグインほど影響を受けやすいので、更新計画とセットで管理しましょう。
まとめ：復旧は「停止→表示を戻す→原因特定」の順が最短
WordPress更新後にサイトが表示されない場合、まずは
キャッシュ/メンテナンスモードを確認し、次に
ログ確保、そして
プラグイン→テーマ→PHPの順で切り分けるのが最短です。復旧後は、ステージング環境・バックアップ・更新手順の標準化で、同様の事故を大幅に減らすことができます。
自力での特定が難しい／事業影響が大きい場合は、無理に触り続けず、保守・復旧の専門家へ相談するのも有効ですよ。
参考リンク
