WordPressのPHPバージョンアップエラー解消完全ガイド｜重大なエラー・画面真っ白からの復旧と主要サーバー別切り戻し手順

WordPressの管理画面に「PHPのバージョンを更新してください」と表示され、サーバーのコントロールパネルからPHPバージョンを切り替えた直後、サイトを開いたら「画面が真っ白になってしまった」「このサイトで重大なエラーが発生しましたと表示され、管理画面にすら入れない」――そんな予期せぬトラブルに直面し、強い不安を感じている方も多いのではないでしょうか。

PHPのバージョンアップは、Webサイトの表示速度向上やセキュリティ脆弱性の排除のために欠かせない重要なメンテナンスです。しかし、利用しているテーマやプラグインが新しいPHPの仕様に対応していない場合、致命的な構文エラー（Fatal Error）が発生し、サイト全体が突然停止してしまうことがあります。

しかし、決して慌てる必要はありません。
PHPの切り替えによってエラーが発生しても、データベースに保存されている記事データや投稿、画像ファイルが消去されたわけではありません。 PHPスクリプトの実行が互換性不整合によって途中でストップしただけです。

本ガイドでは、PHPバージョンアップ直後にエラーが発生して困っている方に向けて、【最短3分】で元の正常な状態へ戻す主要4大レンタルサーバー別の即時切り戻し（ロールバック）手順から、デバッグログを用いた原因プラグインの特定方法、二度とエラーを起こさないための予防策までを完全網羅して分かりやすく解説します。

なお、事前の準備や標準的なバージョンアップ手順全体を確認したい方は、当サイトの親記事である WordPressのPHPバージョンアップ完全手順｜主要サーバー別変更手順と非推奨エラー・互換性トラブル解消法 もあわせて参考にしてください。

PHP更新直後にエラーが出たときの初動対応と症状別クイック切り分け

PHPバージョンを切り替えた直後にサイトにアクセスできなくなった場合、手当たり次第に設定ファイルを変更したり、サーバーのデータベースを操作したりしてはいけません。誤った操作を行うと、軽微なエラーが二次災害となり、復旧を難しくしてしまう恐れがあります。

まずは落ち着いて現状の症状を観察し、適切な初動対応を取りましょう。

落ち着いて確認すべき初動の基本姿勢

エラー発生時に最も大切なことは、「現状の症状を正確に把握し、最優先で公開サイトを元に戻す」 という意識を持つことです。

1. 焦ってファイルを削除・初期化しない：サーバーのファイルを無理に削除したり、WordPressを再インストールしようとすると、取り返しのつかないデータ損失を招きます。
2. 直前の変更内容をメモしておく：切り替え前のPHPバージョン（例: PHP 7.4.33 や PHP 8.1.x）と、新しく選択したバージョン（例: PHP 8.3.x）を正確に把握します。
3. 復旧を最優先にする：エラー原因の究明よりも先に、まずは直前のPHPバージョンへ切り戻してサイトの公開状態を回復させることが鉄則です。

【最短3分】症状別クイック切り分けフローチャート

PHP更新後に発生するトラブルは、画面の表示状態によって大きく4つに分類できます。以下の症状別切り分けに従って、現在のサイト状態を特定してください。

画面の表示症状	想定される主な原因	最優先の初動対処
画面が完全に真っ白（WSOD）	プラグインやテーマの致命的エラー（Fatal Error）によるスクリプト停止	サーバーパネルから旧PHPバージョンへ即時切り戻し
「このサイトで重大なエラーが発生しました」	WordPressコアによる例外検知、プラグインの互換性崩壊	管理者メール宛のリカバリーモード通知を確認、または切り戻し
「500 Internal Server Error」	.htaccessの古いハンドラ記述残留、memory_limit不足	.htaccessの記述確認、またはPHPバージョン切り戻し
「Deprecated: …」等の警告が露出	非推奨構文の警告（プログラム自体は動作中）	wp-config.phpでdisplay_errorsを非表示化（サイト停止は不要）

画面が真っ白になる現象については、当サイトの別記事 【最短5分】WordPressの画面が真っ白（WSOD）になった時の原因別切り分けと主要サーバー別復旧ガイド でも詳しく解説していますが、PHPバージョンアップ直後に起きた場合は「直前のPHPへの切り戻し」が最も確実かつ最速の解決策となります。

