PHPバージョンアップ後の500エラーの原因と直す順番【事例あり】

サーバーの管理画面でPHPのバージョンを上げたら、サイトが「500 Internal Server Error」になった。戻せば直るのか、戻していいのか、原因はどこを見れば分かるのか。この記事は、その状態から復旧して、原因を直して、もう一度上げるまでの順番を書いたものです。

先に答えを書くと、まず前の版に戻して表示を取り戻し、そのあとで原因を3つの層のどれかに絞ります。層はWAF、サーバー設定、WordPressの3つで、直前にやった操作がPHPの切り替えだけなら、見る場所はかなり限られます。切り替えの手順そのものはWordPress PHPバージョンアップ｜エラーの直し方と手順に書いているので、この記事は「もう500が出ている」ところから始めます。

根拠にしたのは、当社で対応した2件です。1件はWooCommerceを更新した直後に2ページ目から501になった家具のECサイト、もう1件は6年分の更新を5サイトにまとめて当てた住宅会社グループ。どちらも末尾の事例ブロックに、症状から結果まで書いています。

伊藤

500の相談で最初に聞くのは「直前に何をしましたか」です。PHPを変えた、とはっきりしている500は、原因が3層のどれかにほぼ収まります。何もしていないのに出た500のほうが、ずっと厄介です。

500エラーの原因は3層。症状の出方でどの層か分かる

ブラウザからの通信は、上の図の順に通ります。最初にサーバー会社のWAF（不正な通信を止める仕組み）、次にサーバーの設定（.htaccess や php.ini）、最後にWordPress本体とテーマ、プラグインです。500という番号はどの層で止まっても出るので、番号だけでは場所が分かりません。見分けるのは症状の出方です。

表の上から2つがいちばん多く、上位の解説記事が扱っているのもここです。下の2つは記事がほとんど無く、ログを見ても何も出ないので、分からないまま「PHPのせい」にされがちです。事例1のサイトがこれでした。ここから、3つの原因を順に見ます。直す順番は次の章にまとめています。

戻しても消えないなら .htaccess の php_flag

PHPを戻しても500が消えないとき、最初に見るのは公開フォルダの .htaccess です。古いサーバーで使っていた次のような行が残っていると、今のレンタルサーバー（PHPをFastCGIやCGIで動かす環境）では500になります。

php_flag display_errors Off
php_value memory_limit 256M
php_value upload_max_filesize 64M

このときサーバーのエラーログには、次のような行が出ます。

[Thu Oct 22 10:12:33 2026] [alert] [client 203.0.113.10]
  /home/example/example.com/public_html/.htaccess:
  Invalid command 'php_flag', perhaps misspelled or defined by a module
  not included in the server configuration

直し方は、その行を .htaccess から消して、同じ設定をサーバーの管理画面の php.ini 設定に移すことです。エックスサーバーなら「サーバーパネル」→「php.ini設定」にあります。サーバーを移転した直後にPHPも上げた、という場合はこのパターンが多く、事例2では移転した1サイトで同じ行を外しています。

php.ini 側にも注意点があります。古い設定ファイル（.user.ini を含む）に、新しいPHPで消えた項目が残っていると、やはり動きません。管理画面の php.ini 設定を一度初期値に戻して、500が消えるかを見るのが早いです。

戻すと直るならテーマ・プラグインの古い書き方

PHPを戻すと直る500は、ほぼこの層です。新しいPHPで消えた関数や書き方をテーマかプラグインが使っていて、そこで処理が止まっています。どのファイルかはログに書いてあります。見る場所は2つです。

500エラーの行はサーバーのエラーログに残る

エックスサーバーは「サーバーパネル」の「エラーログ」で、画面に表示するかダウンロードするかを選べます。さくらのレンタルサーバは「サーバーステータス」→「アクセスログ」でエラーログの「保存する」にチェックを入れておくと、「本日のエラーログ」から読めます。ConoHa WINGとロリポップは公式マニュアルにエラーログの項目が見当たらなかったので、管理画面のログの項目を探すか、サポートに場所を聞いてください。

