目次
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・アップロード・設定を含めたバックアップを自動化し、復元テストも定期的に行いましょう。いざという時、復元できないバックアップは役に立ちません。ステージング環境で更新テスト
本番前にテスト環境で更新し、表示・フォーム・決済・会員機能など重要導線だけでも必ず確認します。これだけで事故率が大きく下がります。更新の運用ルール化
- 更新は営業時間外・事前告知・担当者の立ち会いで実施
- 「更新前チェック（バックアップ/容量/ログ取得）」と「更新後チェック（表示/主要機能）」をテンプレ化
- 不要なプラグイン・停止中テーマは削除（攻撃面もトラブル要因も減る）
