Hara Daizo WordPressで500 Internal Server Errorが表示された場合、HTTPコードだけでは原因を特定できません。500は、サーバーが予期しない状態に遭遇し、リクエストを処理できなかったときの汎用エラーです。
そのため、設定を片端から変えるより、直前の変更とエラーログを先に確認する方が復旧しやすくなります。ほかのHTTPコードとの違いはWordPressのHTTPエラー一覧を参照してください。
WordPressの500 Internal Server Errorとは
500 Internal Server Errorは、サーバー内部で予期しない状態が発生して処理を完了できなかったことを示します。「WordPress本体が壊れた」という意味に限定されません。
WordPressサイトでは、PHPのFatal error、プラグイン・テーマ、.htaccess、メモリ不足、Webサーバー設定などが引き金になることがあります。まずログから具体的なエラーを探します。
500エラーが出たら最初に確認すること
作業前に次を記録します。
- 500になった正確なURL
- 発生日時
- サイト全体か特定ページか
wp-adminへ入れるか- 直前に更新したWordPress・テーマ・プラグイン・PHP
- ホスティング側の障害情報
ファイルや設定を変更する前に、復旧できるWordPressのバックアップがあるかも確認します。
エラーログで原因を確認する
500は原因を隠したまま返されることが多いため、ログ確認が最優先です。PHPエラーメッセージを公開画面へ表示し続けるのではなく、ログへ記録して調査します。
WordPressのデバッグログを確認する
検証中だけwp-config.phpでWordPressデバッグを有効にし、画面表示を抑えながらログへ記録できます。
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );通常はwp-content/debug.logへ記録されます。ログにはファイルパスや機密情報が含まれる可能性があるため公開しないでください。原因確認が終わったら、常時デバッグが不要な本番サイトでは設定を元に戻します。
レンタルサーバーのエラーログを確認する
WordPressが起動する前に500になっている場合、debug.logへ残らないことがあります。その場合はWebサーバーやPHPのエラーログを確認します。
「500が出た時刻」と「ログの時刻」を合わせるのがポイントです。古いエラーを現在の原因と誤認しないようにします。
.htaccess・パーマリンクを確認する
ApacheやLiteSpeed系では、.htaccessの記述ミスやrewriteの問題で500になることがあります。編集した直後なら、バックアップとの差分を確認します。
WordPress管理画面へ入れる場合は、.htaccessを直接書き直す前にパーマリンク設定とサーバー構成を確認してください。Nginx環境では通常.htaccessを使いません。
プラグイン・テーマを切り分ける
プラグインやテーマの更新直後に500になった場合、該当ソフトウェアとPHPの互換性、Fatal error、競合を疑います。
管理画面へ入れるなら直前に更新したものから検証環境で停止します。管理画面へ入れない場合は、SFTPやホスティングのファイルマネージャーで対象プラグインのディレクトリ名を一時変更するなど、元に戻せる方法で切り分けます。削除してしまうと設定や復旧判断が難しくなるため避けます。
テーマを切り分ける場合も、本番で安易にテーマを切り替えるとウィジェットや表示設定へ影響することがあります。バックアップと検証環境を優先します。
PHPバージョン・メモリ・Fatal errorを確認する
PHPのバージョン変更、古いコードとの非互換、メモリ不足、実行時間超過などが500につながる場合があります。
エラーログにPHPのFatal errorやAllowed memory sizeなど具体的な記録があれば、その内容を基に修正します。原因を確認せずメモリ上限だけを大きくしても、根本原因が重い処理やループなら再発します。
PHPの変更手順と互換性確認はWordPressのPHPバージョン確認・更新を参照してください。
WordPressコアファイルの破損を確認する
更新途中の失敗や不完全なファイル転送でWordPressコアが欠けている場合もあります。ただし、コア再インストールは最初の一手ではありません。
プラグイン・テーマ・PHP・ログを確認しても原因が見つからず、コア破損が疑われる場合に、バックアップを確保して公式配布ファイルとの照合や再配置を検討します。WP-CLIを利用できる環境なら、コアのチェックサム検証も選択肢です。
wp-contentやwp-config.phpはサイト固有データなので、コア再配置の際に上書き対象を誤らないようにします。
管理画面にも入れない場合の対処
管理画面も500になるときは、WordPressの画面操作だけで切り分けられません。
- ホスティングの障害情報を確認
- サーバー・PHPエラーログを確認
- SFTPまたはファイルマネージャーで直前変更を確認
- プラグイン・テーマを元に戻せる方法で切り分け
.htaccessやPHP設定の変更履歴を確認- 必要ならバックアップから復元
復元する場合は、どの時点までデータが戻るかを確認してから実行します。
500エラーと真っ白画面の違い
画面が真っ白でも、裏では500が返っている場合があります。一方、HTMLは200で返っているのにCSSやテンプレートの問題で何も見えないケースもあります。
レスポンスコードを確認し、白画面そのものの切り分けはWordPressが真っ白になった場合の対処を参照してください。
解決しない場合にサーバーへ伝える情報
ホスティングへ問い合わせる場合は、対象URL、発生日時、500のレスポンス、直前変更、PHPバージョン、エラーログの該当行をまとめます。
「500です」だけより、再現条件とログがある方がWebサーバー、PHP、WordPressのどこで失敗しているかを特定しやすくなります。
よくある質問
最初にログと直前変更を確認します。停止が必要な場合も、直前に更新したものから切り分ける方が影響を抑えられます。本番で一度に全停止すると別機能まで止まるため注意してください。
ログにメモリ不足が記録されている場合は有効なことがありますが、500の原因は他にもあります。原因不明のまま上限だけを増やす方法は適切ではありません。
本番での常時有効化は推奨しません。調査中だけログ取得に使い、画面表示は抑え、原因確認後は通常の設定へ戻します。
まとめ
WordPressの500 Internal Server Errorは、コードだけでは原因を特定できない汎用エラーです。直前の変更とログを先に確認し、その後.htaccess、プラグイン、テーマ、PHP、コアの順に切り分けます。
元に戻せる状態を確保し、複数の設定を同時に変更しないことが、復旧時間を短くするポイントです。