「エラーログ」をクリック（中略）「表示」をクリックすると、ログが表示されます。

エックスサーバー マニュアル「エラーログ」

500エラーの原因のファイルと行は debug.log に出る

WordPress側のログは wp-config.php に次の3行を足すと wp-content/debug.log に書き出されます。画面には出さない設定にしておけば、訪問者にエラーが見えることはありません。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

PHPを上げ直してサイトを開くと、500になった瞬間の行が残ります。たとえばこういう行です。

[22-Oct-2026 10:15:02 UTC] PHP Fatal error:  Uncaught Error:
  Call to undefined function create_function()
  in /home/example/example.com/public_html/wp-content/themes/old-theme/inc/widgets.php:120

読むのは3か所だけです。「Fatal error」なら処理が止まる種類のエラー、「Warning」や「Deprecated」なら止まらない警告。「in」の後ろがファイルの場所で、themes の下ならテーマ、plugins の下ならプラグイン。末尾の数字が行番号です。この例は古いテーマの120行目で、PHP 8.0で消えた create_function が呼ばれています。

プラグインが原因なら、更新があれば更新、無ければ代わりのプラグインに替えます。テーマが原因なら、その行を今の書き方に直します。自作テーマや何年も前の有料テーマは、同じ種類のエラーが複数のファイルに散らばっていることが多く、事例2のサイトではテーマの修正を先に済ませてからPHPを上げました。管理画面に入れないときにFTPでプラグインを止める手順や、PHP 8で多いエラーの例はバージョンアップの記事の「エラーが出たら」の節にまとめています。

ログを有効にして原因が分かったら、3行は元に戻してください。debug.log は公開フォルダの中にあるので、残しておくとサーバーの構成が外から読めます。

2回目で止まるならWAFの誤検知。画面は501や403

ここは上位の解説記事にほぼ書かれていない層です。PHPやプラグインを更新したあと、トップページは開くのに、再読み込みしたり2ページ目に移ったりすると青いエラー画面になる。エックスサーバーなら画面に「501 Not Implemented」と出て、他社のWAFでは403になることが多い。500と思い込んで探すと、いつまでも見つかりません。

仕組みはこうです。更新で新しく入った機能が、訪問者のブラウザにCookieを保存する。2回目の通信ではそのCookieが一緒に送られる。WAFがCookieの中の文字列を見て、サーバーのコマンドを実行する攻撃だと判定して止める。止められた通信はWordPressまで届かないので、エラーログにも debug.log にも何も残りません。

エックスサーバーの501の画面には「対応していないメソッド（MOVE/COPYなど）を使用した」と書かれていますが、これは決まり文句です。WAFがどの理由で止めても同じ画面が出るので、この文言から原因を探しても何も出ません。

確かめ方は、シークレットウィンドウで開き直すことです。Cookieが無い状態なので1ページ目は表示され、2ページ目で止まれば、ほぼ確定です。

WooCommerceの注文の属性のCookieが代表例

WooCommerceは8.5（2024年1月）から「注文の属性」（Order Attribution）という機能が最初から有効になり、訪問者がどこから来たかを記録するCookie（sbjs_current など）を保存します。このCookieがWAFに誤検知される問題は、公開直後からWooCommerce側でも認識されています。

Since the release of WooCommerce 8.5.1 yesterday, we received reports about stores getting 403 Forbidden errors caused by Web Application Firewall (WAF) rules

WooCommerce Developer Blog「WooCommerce 8.5.1 issues with Web Application Firewalls (ModSecurity)」2024年1月16日

事例1のサイトでは、Cookieの中の「|||id=」という文字列が、エックスサーバーのWAF「コマンド対策」に引っかかっていました。「|」の直後にコマンド名（id、ls、cat など）が来る形を攻撃とみなす判定で、Cookieの値がたまたまその形だったという誤検知です。WooCommerceの機能もWAFも、それぞれは正常に動いていました。

注文の属性を使い続けたい場合は、子テーマの functions.php に次の1行を入れます。Cookieの中身がbase64で符号化され、「|||id=」のような文字列が出なくなるので、WAFをONのまま使えます。