PHPバージョンアップ後に発生するエラーの4大原因とメカニズム

なぜ、PHPバージョンを新しくしただけでサイトが表示されなくなってしまうのでしょうか。そのメカニズムを理解しておくと、切り戻した後の根本対策がスムーズになります。主な原因は以下の4点に集約されます。

原因1：プラグイン・テーマのPHP8.x互換性不足（非推奨関数の廃止とFatal Error）

PHPバージョンアップで最も多いトラブル原因が、「古いプラグインやテーマがPHP 8.x系の新仕様に対応していないこと」 です。

PHPは、メジャーアップデート（PHP 7系から8系など）やマイナーアップデート（8.1から8.2、8.3など）の過程で、過去のバージョンで使われていた曖昧な関数やセキュリティリスクのある古い構文を段階的に廃止してきました。
例えば、PHP 7系では「Deprecated（非推奨警告）」にとどまっていたコードが、PHP 8系では「Fatal Error（致命的エラー）」としてスクリプト全体の実行を即座に停止させる仕様に変更されています。

具体的には、以下のようなケースでクラッシュが発生します。

• 未定義変数の参照や配列アクセスの厳格化による型エラー（TypeError）
• 廃止された旧式関数（例: each() や create_function() 等）の呼び出し
• 引数の型宣言の不一致や必須引数の順序違反

数年間アップデートされていないプラグインや、独自に開発した古いテーマを有効化している場合、PHPを更新した瞬間に処理落ちしてサイトが真っ白になります。

原因2：memory_limit（メモリ上限）の不足によるスクリプト処理落ち

PHPのバージョンが新しくなると、メモリ管理エンジンの改善により通常は効率化されますが、プラグインやWordPress本体の初期化処理のタイミングによっては、一時的にメモリ消費のピークが従来と異なる挙動を示すことがあります。

サーバー環境において、PHPスクリプト1プロセスあたりに割り当てられるメモリ上限（memory_limit）が「128MB」などの低めに設定されている場合、バージョンアップに伴うライブラリの読み込み負荷によって上限を突破し、「Fatal error: Allowed memory size of … bytes exhausted」 というメモリ枯渇エラーが発生します。

特に、画像処理プラグインや高機能なSEOプラグイン、ECプラグイン（WooCommerce等）を多数導入しているサイトで起こりやすい原因です。

原因3：データベース接続設定・PHP拡張モジュールの不整合

PHPのバージョンを変更すると、Webサーバー内で動作するPHPモジュール群も新しいバージョン用のライブラリに切り替わります。
この際、MySQLやMariaDBと接続するための拡張モジュール（mysqli や pdo_mysql）の読み込み設定が不完全だったり、データベースのパスワード認証形式が新しいPHPの暗号化方式と一致しなかったりすると、「データベース接続確立エラー（Error establishing a database connection）」 が発生します。

また、文字コード処理を行う mbstring や、暗号化処理を行う openssl などの必須拡張モジュールが新しいPHP環境で無効化されている場合も、WordPressが正常に起動できず500エラーとなります。

原因4：.htaccessに残った古いPHPハンドラ記述の競合

過去に手動でPHPのバージョンを指定していたり、古いサーバー移行ツールを使用したことがあるサイトでは、WordPressのルートディレクトリにある .htaccess ファイル内に古いPHPハンドラ（Handler）の記述が直接書き込まれていることがあります。

例えば、以下のような古い記述が .htaccess に残っているケースです。

# 古いサーバー設定の残留例
AddHandler application/x-httpd-php74 .php

この状態でサーバーの管理画面からPHPバージョンを「PHP 8.3」に切り替えると、サーバー側のシステム設定と .htaccess 内の個別指示が真っ向から競合し、Webサーバー（Apache）がどちらのハンドラで処理すべきか判断できず、「500 Internal Server Error」 を吐き出してWebサイト全体が停止します。

【緊急対応】主要4大レンタルサーバー別 PHPバージョンの即時切り戻し手順

サイトがエラーで停止して訪問者がアクセスできない状態にある場合、何よりも優先すべきは「直前の正常稼働していたPHPバージョンへの即時切り戻し（ロールバック）」 です。
原因調査やコードの修正は、サイトを復旧させてから落ち着いて行えば問題ありません。

