クライアントから「サイトが真っ白で何も表示されません」と連絡が入ると、制作側はまず落ち着いて原因を切り分ける必要があります。
「更新した直後に真っ白になった。戻し方を間違えるのが怖くて、触れない」
「管理画面にも入れず、サーバー側を触る自信がない」
WordPressの白画面は、PHPの致命的エラーが画面に表示されないことで起きる場合が代表的です。原因としては、プラグイン、テーマ、PHPのメモリ不足、PHPバージョンの不一致がよく挙がります。ただし、見た目だけで原因は決められません。HTTPステータスやサーバーのログを確認し、影響の小さい順に切り分ければ、復旧できるケースは少なくありません。
この記事でわかること
- 白画面の代表的な原因と、WordPressの外側で起きるケース
- 作業に入る前に確認しておきたいこと
- FTPやファイルマネージャーでできる切り分け手順と注意点
- 復旧後の確認と、再発を防ぐ運用
- 自力対応を切り上げて任せるべき判断基準
1. 「真っ白」の正体：エラーが出ていないだけで、裏では処理が止まっている
WordPressはPHPで動いています。PHPの処理が途中で致命的エラー（Fatal error）によって止まると、HTMLが最後まで出力されません。本番環境ではエラーメッセージを画面に出さない設定にしているのが普通なので、その結果として画面が真っ白に見えます。WordPress公式のデバッグ解説でも、エラーに到達した際に白い画面になるPHPの挙動に触れられています。
WordPress 5.2以降は、条件によってエラーメッセージが表示され、管理者へリカバリーモードの案内メールが届きます。ただし、すべてのエラーでメールが送られるわけではありません。メールが届かなくても、原因調査をやめる理由にはなりません。
まずは、白画面の代表的な原因と、最初に確認することを整理します。
| 疑う箇所 | 起きやすい場面 | 最初に確認すること |
|---|---|---|
| プラグイン | 更新・新規導入の直後、他のプラグインとの競合 | エラーログで該当プラグインを確認し、そのフォルダだけを切り分ける |
| テーマ | functions.phpの編集直後、テーマ更新の直後 | エラーログで該当ファイルを確認し、標準テーマでの表示を試す |
| PHPのメモリ不足 | 画像処理や大量データの処理、重いプラグインの実行時 | エラーログの「Allowed memory size … exhausted」を探す |
| PHPバージョンの不一致 | サーバー側のPHPを更新した直後、古いプラグインやテーマの利用 | 直前のPHPバージョン変更の有無を確認する |
| コアファイルの破損 | WordPress更新の中断、ファイルの誤った上書き | 同じバージョンの公式ファイルと照合する（SSHが使えるならwp core verify-checksumsも利用できる） |
| WordPressの外側 | ディスク容量の枯渇、データベースの不具合、CDNのキャッシュ、不正な改ざん | HTTPステータスとサーバーのエラーログを確認する。改ざんが疑われる場合は作業前に現状を保全する |
「原因の特定や復旧まで、まとめてお願いしたい」という場合は、他社が制作したサイトの修正・改修もお受けしています。白画面の調査についても、まずは状況をお知らせください。
2. 触る前に確認すること：範囲・直前の変更・バックアップ・改ざんの兆候
白くなっている範囲とHTTPステータスを確認する
トップページだけか、全ページか、管理画面（/wp-admin/）だけかを確認します。あわせて、ブラウザの開発者ツールでHTTPステータスを確認します。500はPHPの致命的エラーやサーバー設定の不備、503は一時的なリソース不足やPHP・サーバー側の停止、200で白い場合は、ページのソースを表示してHTMLが出力されているかを見ます。ただし、ステータスだけで原因は決められません。ログと組み合わせて判断してください。確認時はシークレットウィンドウを使い、キャッシュ系プラグインやCDNのキャッシュも消してください。
直前の変更を確認する
直前の変更は、原因を絞る有力な手がかりです。クライアントや担当者に、次の点を確認してください。
- WordPress本体・プラグイン・テーマの更新をしたか
- プラグインを追加・削除したか
- functions.phpなどを編集したか
- サーバーのPHPバージョンを変更した、またはサーバーを移転したか
管理者メールのリカバリーモードを確認する
致命的エラーが検知されると、サイトの管理者メールアドレス宛に「リカバリーモード」へ入るためのリンクが送られることがあります。このリンクから入ると、原因と判定されたプラグインやテーマがそのセッション内だけ一時停止され、管理画面に入れる場合があります。サイト全体を止める操作ではありません。
納品後の管理者メールアドレスはクライアント担当者のものになっていることが多く、制作側には届きません。迷惑メールフォルダも含めて、クライアントに受信箱の確認を依頼しましょう。見当たらなければ、次の手順に進みます。
改ざんの兆候がないか確認する
身に覚えのないファイル変更や管理者アカウント、ホスティング会社からのマルウェア通知があれば、通常の不具合とは別の対応が必要です。プラグインの停止やファイルの書き換えの前に、ログとファイルの現状を保全し、サーバー管理者やセキュリティの担当者へ相談してください。
バックアップを取り、クライアントの了承を得る
現状のファイル一式とデータベースを、そのままの状態で取得しておきます。データベースはFTPでは取れないため、サーバーの管理パネルやphpMyAdminから書き出してください。
まず「原因を調査中です」と一報を入れます。本番のファイル操作は、フォームや予約などの機能に影響する場合があります。作業内容と時間帯について了承を得てから進め、復旧の見込み時間は原因が分かってから伝えるのが安全です。調査が長引く場合は、503を返すメンテナンス画面の掲出も検討してください。
3. 原因を切り分ける手順（FTP・ファイルマネージャーでできる）
ここからは、管理画面に入れない前提の手順です。進める順番は「サーバーのログ → WordPressのデバッグログ → プラグイン → テーマ → メモリ → PHPバージョン」です。変更は1回に1か所だけにし、表示確認と記録をしながら進めます。
ステップ1：まずログで原因を見る
最初に、ホスティングの管理画面でPHPやWebサーバーのエラーログを確認します。手がかりが得られない場合に、WordPressのデバッグログを使います。wp-config.phpに次の設定を追記します。場所は「That’s all, stop editing!」のコメント行より前です。すでにWP_DEBUGなどが定義されている場合は、既存の値を書き換えます。Windowsのメモ帳は使わず、UTF-8（BOMなし）で保存できるエディタで編集してください。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/path/to/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOGにtrueを指定すると、ログはwp-content/debug.logに出力されます。この場所は外部から閲覧できてしまう環境があり、ファイルのパスなどが含まれるおそれがあります。公式ハンドブックでは、保存先をファイルパスで指定できると説明されています。上の例のように、公開ディレクトリの外を指定しましょう。/path/to/logs/...は例です。そのまま貼らず、実在し、PHPから書き込める絶対パスに置き換えてください。分からなければ、ホスティングのエラーログを優先します。
ログでは「Fatal error」の行を探します。パスが/wp-content/plugins/○○/ならそのプラグイン、/themes/○○/ならテーマが候補です。「Allowed memory size … exhausted」ならメモリ不足を疑います。
公式ハンドブックでは、WP_DEBUGは本番サイトでの利用を推奨せず、ローカルやステージング向けとされています。本番で使った場合は、調査後すぐに設定を元に戻してください。ログは必要な分を安全な場所へ退避してから、公開領域に残ったものを削除します。
ステップ2：プラグインを切り分ける
ログで特定のプラグインが分かっている場合は、そのフォルダだけをリネームするのが、影響の小さい方法です。分からない場合は、wp-content/pluginsフォルダの名前を「plugins_off」などに変更し、通常のプラグインをまとめて読み込ませない状態にします。作業前に、有効だったプラグインの一覧をデータベースのactive_plugins（テーブル名の接頭辞はサイトごとに異なります）や、WP-CLIが使えればwp plugin list --status=activeで控えてください。
WordPress公式のトラブルシューティングでは、そのあと管理画面のプラグイン画面（/wp-admin/plugins.php）へアクセスし、プラグインが見つからない状態をWordPressに認識させてから、フォルダ名を戻す流れが案内されています。これでプラグインは無効のまま残り、設定は保持されますが、有効だった状態は元に戻りません。
- サイトが表示された場合：通常プラグインのいずれか、またはプラグイン同士やテーマとの組み合わせが原因の可能性が高くなります。控えた一覧を見ながら1つずつ有効にして、再現するか確認します。
- 注意点：mu-plugins（Must-Useプラグイン）は、この方法では止まりません。また、止めている間は、お問い合わせフォームや予約、決済などの機能も止まります。時間帯を選び、クライアントの了承を得てから進めてください。
SSHとWP-CLIが使える環境では、wp plugin deactivate --allで一括無効化できます。プラグインのエラーでWP-CLI自体が起動しない場合は、--skip-pluginsで読み込みを避けられることがあります。ただし、mu-pluginsは読み込まれます。
ステップ3：テーマを標準テーマで確認する
プラグインを止めても直らない場合は、直前に編集したfunctions.phpをバックアップに戻せないかを先に確認します。それでも切り分けたい場合は、有効テーマのフォルダ名を変更します。標準テーマがインストールされていれば、WordPressが自動で切り替えます。このとき、有効テーマの設定がデータベース上で書き換わるため、フォルダ名を戻しても有効テーマは元に戻りません。元のテーマ名を控え、SSHが使えるならwp theme activateで切り替える方法もあります。
サイトが表示されたら、原因はテーマ側にある可能性が高いです。直近で編集したfunctions.phpや、子テーマと親テーマのバージョン不整合を確認します。ただし、標準テーマで表示されても、元のデザインや機能が復旧したわけではありません。切り替わると、ウィジェットやメニューの割り当てが変わる場合があります。戻したあとは、管理画面で有効なテーマと設定を確認してください。
ステップ4：メモリ上限を引き上げる
ログにメモリ不足の記録があれば、wp-config.phpに次の1行を追記します。
define( 'WP_MEMORY_LIMIT', '256M' );位置はステップ1と同じです。WP_MEMORY_LIMITは主にフロント側の上限で、管理画面側ならWP_MAX_MEMORY_LIMITも確認します。256Mは一例です。ホスティング側の設定によってはこの1行で上限を上げられないため、その場合はホスティングの設定を確認します。これは一時復旧の手段で、増やすだけでは根本原因が隠れる可能性があります。消費している処理も確認してください。
ステップ5：PHPバージョンを確認する
サーバー側のPHPを更新した直後に白くなった場合は、ホスティングの管理画面で以前のバージョンに戻し、表示を確認する方法があります。ただし、旧バージョンがサポート終了済みの場合や、環境を他サイトと共有している場合は、影響を確認してから実施してください。
ここまでで直らず、コア破損が疑われる場合は、同じバージョンの公式ファイルで、wp-adminとwp-includes、ルート直下のファイルを上書きする方法があります（wp-contentとwp-config.phpは除く）。必ずバックアップを取ってから行ってください。
「ログは取れたけれど、原因の見極めや修正に自信がない」という場合は、お気軽にご相談ください。
4. 復旧したあとにやること、再発を防ぐ運用
復旧直後にやること
- デバッグ設定を戻す：WP_DEBUGとWP_DEBUG_LOGを元の設定に戻し、ログは退避したうえで公開領域から削除します。
- 名前を変えたフォルダを確認する：フォルダ名と、有効なプラグイン・テーマの状態が意図通りかを確認します。
- 表示と業務機能を確認する：トップ、下層ページ、管理画面、スマートフォン表示に加え、フォーム送信と通知メールを確認します。予約・会員・ECのサイトでは、予約・注文・ログイン・決済も確認し、決済はテストモードで試します。
再発を防ぐ運用
- 更新の前にバックアップを取る：ファイルとデータベースの両方を、更新頻度に合わせて取得します。
- 更新は検証環境で先に確認する：ステージングで確認してから本番へ反映し、アクセスの少ない時間帯に1つずつ更新します。
- PHPバージョンを上げる前に互換性を確認する：使用中のプラグインとテーマが動くか先に確認します。
- 使っていないプラグインとテーマを減らす：未使用のものは削除します。ただし標準テーマは1つ残します。
- リカバリーモードのメール宛先を決めておく：wp-config.phpに次の設定を同じ位置で入れると、通知メールの宛先を制作側のアドレスに変更できます。指定できるのは1つのアドレスだけで、管理者メールには届かなくなるため、複数人で受けるなら共有アドレスを使います。
define( 'RECOVERY_MODE_EMAIL', '[email protected]' );5. 自力で対応するか、任せるか：切り上げの判断基準
次のいずれかに当てはまる場合は、自力対応を続けるか、専門の制作会社やサーバー管理者に相談するかを、早めに判断することをおすすめします。
- ログに手がかりがない：ログが空、またはエラーの内容から原因が絞れない
- サーバー設定やデータベースが絡んでいそう：.htaccessやPHP設定、データベース接続など、WordPressの外側が疑わしい
- 改ざんの兆候がある：身に覚えのない変更や不審なアカウントがある
- 本番サーバーの権限が自分にない：FTPやサーバー管理画面に入れず、手を出せない
- 止まっている時間の損失が大きい：ECサイトや予約サイトなど、1日止まるだけでクライアントの機会損失が大きい
コーディングコネクションでは、他社が制作したWordPressサイトの修正・改修もお受けしています。納品後の運用を任せたい制作会社様向けに、WordPress保守プランもご用意しています。
- 料金：月額30,000円〜（税別）、初期費用0円、最低契約期間3ヶ月
- 標準の内容：バックアップと復旧、WordPress本体・プラグイン・PHPの更新と不具合修正、月次レポートなど
- 提供の形：貴社名義でのご提供もご相談いただけます
料金はサイトの規模や構成によって変わります。まずは無料のサイト診断で、対応可否とお見積りをご報告します。月額の標準内容とは別に、緊急時の対応範囲・費用はご相談のうえでご案内します。まずはお問い合わせください。
「クライアントのサイトの保守体制を、そろそろ整えたい」という場合は、WordPress専用の保守プランもございますので、まずはお気軽にお問い合わせください。
6. よくある質問
Q. 管理画面には入れるのに、公開側のページだけ真っ白です。
公開側だけが白い場合は、テーマやフロント側のプラグイン、テンプレートを疑います。管理画面だけが白い場合は、管理画面で読み込まれるプラグインやメモリの上限を疑います。いずれも、ログで該当ファイルを確認するのが確実です。
Q. デバッグログが作られない、または空のままです。
追記位置が「That’s all, stop editing!」より後ろになっていないか、同じ定数が重複していないか、保存先に書き込み権限があるかを確認してください。WordPressの外側のエラーは、サーバー側のログに出ることもあります。
Q. 直ったのに、また白画面になりました。
メモリを増やしただけなど、対症療法だった可能性があります。更新は1つずつ行い、どの変更で再発したかを特定してください。
この記事のまとめ
- 白画面の原因はプラグイン・テーマ・メモリ・PHPバージョンが代表的。ただし見た目だけでは決められないため、HTTPステータスとログを先に確認する
- 作業の前に、範囲・直前の変更・改ざんの確認、バックアップ、クライアントの了承を済ませる
- 切り分けは影響の小さい順に、1回に1か所ずつ変更する。ログの保存先やプラグイン停止の影響には注意する
- 復旧後は、業務機能まで確認し、デバッグ設定を戻す
- ログに手がかりがない、サーバー設定が絡む、改ざんが疑われる場合は、早めに相談する判断も大切
サイトの切り分けや保守の体制づくりで、お困りごとやご依頼などがありましたら、お気軽にご相談ください。
コーディングコネクションのサービス詳細はこちら
