WordPressのPHPは、レンタルサーバー側で動くプログラムの実行環境です。古いPHPを使い続けるとセキュリティ更新を受けられず、新しいテーマやプラグインが動かない原因になります。一方、対応確認をせず急に上げると、古いコードがエラーを起こすこともあります。
安全な更新には、現在の構成確認、バックアップ、互換性テスト、サーバーでの切り替え、更新後確認、戻し方の準備が必要です。ここでは2026年8月時点のWordPress公式要件とPHP公式のサポート状況を基準に、手順を説明します。
PHPとは?WordPressとの関係
PHPは、WordPress本体、テーマ、プラグインの多くを動かすサーバー側のプログラミング言語です。訪問者がページを開くと、PHPが設定やデータベースの内容を処理し、ブラウザへ返すHTMLなどを生成します。
PHPはWordPress管理画面からインストールするものではなく、通常はレンタルサーバーやホスティング事業者が提供します。同じサーバーに複数サイトがある場合、ドメインやディレクトリごとにPHPを切り替えられることもあれば、アカウント全体へ適用される場合もあります。
「WordPressのバージョン」と「PHPのバージョン」は別です。片方だけ新しくても、組み合わせるテーマやプラグインが未対応なら不具合が起こります。
ブラウザへ返るページだけでなく、管理画面、WP-CLI、cron、画像処理、メール、バックアップもPHPを使う場合があります。通常の閲覧ができても、夜間処理や管理操作だけ失敗することがあるため、更新後は複数の経路を確認します。
PHPには本体のほか、mbstring、curl、intl、imagickなどの拡張があります。バージョンを切り替えたときに利用できる拡張や設定値が変わるホスティングもあるため、PHP番号だけを比べないでください。
WordPressで推奨されるPHPバージョン
WordPress.orgのRequirementsページは、2026年8月時点でPHP 8.3以上を推奨しています。WordPress 7.0の最低サポートはPHP 7.4ですが、最低条件を満たすことと、安全で推奨される構成であることは同じではありません。
PHP公式は各リリース系列を、最初の2年間は通常サポート、その後2年間は重大なセキュリティ問題を対象にサポートします。同時点でサポート中の系列は8.2、8.3、8.4、8.5です。8.2のセキュリティサポートは2026年12月末まで、8.3は2027年末まで、8.4は2028年末まで、8.5は2029年末までとされています。
更新先は単純に最大の数字へ決めません。WordPress本体の対応表、使用中テーマと全プラグインの要件、サーバーの提供状況を確認し、サポート中で互換性が確認できる系列を選びます。迷う場合は、WordPressの推奨基準である8.3以上のうち、ホスティングと主要製品が正式対応するものを選びます。
PHP 8.2は2026年末までセキュリティサポート中でも、WordPressの推奨値8.3以上には届きません。短期の互換性確保に使う場合は、次の更新先と期限を決めます。8.5へ上げられる構成でも、テーマや決済プラグインが8.3までしか検証していないなら、先に開発元の情報とテスト結果を確認します。
サーバー事業者が独自に古いPHPへセキュリティ修正を提供する場合があります。その範囲と終了日はPHP公式の期間とは別なので、契約事業者へ確認します。「延長対応中」という表示だけで、新機能や全バグ修正まで受けられると考えないでください。
WordPressとPHPのバージョン対応を確認する方法
WordPress公式のCore Handbookには、WordPressとPHPの対応表があります。2026年8月時点では、WordPress 7.0はPHP 7.4から8.5まで対応として掲載されています。古いWordPressは新しいPHPに対応しない組み合わせがあるため、必ず自サイトの本体バージョンの行を確認します。
確認する場所は次の3つです。
- WordPress公式のPHP compatibility and WordPress versions
- 使用中テーマの公式配布ページ、変更履歴、サポート文書
- 各プラグインの公式配布ページ、変更履歴、システム要件
配布ページに必要PHPの最低値しか書かれていない場合、更新先のPHPで十分に検証されているとは限りません。決済、会員、フォーム、バックアップなど停止時の影響が大きい機能は、開発元の互換性情報を個別に確認します。
独自テーマや保守終了したプラグインは、公式の対応表がありません。コード検索で削除・変更されたPHP機能を探し、静的解析と実行テストを組み合わせます。警告を一時的に非表示へするだけでは互換性が直ったことになりません。
テーマの名前が同じでも、親テーマ、子テーマ、独自改修で結果が変わります。現在有効なファイル一式を対象にし、未使用プラグインも削除前の影響確認を行います。MUプラグインやホスティング固有のプラグインは通常の一覧と別に表示されるため見落とさないでください。
WordPress本体が古い場合は、PHPより先に本体を段階的に更新することがあります。手順と注意点は「本体バージョンの更新」で確認できます。
現在のPHPバージョンを確認する方法
管理画面で「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」を展開すると、PHPのバージョンを確認できます。サイトヘルスは情報表示の画面であり、そこからPHPを変更するものではありません。
サーバー管理画面にも、PHP設定、PHPバージョン切替、サーバー情報などの名称で表示されます。複数ドメインがある場合は、対象ドメインを選んでから確認してください。
コマンド操作が許可された環境では、PHP CLIのバージョンも確認できます。ただし、コマンドラインのPHPとWebサイトを実行するPHPが異なる構成があります。ブラウザから動くWordPressのサイトヘルスと、サーバー管理画面の両方を照合するのが確実です。
phpinfoを公開URLへ置く方法は、モジュールやパスなど多くのサーバー情報を外部へ見せるため推奨しません。調査で一時的に使った場合も、作業後に必ず削除します。
WordPressから確認できない場合は、サーバーのアクセスログやレスポンスヘッダーだけで推測せず、事業者の管理画面かサポートへ問い合わせます。CDNやリバースプロキシを使うと、外から見える情報と実行サーバーが一致しないことがあります。
複数のPHP設定画面があるサーバーでは、Web実行用、CLI用、cron用が分かれていることがあります。自動バックアップやWP-CLIだけ古いPHPを使っていないか、管理画面の説明を読みます。
PHPを更新する前の互換性チェック
最初に、サイトの構成表を作ります。WordPress本体、テーマ、子テーマ、必須プラグイン、PHP、データベース、外部連携を記録し、使っていないテーマとプラグインを整理します。
次に、ファイルとデータベースをバックアップし、実際に復元できることを確認します。サーバー会社の自動バックアップだけに頼らず、保持期間と復元単位を把握してください。
可能なら本番をステージングへ複製し、更新先PHPへ切り替えて次をテストします。
- トップ、記事、固定ページ、検索、404ページの表示
- 管理画面へのログイン、投稿編集、画像アップロード
- 問い合わせ、会員登録、決済、予約などの送信
- 定期処理、バックアップ、キャッシュ、メール
- ブラウザのエラーとPHPエラーログ
見た目が正常でも、警告や非推奨機能がログへ出ていないかを確認します。PHP互換性診断プラグインは補助にはなりますが、動的に呼ばれるすべてのコードや外部連携を保証するものではありません。
ステージングは、WordPressとプラグインだけでなく、PHP設定も本番へ寄せます。memory_limit、max_execution_time、upload_max_filesizeなどが大きく違うと、本番だけバックアップや画像処理に失敗します。データ量も極端に少ない空サイトではなく、機密情報を除いた実運用に近い件数で試します。
テスト結果は、画面名、操作、期待結果、実結果で記録します。ログインできる、投稿できる、といった主要経路に加え、パスワード再設定、予約投稿、サイトマップ生成、外部API通信など定期・例外経路も含めます。
WordPressのPHPバージョンを安全に更新する手順
本番作業では、問い合わせや注文が少ない時間帯を選び、関係者へ影響範囲を知らせます。更新前の最終バックアップ、戻すPHP、サーバー会社の連絡先を手元に用意します。
作業順は以下です。
- WordPress本体、テーマ、プラグインを互換性のある版へ更新する
- キャッシュを消し、更新前の状態が正常か確認する
- データベースとファイルをバックアップする
- サーバー管理画面で対象ドメインのPHPを変更する
- 数分待ち、公開側と管理画面を確認する
- 重要機能を送信テストし、ログを確認する
- 問題がなければ監視を続け、作業記録を残す
PHPの更新とWordPress本体の大型更新を同時に行うと、問題が起きたときに原因を分けにくくなります。必要な更新を小さな単位に分け、その都度確認します。
作業中に受付を止められないECや会員サイトでは、PHP変更の瞬間にも書き込みが発生します。表示だけのバックアップではなく、切り替え時点のDBを確保し、問題時に新規注文や登録をどう保全するかを決めます。短いメンテナンス表示を使うほうが安全な場合もあります。
自動更新が同じ時間帯に走ると構成が変わるため、PHP作業中は更新予定を確認します。作業者、開始時刻、変更前後の値、テスト結果を記録し、別の担当者が後から状態を判断できるようにします。
サーバー管理画面でPHPを変更する
レンタルサーバーへログインし、PHP設定またはPHPバージョン切替を開きます。対象ドメインを確認し、検証済みのバージョンを選び、変更を確定します。画面の名称と反映時間は事業者によって異なります。
切り替え前に、現在値を画面メモやスクリーンショットで残します。複数サイトへ同時適用される場合は、すべてのサイトで互換性確認が必要です。選択肢がない、または古いPHPしかない場合は、サーバー事業者へ提供予定を確認し、必要なら移転を検討します。
VPSや専用サーバーでパッケージを直接更新する作業は、Webサーバーとの接続方式、拡張モジュール、サービス再起動まで関係します。管理権限と復旧手段がなければ、サーバー管理者へ依頼してください。
レンタルサーバーで切り替えが反映されない場合は、対象ドメイン、反映待ち時間、サーバーキャッシュを確認します。PHP-FPMやOPcacheが古いプロセスを保持する環境では、事業者が用意した再起動やキャッシュ削除の手順に従います。権限のない利用者がプロセスを強制終了しないでください。
更新後にサイトと管理画面を確認する
公開側では、キャッシュ済みページだけを見ないように、ログイン、検索、フォームなど動的な画面も確認します。管理画面では投稿編集、メディア、プラグイン一覧、サイトヘルスを開きます。
サーバーのPHPエラーログに、Fatal error、Uncaught Error、Deprecatedなどが出ていないかを調べます。Deprecatedは直ちに停止しない場合もありますが、将来のPHPで動かなくなる可能性を示すため、テーマやプラグインの更新・修正計画へ入れます。
決済やフォームは、画面上の完了だけでなく、通知、データ保存、外部システムへの反映まで確認します。翌日にもエラー件数、問い合わせ、アクセス解析の急変を見ます。
性能も変更前後で比べます。ただし、PHP更新直後はキャッシュが空で遅く見えることがあります。同じページ、同じキャッシュ条件、近い時間帯で応答時間とエラー率を比較し、一度の体感だけで判断しません。
管理画面のサイトヘルスでPHP番号が変わったことを確認し、サーバー管理画面の表示と一致させます。cronやCLIを別PHPで動かす設定なら、それぞれのジョブも試します。
PHP更新後に不具合が出た場合の戻し方
白い画面、500エラー、管理画面へ入れない状態になったら、まずエラーの時刻と表示を記録します。サーバー管理画面へ入れる場合は、先ほど記録した元のPHPへ戻します。反映後にキャッシュを消し、サイトが復旧するか確認します。
元へ戻して直るなら、更新先PHPとの互換性が原因である可能性が高いでしょう。エラーログに出たファイルパスから、テーマ、プラグイン、独自コードのどこで失敗したかを絞ります。問題製品を最新版へ更新し、ステージングで再試験します。
画面が真っ白になった場合の切り分けは「更新後に画面が真っ白になったら」で詳しく確認できます。原因を調べず古いPHPへ戻したまま終えず、期限を決めて修正・代替・サーバー移転を進めてください。
PHPを戻しても復旧しない場合は、同時に行ったWordPress更新、キャッシュ、ファイル変更、DB更新も確認します。必要なら作業前のバックアップへ復元しますが、更新後に入った注文や問い合わせを失わないよう、差分を保全します。
一時的に元へ戻した後は、問題の製品名、エラー行、再現操作、更新先PHPを記録します。開発元へ問い合わせるときは、個人情報や秘密鍵を除いたログ、WordPress、PHP、製品バージョンを伝えます。原因製品を特定できないまま全プラグインを本番で停止するのは避けます。
修正版が提供されない場合は、互換性のある代替製品へ移行するか、独自コードを改修します。古いPHPへ戻すことを恒久策にせず、期限、担当、テスト日を決めて再更新します。
PHPバージョンを古いまま使うリスク
PHP公式のサポートが終了した系列には、通常のバグ修正やセキュリティ修正が提供されません。WordPressが技術的に起動していても、安全に運用できるとはいえません。
また、新しいテーマやプラグインが古いPHPの対応を終了すると、更新できない、機能が追加されない、インストールに失敗するといった問題が起こります。その結果、WordPress本体も上げられず、複数の古い要素を抱える状態になります。
古いPHPを維持する時間が長いほど、後の更新幅とテスト量が増えます。すぐに切り替えられない場合は、不要な機能の停止、アクセス制限、監視強化を行い、テーマ改修、プラグイン交換、サーバー移転の期限を決めます。
サーバー移転を伴う場合は、移転先で利用できるPHPと拡張、DB、Webサーバー、メール送信を先に確認します。同じPHP 8.3でも設定や拡張が違えば動作は変わります。移転とPHP更新を同日に行う必要があるときは、旧環境を一定期間保持し、DNSを戻せる条件を準備します。
よくある質問
最新版がWordPress本体とすべてのテーマ・プラグインに対応しているとは限りません。PHP公式でサポート中か、WordPressの対応表に載っているか、主要製品が対応しているかを確認し、ステージングで試してから更新します。
あります。古いテーマ、プラグイン、独自コードが、新しいPHPで削除・変更された機能を使っている場合などに起こります。元のPHPへ戻せるようにし、エラーログから原因を特定します。
この記事はサーバーでPHPバージョンを確認・更新する手順が中心です。テーマのPHPファイル編集、関数追加、php.iniの設定変更は別の作業で、必要な権限と影響範囲も異なります。
まとめ
WordPress.orgは2026年8月時点でPHP 8.3以上を推奨しています。更新先は、PHP公式のサポート期間、WordPress本体の対応表、テーマとプラグインの要件を照合して決めます。最低対応バージョンで動くことを、安全な推奨構成と取り違えないでください。
本番変更の前に、構成記録、バックアップ、ステージングテスト、元のPHPへ戻す手順を用意します。切り替え後は、公開画面だけでなく管理画面、フォーム、決済、メール、エラーログまで確認し、問題があれば元へ戻して原因を修正します。