国内で利用者の多い主要4大レンタルサーバー（エックスサーバー、ConoHa WING、さくらインターネット、ロリポップ！）における、具体的な切り戻し手順をステップ順に解説します。

エックスサーバー：サーバーパネルでの即時切り戻し手順

エックスサーバーはドメインごとに個別のPHPバージョンが管理されており、管理画面からの切り戻し操作は数十秒から1分程度で迅速に反映されます。

1. サーバーパネルへログイン: エックスサーバーの契約管理画面から対象サーバーの「サーバーパネル」にログインします。
2. 「PHP Ver.切替」を選択: メニュー中央の「PHP」項目内にある「PHP Ver.切替」をクリックします。
3. 対象ドメインの選択: 複数ドメインを運用している場合は、エラーが発生しているドメイン名の右側にある「選択する」をクリックします。
4. 旧バージョンの指定: 「変更後のバージョン」のプルダウンメニューを開き、変更直前まで安定稼働していたバージョン（例: PHP 8.2.x や PHP 8.1.x 等）を選択します。
5. 変更の確定: 「変更」ボタンをクリックします。

変更完了のメッセージが表示されたら、ブラウザでWebサイトを再読み込み（F5キーまたはCtrl+F5）し、正常に表示が復旧していることを確認してください。

ConoHa WING：コントロールパネルでの切り戻しとWAF確認手順

ConoHa WINGはコントロールパネルのレスポンスが高速で、PHP設定の変更は即座に反映されます。

1. コントロールパネルへログイン: ConoHaのコントロールパネルにログインします。
2. サイト設定を開く: 左側メニューの「サイト管理」＞「サイト設定」をクリックします。
3. 応用設定のPHP設定を表示: 画面上部のタブから「応用設定」を選択し、「PHP設定」アコーディオンをクリックして開きます。
4. 旧バージョンへの変更: バージョン表示の右側にある「鉛筆アイコン（編集）」をクリックし、プルダウンから直前の安定バージョン（例: 8.2 等）を選択して「保存」をクリックします。

なお、ConoHa WINGではPHPバージョンアップ時に備え付けのWAF（Web Application Firewall）が管理画面の通信を攻撃と誤判定し、403 Forbiddenエラーを発生させることがあります。もし切り戻し後も管理画面だけ開けない場合は、左側メニュー「サイト管理」＞「サイトセキュリティ」＞「WAF」を開き、直近の除外ログを確認して一時的に除外設定を行ってください。

さくらインターネット：新コントロールパネルでの言語バージョン切り戻し手順

さくらのレンタルサーバ（新コントロールパネル）では、サーバー全体の設定またはドメインごとの個別設定から簡単に切り戻しが可能です。

1. サーバコントロールパネルへログイン: さくらインターネットの「サーバコントロールパネル」へログインします。
2. 言語バージョン設定を開く: 左メニューの「スクリプトとプログラム」をクリックし、「言語バージョン設定」を選択します。
3. バージョンの再指定:
   • サーバー全体で運用している場合は、「パッケージ」タブの「PHPのバージョン」プルダウンから旧バージョン（例: PHP 8.2）を選択します。
   • ドメインごとに設定している場合は、「ドメインごとの設定」を展開し、該当ドメインのバージョンを変更します。
4. 設定の保存: 画面下部にある「保存する」ボタンをクリックします。

反映はほぼ即時行われます。ブラウザのキャッシュをクリアしてサイトの表示を確認してください。

ロリポップ！：ユーザー専用ページでのPHP設定変更と反映タイムラグ対策

ロリポップ！（Lolipop!）は、操作自体は非常にシンプルですが、「設定変更から実際のサーバー反映までに5分〜10分程度のタイムラグが発生する」 という特徴があります。変更直後に直っていなくても焦らず待つことが重要です。

1. ユーザー専用ページへログイン: ロリポップ！の管理画面にログインします。
2. PHP設定を開く: 左側メニューの「サーバーの管理・設定」＞「PHP設定」をクリックします。
3. 対象ドメインの確認: ドメイン一覧の中から、エラーが出ているドメインの行を探します。
4. 旧バージョンを選択: 「バージョン」のプルダウンから、変更前の安定バージョン（例: PHP 8.2 (モジュール版)）を選択します。
   ※特別な理由がない限り、処理が高速な「モジュール版」を選択してください。
