WordPressのPHP更新とエラー時の確認順

更新前か、更新後のエラーかを先に確かめる

更新通知を受けた段階なら対応条件を、変更後にサイトが動かなくなった段階なら直前の変更とエラーの記録を、先に確認してください。

準備中なら環境と対応条件の確認へ

PHPは、サーバー上でWordPressやテーマ、プラグインの処理を動かす実行環境です。WordPress本体の更新とは別の作業なので、管理画面の更新ボタンを押すだけでPHPも更新されるわけではありません。

「PHPの更新が必要」「更新を推奨」という通知が出たら、表示元と全文を保存し、現在のPHPと求められている条件を照合します。通知に版の指定があっても、テーマやプラグインを含めた対応確認が必要です。

PHP開発元のサポートが終了すると、その版への脆弱性修正は提供されなくなります。画面が正常に見えることと、修正を受けられることは別なので、終了済み・終了間近の版なら移行準備を優先する段階です。

エラーが出ているなら変更の記録と相談へ

PHPを変えた直後から白い画面や「重大なエラー」、ログイン不可になった場合は、変更日時、対象ドメイン、変更前後のPHPを先に控えてください。画面のエラー文と、サーバー管理画面で見られる同時刻のログも保存します。

WordPressに入れなくても、サーバー会社の管理画面や問い合わせ窓口は確認先です。元のPHPを選べるか、変更が別サイトへ及ぶかを確かめ、後述の条件に沿って一時切戻しを検討しましょう。

PHPを更新できる条件を揃える

更新先は、数字の大きさだけでなく、サイトの構成と提供条件が重なる版から選びます。「WordPressの推奨」「テーマの対応」「サーバーで選べる版」「PHP開発元のサポート」は、それぞれ別の確認事項です。

現在の版と本体・テーマ・プラグインの対応を照合する

管理画面の「ツール」→「サイトヘルス」→「情報」で「サーバー」を開き、PHPバージョンを確認してください。対象ドメインのサーバー設定と突き合わせ、WordPress本体、使用中の親・子テーマ、プラグインの版も記録します。

配布元の動作要件や更新履歴では、現在使っている製品の版と変更先PHPの組み合わせを確かめておきましょう。「PHP 7.4以上が必要」という最低要件だけでは、それより新しいすべてのPHPでの動作確認を意味しません。

本体や製品に更新が必要なら、バックアップを用意し、現在のPHPで動く対応版へ一つずつ更新します。PHP変更と同時にまとめて更新しないことが、異常の出た変更を追える条件です。

古いPHPでは更新先の本体や製品を動かせない場合、互いの対応範囲が重なる版を使って段階的に移す必要があります。この場合に必要なのは、保守担当と中間の版・変更順を決め、検証環境で一連の移行を確かめることです。

長く更新されていない製品や独自コードの対応が分からない場合は、製品名・版・変更予定のPHPを制作者へ伝えてください。対応版への更新や代替機能の準備を済ませ、検証環境で主要機能が動くことを確かめてから本番へ進みます。

ホストの提供版とPHPサポート期限を確認する

2026年10月16日時点で、WordPress公式の要件ページが推奨するPHPは8.3以上です。これは、個々のテーマやプラグインまで互換性を保証する条件ではありません。

PHP公式のサポート区分と、セキュリティ修正を受けられる期限を次の表にまとめます。通常サポートではバグとセキュリティ問題の修正を受けられ、その後は重大なセキュリティ問題への修正のみとなる仕組みです。

候補が複数あるなら、互換性確認と機能テストを通過した通常サポート中の版を第一候補にしましょう。対応事情で8.3を使う場合も、期限までに次の版へ移れるよう、未対応製品と再確認日を記録します。

なお、8.4の通常サポートは2026年12月31日までで、その後もセキュリティ修正は2028年末まで続く予定です。区分は日付で変わるため、実際に変更する前にPHP公式のサポート表を確認してください。

