WordPressの500 Internal Server Errorは、画面には理由が出ませんが、原因はほぼ例外なくサーバーかPHPのエラーログに記録されています。闇雲にプラグインを消すより、ログを1行読むほうが早く、迷わずに原因へたどり着けます。この記事を読むと、ログの場所を見つけて原因を特定し、プラグイン・テーマ・.htaccess・メモリ・PHPのバージョンといった代表的な原因ごとに対処できるようになります。
500エラーの正体
500は「サーバー内部で処理が失敗した」ことを示すだけの、非常に大まかなステータスです。WordPressでよくある原因は次のとおりです。
- プラグインやテーマのPHPの致命的エラー（Fatal error）
- PHPのメモリ上限の超過
.htaccessの記述ミスや、その環境で使えない命令- PHPのバージョンアップ後に、古いコードが動かなくなった
- ファイルの権限や所有者の誤り
どれも画面上は同じ500ですが、ログには原因ごとに異なるメッセージが残ります。
「重大なエラーが発生しました」と表示される場合
WordPress 5.2以降では、PHPの致命的エラーが起きると、真っ白な画面ではなく「このサイトで重大なエラーが発生しました」という画面と500ステータスを返します。このとき、管理者のメールアドレス宛てに、原因となったプラグインやテーマの名前と、リカバリーモードへのリンクを記載したメールが届くことがあります。
リカバリーモードでログインすると、エラーの原因になっているプラグインやテーマだけが一時停止された状態で管理画面に入れます。メールが届いていれば、まずこれを使うのが一番安全です。届かない場合（サーバーがメールを送れない環境など）は、次の手順でログから原因を探します。
手順1：エラーログを確認する
ログの場所は環境によって異なります。VPSやクラウドの一般的な場所は次のとおりです。
# Apache（Debian/Ubuntu）
sudo tail -50 /var/log/apache2/error.log
# Nginx（PHPのエラーはphp-fpm経由でここに出ることも多い）
sudo tail -50 /var/log/nginx/error.log
# php-fpm（サービス名はPHPのバージョンで変わる）
sudo journalctl -u php8.3-fpm --since "30 min ago"レンタルサーバーでは、コントロールパネルの「エラーログ」画面や、ホームディレクトリ内のログフォルダで確認できます。
サーバーのログにPHPのエラーが出ていない場合は、WordPressのデバッグログを一時的に有効にします。wp-config.php の /* That's all, stop editing! */ の行より上に書きます。
// デバッグを有効化（調査が終わったら false に戻す）
define( 'WP_DEBUG', true );
// エラーをファイルに記録（既定は wp-content/debug.log）
define( 'WP_DEBUG_LOG', true );
// 画面にはエラーを表示しない
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );エラーを再現させてから wp-content/debug.log を開くと、エラーの内容とファイル名、行番号が記録されています。
tail -30 /var/www/html/wp-content/debug.logwp-content/debug.log は、ブラウザから直接開ける場所にあります。サーバーのパスやプラグイン名が外部に見える状態になるため、調査が終わったら設定を元に戻し、ログファイルも削除してください。WP_DEBUG_LOG には true の代わりにファイルのパスを指定でき、公開ディレクトリの外に書き出すこともできます。
ログのメッセージから原因を読む
代表的なメッセージと意味は次のとおりです。
PHP Fatal error: Uncaught Error: Call to undefined function ...… 存在しない関数を呼んでいる。プラグイン同士の依存関係の崩れや、PHPの拡張モジュール不足で起きるPHP Fatal error: Allowed memory size of ... bytes exhausted… メモリ上限の超過PHP Parse error: syntax error ...… ファイルの構文エラー。functions.php を編集した直後によく起きるInvalid command 'php_value'….htaccessに、その環境で使えないPHP設定の命令が書かれているRequest exceeded the limit of 10 internal redirects….htaccessの書き換えルールがループしている
エラーの行に含まれるファイルのパス（wp-content/plugins/プラグイン名/... や wp-content/themes/テーマ名/...）を見れば、どのプラグインやテーマが原因かが分かります。
手順2：プラグインが原因の場合
ログで原因のプラグインが特定できたら、そのプラグインのフォルダ名だけを変更して無効化します。WordPressは、フォルダが見つからないプラグインを自動で無効化します。
cd /var/www/html/wp-content/plugins
mv problem-plugin problem-plugin.off原因が分からない場合は、plugins フォルダ自体の名前を変えるとすべてのプラグインが無効になります。サイトが表示されたらフォルダ名を戻し、管理画面のプラグイン一覧から1つずつ有効化して、500が再発するものを探します。この方法では、フォルダ名を戻してもプラグインは無効のままなので、有効化をやり直す必要があります。
WP-CLIが使える場合は、ファイル操作の代わりに次のコマンドで対応できます。
# 状態を記録してから作業
wp plugin list --status=active --field=name > active-plugins.txt
# プラグインを読み込まずに実行し、問題のプラグインを無効化
wp plugin deactivate problem-plugin --skip-plugins--skip-plugins を付けると、プラグインを読み込まずにWP-CLIを実行できます。プラグインの致命的エラーでWP-CLI自体が動かないときに使います。
手順3：テーマが原因の場合
ログのパスがテーマを指している場合や、プラグインをすべて止めても直らない場合は、テーマを疑います。
# インストール済みのテーマを確認
wp theme list --skip-themes --skip-plugins
# デフォルトテーマに切り替える
wp theme activate twentytwentyfive --skip-themes --skip-pluginsWP-CLIがない場合は、使用中のテーマのフォルダ名を変えると、WordPressはインストール済みの別のテーマで表示しようとします。デフォルトテーマが1つも入っていないと切り替えられないため、普段から1つは残しておくと安心です。
functions.php を編集した直後に500になった場合は、編集した箇所の構文エラーがほとんどです。ログに出ている行番号の前後を確認し、閉じ忘れたカッコやセミコロンの抜けを直します。
手順4：.htaccessが原因の場合
Apacheを使っている環境では、.htaccess の誤りも500の典型的な原因です。
cd /var/www/html
cp .htaccess .htaccess.bak
mv .htaccess .htaccess.off.htaccess をなくしてトップページが表示されれば、原因は .htaccess です。管理画面の「設定」→「パーマリンク」で「変更を保存」を押すと、WordPress標準の .htaccess が作り直されます。その後、バックアップから必要な記述だけを1つずつ戻し、どの記述が原因かを確かめます。
よくある原因が php_value や php_flag です。これらはApacheのPHPモジュール（mod_php）でしか使えず、PHP-FPMで動いている環境に書くと500になります。PHP-FPM環境では、PHPの設定は php.ini やプールの設定、ディレクトリに置く .user.ini で変更します。
手順5：メモリ不足の場合
ログに Allowed memory size of ... bytes exhausted が出ていれば、PHPのメモリ上限に達しています。wp-config.php で、WordPressが使うメモリの上限を引き上げます。
// フロント側の上限
define( 'WP_MEMORY_LIMIT', '256M' );
// 管理画面の重い処理（画像処理・更新など）での上限
define( 'WP_MAX_MEMORY_LIMIT', '512M' );ここで指定した値は、PHP本体の memory_limit をWordPressが引き上げようとする目安です。サーバー側で上限を固定している環境では、wp-config.php を書き換えても効果がありません。その場合は php.ini やサーバーの管理画面で memory_limit を変更します。
メモリの上限を上げても直らない、あるいは上限を何度上げても足りない場合は、プラグインの不具合で処理が終わらなくなっている可能性があります。ログのファイルパスから原因を探してください。
手順6：PHPのバージョン変更後に起きた場合
PHPのバージョンを上げた直後に500になったなら、古いプラグインやテーマが新しいPHPに対応していない可能性があります（2026年10月現在、PHP 8系への移行で削除された関数や、型の扱いが厳しくなったことが原因になる例が多く見られます）。
- 一時的に元のバージョンに戻してサイトを復旧させる
- ログに出ているプラグインやテーマを更新する。更新が止まっているものは代替を探す
- 検証用の環境で新しいバージョンに切り替え、問題がないことを確認してから本番を切り替える
レンタルサーバーでは、コントロールパネルからドメインごとにPHPのバージョンを変更できることが多いです。
復旧後に行うこと
500が解消したら、次の点を確認して作業を終えます。
WP_DEBUGをfalseに戻し、debug.logを削除する- 無効化したプラグインやテーマを、更新版が出るまで止めておくか、代替に切り替える
- 名前を変えた
.htaccess.offなどの一時ファイルを片付ける - 原因と対処を記録しておく。同じプラグインの更新で再発したときに、すぐ対応できます
プラグインやテーマを更新する前にバックアップを取る習慣があれば、500が出ても更新前の状態にすぐ戻せます。
まとめ
- 500の原因は、ほぼ例外なくサーバーかPHPのエラーログに記録されている。最初にログを確認する
- 「重大なエラーが発生しました」の画面が出たら、管理者宛てのリカバリーモードのメールを確認する
- サーバーのログで分からなければ、
WP_DEBUG_LOGで一時的に記録する。調査後は無効化してログを削除する - ログのファイルパスで、原因のプラグインやテーマを特定し、フォルダ名の変更やWP-CLIで無効化する
.htaccessのphp_valueはPHP-FPM環境で500の原因になる- メモリ不足は
WP_MEMORY_LIMITで引き上げるが、サーバー側の上限が優先される