5. 変更の実行: 「変更」ボタンをクリックします。

「設定を変更しました」と表示された後、サーバー内部の同期処理が行われます。約5分〜10分経過してからブラウザをスーパーリロード（Ctrl+Shift+R）して復旧を確認しましょう。

エラー原因の特定フロー（デバッグモードとログ解析）

直前のPHPバージョンへ切り戻してサイトが正常に戻ったら、次は「なぜ新しいPHPバージョンでエラーが起きたのか」という根本原因を突き止めます。
原因を放置したままでは将来的にPHPを安全に更新できず、セキュリティ期限切れのリスクを抱え続けることになります。

原因の特定には、WordPressに備わっているデバッグ機能（WP_DEBUG） とエラーログ（debug.log）を活用します。

wp-config.php で安全に WP_DEBUG と WP_DEBUG_LOG を有効化する手順

通常、本番サイトでデバッグモードを不用意に有効化すると、一般の訪問者のブラウザ画面にエラー内容がそのまま表示されてしまい、システムの内部パスやデータベース構造が露出するセキュリティリスクが生じます。

そのため、「画面には一切エラーを出さず、サーバー内のログファイル（debug.log）にだけ記録する」 という安全な記述を用います。

サーバーのファイルマネージャーまたはFTPソフトでWordPressのルート直下にある wp-config.php を開き、/* 編集が必要なのはここまでです ! WordPress でのコーディングをお楽しみください。 */ という行の直前に、以下のコードを記述します。

// デバッグログの安全な記録設定（画面非表示・ログ出力のみ）
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

この設定を保存した後、再度サーバーパネルからPHPバージョンを新しいバージョンへ切り替えてエラーを一度再現させ、すぐに元のバージョンへ戻すか、テスト環境で再現させます。
すると、サーバー上の /wp-content/debug.log に詳細なエラー履歴が自動生成されます。

debug.log からエラーを引き起こしているプラグイン名・テーマを特定する読み方

生成された wp-content/debug.log をテキストエディタで開くと、日時の後にエラーのレベルや原因行が記録されています。
見るべきポイントは、行頭に 「PHP Fatal error」 または 「PHP Parse error」 と書かれている部分です。

