WordPressのPHPバージョン確認方法｜サイトヘルスと更新前の点検

こんにちは。バナナデスクです。

WordPressに「PHPの更新」を勧める表示が出たとき、最初にすることは、いま動いているPHPの番号を確かめることです。更新先を選ぶ前に、どのサイトで、どのバージョンを使っているのかを一つのメモに残しましょう。

PHP（ピーエイチピー）は、WordPressのプログラムに使われる言語です。サーバーという、サイトのデータを保管してページを届けるコンピューター上で動きます。WordPress本体にもPHPにもそれぞれ版を表す番号があるため、WordPressの番号だけではPHPの状態は分かりません。

この記事では、自分のサイトのPHPバージョンを確認し、更新前に必要な準備を書き出すところまで進めます。管理画面で現在の数字を読むだけなら、PHPの設定は変わりません。私が独立した検証サイトで行った切り替えと復元の記録も、確認する順番の参考として紹介します。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

更新日：2026年11月10日

サイトヘルスから現在のPHPバージョンを確認する

サイトヘルスは、WordPressの動作環境や状態を調べる管理画面の機能です。WordPress公式のPHP更新の案内でも、「ツール」→「サイトヘルス」→「情報」→「サーバー」の順に開き、PHPバージョンを確認する方法が示されています。

画面にはWordPress、テーマ、プラグインなどの情報も並びます。テーマはサイトの見た目を整えるもの、プラグインは問い合わせなどの機能を追加するものです。それぞれにバージョンがあるので、今回は「PHPバージョン」と書かれた行の数字を探してください。

1. 確認したいサイトのWordPress管理画面にログインします。サイト名とURLを見て、本番サイトかテスト用のサイトかを確かめます。
2. メニューの「ツール」から「サイトヘルス」を開きます。
3. 「情報」タブを選び、「サーバー」の項目を開きます。必要に応じて下へスクロールし、「PHPバージョン」または「PHP version」を探します。
4. 表示された数字を、最後の桁までそのまま控えます。たとえば8.3.33なら、8.3だけに省略せず8.3.33と記録します。
5. 同じメモに、対象サイトのURL、本番かテストか、確認日を書きます。ここまでで現在のPHPを確認する作業は完了です。

「サイトヘルス」を開くメニューが見当たらないときは、そのサイトの管理者に確認を依頼してください。似た名前の別サイトで調べた数字を、自分のサイトの値として使わないようにします。

私は2026年10月1日の検証で、WordPress Playgroundのサイトヘルスに「PHP version 8.3.33」と表示されることを確認しました。WordPressは7.1.2でした。Playgroundはブラウザー内でWordPressを試せる環境で、この記録はこのブログの本番サーバーの値ではありません。自分のメモには、例の数字ではなく、自分の画面に出た数字を入れてください。

PHPの推奨版とサポート期限は別々に確認する

2026年11月9日に再確認したWordPress公式の動作要件は、PHP 8.3以上を推奨しています。ここでいう8.3は、8.3.33などをまとめた「系列」です。末尾の数字まで含む版が最新かどうかや、使っているテーマが対応しているかは、別に確認します。

同日に再確認したPHP公式のサポート表には、二つの期限があります。「通常サポート」は、不具合とセキュリティ上の問題の修正を受ける期間です。その後の「セキュリティ対応」は、重要なセキュリティ問題への修正に限られる期間です。

PHP 8.3はWordPressの推奨条件を満たしますが、通常サポートは2025年12月31日に終了しています。セキュリティ対応の期限は2027年12月31日です。このように、推奨条件を満たすかどうかと、どの修正をいつまで受けられるかを分けて読みます。

表は2026年11月9日に公式資料と照合した、系列ごとの期限です。PHP 8.4のセキュリティ対応は2028年12月31日までです。8.3.33や8.4.25といった、この記事の検証時に表示された版が、いまも最新という意味ではありません。

更新先を考えるときは、契約しているサーバー会社が提供する版の中から、WordPress、使用中のテーマ、プラグインが対応する候補を確認します。サーバー会社は、この記事では「ホスト」とも呼びます。サポート期限が長いことだけで決めず、自分のサイトで必要な機能が動くかも点検してください。

