WordPressのPHPバージョンを安全に上げる手順｜重大なエラーが出たときの戻し方

WordPress を長く運用していると、ある日サーバー会社から「古い PHP のサポートが終わります」という案内が届きます。管理画面にも「PHP の更新が必要です」と出てきて、上げなきゃいけないのは分かっている。でも、上げた瞬間にサイトが真っ白になったらどうしよう……と後回しにしがちな作業です。

特に今年は、PHP 8.2 のセキュリティサポートが 2026年12月31日で終わります。8.2 のまま運用しているサイトは、年内に一度見直しておくタイミングです。

この記事では、制作者向けに「PHP を上げる前に確認すること」「切り替えの手順」「エラーが出たときの戻し方と原因の探し方」を、順番にまとめます。

まず、いまの PHP と推奨バージョンを確認する

現在の PHP バージョンは、管理画面の ツール → サイトヘルス → 情報 → サーバー で確認できます。サイトヘルスの「ステータス」に PHP の更新を促す項目が出ていれば、それも目安になります。

WordPress 公式の動作環境ページでは、執筆時点で PHP 8.3 以上 が推奨されています。PHP 7.4 以上でも動きはしますが、7.4 はすでにサポートが終わっており、公式でもセキュリティ上のリスクがあると明記されています。

PHP 本体のサポート期限（php.net の Supported Versions より）は次のとおりです。

バージョン	通常サポート終了	セキュリティサポート終了
8.2	2024年12月31日	2026年12月31日
8.3	2025年12月31日	2027年12月31日
8.4	2026年12月31日	2028年12月31日
8.5	2027年12月31日	2029年12月31日

これから上げるなら、8.3 以上を選んでおけば当面は安心です。ただし、いきなり最新に飛ばすより、テーマやプラグインが対応しているバージョンを選ぶほうが大事です。

上げる前にやっておく4つのこと

1. バックアップを取る

ファイル一式とデータベースの両方を取ります。PHP を戻せば直るケースがほとんどですが、プラグイン更新なども一緒にやると、何かあったときに「どこまで戻せばいいか」が分からなくなります。バックアップは作業の直前に取り直しておきましょう。

2. WordPress 本体・テーマ・プラグインを先に更新する

古いプラグインほど、新しい PHP で動かない書き方が残っています。PHP を上げる前に、本体・テーマ・プラグインを最新にしておくだけで、トラブルの多くは防げます。

プラグインの詳細画面で「テスト済み WordPress バージョン」や「必要な PHP バージョン」を見て、長いあいだ更新が止まっているものがないかも確認しておきます。止まっているものは、代わりのプラグインを探すか、使わないなら停止・削除を検討します。

3. 自作テーマ・独自コードを洗い出す

制作案件で一番つまずきやすいのはここです。公開プラグインは作者が対応してくれますが、functions.php や自作のテーマ・プラグインは誰も直してくれません。古い書き方（すでに削除された関数や、PHP 8 で厳しくなった型の扱いなど）が残っていないか、可能なら事前に目を通しておきます。

4. 検証環境で先に試す

ステージング環境やローカル環境があれば、そちらで先に PHP を上げて、トップページ・下層ページ・お問い合わせフォームの送信・管理画面の投稿編集あたりを一通り触っておきます。本番で試すのは、それができないときの最終手段です。

切り替えはサーバーの管理画面から

多くのレンタルサーバーでは、管理画面から PHP のバージョンを切り替えられます。たとえば XSERVER なら、サーバーパネルの 「PHP Ver.切替」 から、ドメインごとにバージョンを選んで設定します。

ドメイン単位で切り替えられるサーバーなら、同じサーバーに複数サイトがあっても、1サイトずつ順番に上げられます。いきなり全部を上げず、影響の小さいサイトから試すのがおすすめです。

切り替えたら、次のページをすぐに確認します。

トップページと、代表的な下層ページ・記事ページ
お問い合わせフォーム（送信と自動返信メールまで）
管理画面へのログインと、投稿の編集・保存
カスタム投稿やカスタムフィールドを使っているページ

「重大なエラー」が出たときの戻し方

切り替え後に「このサイトで重大なエラーが発生しました」と表示されたり、画面が真っ白になったりしたら、まずは落ち着いて PHP のバージョンを元に戻します。同じ画面から戻せば、ほとんどの場合はすぐに元どおり表示されます。原因の調査は、サイトを戻してからで大丈夫です。

リカバリーモードのメールを確認する

WordPress 5.2 以降には、致命的なエラーが起きたときに、サイトの管理者メールアドレス宛てに「リカバリーモード」へのリンクを送る仕組みがあります。リンクから入ってログインすると、エラーの原因になったプラグインやテーマを一時停止した状態で管理画面に入れて、どれが原因かも表示されます。

このとき停止されるのは、リンクを開いた自分のブラウザだけです。ほかの訪問者には引き続きエラーが見えているので、原因のプラグインを停止するか、PHP を戻すところまでは早めに済ませましょう。

エラーログで原因を特定する

メールが届かない・どのコードが原因か分からないときは、wp-config.php でデバッグログを有効にします。/* That's all, stop editing! */ の行より前に、次の内容を追加します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

これで、エラーは画面に出さず、wp-content/debug.log に記録されるようになります。ログに出たファイル名と行番号を見れば、どのプラグイン・テーマのどこで止まっているかが分かります。

原因が分かったら、調査が終わり次第、WP_DEBUG は必ず false に戻し、debug.log も削除しておきましょう。公式ドキュメントでも本番サイトで使い続けることは推奨されていません。ログには公開したくない情報が含まれることもあります。

管理画面に入れないときは、プラグインのフォルダ名を変える

管理画面そのものが開けない場合は、FTP やサーバーのファイルマネージャーで wp-content/plugins の中にある、原因と思われるプラグインのフォルダ名を一時的に変更します（例：plugin-name → plugin-name_off）。WordPress はそのプラグインを読み込めなくなり、自動的に無効化されます。どれか分からないときは、plugins フォルダごと名前を変えて、一つずつ戻していく方法もあります。

まとめ

PHP の更新は、手順さえ決めておけば怖い作業ではありません。

PHP 8.2 のセキュリティサポートは2026年末まで。いまのバージョンをサイトヘルスで確認する
上げる前に、バックアップと本体・テーマ・プラグインの更新を済ませる
自作テーマや独自コードは、事前に検証環境で確認する
エラーが出たら、まず PHP を戻す。原因はリカバリーモードと debug.log で探す
調査が終わったらデバッグ設定は必ず元に戻す

サイトを長く安全に動かすためにも、「サーバーから案内が来たら対応」ではなく、年に一度くらいは自分から確認する習慣をつけておくと安心です。