[01-Jan-YYYY 10:15:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function create_function() in /home/user/example.com/public_html/wp-content/plugins/old-social-widget/widget.php:42

上記のログを読み解く手順は以下の通りです。

1. エラーの種類: PHP Fatal error（致命的エラーによる処理停止）
2. 原因の内容: Call to undefined function create_function()（PHP 8.0で完全廃止された古い関数 create_function が呼び出された）
3. 原因箇所のファイルパス: /wp-content/plugins/old-social-widget/widget.php:42

このパスを見ることで、トラブルを引き起こしている元凶が old-social-widget というプラグインの42行目であることが一目瞭然で分かります。
もしパスが /wp-content/themes/my-theme/... となっていれば、現在使用しているテーマファイル側の記述が原因です。

管理画面に入れない場合にFTPやファイルマネージャーからプラグインを一時無効化する方法

もし新しいPHPバージョンのまま管理画面にログインできなくなってしまった場合でも、FTPソフトやレンタルサーバーのファイルマネージャーを使えば、WordPress管理画面を通さずに問題のプラグインだけを強制的に無効化できます。

1. ファイル管理画面へアクセス: 契約サーバーのファイルマネージャー、またはFTPクライアント（FileZilla等）でサーバーに接続します。
2. プラグインディレクトリへ移動: WordPressルートディレクトリから /wp-content/plugins/ ディレクトリを開きます。
3. 原因プラグインのフォルダを特定: 先ほどのデバッグログで判明したプラグインのフォルダ（例: old-social-widget）を探します。
4. フォルダ名を一時的に変更: フォルダ名の末尾に「_disabled」や「_temp」などを追記してリネームします（例: old-social-widget_disabled）。
5. 自動無効化の完了: フォルダ名が変更されると、WordPressは「プラグインファイルが存在しない」と判断し、設定データを保持したまま該当プラグインのみを自動的に停止します。

この状態でブラウザを更新すると、問題のプラグインのみが除外された状態でサイトと管理画面が正常に起動します。
その後、管理画面から代替プラグインを探すか、プラグインのアップデートを行いましょう。

PHPバージョンアップでエラーを出さないための事前予防チェックリスト

PHPバージョンアップによるエラーは、事前の確認と準備を徹底することで9割以上回避できます。
次回以降のバージョンアップ作業を行う際は、必ず以下の事前予防チェックリストを実践してください。

プラグイン・テーマの最終更新日とPHP互換性の事前確認

WordPressサイトがクラッシュする最大の原因は、長期間メンテナンスされていないプラグインやテーマです。

1. プラグインの最終更新日を確認:
   WordPress公式ディレクトリのプラグインページや管理画面のプラグイン詳細を開き、「最終更新日」が1〜2年以上前で停止していないか確認します。長期間放置されているプラグインは、PHP 8系の新構文に対応していない可能性が極めて高いため、同等機能を持つ最新のプラグインへの乗り換えを検討してください。
2. テーマの最新対応状況を確認:
   利用しているテーマの開発元公式サイトやお知らせを確認し、新バージョンのPHP（PHP 8.2や8.3等）での動作検証がアナウンスされているかをチェックします。親テーマだけでなく、自作の子テーマの functions.php に古いPHP構文が書かれていないかも点検しましょう。
3. 不要な停止中プラグインの完全削除:
   「停止中」のプラグインであっても、一部のファイルがサーバー上に残っていることでセキュリティ脆弱性の温床になったり、意図しないライブラリ読み込みで干渉を引き起こすことがあります。使っていないプラグインやテーマは事前に完全に削除しておきます。

サイト全体の事前バックアップ実施手順（DBとファイル一式）

PHPのバージョン切り替え自体はサーバー側の処理ですが、万が一のシステム障害やプラグイン更新時のデータ破損に備えて、必ず直前の完全バックアップを取得しておきます。

保存すべきデータは以下の2点です。

• データベース（MySQL/MariaDB）: すべての投稿記事、固定ページ、コメント、ユーザーデータ、各種設定値。
• Webサーバー上のファイル群: /wp-content/ 配下のテーマ・プラグイン・アップロード画像、および最重要設定ファイルである wp-config.php と .htaccess。

主要レンタルサーバー（エックスサーバーやConoHa WING等）では、過去14日分の自動バックアップ機能が標準提供されていますが、作業直前にはプラグイン（All-in-One WP MigrationやUpdraftPlusなど）を用いて手動バックアップをローカルPC等にダウンロードしておくのが最も確実です。

詳しいバックアップ方法や最短10分でのリストア手順については、当サイトの解説記事 【最短10分復旧】WordPressバックアップ＆復元完全手順｜主要サーバー別自動復元・プラグイン・手動リストア をご参照ください。

ステージング環境（テスト環境）での先行検証手順

本番サイトでぶっつけ本番のバージョンアップを行うのは非常にハイリスクです。
特にECサイトや企業コーポレートサイト、大規模メディアなど、1分間のダウンタイムでも大きな機会損失につながるサイトでは、ステージング環境（本番サイトの複製テスト環境）での先行検証 が必須となります。

エックスサーバーの「ステージング機能」やConoHa WINGの「サイトコピー機能」を利用すれば、ボタン数クリックで本番と全く同一の検証用環境を構築できます。

ステージング環境を作成したら、以下の項目を順にテストします。

• ステージング環境のみPHPバージョンを最新推奨版へ切り替える
• トップページ、主要記事、固定ページのレイアウトが崩れていないか確認する
• お問い合わせフォーム（Contact Form 7等）からテスト送信を行い、正常に送受信できるか検証する
• 管理画面にログインし、新規記事の投稿や画像アップロードが問題なく行えるか確認する

テスト環境で一切のエラーが発生しないことを確認した上で本番環境の切り替えに進めば、トラブルのリスクをほぼ完全に排除できます。

WordPressのPHPバージョンアップエラーに関するよくある質問（FAQ）

PHPバージョンアップ時のエラーに関して、サイト管理者から多く寄せられる質問とその回答をまとめました。

Q1: PHPを古いバージョンに戻したまま放置しても安全ですか？

回答：決して安全ではありません。長期間の放置は深刻なセキュリティリスクを招きます。

PHPにはバージョンごとに明確な「公式セキュリティサポート期限（EOL：End of Life）」が定められています。サポート期限が終了した古いPHPバージョンに対しては、新たに重大な脆弱性（リモートコード実行や情報漏えいリスクなど License等）が発見されても、公式の修正パッチは一切提供されません。

サイバー攻撃者はサポート切れのPHP環境を自動ツールで常に狙っており、サイト改ざんやマルウェア感染の標的になります。エラーが出た直後は一時的に旧バージョンへ切り戻してサイトを復旧させるべきですが、その後速やかに原因プラグインを特定・改修し、サポート期間内の最新バージョンへ移行する必要があります。

Q2: 「このサイトで重大なエラーが発生しました」と出たときのリカバリーモード利用法は？

回答：WordPressの管理者メールアドレス宛に届く「緊急ログイン用URL」からダッシュボードにアクセスできます。

WordPress 5.2以降には、PHPの致命的エラーを検知した際に管理者メール宛へ自動通知を送る「リカバリーモード」が標準装備されています。

サイトが重大なエラー画面になった場合、管理者宛に「サイトで技術的な問題が発生しています」という件名のメールが送信されます。メール本文内に記載されている「リカバリーモード用リンク」をクリックすると、原因となっているプラグインやテーマが自動的に一時停止された状態で管理画面に安全にログインできます。管理画面に入ったら、通知に記載されたプラグインを無効化してください。

Q3: PHPバージョンを更新したのに管理画面で古いバージョンのまま表示される原因は？

回答：サーバー側のキャッシュ機能やOPcacheの残留、またはドメイン設定の階層相違が主な原因です。

サーバーコントロールパネルでPHPを変更したにもかかわらず、WordPressの「サイトヘルス」等で反映が確認できない場合、以下の原因が考えられます。

• キャッシュの残留: サーバー側のOPcache（PHPバイトコードキャッシュ）や高速化アクセラレータが古い情報を保持している。サーバーパネルからキャッシュクリアを実行するか、数分間待ちます。
• 対象ドメインの指定ミス: サブドメインや複数ドメインを管理している場合、変更対象と異なるドメインのPHP設定を変更してしまっているケースがあります。設定対象のホスト名を再確認してください。

まとめと関連記事・安全なPHP運用の次のステップ

WordPressのPHPバージョンアップ直後にエラーが発生しても、焦らず冷静に対処すれば数分で復旧できます。

トラブル復旧後の安全チェック項目

旧バージョンへの切り戻しや原因プラグインの停止によってサイトが無事に復旧したら、最後に以下の点検を行ってください。

• [ ] WP_DEBUG設定の解除: 復旧確認後は、wp-config.php に追記したデバッグコードを無効化（define('WP_DEBUG', false);）に戻したか
• [ ] サイト全体の表示確認: トップページだけでなく、個別記事・お問い合わせフォーム・管理画面が正常に稼働しているか
• [ ] 根本原因の解決計画: 今回エラーを引き起こしたプラグインのアップデート状況を確認し、必要に応じて代替プラグインを選定する
• [ ] 最新バックアップの保管: 復旧後の正常な状態のバックアップを新たに保存したか

関連手順ガイド（親記事）へのご案内

安全なPHPバージョンアップの事前準備や主要サーバー別の標準的な変更フロー、非推奨警告（Deprecated）の非表示化テクニックについては、以下の親記事で体系的に解説しています。今後のバージョンアップ作業のロードマップとしてぜひご活用ください。

👉 WordPressのPHPバージョンアップ完全手順｜主要サーバー別変更手順と非推奨エラー・互換性トラブル解消法

また、関連するWordPressトラブル復旧ノウハウは以下でも詳しく解説しています。

• 【最短5分】WordPressの画面が真っ白（WSOD）になった時の原因別切り分けと主要サーバー別復旧ガイド
• 【最短10分復旧】WordPressバックアップ＆復元完全手順｜主要サーバー別自動復元・プラグイン・手動リストア