検証サイトで8.3から8.4へ変更し、8.3へ戻した記録

私は、本番から独立したWordPress Playgroundで、PHPの設定を切り替え、元の設定へ戻す操作を行いました。WordPressは7.1.2です。Playgroundの「Site Settings」でPHPの系列を選び、「Apply」で適用した後、WordPressのサイトヘルスを開き直して表示を読みました。

ただし、最初の切り替え直後には数字がそろいませんでした。実行環境から取得した値は8.4.25でしたが、サイトヘルスには8.3.33が表示されていました。重複していたタブを閉じ、Playground全体を再読み込みしてからサイトヘルスへ入り直すと、8.4.25になりました。不一致の原因までは特定できていません。

2026年10月1日のWordPress Playground検証で私が確認したのは、検証サイト内のPHP設定の切り替え、サイトヘルスの表示値、8.4時のホーム表示、8.3への復元です。この日の検証では、本番の設定変更、契約サーバーの管理画面操作、フォーム送信は行いませんでした。問い合わせの到達、決済、すべてのプラグインの互換性も、この日の確認範囲には含まれません。互換性とは、組み合わせたソフト同士が問題なく動くかということです。

自分の点検に取り入れたいのは、設定を保存した後に、実際に使われている値を読み直すという順番です。「Applyを押せた」だけで終えず、対象のサイトヘルスへ入り直し、必要なページや機能を確かめて記録します。

サーバーの設定と数字が違うときは、対象をそろえる

レンタルサーバーの管理画面は、WordPressの管理画面とは別の場所です。PHPを選ぶ欄があっても、その設定がどのサイトへ適用されるかを先に確認します。ドメインとは、サイトの住所のうちexample.comのような名前の部分です。同じ契約で複数のドメインを管理している場合は、対象を取り違えないようにしてください。

2026年11月10日、私はXserverの旧サーバーパネルで、対象ドメインの「現在のバージョン」を確認しました。同じサイトのWordPressのサイトヘルスにある「PHP バージョン」と照合し、数字が末尾まで一致することを確認しました。この日は表示の確認だけで、PHPの変更や、更新前後のフォーム送信・通知到達の試験はしていません。

Xserverの旧サーバーパネルでは、まず対象のドメインを確認し、「PHP Ver.切替」の「PHPバージョン切替」画面で、表の「現在のバージョン」を見ます。次に、同じサイトのWordPressで「ツール→サイトヘルス→情報→サーバー」を開き、「PHP バージョン」と比べます。確認だけなら「変更後のバージョン」は選ばず、「変更」ボタンも押しません。画面例はXserver公式案内の「旧サーバーパネル」をご覧ください。

契約全体で使う既定値、サイトごとの設定値、文字の命令で処理を実行するコマンド用のPHPは、同じとは限りません。WordPressのサイトヘルスと比較したいのは、確認中のサイトをウェブで動かすPHPです。

1. サイトヘルスで控えたURLと、サーバー管理画面で選択しているドメインを照合します。本番とテスト用サイトの違いも確認します。
2. ホストの公式案内で、そのPHP設定欄がどこへ適用されるか、変更が反映されるまでに待ち時間があるかを調べます。
3. 古い管理画面のタブや別サイトを見ていないか確かめ、対象サイトのサイトヘルスを開き直します。
4. まだ数字が違う場合は、対象URL、サイトヘルスの値、サーバー設定欄の値を整理して、ホストへ問い合わせます。

数字が合わない理由を確かめるために、PHPを何度も切り替える必要はありません。変更場所や項目名はホストによって違うため、自分が契約している会社の案内で、対象と適用範囲を確認してから先へ進みます。

更新前の台帳を作る

現在の値が分かったら、更新の準備を一枚の一覧にします。これをここでは「台帳」と呼びます。次の表は、これから記入する項目を示した架空台帳です。テーマやプラグインの名称、版は、自分のサイトに表示されたものを控えてください。未確認の欄は、推測で埋めず「未確認」と残します。