add_filter( 'wc_order_attribution_use_base64_cookies', '__return_true' );

Setting this filter to true will use Base64 encoding for the data captured in the order attribution cookies, avoiding any substrings that may trip up overzealous WAFs

WooCommerce「Order Attribution Tracking」

伊藤

事例1でいちばん時間を使ったのは、WAFを疑うまででした。ログに何も無い、IPを変えても出る、シークレットで開くと1ページ目は出る。この3つがそろったら、WordPressの中を探すのをやめてWAFを見てください。

500エラーは、戻してから原因を絞り、直して上げ直す

原因が3つに分かれても、やる順番は1つです。表示を取り戻してから原因を絞り、直してから上げ直します。順番を変えると、戻せない状態で原因を探すことになったり、直したつもりで本番を壊したりします。

まず前のPHPに戻す。戻して終わりにしない

サイトが見えない時間を短くするのが先です。サーバーの管理画面でPHPの版を切り替え前の番号に戻します。エックスサーバーなら「サーバーパネル」→「PHP Ver.切替」、ほかの会社も名前は違いますが同じ場所にあります。戻してから数分で表示が戻れば、原因はPHPの版に関係するもの、と確定します。

戻して直ったからといって、そのままにはしないでください。古いPHPは修正が止まっていて、2026年10月のPHP本体の脆弱性（php2shell）では8.1以前に修正版が出ませんでした。戻すのは応急処置で、原因を直して上げ直すまでが作業です。

戻しても直らないなら、原因はPHPの版ではありません。その場合はこの記事の3層のうちWAFの層か、PHPの切り替えと同時にやった別の操作（プラグインの更新、サーバーの移転）を疑います。

戻せないときは、テスト環境で直してから上げる

戻す先が無いことがあります。サーバー会社が古い版の提供をやめていて選べない、戻せる版が7.4や8.1で、修正版の出ないPHPに戻すことになる、という場合です。php2shellのあとは8.1以前に戻すこと自体が勧められません（php2shellとは｜WordPressサイトで今やること）。

この場合は本番で試行錯誤せず、本番のバックアップを別の場所に復元して、そこで新しいPHPに切り替え、出たエラーを1つずつ直します。エックスサーバーとさくらには、本番と同じ内容を別の場所にコピーして試す機能があります。直し終えたら本番のテーマとプラグインを同じ状態にして、本番のPHPを上げます。

テスト環境にはWAFが無いので、事例1のような誤検知はテストでは起きません。本番に反映したあとの確認は、上の順番の5つ目のとおり、実際のブラウザで複数ページを移動してください。プログラムでページを取得する確認では、Cookieが作られないので見つかりません。

自分で直す時間が取れない、ログを読んでも原因のファイルが分からない、という場合は、バージョンアップ代行で原因の特定から上げ直しまで行っています。エラー画面と切り替え前後の版を送っていただければ、どの層かの見当は無料でお伝えします。

実際の対応事例

本文の根拠にした2件です。

更新後に2ページ目から501が出たECサイト

家具のECサイト（WordPress＋WooCommerce・エックスサーバー）｜2026年10月

STEP

症状

WordPress 6.1.2→7.1.3、PHP 7.4→8.3、WooCommerce 7.0→9.8系の更新を本番に反映した直後、トップページは開くのに、再読み込みや2ページ目でエックスサーバーの「501 Not Implemented」の画面になる。PC・スマホ、ログインの有無に関係なく出て、訪問者のほぼ全員が商品を見て回れない状態

STEP

原因

WooCommerce 8.5で追加された「注文の属性」が作るCookie（sbjs_current など）の中の「|||id=」という文字列を、エックスサーバーのWAF「コマンド対策」が攻撃と判定していた。WooCommerceの機能もWAFもそれぞれは正常で、2つが組み合わさって起きた誤検知。ローカルのテスト環境にはWAFが無く、表示確認もプログラムでページを取得する方法だったためCookieが作られず、事前に再現しなかった

STEP

対応内容

