PHPの重大な脆弱性（2026年10月21日公開）への対応で、レンタルサーバーの管理画面から PHP のバージョンを上げた。すると、ホームページが真っ白になった、あるいは「このサイトで重大なエラーが発生しました」と出て開かなくなった——。この記事は、その状態から元に戻し、原因を見つけて、安全に上げ直すまでを順番に整理したものです。
先に結論です。まず PHP のバージョンを元に戻して表示を復旧させ、次にエラーログで「どのプラグイン・テーマ・プログラムで止まったか」を特定し、それを直すか入れ替えてから上げ直します。原因のほとんどは PHP そのものではなく、新しい PHP で削除された書き方を使っている古いプラグインやテーマです。ただし、戻した状態で放置はできません。PHP 開発元のアドバイザリによると、修正版は PHP 8.2.35・8.3.36・8.4.27・8.5.12 だけで、8.1 以前には修正版が出ていないからです。
結論：真っ白になったら、この順で動く
順番 | やること | かかる時間の目安 |
|---|---|---|
① | サーバーの管理画面で PHP を元の版に戻す（表示の復旧） | 数分 |
② | エラーの出どころを特定する（WordPress のリカバリーメール／debug.log） | 15〜30分 |
③ | 原因のプラグイン・テーマを更新、代替に入れ替え、または停止する | 内容しだい |
④ | バックアップを取ってから PHP を上げ直し、表示とフォームを確認する | 30分〜 |
①で戻せない（管理画面に版の選択が無い、VPS で自分で入れている）場合や、③の対象が独自に作り込んだプログラムの場合は、制作会社や保守の担当者に相談する段階です。
なぜ PHP を上げると古いサイトが止まるのか
PHP はバージョンが上がるたびに、古い書き方を少しずつ削っています。特に影響が大きいのが PHP 7 系から 8 系への切り替えです。PHP 開発元が公開している PHP 8.0 の変更点（UPGRADING）には、次のような変更が並んでいます。
- 関数の削除：
create_function()、each()、money_format()、get_magic_quotes_gpc()などが削除された。使っているプログラムは、その行に来た時点で止まる - 警告がエラーに格上げ：たとえば「オブジェクトでない値のプロパティに書き込む」といった操作は、以前は注意・警告で済んでいたが、8.0 からはエラー（処理が止まる扱い）になった
- 注意が警告に格上げ：未定義の変数や配列のキーを読む操作は「警告」になった。止まりはしないが、画面に警告文が出ることがある
さらに PHP 8.1 以降も、非推奨（将来削除される予告）の項目が毎回増えています。PHP 8.2 では「動的プロパティの作成」が非推奨になりました。非推奨はそれだけでは止まりませんが、設定によっては画面に Deprecated の文字が並びます。
つまり 「PHP 7.4 のまま何年も更新していないサイト」を一気に 8.2 以上へ上げると、止まる可能性がいちばん高いということです。実務でも、真っ白になる相談のほとんどは「長く手を入れていない WordPress」か「昔の制作会社が書いた独自の PHP」です。PHP 8.1 以前のサイトの選択肢全体はPHP 7.4・8.1以前は修正版なし｜PHP2Shell脆弱性の対処にまとめています。
① まず PHP を元の版に戻す
共用のレンタルサーバーでは、PHP のバージョンはサーバーの管理画面でドメインごとに選ぶ形が一般的です。上げたときと同じ画面で、元の版を選び直してください。数分で表示が戻ることがほとんどです。
- 戻しても直らない：PHP 以外にも同時に何かを変えていないか（プラグインの一括更新、WordPress 本体の更新）を思い出してください。更新が途中で止まって「メンテナンス中」の画面が残っている場合は「ただいまメンテナンス中です」が戻らない時の原因5つの切り分けが使えます
- 戻した状態は「仮の姿」：PHP 8.1 以前は、2026年10月21日に公開された2件の脆弱性（CVE-2026-109618／CVE-2026-109619。いずれも深刻度 Critical）の修正対象外です。ただし共用サーバーでは、事業者が古い版にも独自に修正を当てている場合があります。自分の契約先の状況はレンタルサーバー別PHP脆弱性対応で確認してください
② エラーの出どころを特定する
WordPress なら、まず管理者宛てのメールを見る
WordPress は致命的なエラーを検知すると、画面に「このサイトで重大なエラーが発生しました」（WordPress 本体のソースでの原文は There has been a critical error on this website.）と表示し、サイトの管理者メールアドレスに「技術的な問題が発生しています」という件名のメールを送ります。WordPress 本体のリカバリーモードのメール送信処理では、このメールにエラーを起こしたプラグイン名またはテーマ名と、ログインして問題のプラグインを止めるためのリカバリーモードのリンクが入ります。
メールが届いていれば、原因の候補はもう書いてあります。届かない場合は、迷惑メールフォルダと「WordPress の管理者メールが今も読めるアドレスか」を確認してください。前任者のアドレスのままになっている会社は珍しくありません。
メールが無いときは debug.log を出す
WordPress の wp-config.php に次の2行を足すと、エラーが wp-content/debug.log に記録されます（WordPress 本体の load.php の仕様）。
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );
この状態で PHP を新しい版に上げ、一度ページを開いてから debug.log を見ます。「PHP Fatal error」の行に出ているファイルのパスが手がかりです。パスに wp-content/plugins/○○ があればそのプラグイン、wp-content/themes/○○ があればそのテーマが原因です。
⚠ 注意が2つあります。WP_DEBUG を true にすると、既定ではエラーが画面にも表示されます（WP_DEBUG_DISPLAY の既定値が true のため）。訪問者に見せたくない場合は define( 'WP_DEBUG_DISPLAY', false ); も足してください。そして調べ終わったら必ず false に戻し、debug.log は削除します。ログにはサーバー内のパスが残るので、公開したままにしないでください。
WordPress ではない（独自の PHP）場合
レンタルサーバーの管理画面にある「エラーログ」を見ます。場所の名前は事業者ごとに違いますが、PHP のエラーは多くの場合ここに残ります。Fatal error の行に出ている関数名（例：Call to undefined function create_function()）が、上の「削除された関数」に当たれば、プログラムの書き換えが必要です。
③ 原因ごとの直し方
原因 | 直し方 | 自分でできるか |
|---|---|---|
プラグインが古い（更新版がある） | PHP を戻した状態でプラグインを最新に更新してから、PHP を上げ直す | できる |
プラグインの開発が止まっている | 同じ機能の別プラグインに入れ替える／使っていなければ削除する | 機能による |
テーマが古い（市販テーマ） | テーマの配布元で更新版を確認する。子テーマに独自の改造がある場合はそこも点検 | 半分 |
制作会社のオリジナルテーマ・独自プログラム | 該当箇所の書き換え。作った会社か、引き継いだ会社に依頼 | 難しい |
WordPress 本体が古い | 本体を更新する（現行の WordPress が要求する PHP の最低版は 7.4） | できる（バックアップ必須） |
PHP を戻した状態でプラグインを更新するのがポイントです。新しい PHP のまま管理画面に入れない状態で無理に直そうとすると、FTP でフォルダ名を変えて止める、といった作業が必要になり、事故の元になります。
④ 上げ直す前にやること
- バックアップを取る：ファイル一式とデータベースの両方。サーバーの自動バックアップがあっても、作業直前の分を手で取っておくと戻しやすい
- 上げる版を決める：修正版が出ているのは 8.2・8.3・8.4・8.5 の4系統です。古いサイトを一気に最新へ上げるより、まず 8.2 か 8.3 で動くことを確かめる方が安全です
- 上げたら確認する場所：トップページだけでなく、問い合わせフォームの送信、ネットショップならカートと決済の手前まで。フォームだけ壊れていることはよくあります。送信できない時の見分け方は問い合わせフォームが送信できないエラーの原因6つが参考になります
- 痕跡の確認：脆弱性の対応で上げたのなら、上げる前の期間に何かされていないかの確認も要ります。手順はPHP更新後にやること7項目にまとめています
直すより作り直した方が早いケース
次のどれかに当てはまるなら、部分的な修理より作り直しを比べた方が、結果的に安く済むことがあります。
- 原因のプラグインが3つ以上あり、どれも開発が止まっている
- テーマが10年近く前のもので、配布元がもう無い
- 作った制作会社と連絡がつかず、独自のプログラムを読める人がいない
古いサイトを「何から見直すべきか」の判断材料はホームページをリニューアルすべき7つのサインに整理しています。
Mihata ではホームページの制作・作り直しもお受けしています。今回のような PHP の更新で古いサイトが動かなくなった、というご相談も、記事の途中で恐縮ですが、よろしければお気軽にご覧ください。
まとめ
- PHP を上げて真っ白になったら、まず元の版に戻して表示を復旧させる
- 原因は WordPress なら管理者宛てのメールか debug.log で、どのプラグイン・テーマかまで特定できる
- PHP 8.0 で削除された関数や、警告からエラーに変わった操作を使っている古いプラグイン・テーマが主な原因
- 戻した状態は仮の姿。修正版が出ているのは PHP 8.2.35・8.3.36・8.4.27・8.5.12 だけなので、原因を直して上げ直す
よくある質問
PHPのバージョンを上げたらサイトが真っ白になりました。まず何をすればいいですか？
レンタルサーバーの管理画面で、PHPのバージョンを元の版に戻すのが最初の一手です。共用サーバーの多くは管理画面のプルダウンで版を選び直せます。表示が戻ったら、原因を調べてから改めて上げます。ただし PHP 8.1 以前には2026年10月21日公開の重大な脆弱性の修正版が出ていないので、戻した状態で長く放置しないでください。
「このサイトで重大なエラーが発生しました」と出るのはなぜですか？
WordPress が致命的な PHP エラーを検知したときに出す画面です。WordPress 本体のソースでは英語の原文が There has been a critical error on this website で、管理者のメールアドレスには、どのプラグインやテーマで止まったかを書いたリカバリーモードのリンクが届きます。PHP を上げた直後なら、古いプラグインやテーマが新しい PHP で動かなくなったのが一番多い原因です。
どのプラグインが原因かはどうやって調べますか？
wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を書くと、エラーが wp-content/debug.log に記録されます。ログに出るファイルのパスに wp-content/plugins/プラグイン名 が含まれていれば、そのプラグインが原因です。調べ終わったら必ず false に戻し、debug.log も削除してください。
PHP 8.0 で何が変わったせいで古いサイトが動かなくなるのですか？
PHP 8.0 では create_function() や each() などの関数が削除され、それまで警告で済んでいた操作の多くがエラー（処理が止まる扱い）に変わりました。PHP 7 時代に作られたテーマやプラグイン、独自のプログラムがこれらを使っていると、PHP 8 系に上げた時点で止まります。