「PHPのバージョンを上げたら、サイトが真っ白になった」
「『このサイトで重大なエラーが発生しました』と表示されて、管理画面にも入れない」
2026年10月に公表されたPHPの緊急の脆弱性をきっかけに、古いPHPから新しいPHPへ切り替えた方も多いと思います。
PHPの開発チームから修正版が出るのはサポート中の版だけなので、8.1以前を使っていたサイトでは、切り替えが避けられません。ところが、切り替えた途端にWordPressが動かなくなる、というのはよくあるトラブルです。
この記事では、PHPのバージョンアップでWordPressが動かなくなる原因と、動かなくなったときの対処法、そしてそうならないための事前の準備を、図解と動画で解説します。
WordPressは、PHPというプログラムの上で、WordPress本体・テーマ・プラグインが動いています。PHPは新しい版になるたびに、古い書き方の一部を使えなくしたり、間違った使い方を厳しくチェックしたりするようになります。下の図（再生ボタンで動画になります）は、その様子を示したものです。
WordPress本体は、新しいPHPへの対応が比較的早く進められています。
問題になりやすいのは、何年も更新されていないプラグインやテーマ、そして制作会社などが独自に書いたプログラムです。
| 変わったこと | どんな影響が出るか | 変わった版 |
|---|---|---|
| 古い関数の削除（each()、create_function() など） | その関数を使っているプラグインが、致命的なエラーで止まる | 8.0 |
| 型のチェックが厳しくなった（数えられない値を count() で数える、など） | 以前は警告で済んでいたものが、エラーで止まるようになった | 8.0 |
| 非推奨の書き方への警告が増えた（動的プロパティなど） | 動作は続くことが多いが、画面やログに警告が出る | 8.2 |
| 古いデータベース用の関数（mysql_ で始まるもの）の削除 | 非常に古いプラグインや独自プログラムが動かなくなる | 7.0 |
特に、7.4から8.0以降へ上げるときは変更が大きく、トラブルが起きやすい段階です。
なお、エラーが出たからといって、新しいPHPそのものに問題があるとは限りません。
以前からあったプログラムの問題が、新しいPHPで表に出たということもよくあります。
また、PHPの切り替えと同じ時期に、プラグインの更新やサーバーの設定変更をしていれば、それも原因の候補です。
決めつけずに、記録と変更の履歴から確かめることが大切です。
画面の様子によって、どこを疑えばよいかの見当がつきます。
ただし、画面やログに表示されたファイルが、そのまま原因とは限りません。
別のプログラムとの組み合わせで起きていることもあるので、ログはエラーの行の前後もあわせて確認しましょう。
ページ上に「Deprecated」「Warning」といった英語の警告文が表示される場合は、すぐにサイトが止まるわけではありません。
ただし、訪問者にサーバーの情報が見えてしまうため、表示はオフにして、原因のプラグインの更新を進めましょう。
動かなくなったときは、次の5つの順番で進めます。
下の図（再生ボタンで動画になります）は、その流れを示したものです。
最初にやるのは、原因探しではなくサイトの復旧です。サイトが止まっている間は、お問い合わせや予約、売上も止まっています。
エラーの記録は戻したあとも残るので、調査はあとからでもできます。
戻す前に、表示された画面のスクリーンショットと、起きた時刻だけメモしておきましょう。
多くのレンタルサーバーでは、管理画面の「PHPのバージョン設定」から、すぐに元の版に戻せます。
これで、多くの場合はサイトが元どおり表示されます。
ただし、8.1以前に戻すのは一時的な措置です。
古い版には今回のような脆弱性の修正版が出ないため、原因を直したら、できるだけ早く新しい版に切り替え直してください。
まず、PHPの切り替えと同じ時期に、ほかに変えたことがないかを思い出します（プラグインやテーマの更新、設定の変更など）。そのうえで、次の3つの方法で原因を探します。
plugins/ の次の名前が、原因のプラグインです。wp-content/debug.log に記録されます。define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
デバッグ記録には注意点があります。debug.log は、初期設定のままではURLを入れれば誰でも見られる場所に作られます。サーバーの情報が漏れる原因になるので、原因が分かったら設定を元に戻し、debug.log を削除してください。なお、Bedrockなど構成が異なるWordPressでは、設定を書く場所が違います。
管理画面に入れる場合は、「プラグイン」の画面から、原因のプラグインを「無効化」します。
管理画面に入れない場合は、FTPソフトやサーバーのファイルマネージャーで、wp-content/plugins/ の中にある原因のプラグインのフォルダ名を変更します（例：plugin-b → plugin-b-off）。WordPressはそのプラグインを読み込めなくなり、自動的に停止します。フォルダ名を元に戻せば、プラグインの設定もそのまま戻ります。
ただし、プラグインを止めると、そのプラグインが担っていた機能も止まります。お問い合わせフォームや決済、予約などのプラグインなら、止めている間はその機能が使えません。止める前に、何の機能のプラグインかを確認し、必要ならサイト上でお知らせしましょう。テスト用の環境があれば、先にそちらで試すのが安全です。
原因がテーマの場合も、wp-content/themes/ の中で同じようにフォルダ名を変えると、WordPressは標準のテーマで表示しようとします（標準のテーマが入っていることが条件です）。
| 原因 | 対処 |
|---|---|
| 更新版が出ているプラグイン・テーマ | 最新の版に更新する |
| 何年も更新されていないプラグイン | 同じ働きをする、更新が続いている別のプラグインに入れ替える |
| 有料テーマ・有料プラグイン | 販売元の対応状況を確認し、最新版を入手する |
| 制作会社などが独自に書いたプログラム | 作った会社や開発者に、新しいPHPへの対応を依頼する |
何年も更新されていないプラグインは、PHPへの対応だけでなく、セキュリティの面でも危険です。
この機会に入れ替えることをおすすめします。
原因を直したら、もう一度新しいPHPに切り替えます。切り替えたあとは、トップページだけでなく、次の点まで確認しましょう。
いちばん良いのは、切り替える前にトラブルを防ぐことです。
PHPの切り替えに限らず、WordPress本体やプラグインの更新でも、不具合は起こり得ます。
更新のたびに迷わないよう、次のような標準の手順を決めておくと安心です。
そして、PHPの更新を長く先延ばしにしないことも大切です。
「動かなくなるのが怖い」と更新を避け続けると、サポートの終わった版のまま、今回のような緊急の脆弱性に直面することになります。
平常時に少しずつ対応しておくほうが、結果的に安全で、手間も少なく済みます。
必ず動かなくなるわけではありません。WordPress本体・テーマ・プラグインが更新されていれば、問題なく動くことがほとんどです。動かなくなるのは、新しいPHPに対応していない古いプラグインやテーマ、独自のプログラムがある場合です。
サイトは一時的に元どおり動きますが、原因が直ったわけではありません。古いPHPには修正版が出ない脆弱性が残ることもあるため、戻したままにせず、原因を直して新しい版に切り替え直しましょう。
おすすめできません。サポートが終わった版には、今回のような重大な脆弱性が見つかっても、PHPの開発チームからの修正版が出ません。サーバー会社が古い版の提供をやめることもあります。トラブルが起きにくい平常時のうちに、計画的に切り替えておくのが安全です。
警告（Deprecated・Warning）だけなら、サイトは動き続けることが多いです。ただし、画面に表示されていると、訪問者にサーバーの情報が見えてしまいます。表示はオフにし、次のPHPの版でエラーに変わる前に、原因のプラグインを更新・入れ替えしましょう。
一般に、新しいPHPは処理の速さが改善されていることが多く、表示が速くなる場合があります。ただし、速さはプラグインの数やサーバーの性能などにも左右されるため、必ず速くなるとは限りません。
まずは元のPHPの版に戻してサイトを復旧させてください。そのうえで、PHPの設定やエラーログの見方はレンタルサーバー会社に、特定のテーマやプラグインが原因なら開発元に、独自のプログラムが原因なら作った制作会社や開発者に相談します。エラーログやリカバリーモードのメール、メモした画面と時刻があれば、原因の特定が早くなります。
金風株式会社では、WordPressのPHPのバージョンアップの事前確認や、動かなくなったサイトの復旧、古いプラグインの入れ替えのご相談を承っています。セキュリティ診断では、PHPのバージョンやプラグインの更新状況もあわせて確認します。お気軽にご相談ください。