最初はこちらの確認アクセスでの制限を疑ったがIPを変えても再現 → 「1回目は出て2回目で止まる」からCookieを推測 → エラーログと debug.log は空 → 注文の属性のCookieを付けると501、外すと200を再現 → 中身を削って「|||id=」を特定 → 「コマンド対策」をOFF（反映に約50分）→ 「注文の属性」のチェックを外す → OFFの間はSiteGuard WP Pluginで補い、WooCommerceのログインと干渉する画像認証は外す → 1週間後に「コマンド対策」をONに戻す計画

STEP

結果

当日中に原因の文字列まで特定し、応急対応と再発防止まで実施。検索エンジンのクローラーはCookieを持ち越さないため影響を受けず、検索順位への影響は無し

この件で分かったのは、本番に反映したあとの確認は、本番のWAFを通した状態で、実際のブラウザで複数ページを移動しないと意味がない、ということでした。

6年分の更新を5サイトに当てた住宅会社グループ

事例2では、テーマのエラーをテスト環境で先に直したので、本番のPHPの切り替えでは500が出ていません。出てから直すより、出る前に直すほうが短い時間で済みます。

よくある質問（FAQ）

前のPHPに戻したら直りました。このままでいいですか？

応急処置としては正解ですが、そのままにはしないでください。古いPHPには脆弱性の修正が出ません。2026年10月のphp2shellでは8.1以前に修正版が出ませんでした。原因を直して、サポート中の8.3以上に上げ直すまでが作業です。

エラーログにも debug.log にも何も出ません。なぜですか？

WAFで止められた通信はWordPressまで届かないので、WordPress側のログには残りません。1回目は表示されて2回目で止まる、画面が501や403、という出方ならWAFの層です。サーバーの管理画面のWAF設定を見てください。

キャッシュを消せば直りますか？

PHPの切り替えが原因の500は、キャッシュでは直りません。事例1のように「Cookieがあると出て、無いと出ない」と結果が変わるなら、キャッシュではなくWAFの判定です。

WAFはOFFのままでもいいですか？

おすすめしません。原因のCookieを作らせないようにするか、base64のフィルターを入れてから、ONに戻してください。OFFの間だけセキュリティプラグインで補う形にします。

自分で直せますか？業者に頼むべきですか？

debug.log の「Fatal error」の行にプラグイン名が出ていて、そのプラグインに更新がある、という場合は自分で直せます。テーマの中の複数のファイルを直す必要がある、戻す先のPHPが無い、ログに何も出ない、という場合は時間がかかるので、代行を検討してください。原因の層の見当は無料でお伝えしています。

まとめ

• まず前のPHPに戻して表示を取り戻す。戻して終わりにせず、原因を直して上げ直す
• 500の出どころはWAF、サーバー設定、WordPressの3層。症状の出方で層が分かる
• 戻しても直らず全ページで出るなら .htaccess の php_flag と php.ini。戻すと直るなら debug.log の「Fatal error」の行
• 1回目は表示されて2回目で止まる、ログが空、画面が501や403、ならWAFの誤検知。WooCommerceの「注文の属性」のCookieが代表例
• 戻せないときはテスト環境で直してから上げる。本番に反映したら実際のブラウザで複数ページを移動して確かめる

PHPバージョンアップ後の500エラーの原因特定と修正（WordPress）、代行できます

費用目安 診断は無料。修正・切り替え作業は ¥19,800〜

想定工数 診断は即日（結果をメールで）

• エラーログと debug.log から原因のファイルと行を特定（無料診断）
• .htaccess・php.ini・テーマ・プラグイン・WAFのどの層かを切り分け
• 前の版に戻せないサイトは、テスト環境で直してから8.3以上へ
• 反映後は本番のWAFを通した状態で、実際のブラウザで複数ページを確認
• 営業の電話・メールはしません

合同会社キューブリック

まずは状況をお聞かせください。作業前に内容と金額をお伝えし、追加料金はいただきません。

代表社員 / WEBエンジニア

無料で相談する

エラー画面のスクリーンショットと、切り替え前後のPHPの版を送っていただくだけで構いません。相見積もり歓迎・営業はしません。