WordPress・PHPバージョンアップでサイトが壊れたときの対処

2026.08.282026.10.03

最終確認：2026年10月3日

WordPressやPHPの更新後にサイトが真っ白になった場合は、追加の更新やファイル削除を続けず、症状と直前の変更を記録します。表示の問題だけならデータが残っていることもありますが、画面だけで「記事は必ず残っている」とは判断できません。

最初に現状を保全し、更新前のバックアップ、管理画面、復旧モード、サーバーのログを確認します。原因の切り分けと、サイトを再び使える状態に戻す作業を分けて進めてください。

最初に記録することと、作業を止める条件

スクロールできます

確認項目	記録する内容
発生した時刻と症状	真っ白、重大なエラー、500、レイアウト崩れ、管理画面だけなど。対象URLと画面を保存
直前の変更	本体、プラグイン、テーマ、PHP、独自コード、サーバー設定。変更前後の版と操作担当
バックアップ	更新前と現在のファイル・DB、取得時刻、保管先、復元の手順
更新後に増えた情報	注文、予約、問い合わせ、記事・会員など。更新前へ戻す際に失われる差分
復旧の権限・担当	サーバー、WordPress、保守担当の権限と、利用可能なサポート

バックアップを取ることや復元の対象が分からない場合、注文・会員等のデータに影響する場合、改ざんの疑いがある場合は、自己判断で削除やDBの復元を進めません。サーバー・保守担当へ、ここまでの記録を渡します。ログに含まれる個人情報、パスワード、復旧リンク等は公開の相談先へ貼らないでください。

症状から、調べる場所を絞る

スクロールできます

症状	原因の候補	最初の確認
真っ白・重大なエラー・500	PHPのエラー、互換性、メモリー、更新ファイルの不備など	管理画面、復旧メール、サーバーのエラーログと発生時刻
本文は出るが見た目が崩れる	CSS・JS・キャッシュ、テーマ変更、独自コードなど	別のブラウザー、読み込みエラー、変更したテーマ・ファイル
DB接続エラー・記事が見えない	接続設定、DBの状態、参照先、権限など	接続先と直前の変更、DBとバックアップを担当者が確認
メンテナンス表示が残る	更新中、または更新の中断	更新が続いていないか、サーバーの状態と更新記録
フォームや予約等だけ動かない	機能の依存関係、認証、外部接続、JS等	該当機能の受付・保存・通知と、直前の変更

キャッシュを消して見た目が戻っても、フォームや予約まで直ったとは限りません。逆に、画面が白いことだけでプラグインが原因と断定せず、エラーと変更履歴を照合します。

管理画面・復旧モードから確認する

管理画面へ入れるかを確認します。入れる場合は、直前に変えたもの、更新結果、該当機能を記録します。
管理者宛ての「技術的な問題」のメールを確認します。WordPressの復旧モードで入れる場合は、示されたプラグインやテーマを調べます。
必要な機能の停止による影響を確認したうえで、原因候補を一つずつ切り分けます。復旧モードでの表示と、通常の訪問者の表示は別に確認します。
原因候補の修正版、対応する構成、バックアップを使う復元などを検討し、変更前の状態と戻す手順を保存してから作業します。

WordPressの復旧モードは、致命的なエラーの一部で管理画面へのアクセスを助ける機能です。すべての障害で動くものではなく、通知メールが届かない場合もあります。復旧モードのリンクを第三者へ公開しないでください。

管理画面に入れない場合のファイル操作

ファイル操作は、権限を持つ担当者がSFTPやサーバーの管理機能などで行います。最初に現在のファイル・DBと設定を保管し、対象のインストール先、元の名前、有効なプラグイン・テーマを記録します。

プラグインの切り分け

特定のプラグインが疑われる場合は、その候補を絞って調べます。WordPressの管理画面へ入れないときの公式手順には、pluginsフォルダー名を変更する方法もあります。

/wp-content/plugins/  →  /wp-content/plugins-off/

