最初に確認すること
トップだけか全ページか、管理画面も同じか、特定の操作で起きるかを確認します。時刻とURL、画面、最近の更新を記録します。外部サービスの障害情報とサーバー稼働も確認し、更新ボタンの連打や設定の同時変更を止めます。
原因ごとの手掛かり
| 原因候補 | 調べる情報 |
|---|---|
| PHP Fatal Error | PHPログのメッセージ・ファイル・行 |
| メモリ不足 | Allowed memory size、対象処理、上限 |
| 設定エラー | Webサーバーログ、直前の設定変更 |
| ファイル・権限 | 所有者、配置、更新失敗の記録 |
| 製品の競合 | 更新履歴、依存先、検証環境での再現 |
エラーログから対象を絞る
サーバー会社が提供するPHP・Webサーバーのエラーログを確認します。WordPressのデバッグを使う場合も、画面へ詳細を表示せず、公開されない保存先と閲覧権限を確保します。ログがないことを、エラーがない証拠にはしません。別のPHP実行系や記録設定を確認します。
復旧を進める手順
- 現状のファイル・DB・設定・ログを保存する。
- 直前の一変更を検証環境で戻して再現を確認する。
- 原因製品の停止、設定の差戻し、正常なデータの復元を選ぶ。
- 管理画面と公開ページ、問題の操作を再確認する。
- ログに同じエラーが増えていないか確認する。
管理画面が開かない場合でも、サーバー側から対応できる経路を使います。ただしアクセス制御や決済製品を止めるなら、公開範囲と取引への影響を先に判断します。
避けたい対処と相談の目安
根拠なくメモリを大幅に増やす、全ファイルを777にする、.htaccessを控えなく消すといった対処は避けます。複数サイトへの影響やサーバー設定の問題なら、サーバー会社と連携します。相談時は秘密情報を除いたログと変更履歴を渡すと原因を絞りやすくなります。
ログの文面から次の調査を決める
Undefined functionなら、必要なコードが読み込まれていない、削除された関数を使っている、依存製品が停止しているなどを調べます。TypeErrorなら呼出し元と引数を確認します。Allowed memory sizeなら上限と消費処理を確認し、上限を上げる前に大量データや再帰などの原因を調べます。ファイル名がプラグイン配下でも、それだけでその製品単独の不良とは断定できません。テーマや別製品から想定外の値を渡された可能性もあります。変更前後の構成を検証先で比較すると、依存関係を調べやすくなります。
連絡・復旧・再発防止を記録する
復旧を優先して直前の変更を戻した場合も、復旧時刻、差戻しの範囲、残る脆弱性、今後の改修を記録します。サーバー会社へ依頼する場合は、対象ホスト、時刻、URL、ログの要点を渡します。コード修正とサーバー設定の両方に関係する場合は、担当を分けたまま情報を共有します。
500なら必ずプラグインが原因ですか？
いいえ。Webサーバー設定、PHP、容量、権限などでも起こります。ログと発生条件から絞ってください。
エラーを非表示にすれば直りますか？
原因は解消しません。利用者への詳細露出を防ぐことと、停止した処理を修正することは別です。記録先を保護したうえで調査します。