画面が真っ白、または「500 Internal Server Error」。原因を決めつけてプラグインやファイルを削除する前に、いつから・どこで起きるかを記録して、安全に切り分けます。
01.最初の5分：障害の範囲と変更履歴を確かめる
トップページだけなのか、全ページなのか、/wp-admin/ も開けないのかを確認します。別のブラウザ・回線でも同じか、エラー番号や発生時刻は何かを記録してください。
直前にWordPress本体、テーマ、プラグイン、PHP、サーバー設定、DNSを変更したか確認します。500系エラーはWordPress内部だけが原因とは限りません。大量の再読み込みや設定変更を繰り返す前に、現在の状態を保全しましょう。
02.管理者へのメールに復旧モードの案内がないか確認
WordPressは一部の致命的なエラーを検出した際、管理者メールにリカバリーモード用リンクを送ることがあります。受信していれば、URLの宛先を確認してアクセスし、問題の原因になったテーマやプラグインの情報を確認します。
メールが来ない場合も、復旧モードが使えないとは限りません。ただし、リンクが届く仕組みに依存しているため、勝手にURLを推測したり不明なリンクを開いたりしないでください。
03.サーバー側のログとバックアップを確認
サーバーのエラーログで、エラー発生時刻と一致するPHPエラー、メモリ不足、権限の問題がないか確認します。ログが見られない場合は契約先のサポートへ問い合わせます。
本番でのデバッグ画面表示は、個人情報や内部のファイルパスを公開してしまうおそれがあります。WordPressのデバッグ設定は公式手順を参照し、原則としてステージング環境での検証や非公開ログで確認してください。
04.プラグイン・テーマの切り分けは複製環境から
ログや発生直前の変更から原因候補を絞り、検証環境で該当プラグインの停止、テーマ切替、PHP構成の再現を試します。必要なプラグインをまとめて停止すると決済・会員・フォームなども動かなくなるため、本番で一括無効化しないことが重要です。
管理画面に入れない場合のFTP操作やディレクトリ名変更は、実施内容によってサービス停止やデータ不整合につながります。バックアップと復旧手順を確認できる管理担当者が実施してください。
05.復旧後に再発防止の記録を残す
原因、発生した組み合わせ、エラーログ、復旧した方法、作業日時、再現手順を記録します。復旧しただけで同じアップデートを本番で繰り返さず、事前の検証環境とバックアップ運用を見直します。
サーバー障害・不正アクセス・データ破損が疑われる場合は、この一般的な手順にこだわらず、契約先のサーバー事業者や専門家へ連絡してください。