この既存の例は、全プラグインを通常の場所から読み込めなくする操作です。フォーム、決済、ログイン制御等も停止し得るため、最初に無条件で実行する手順ではありません。通常のプラグイン以外の独自実装やサーバー側の問題までは止まりません。

フォルダーを戻すだけで有効状態や機能が元どおりになるとは限りません。管理画面で状態を確認し、依存関係を踏まえて必要なものを段階的に戻します。削除は無効化とは別の処理です。「設定は絶対に消えない」と考えて、削除や再インストールへ進まないでください。

テーマと更新ファイルの確認

テーマのフォルダー名を変えれば必ず標準テーマへ切り替わる、とは限りません。利用できる別のテーマ、親子テーマ、独自機能、切り替え後の設定への影響を確認し、担当者が検証環境で調べます。

本体の更新が中断した場合は、公式の更新手順を確認します。更新中なのにメンテナンスファイルを消したり、wp-contentやwp-config.phpをまとめて上書きしたりしないようにしてください。

エラーは公開画面に出さず、保護したログで調べる

まずサーバーの管理画面で閲覧できるエラーログを確認します。WordPressのデバッグ設定は、公式の説明に従い、検証環境での利用を基本にします。

次は担当者向けの記入例です。ログの保存先は実在する非公開の場所へ置き換え、書き込み権限とアクセス制限を確認します。既存の同じ定数を重複して追加せず、設定ファイルのバックアップを取ってから修正してください。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/path/outside-public/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_LOGをtrueにすると標準ではwp-content/debug.logへ記録します。WP_DEBUG_DISPLAYをfalseにしても、ログファイルをURLから読める状態なら情報は保護できません。非公開の保存先やサーバー側の制限を確認してください。true・falseを引用符で囲んだ文字列にしないことも注意点です。

調査後はWP_DEBUGとWP_DEBUG_LOGを停止し、公開のエラー表示を有効にしない状態へ戻します。調査用ログは、必要な証跡を権限を限定して保存し、公開領域や不要な場所に残さないようにします。

PHPを戻す場合と、バックアップへ戻す場合

スクロールできます

復旧方法	確認する条件	復旧後に残る作業
PHPの切り戻し	サーバーが旧版を提供するか、更新前の版と構成、セキュリティ面	原因の修正、対応版での再検証、終了期限を決める
プラグイン・テーマの修正等	開発元の対応、依存機能、変更箇所、データの互換性	表示・保存・受付・通知の確認、必要な代替への移行
更新前のバックアップの復元	ファイルとDBの対応、復元先、更新後の注文・予約等の差分	差分の保全・反映、再発原因の調査、再更新の計画

PHPを戻せるかは契約先の提供条件によります。旧版へ戻せない場合もあるため、復旧策を切り戻しだけに依存させません。古い版で表示が戻っても、恒久対応が済んだわけではありません。PHPの公式サポート期間と、WordPress・テーマ・プラグインの対応状況を確認します。

更新前のDBへ戻すと、更新後に追加された情報を失うことがあります。先に差分を保全し、必要な情報をどう反映するかを決めてください。データが見えない場合も、DBを削除してWordPressを入れ直す前に、参照先とデータの状態を確認します。

次回の更新を安全に進める確認表

スクロールできます

工程	確認すること
更新前	変更内容・対応版・独自コード・依存関係を確認。ファイルとDBを保管し、復元方法を確認
検証環境	本番に近い構成で表示と機能を確認。公開検索、実メール送信、決済、外部連携等を制御
本番の計画	担当、更新の順序、必要な受付停止、監視、失敗時の戻し方を決める
更新と確認	検証した順序で実施。各段階で結果を記録し、原因を追える状態にする
復旧・公開確認	主要URL、管理画面、受付・保存・通知、定期処理・外部連携を確認
継続運用	セキュリティ修正の確認、通常更新の担当と日程、開発終了した機能の代替を管理