サーバーの選択欄に古いPHPが残っていても、PHP開発元のサポートが続いている証拠にはなりません。逆に、公式に新しい版が出ても契約中の環境で選べるとは限らないため、ホストの公式案内と実際の選択欄を照合してください。

例えばエックスサーバーは「Xアクセラレータ Ver.2」利用時に8.5.x・8.4.x・8.3.xなどを提供し、さくらのレンタルサーバはプランによる実行モードの違いも説明しています。契約したサービス・プランに合う案内でなければ、自分の環境での提供条件は読み取れません。

保存と検証を用意して更新する

変更前には、バックアップの有無だけでなく、何を、どの時点へ、誰が戻せるかまで確認してください。検証と変更後の点検を一続きに用意し、PHPを一度切り替えたまま確認を後回しにしないようにします。

ファイル・DB・設定と戻す手段を用意する

WordPressの復元に必要なのは、サイトのファイルとデータベースの両方です。テーマ、プラグイン、画像、設定ファイルを含むファイル群と、投稿・各種データを持つDBを、対応する時点の組として保存してください。

本体や製品の更新を先に済ませた場合は、PHPを変更する直前にも、正常に動く構成のファイルとDBを組で保存します。PHPの実行版やサーバー側の設定は別に記録し、切戻し条件も確認してください。復旧方法を確認する際のチェック項目は次のとおりです。

• 対象サイトとDB名、保存日時、保存されたファイル・DBの範囲
• 保存先へアクセスできる権限、保存期間、取り出せるバックアップ
• 復元の操作場所、担当者、所要時間の目安と料金の有無
• 変更前のPHPを選び直せる条件と、その設定が及ぶサイト
• 復元時に上書きされる投稿・注文・会員情報などの範囲

復元可能性は、手順書があるだけでなく、バックアップを取り出せることや検証環境での復元確認まで含めて確かめてください。戻す方法が分からない場合は、本番変更の前にサーバー会社や保守担当へ確認します。

検証環境は、本番と同じ本体・テーマ・プラグイン・独自コードを使い、必要なPHP拡張や設定値も照合して、変更先PHPで主要機能を試す場所です。決済やメールの外部送信はテスト設定にし、検証データを本番へ送らないようにしてください。

本番では、作業と復旧に使える時間、対応する担当者、問題時の連絡先を確保します。フォームや購入機能を検証できないまま変更すると、利用者が使えなくなっていても気づけません。

ホスト公式手順で変更し、主要機能を確認する

本番を変更する前に、主要機能を確認できる担当と作業時間を決め、利用中のサーバー会社が指定する管理画面や窓口で操作しましょう。画面名を別のホストへ読み替えるのではなく、契約中の環境の公式手順を使います。

エックスサーバーの新サーバーパネルなら、「PHP Ver.切替」で対象ドメインのペンアイコンを開き、変更先を選んで「設定する」が公式の流れです。旧パネルは確定ボタンが「変更」なので、表示中のパネルに合うエックスサーバー公式の切替手順を確認してください。

さくらのレンタルサーバでは「スクリプト設定」内の「言語バージョン設定」から選択し、「保存する」で確定します。実行モードや対象プランの条件は、さくら公式のPHP変更手順で確認が必要です。

1. 変更内容を記録して確定する

   対象サイト、変更前後の版、日時、影響する範囲を控え、PHPだけを変更してください。反映待ちの間に別の版への切替や製品更新を重ねないようにします。

2. 反映したPHPを確認する

   公式案内の反映条件に従い、サイトヘルスとサーバー側の値を確認してください。値が一致しなければ、対象ドメインや反映状況を先に調べましょう。

3. 変更前と同じ操作で機能を試す

   主要ページの表示、ログイン、投稿編集・保存、画像のアップロード、検索、フォーム送信と受信を確認します。購入・会員機能があるサイトでは、注文や会員の主要な操作も点検対象です。