WordPressの版は「ダッシュボード」→「更新」で読みます。テーマは「外観」→「テーマ」で有効なテーマの「テーマの詳細」を開き、プラグインは「プラグイン」→「インストール済みプラグイン」の一覧で、使用中の名称と版を控えます。ここでは更新ボタンを押さず、現在の情報を読み取ります。親テーマは土台になるテーマ、子テーマはその土台を使って変更を加えるためのテーマです。子テーマを使っている場合は、親と子の両方を台帳に記録します。

プラグインは名前だけでなく、「問い合わせフォーム」「会員ログイン」のように役割も添えます。すると、更新後に必ず確かめる操作を選びやすくなります。対応条件が分からない製品は、作者の説明やサポートで、使用中の版が変更候補のPHPに対応するかを確認してください。

バックアップは、正常な状態へ戻すための予備のコピーです。WordPressでは、画像やテーマなどの「ファイル」と、記事や設定などを保存する「データベース」の両方を対象にします。データベースは、表の中ではDBと略しています。取得日時に加えて、どこに保存され、どの手順で復元するかまで控えます。

さらに、PHPを元の系列へ戻す方法も必要です。サイトのバックアップを用意することと、ホスト側のPHP設定を戻せることは、別々に確かめます。WordPressへログインできなくなった場合でも、誰がどの管理画面や窓口から対応できるかを、変更前に決めてください。

WordPress公式のPHP更新案内も、更新前のバックアップと、テーマ・プラグインの互換性確認を挙げています。チェック結果だけで終えず、次の節で実際に使う操作を確認項目にします。

変更前後で、同じ操作を比べる

本番とは別のテスト環境を用意できる場合は、実際に使うテーマやプラグインを含めた状態で比べます。まず現在のPHPで結果を残し、更新の準備が整ったらホストの手順に沿ってテスト環境のPHPを切り替え、同じページ、同じアカウント、同じ入力内容で確認します。変更前からあった問題も書いておくと、今回の切り替えで起きた変化と区別できます。

以下は実サイトを想定した確認計画の見本です。先ほどのPlaygroundでの実測結果を並べた表ではありません。

問い合わせフォームでは、送信後に受付完了の画面が出ることと、通知先にメールが届くことを分けて記録します。「送信できました」と表示されても、必要な通知まで届いたかはその表示だけでは分かりません。変更前後で、テストの送信先や確認する受信箱をそろえます。

テストを始める前に、本番の顧客へメールが送られないか、実際の課金が起きないかを、対象機能の設定で確認してください。サイトをテスト環境へコピーしても、送信先や外部サービスとの接続まで切り離されているとは限りません。テスト用の送信先や、許諾のあるテストアカウントを使える状態にしてから試します。

変更後に必要な機能が動かなくなったら、起きた操作と表示を記録し、あらかじめ確認した復旧手順に沿って対応します。PHPの設定を戻すことと、必要に応じてサイトのバックアップを復元することを、担当者やホストと確認した順序で進めます。

バージョン確認ができたら、対応条件へ進む

まず完成させるのは、「対象URL」「本番かテストか」「サイトヘルスのPHPの現在値」「確認日」がそろったメモです。その値がホストのどのサイト設定に対応するかまで分かれば、次に調べる対象を絞れます。

更新へ進む前には、ホストが提供する版、WordPressとテーマ・プラグインの対応、バックアップ、PHPを戻す方法、変更前後の確認項目をそろえます。分からない項目があれば、その項目を質問として残し、ホストや製品の作者へ確認してください。サポート状況は変わるため、実際に変更する日にも公式情報を読み直します。

私は、設定を切り替えた記録と、その後に確認できた結果を分けて残すことを勧めます。まずは一つのサイトで現在の数字を正しく控える。そこから準備を積み上げれば、何を確かめてから更新するかを、自分のサイトの条件で判断できます。

関連記事：Gutenbergの使い方｜WordPressでブロックを組み、再利用できる記事を作る