
PHP 8.1以上に変更すると500エラーが起きる時の原因と対処法
WordPressサイトでPHPを8.0から8.1以上に切り替えると500 Internal Server Errorが発生する場合は、サーバー側のエラーログ確認と拡張機能・PHPハンドラの互換性チェックが解決の最短ルートになる。WordPressのdebug.logが空でも、エラーがWordPress起動前に発生している可能性が高い。
PHP 8.1以上への変更で500エラーが起こる原因

500 Internal Server Errorは「サーバー内部で想定外のエラーが起きた」ことを示す汎用的な表示だ。原因はWordPress内のプラグインやテーマとは限らない。PHPのバージョンアップに伴うサーバー側の設定変更、拡張機能の欠落、PHPハンドラの切り替えなど、WordPressが動き出す前の段階でエラーになるケースも多い。
特にPHP 8.0から8.1以上への変更時は、非推奨だった機能の正式な削除や、デフォルト設定の変更が影響する。古いプラグインやテーマのコードがPHP 8.1で動かない場合もあるが、そのケースでは多くの場合WordPressのデバッグログに記録が残る。一方、debug.logに何も出ない500エラーは、サーバーレベルでの問題を疑うべきだ。
サーバーのエラーログを確認する手順

まず確認すべきは、レンタルサーバーのコントロールパネルにある「エラーログ」または「サーバーログ」だ。PHP 8.1でエラーが出ている場合、WordPressのdebug.logではなく、このサーバーログにだけ記録が残っていることがある。
コントロールパネルで該当ログを探す
国内の一般的なレンタルサーバーでは、管理画面の「ログ」や「アクセス解析」の近くにエラーログの項目がある。エラーログにはタイムスタンプとともに、どのPHPハンドラが失敗したのか、どの拡張機能が読み込めなかったのか、メモリ不足が起きたのかといった記録が残る。エラー発生直後の行をコピーしておくと、原因の特定が速い。
上のデモはサーバーのエラーログを確認する一連の流れを示している。ログにPHPの拡張機能名(例「mysqli」や「curl」)が書かれていれば、その拡張機能がPHP 8.1環境で有効になっていない可能性が高い。ハンドラ名(例「php-fpm」や「FastCGI」)の記述があれば、ハンドラの切り替えに失敗しているケースが考えられる。
PHPハンドラと拡張機能の互換性を確かめる

サーバーログにWordPressが起動する前のエラーが記録されている場合、原因はPHPハンドラまたはPHPの拡張機能にある。PHPハンドラとは、サーバーがPHPファイルを実行するための仕組みのことだ。PHP 8.0から8.1に切り替える際、ハンドラの設定が初期化されたり、互換性のない組み合わせになったりすることがある。
最小限のPHPファイルで切り分ける
WordPressとは無関係に、PHP 8.1自体が正常に動くかどうかを確認する方法がある。FTPソフトなどでWordPressと同じディレクトリに、内容が <?php phpinfo(); ?> だけのファイル(例 php-check.php)をアップロードし、ブラウザでアクセスする。
このファイルも500エラーになるなら、WordPressやプラグインの問題ではない。サーバーのPHP設定・ハンドラ・拡張機能そのものに問題がある。逆にこのファイルが正常に表示されるなら、WordPress側のコードに原因があるため、プラグインやテーマの互換性を順に調べる。
この切り分けでサーバー側の問題だと判明したら、レンタルサーバーの管理画面からPHP 8.1に切り替えた直後の設定を確認する。PHPハンドラが「利用不可」になっていたり、必要な拡張機能(mysqli、mbstring、curl、zipなど)が「無効」になっていたりしないかを確かめる。
debug.logが空でも見落とさない5つのチェックポイント