表示はログアウト状態でも確認し、PCとスマートフォンで崩れがないかを見てください。フォームは入力欄が出るだけで終えず、テスト送信の完了と通知先での受信まで確かめます。

切替機能の提供と、製品の修正・検証・復旧代行は別の費用項目です。依頼する場合は作業範囲と見積もりを確認し、「PHP更新はすべて無料」とひとまとめにしないでください。

PHP更新後のエラーで確認すること

変更直後の異常は、発生時点とログを直前の変更に結び付けて調べます。PHPを戻すか、データを戻すかでは影響が違うため、表示が直らないという理由だけでバックアップ復元へ進めるのは早計です。

重大なエラー・ログイン不可は発生時点とログを記録する

まず、サイト全体が開けないのか、フォームなど特定の機能だけが止まるのかを確かめてください。相談先へ渡す情報を、次の項目に揃えます。

• 発生日時と直前に行った操作、PHP以外に更新したもの
• 対象URL、再現する操作、変更前後のPHPと各製品の版
• 画面の正確なエラー文、同時刻のエラーログ
• 一時切戻しをした場合の版・日時・改善した機能と残る症状

ログ内のファイル名や行番号は、テーマ・プラグイン・独自コードのどこを調べるかの手掛かりです。PHP変更直後という時系列だけで原因を断定せず、サーバー会社には反映状況やログの確認を、該当製品の提供元には対応状況の確認を依頼してください。

ログが見つからない場合は、保存場所と取得方法をサーバー会社へ問い合わせます。WordPressのデバッグ記録が必要なら、保守担当と検証環境で再現を試し、画面へのエラー表示を抑える設定とログの保護も確認してください。

ログには内部パスや利用者情報が含まれる場合があるため、公開記事や掲示板へ全文を貼り付けるのは避けます。問い合わせ先が指定する非公開の方法で、該当時刻の必要部分を共有してください。

一時切戻しとデータ復元を分け、原因修正後に再更新する

PHP変更直後から主要機能が止まり、元の版をホストが提供していて、切替範囲と影響を確認できる場合は、一時的に変更前のPHPへ戻して動作を確かめる方法があります。元の版を選べない場合や、他サイトも含む設定で影響を判断できない場合は、変更を重ねずサーバー会社へ相談してください。

PHP設定の切戻しは実行環境を戻す操作であり、投稿や注文データを過去へ戻す操作ではありません。戻して表示が直れば、変更先PHPとの互換性を調べる材料になるので、復旧した機能も記録してください。

ログが特定製品を指しているなら、検証環境でその対応版への更新や修正を一つずつ試しましょう。個別停止が必要な場合も、その機能への影響を確かめてから行い、変更と結果を記録します。

切戻し後に動いたことは、古いPHPを使い続けてよい理由にはなりません。対応版への更新、独自コードの修正、代替機能の準備を終え、変更先PHPで同じ主要機能を再テストしてください。

再更新の日程と担当を決め、確認を通過した構成を本番へ反映します。PHPを戻しても症状が変わらず、変更との関係が分からない場合は、記録を保守担当へ渡して調査を引き継ぐ段階です。

まとめ：変更条件と確認結果を残す

WordPressのPHP更新は、対応する版とホストの提供条件を合わせ、ファイル・DBの保存、検証、変更後の機能テストを用意して進めてください。まず現在のPHPと各製品の版を控え、対応の未確認項目と戻す手段を確認します。

変更直後の異常には、時刻・変更内容・ログの記録と、条件を確認した一時切戻しで対応するのが基本です。データ復元は上書きの範囲を別に判断し、原因を直した構成で再更新へ進んでください。

作業後は変更前後の版、テスト結果、残った問題、次の確認日と担当を一つの記録に残します。復旧できた時点で記録を閉じず、サポート中のPHPへ移行した状態を確認するところまで進めてください。