WordPressを開いたときに「500 Internal Server Error」と表示されても、記事やデータベースが消えたと決まったわけではありません。500は、サーバーが要求を処理している途中で予期しない状態になり、処理を完了できなかったことを示すHTTPステータスです。画面には原因まで出ないため、プラグイン、テーマ、PHP、.htaccess、容量、ファイル所有者などを順番に切り分けます。
復旧を急ぐほど大切なのは、思いついた設定を一度に変えないことです。まずエラーが出たURL・時刻・操作・直前の変更を残し、障害情報とエラーログを確認します。原因に近い一手だけを変更し、表示が戻ったかを確かめます。
500を消すために、全プラグイン停止、PHP変更、.htaccess削除、権限変更、バックアップ復元を同時に行わないでください。どの操作で直ったか分からなくなり、別の障害やデータの巻き戻りを招きます。
この記事では、初心者でも元に戻せる範囲を守りながら、500エラーの原因を絞って復旧する手順を解説します。
先に結論：500エラーは7段階で確認する
| 順番 | 確認すること | 判断できること |
|---|---|---|
| 1 | URL、時刻、操作、表示を記録 | ログと直前の変更を照合できる |
| 2 | サイト全体・管理画面・特定操作を比較 | エラーの範囲を分けられる |
| 3 | サーバー障害、容量、利用上限を確認 | WordPress外の原因を先に除外できる |
| 4 | サーバーとPHPのエラーログを確認 | 失敗したファイルや処理を絞れる |
| 5 | 直前に変えたプラグイン・テーマ・PHPを戻す | 変更起因かを最小操作で確認できる |
| 6 | .htaccess、所有者、権限を確認 | Webサーバー側の設定不整合を探せる |
| 7 | 復旧後に重要機能とログを再確認 | 表示だけ戻った不完全復旧を防げる |
RFC 9110の500 Internal Server Errorでは、サーバーが予期しない状態に遭遇し、要求を処理できなかったと定義されています。つまり500は原因名ではなく結果です。WordPress公式のCommon WordPress errorsも、内部サーバーエラーを複数の候補から調べる出発点として扱っています。
500とよく似たエラーを最初に分ける
| 表示 | 大まかな意味 | 最初の確認先 |
|---|---|---|
| 500 Internal Server Error | サーバー内部で処理を完了できない | 発生時刻、直前の変更、エラーログ |
| 403 Forbidden | 要求は理解されたがアクセスを拒否 | WAF、アクセス制限、ユーザー・ファイル権限 |
| 404 Not Found | URLに対応する資源が見つからない | URL、公開状態、パーマリンク |
| データベース接続確立エラー | WordPressがデータベースへ接続できない | DB障害、接続情報、サーバー状態 |
| 重大なエラー | WordPressがPHPの致命的エラーを検知 | 復旧モード、通知メール、PHPログ |
| メンテナンス中 | 更新処理の保護表示が残っている | 更新の継続・停止、.maintenance |
表示が403ならWordPressの403 Forbiddenを直す確認順、404ならWordPressの404エラーを直す手順へ進んでください。「重大なエラー」と表示される場合は重大なエラーから安全に復旧する方法、データベース接続の表示ならデータベース接続確立エラーの確認順が対象です。
最初に500になる範囲を分ける
サイト全体と管理画面の両方が500になる
トップページ、複数の記事、/wp-admin/がすべて500なら、個別記事の内容より、サーバー障害、PHP起動、共通プラグイン、テーマ、Webサーバー設定、容量不足を優先します。別端末で何度も再読み込みするより、サーバー会社の障害・メンテナンス情報と管理画面の利用状況を確認してください。
公開ページは見えるが管理画面だけ500になる
管理画面だけなら、管理画面で読み込むプラグイン、更新処理、管理用PHP処理、ログイン周辺を確認します。ログイン画面へ到達できない症状が混ざる場合は、WordPress管理画面へ入れないときの安全な確認手順でCookieやリダイレクトも分けてください。
保存・更新・フォーム送信など特定操作だけ500になる
閲覧はできるのに、記事保存、画像処理、プラグイン更新、問い合わせ送信などで500になる場合、その操作で初めて動くPHP処理、REST API、Ajax、外部通信、メモリや実行時間が候補です。失敗した操作名と時刻がログ調査の手掛かりになります。同じ送信を連打すると重複登録や通知の多重送信につながるため、再試行は最小限にします。
特定の1ページだけ500になる
特定ページだけなら、そのページ固有のブロック、ショートコード、テンプレート、クエリ、埋め込みが候補です。ページを削除する前に複製やリビジョンを確保し、問題の直前に追加した要素から小さく戻します。すべてのページへ共通する設定を変えるのは後回しです。
変更前に残す記録
- 500が出た完全なURL
- 発生日時とタイムゾーン
- 閲覧、保存、更新、送信など直前の操作
- 画面に出た全文とスクリーンショット
- サイト全体・管理画面・特定ページでの再現範囲
- 直前に更新・有効化・編集した対象
- 利用中のPHPバージョンとサーバー
- 同時刻のエラーログ、アクセスログ、利用上限の表示
スクリーンショットやログを共有するときは、サーバー内の絶対パス、ユーザー名、IPアドレス、メールアドレス、Cookie、認証情報を隠してください。発生時刻を秒単位まで残せれば、大量のログから該当行を探しやすくなります。
手順1：サーバー障害・容量・利用上限を確認する
複数サイトやサーバー管理画面にも異常がある場合は、WordPressを触る前に障害情報を確認します。ディスク容量やファイル数の上限に達すると、キャッシュ、セッション、更新用ファイル、ログを書けずに処理が失敗することがあります。容量不足なら、内容を確認せずファイルを大量削除するのではなく、不要な古いバックアップや肥大化したログを特定し、保存要否を判断します。
CPUやメモリ、同時実行数などの上限超過が表示されている場合は、発生時刻とアクセス増加、バックアップ、画像変換、バッチ処理を照合します。表示速度や負荷の継続的な問題はWordPressが重い原因を安全な順番で調べる方法、サイト全体の環境情報はWordPressサイトヘルスの見方も役立ちます。
手順2：公開画面にエラー詳細を出さずログを確認する
500の原因に最も近い情報は、画面ではなくサーバーやPHPのエラーログにあります。サーバー管理画面のエラーログ機能を先に使い、発生時刻とURLに近い行を探します。WordPressのデバッグ機能が必要な場合は、WordPress公式のDebugging in WordPressを確認し、ログへの記録と公開画面への表示を分けて扱います。
本番サイトでPHPエラーを訪問者の画面へ表示したままにしないでください。ファイルパスや内部情報が露出するおそれがあります。WordPress公式のDisplay Errorsも、本番環境でのエラー表示を無効にするよう案内しています。
ログで見る箇所
- エラーが発生した日時
- Fatal error、Parse error、memory、timeoutなどの種類
wp-content/pluginsやthemesに続く名前.htaccessやWebサーバー設定に関する記録- No space、quota、permission deniedなど容量・権限の記録
- 同じエラーの繰り返し回数
ログに名前が出たプラグインが必ず悪いとは限りません。別の処理から呼び出された結果、そのファイルで止まった可能性もあります。エラー文、発生操作、直前の変更を組み合わせて判断します。
手順3：直前のプラグイン・テーマ変更を最小限だけ戻す
更新直後から500になり、ログが特定のプラグインを示す場合は、その対象だけを停止または直前の正常版へ戻します。管理画面へ入れないときにフォルダ名を変える操作は全停止ではなく対象限定で行い、元の名前を必ず記録します。復旧後は互換性、提供元の更新情報、再有効化時のログを確認してください。整理の考え方はWordPressプラグインを安全に整理する方法、更新前後の手順はWordPressを安全に更新する順番で詳しく解説しています。
テーマ変更直後なら、子テーマの編集、テンプレート、関数追加、必要プラグインとの組み合わせを確認します。本番でいきなり別テーマへ切り替えると表示や計測が崩れるため、可能ならWordPressのテスト環境で再現し、変更箇所を絞ります。
手順4：PHPの互換性・メモリ・実行時間を確認する
PHP変更後に500が始まった場合は、最新版という言葉だけで判断せず、WordPress本体、テーマ、プラグインの対応状況を確認します。まず変更前のバージョンを記録し、サーバー会社が用意した切り戻し手順を使います。安全な確認項目はWordPressのPHPバージョンを確認・更新する方法にまとめています。
ログにメモリ不足や実行時間超過が出たときは、上限だけを大きくする前に、どの処理が消費しているかを確認します。巨大画像の変換、バックアップ、インポート、複雑な検索、外部API待ちが原因なら、処理対象やプラグイン設定を見直す方が再発防止になります。上限変更が必要でも、契約サーバーの推奨範囲とサポート案内に従います。
手順5：.htaccessとWebサーバー設定を確認する
.htaccessは主にApache系サーバーで使われ、パーマリンク、アクセス制御、PHP設定、リダイレクトなどが書かれます。記述ミスやサーバーで許可されていない命令があると、500の原因になることがあります。Nginxでは通常、同じ役割を別のサーバー設定で行うため、他サイトの.htaccessをコピーしても解決しません。
直前に編集した事実やログの根拠がある場合だけ、現在のファイルをダウンロードしてバックアップし、変更箇所を戻します。パーマリンク再保存でWordPress標準の書き換え規則を再生成する方法もありますが、独自リダイレクトやセキュリティ設定を上書きしないよう内容を比較してください。Apacheでの扱いはWordPress公式のApache HTTPD / .htaccessが参考になります。
.htaccessを確認せず削除したり、検索で見つけた設定をそのまま貼り付けたりしないでください。管理画面、記事URL、HTTPS、アクセス制限が同時に壊れることがあります。
手順6：ファイル所有者と権限を確認する
移行、手動アップロード、復元の後に500が出た場合は、ファイルやフォルダの所有者と権限がサーバー構成に合っているかを確認します。WordPress公式のChanging File Permissionsは、権限が厳しすぎてもサーバーが必要なファイルへアクセスできず、緩すぎても安全性を失うと説明しています。
解決策としてファイルやフォルダを一律777にしないでください。すべての利用者に読み書き・実行を許す状態になり、改ざんや不正ファイル実行の危険が高まります。契約サーバーの標準値と所有者を確認し、不明なら対象パスとエラー時刻を添えてサポートへ依頼します。
移行後の500では、PHPバージョン、拡張機能、公開ディレクトリ、所有者、環境変数も旧サーバーと異なる場合があります。サイト全体を復元し直す前に、WordPress移行前後のチェックリストとサーバーを見直す判断基準を使い、差分を整理します。
復旧後に確認する7項目
- トップページと500が出たURLが開く
- WordPress管理画面へログインできる
- 記事の表示・保存・更新ができる
- 問い合わせ、購入、会員機能など重要操作が動く
- 画像、CSS、JavaScriptが欠けていない
- キャッシュを削除した別ブラウザでも正常
- エラーログに同じ致命的エラーが増えていない
キャッシュに以前の500や古い画面が残ることがあります。原因を直してから、WordPress、サーバー、CDN、ブラウザの順に対象キャッシュを削除します。原因修正前に全キャッシュを何度も消しても復旧にはなりません。安全な範囲はWordPressキャッシュ設定の基本で確認できます。
自分で直せないときにサポートへ伝える情報
- 対象ドメインと完全なURL
- 発生日時とタイムゾーン
- 500が出る範囲と再現操作
- 直前に行った更新・設定変更・移行
- PHPバージョンとWordPressバージョン
- エラーログの該当部分
- 実施した対処と、その後の変化
- 正常だった最後の日時と利用可能なバックアップ
「500です」だけでなく時刻と再現操作を添えると、サーバー側のアクセスログやPHPログと照合しやすくなります。ログ全文には機密情報が含まれる場合があるため、サポートが指定した安全な窓口で送ります。
500エラーを減らす予防策
- 更新前にファイルとデータベースの両方をバックアップする
- 大きな更新やPHP変更はテスト環境で確認する
- プラグイン、テーマ、PHPを放置せず対応状況を見ながら更新する
- 変更日時、変更者、対象、切り戻し方法を記録する
- ディスク容量、エラーログ、サイトヘルスを定期確認する
- 使っていないプラグインや古いバックアップを整理する
- 復元手順を平常時に一度確認する
バックアップは保存しただけで安心せず、復元対象と保管先を確認します。基本はWordPressバックアップの取り方、日常の防御はWordPressセキュリティ設定の基本を参照してください。
よくある質問
再読み込みを続ければ直りますか？
一時的な障害なら戻ることはありますが、原因確認にはなりません。保存や送信の途中だった場合は重複処理の危険もあります。1回比較したら時刻を記録し、障害情報とログを確認してください。
全プラグインを停止するのが最速ですか？
原因が不明な緊急診断で使われることはありますが、フォーム、セキュリティ、キャッシュなど複数機能が同時に止まります。直前の変更とログから対象を絞れるなら、1つずつ確認する方が安全です。全停止する場合も影響を理解し、復旧順と元の有効状態を記録します。
バックアップを丸ごと復元すれば解決しますか？
ファイル破損や設定変更が原因なら有効な場合があります。しかし、サーバー障害、容量不足、PHP環境の変更は復元だけでは直らず、復元時点以降の注文、問い合わせ、投稿を失うおそれもあります。原因と復元範囲、取得日時を確認してから判断してください。
500が自然に消えたら調査は不要ですか？
不要とは限りません。負荷上限、外部APIの一時停止、ディスク逼迫などは再発します。発生時刻のログ、容量、直前の自動処理を確認し、原因候補と再発時の連絡先を残してください。
まとめ
WordPressの500 Internal Server Errorは原因名ではなく、サーバーが処理を完了できなかった結果です。URL・時刻・操作を記録し、発生範囲、サーバー状態、エラーログ、直前の変更、PHP、Webサーバー設定、所有者・権限の順に確認してください。
一度に複数箇所を変えず、元に戻せる一手ずつ進めることが、安全で再現性のある復旧につながります。表示が戻った後も、管理画面、保存、問い合わせなどの重要機能とログを確認して完了です。