WordPressのdebug.logにエラーが残っていない場合でも、500エラーの原因は必ず存在する。以下の5点を順に確認すると、隠れた原因に行き着きやすい。
1. wp-config.phpのデバッグ設定を再確認する
WP_DEBUG と WP_DEBUG_LOG が両方とも有効になっているかを確認する。WP_DEBUG_DISPLAY が false のままでもログは出力されるが、設定の記述位置が古いテーマのコードより後だと、エラーが発生する時点でログ設定が読み込まれないことがある。wp-config.phpのなるべく先頭近くに記述を移動しておくと確実だ。
2. php.iniや.user.iniの記述を確認する
PHPのバージョンを変更すると、ホームディレクトリ直下の php.ini や .user.ini が別バージョンの設定として適用される場合がある。PHP 8.0向けに書いた設定がPHP 8.1では不正な構文になるケースや、設定した内容がホスティング側の制限と競合するケースがある。
3. 拡張機能の有効状態を一覧で比較する
PHP 8.0で有効だった拡張機能が、PHP 8.1では無効になっていることがある。特に画像処理のGDや、データベース接続のmysqli、マルチバイト文字列のmbstringが無効だと、WordPressは起動すらできない。phpinfo() の結果をPHP 8.0と8.1で並べて比較すると、差分に気づきやすい。
4. .htaccessからPHP関連の記述を一度外す
PHPのバージョンやハンドラを指定する .htaccess の記述が、新しいPHPの設定と競合して500エラーを起こすことがある。WordPressの標準的な記述だけにした .htaccess を新しく作ったうえで、PHP関連のカスタム記述を一時的に外して確認する。
5. サーバー会社の障害情報と設定上限を確認する
そのサーバーがPHP 8.1への切り替えを一時的に制限している場合や、特定のハンドラがメンテナンス中の可能性がある。サーバー会社の障害・メンテナンス情報ページを確認すると、想定外の原因に行き着くこともある。
WooCommerceを使うPHP 8.1移行で気をつける互換性

WooCommerceはPHP 8.1に正式対応している。ただし、導入している拡張プラグインや子テーマの中にはPHP 8.1で動作しない古いコードが残っている場合がある。PHP 8.0から8.1への変更で、関数の呼び出し方が非推奨から削除に変わったものが影響することもある。
切り分けテストは、WooCommerce以外のプラグインをすべて無効化し、標準テーマ(Twenty Twenty-Fourなど)に切り替えた状態でPHP 8.1を適用する手順が確実だ。その後、1つずつプラグインを有効化して、どのプラグインで500エラーが再発するかを突き止める。ただし、この手順でエラーが再発しない場合も、先に述べたサーバーレベルの問題が残っている可能性を忘れてはならない。
よくある質問
500エラーが出たまま管理画面にログインできない場合はどうする?
FTPソフトでwp-content以下のpluginsフォルダ名を一時的に変更すると、全プラグインを無効化できる。同じくテーマフォルダ名を変更すると標準テーマに切り替わる。その後、PHP 8.1でサイトが表示されるかを確認する。
PHP 8.1に切り替える前の注意点は?
事前にサイト全体のバックアップを取る。次に、プラグインとテーマがPHP 8.1に正式対応しているか、各プラグインの公式ページで確認する。対応表記がない場合は、PHP 8.0のままテスト環境で切り替えテストを行うのが安全だ。
サーバーログで「Allowed memory size exhausted」と出る場合は?
PHPのメモリ上限を増やすことで改善する。wp-config.phpの WP_MEMORY_LIMIT を256MBや512MBに設定し、php.iniの memory_limit も確認する。レンタルサーバー側で上限が固定されている場合は、サーバーの仕様を確認する。
debug.logに「Fatal error」と出る場合の読み方は?
エラーが発生したファイル名と行番号が記録されているので、該当するプラグインやテーマを特定できる。プラグイン名が明示されている場合は、そのプラグインを無効化するか、PHP 8.1対応版への更新を確認する。
PHP 8.0に戻せば解決するが、8.1のままにしたい場合は?
PHP 8.0に戻してサイトを復旧させたうえで、8.1で動かない原因を特定する。テスト環境を作り、プラグインやテーマの互換性を1つずつ確認して、修正または代替プラグインを導入してから本番環境を切り替えるのが安全な進め方だ。
この記事のポイント
- PHP 8.1以上での500エラーはサーバーログに原因が記録されていることが多い
- debug.logが空でもWordPress起動前のエラーを疑う
- 最小のPHPファイルでサーバー側とWordPress側を切り分ける
- PHP 8.0で有効だった拡張機能が8.1で無効になっていないか確認する
- WooCommerceは公式対応だが拡張プラグインの互換性は個別に確かめる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
