WordPressを開いたら、文字も画像も表示されず、真っ白な画面だけになっている。管理画面にも入れない。この状態でも、投稿や画像がすべて消えたとは限りません。多くの場合は、プラグイン、テーマ、PHP、更新失敗などにより、ページを生成する処理が途中で止まっています。
最初に行うのは、ファイルの削除や初期化ではありません。症状が出る範囲、発生時刻、直前の変更、管理画面に入れるか、管理者メールへ復旧案内が届いているかを確認します。作業前のバックアップを確保し、一度に一つだけ変更することが重要です。
この記事では、WordPressが真っ白になったときの確認順を、管理画面に入れる場合と入れない場合に分けて解説します。プラグインやテーマの切り分け、エラーログ、バックアップ復元、専門家へ依頼する判断まで、安全性の高い順に確認できます。
WordPressが真っ白になったら最初に確認する7項目
慌てて複数の設定を変えると、原因と戻し方が分からなくなります。まず、次の7項目を順番に確認してください。
- 公開画面だけでなく、下層ページと管理画面も真っ白か確認する
- 画面、エラー文、対象URL、発生時刻を記録する
- 管理者メールと迷惑メールにリカバリーモードの案内がないか確認する
- 直前に更新・有効化・編集したプラグイン、テーマ、PHP設定を確認する
- 変更前に現在のファイルとデータベースをバックアップする
- 決済、予約、問い合わせが止まっている場合は、技術調査と同時に業務影響へ対応する
- 一度に一つだけ変更し、結果と元へ戻す方法を記録する
管理画面に入れる場合は、リカバリーモード、サイトヘルス、直前に変更したプラグインやテーマの順に確認します。管理画面に入れない場合は、サーバーのエラーログとバックアップを確認し、必要に応じてファイルマネージャーやSFTPで原因候補を切り分けます。
バックアップがない、ファイル操作に慣れていない、決済や予約が止まっている、改ざんの疑いがある場合は、無理に作業を続けず、サーバー会社や保守担当者へ相談してください。
WordPressの真っ白画面とはどのような状態か
真っ白画面とは、ページを開いても本文やエラーメッセージが表示されず、白い画面だけが見える状態です。WordPress公式の「Common WordPress errors」では、PHPエラーやデータベースエラーが白い画面として現れることがあると案内されています。現在のWordPressでは、致命的なエラーを検知すると「このサイトで重大なエラーが発生しました」と表示し、サイト管理者のメールアドレスへ復旧案内を送る場合もあります。
真っ白に見えても、すべてのデータが消えたとは限りません。多くの場合、WordPressがページを生成する途中で処理を続けられなくなっています。投稿や画像がデータベースやサーバーに残っていても、PHPの実行が止まれば、ブラウザーへ完成したページを返せません。そのため、最初の目的は「削除されたデータを作り直すこと」ではなく、「どこで処理が止まったかを安全に切り分けること」です。
サイト全体が真っ白か一部だけかを確かめる
トップページだけでなく、下層ページ、投稿ページ、ログイン画面、管理画面を確認します。すべてのページが真っ白なら、サイト全体で読み込まれるプラグイン、テーマ、WordPress本体、PHP環境などが候補です。特定のページだけなら、そのページで使っているブロック、ショートコード、テンプレート、埋め込み機能、個別のデータが関係している可能性があります。
パソコンでは真っ白でもスマートフォンでは見える、ログイン中だけ症状が出る、特定のブラウザーだけで起きる場合は、キャッシュやブラウザー拡張機能の影響も考えます。別の端末やシークレットウィンドウで同じURLを開き、結果を記録してください。ただし、複数の環境で同じ白画面になるなら、端末側だけの問題と決めつけず、WordPress側やサーバー側の確認へ進みます。
白画面と接続エラーを混同しない
「データベース接続確立エラー」「500 Internal Server Error」「403 Forbidden」「このサイトにアクセスできません」など、画面に具体的な表示がある場合は、真っ白画面とは原因の範囲が異なります。表示された文言、HTTPステータス、サーバー会社からの障害情報を優先して確認します。見た目が白くても、ブラウザーのタイトルや開発者ツールにエラーが出ている場合があります。
500エラー、データベース接続エラー、404など、白画面以外の表示がある場合は、「WordPressでよくあるエラーと対処法」から症状に合う確認順を選んでください。
エラーの種類を正しく伝えられるだけで、サポートへ依頼したときの調査時間が短くなります。画面のスクリーンショット、対象URL、発生時刻、直前に行った作業、別端末での結果を残しておきましょう。認証情報や顧客情報が映り込む場合は、共有前に必ず隠します。
最初に行うべき安全確認
復旧を急ぐと、検索で見つけたコードをそのまま貼り付けたり、プラグインとテーマを一度に削除したりしがちです。しかし、変更を重ねるほど元の状態が分からなくなります。まず現状を保存し、影響範囲を確認し、直前の変更を一つずつ戻せる状態を作ります。
直前の変更と発生時刻を記録する
WordPress本体、テーマ、プラグインを更新したか、新しいプラグインを有効化したか、PHPのバージョンを変更したか、functions.phpやCSSを編集したかを確認します。自動更新が有効な場合は、自分で操作していなくても更新されていることがあります。WordPressやプラグインから届いた更新メール、サーバーの作業履歴、保守担当者との連絡も見直します。
「昨日までは正常だった」だけでなく、最後に正常表示を確認した時刻と、最初に異常を確認した時刻を分けて記録します。アクセス解析や監視通知があれば、発生時間をさらに絞れます。この時間帯が分かると、サーバーのPHPエラーログや更新履歴から原因を探しやすくなります。
変更前にバックアップを確保する
復旧作業の前に、現在のファイルとデータベースを保存できるなら保存します。壊れている状態のバックアップでも、後から設定や投稿データの一部を取り出す材料になります。既存の自動バックアップがある場合は、取得時刻、保存対象、保存先、復元方法を確認します。
バックアップの対象や保存先が分からない場合は、「WordPressのバックアップ方法とプラグインの選び方」で、ファイル・データベース・復元確認の考え方を先に確認してください。
バックアップがあるからといって、すぐ全体を復元する必要はありません。復元すると、バックアップ取得後の投稿、問い合わせ、注文、会員情報などが巻き戻る可能性があります。まず原因を切り分け、必要に応じてファイルだけ、データベースだけ、特定のプラグインだけを戻せるか検討します。
本番サイトへの影響を止める
予約、決済、問い合わせ、会員ログインなど事業に関わる機能が止まっている場合は、技術調査と並行して業務上の影響を確認します。別の連絡手段を案内できるか、広告やキャンペーンから障害ページへ流入し続けていないか、関係者へ状況共有が必要かを判断します。
原因が分からないまま本番環境で何度も操作するのは避けます。ステージング環境や複製環境があるなら、そこで原因を再現してから本番へ反映するほうが安全です。複製環境がない場合も、一度に一つだけ変更し、変更前後の結果を残します。
真っ白画面の主な原因
真っ白画面は「白い画面」という一つの症状ですが、原因は複数あります。起きやすい順番を断定するのではなく、直前の変更とログの内容から候補を狭めます。
プラグインの不具合や競合
プラグインの更新後、別のプラグインとの組み合わせ、WordPress本体やPHPとの互換性不足により、致命的なPHPエラーが起きることがあります。キャッシュ、セキュリティ、フォーム、最適化、ページビルダーなど、広い範囲で動くプラグインはサイト全体へ影響する場合があります。ただし、種類だけで原因を決めつけず、更新履歴とログを確認します。
管理画面に入れるなら、直前に更新または有効化したプラグインから一つずつ停止して確認します。すべてを同時に停止すると一時復旧は早くても、問い合わせフォームやセキュリティ機能まで止まり、原因も特定しにくくなります。緊急時に一括停止した場合は、必要な機能と確認順を決めて一つずつ戻します。
テーマや独自コードのエラー
テーマ更新、子テーマの編集、functions.phpへの追記、コードスニペットの変更でも真っ白画面が起きます。テーマ固有の関数が見つからない、PHPの文法に誤りがある、古い記述が新しいPHPで動かないなどが代表例です。直前にテーマファイルを編集したなら、編集箇所を最初の候補にします。
親テーマを直接編集している場合は、更新時に変更が上書きされるだけでなく、復旧時の比較も難しくなります。正常なバックアップや配布元の同一バージョンと比較し、独自変更を分離します。テーマを切り替える前には、ウィジェット、メニュー、サイトエディターの設定、テンプレートなどへの影響を確認してください。
PHPのバージョンやメモリの問題
サーバーのPHPを更新した直後に、古いテーマやプラグインが対応できずエラーになることがあります。反対に、WordPressやプラグインが要求する環境よりPHPが古い場合も問題になります。PHPバージョンだけを何度も上下させるのではなく、現在値、変更前の値、各製品の対応条件、エラーログを確認します。
処理に必要なメモリが上限を超えると、「Allowed memory size exhausted」といった記録が残ることがあります。上限を増やせば一時的に動く場合もありますが、負荷の大きい処理や不具合を隠すだけになることもあります。WordPress公式資料も、メモリ調整だけで根本原因が解決するとは限らない点を示しています。サーバー会社の仕様とログを確認し、必要なら専門家へ相談します。
更新失敗やファイル破損
WordPress本体、テーマ、プラグインの更新中に通信が切れたり、ディスク容量が不足したり、ファイル権限に問題があったりすると、必要なファイルがそろわないことがあります。更新直後から全体が真っ白になった場合は、更新対象、更新結果のメール、サーバーの空き容量、保守モードの残りを確認します。
WordPress本体のファイルを入れ直す場合も、wp-contentやwp-config.phpまで無計画に上書きしてはいけません。投稿データ、アップロード画像、テーマ、プラグイン、接続情報を失う危険があります。公式の手動更新手順を理解できない場合は、作業を止めて支援を求めるほうが安全です。
サーバーやデータベースの問題
サーバー障害、容量超過、ファイル権限、WAF、データベースの停止など、WordPressの管理画面だけでは直せない原因もあります。同じサーバー上の別サイトやメールも動かない、サーバー会社の管理画面にも入れない、障害情報が公開されている場合は、WordPressの設定変更より先にサーバー会社へ確認します。
データベース接続情報を不用意に書き換えると、元に戻せなくなるおそれがあります。wp-config.phpにはデータベース名や認証情報が含まれるため、内容をメールやチャットへ丸ごと貼り付けないでください。サポートへ共有するときも、必要なエラー文と環境情報だけに絞ります。
管理画面に入れる場合の対処手順
管理画面へ入れるなら、ファイルを直接操作する前に、WordPress上で確認できる情報を使います。トップページが真っ白でも、管理画面が動いていることがあります。
リカバリーモードの案内を確認する
WordPress 5.2以降には、致命的なエラーを検知したときに復旧を助ける仕組みがあります。管理者メールに案内が届いていないか、迷惑メールフォルダーも含めて確認します。案内には問題を起こした可能性のあるテーマやプラグインが示される場合があります。
メールが届かないからといって、案内URLを推測して作らないでください。管理者メールが古い、メール送信自体が止まっている、別の種類のエラーである可能性があります。サーバーのPHPエラーログやWordPressのデバッグログを確認できる体制へ切り替えます。
サイトヘルスと更新履歴を確認する
管理画面の「ツール」から「サイトヘルス」を開ける場合は、致命的な問題、推奨改善、PHPバージョン、アクティブなテーマやプラグインなどを確認します。サイトヘルスは原因を自動で修理する機能ではありませんが、環境情報を整理する手掛かりになります。
プラグインやテーマの更新画面、メール通知、サーバーの自動更新履歴も見ます。複数の更新が同時に行われていたなら、停止や戻しを無作為に行わず、更新時刻とエラーログの時刻を照合します。
直前の変更を一つずつ止める
直前に有効化したプラグインが明確なら、そのプラグインを停止して表示を確認します。変化がなければ元の状態を記録したうえで次の候補へ進みます。テーマを変更した直後なら、正常に動作していたテーマやWordPress標準テーマへ一時的に切り替えて確認します。
プラグイン停止やテーマ切り替えは、表示以外の機能へも影響します。フォーム送信、決済、会員機能、SEO設定、アクセス解析、セキュリティ対策などを確認し、復旧後に戻すべき設定を一覧にしておきます。
管理画面に入れない場合の復旧手順
管理画面まで真っ白な場合は、レンタルサーバーのファイルマネージャーやSFTP、FTPなどでWordPressのファイルへアクセスする方法があります。ただし、ファイル名の変更や設定ファイルの編集にはリスクがあります。操作方法が分からない、バックアップがない、事業サイトで停止時間の影響が大きい場合は、この段階でサーバー会社や保守担当者へ相談してください。
プラグインをファイル側から停止する
WordPress公式のトラブルシューティング資料では、管理画面へ入れないときに、FTPやサーバーのファイルマネージャーでwp-content/pluginsフォルダー名を一時的に変更し、すべてのプラグインを停止する方法が案内されています。表示が戻れば、プラグイン群が原因候補です。
表示を確認した後はフォルダー名を元へ戻します。ただし、プラグインは停止した状態になるため、一つずつ有効化して原因を切り分けます。フォーム、決済、セキュリティ、キャッシュなども止まる可能性があるため、バックアップと戻し方を用意してから行ってください。操作に慣れていない場合は、サーバー会社または保守担当者へ依頼します。
ただし、フォルダー名を変えただけで原因のプラグインが特定できたわけではありません。元のフォルダー名へ戻したうえで、個々のプラグインを一つずつ切り分けます。キャッシュやセキュリティ、必須プラグインの扱いは環境により異なるため、復旧後の動作確認を省かないでください。
テーマを切り分ける
プラグインを停止しても変化がなく、テーマが原因と考えられる場合は、アクティブテーマのフォルダー名を一時的に変更して切り分ける方法があります。WordPressが利用可能な標準テーマへ切り替えられる状態であることが前提です。標準テーマが存在しない、ブロックテーマや独自テーマの構造が分からない場合は、無理に進めません。
表示が戻ったら、テーマそのもの、子テーマ、独自コード、必要なプラグインとの組み合わせを別環境で確認します。いきなり同じテーマを再有効化すると、再び管理画面へ入れなくなる可能性があります。
エラーログを確認する
レンタルサーバーにはPHPエラーログを確認できる機能が用意されていることがあります。発生時刻と一致するFatal error、Parse error、Allowed memory size exhaustedなどの記録を探します。ファイルパスや行番号、プラグイン名、テーマ名が含まれていれば、原因候補を絞れます。
WordPressのWP_DEBUGとWP_DEBUG_LOGを使う方法もありますが、本番サイトで画面へエラーを表示すると内部情報が訪問者に見える危険があります。WordPress公式のデバッグ資料では、変更前にステージング環境または適切なバックアップを確保するよう注意し、デバッグ機能は主に開発環境で使うものと説明しています。設定に慣れていない場合は、サーバー会社や技術担当者へ依頼します。
キャッシュを必要な範囲だけ消す
復旧操作をしたのに白画面が残る場合、ブラウザー、キャッシュプラグイン、サーバー、CDNに古い応答が残っていることがあります。別ブラウザーやシークレットウィンドウで確認し、原因に近い層から必要な範囲だけ削除します。
全キャッシュ削除は一時的にサーバー負荷を上げることがあります。アクセスの多いサイトでは、削除の対象と時間帯を考えます。また、キャッシュを消して見えるようになっても、元のPHPエラーが解消したとは限りません。ログと再発の有無を確認します。
デバッグ設定を使うときの注意点
真っ白画面ではエラーが見えないため、デバッグを有効にしたくなります。しかし、設定方法を誤ると、ファイルパスやシステム情報を公開画面へ出す危険があります。
画面表示よりログ記録を優先する
WordPress公式は、デバッグ機能を主にローカル環境やステージング環境で使うものとして案内しています。作業前にステージング環境または適切なバックアップを確保してください。
本番サイトで調査が必要な場合は、エラーを訪問者へ表示せず、必要な期間だけログへ記録します。WP_DEBUG_DISPLAYを無効にし、調査後は追加した設定を元へ戻します。ログには内部パスや非公開情報が含まれる場合があるため、公開URLやチャットへ丸ごと貼り付けないでください。
ログにはサーバー内部のパス、URL、プラグイン名、場合によっては個人情報につながる内容が含まれます。公開リンクで共有せず、必要な行だけを安全な方法で担当者へ渡します。パスワード、APIキー、Cookie、データベース接続情報は送らないでください。
エラーの最後の行だけで判断しない
ログに表示された最後のファイルが、必ず根本原因とは限りません。別のプラグインが不正な値を渡し、最後にテーマ側でエラーになった可能性もあります。発生時刻、エラーの種類、呼び出し履歴、直前の更新を合わせて判断します。
同じエラー文を検索して見つけたコードを、そのまま本番環境へ貼るのは避けます。WordPress、PHP、テーマ、プラグインのバージョン、サーバー構成、独自変更が異なれば、同じ症状でも対処は変わります。
バックアップから復元する判断
原因が分からないまま長時間停止している場合、正常だった時点のバックアップへ戻すことは有力な選択肢です。ただし、復元は「過去の状態へ巻き戻す操作」です。正常表示を取り戻せても、バックアップ取得後のデータが失われる可能性があります。
復元前に対象と時刻を確認する
ファイルとデータベースの両方が含まれるか、どの日時の状態へ戻るか、復元後に失われるデータは何かを確認します。ブログ中心のサイトなら新しい投稿やコメント、事業サイトなら問い合わせや予約、ECサイトなら注文や会員情報への影響を調べます。
テーマやプラグインのファイルだけが原因なら、サイト全体を巻き戻す必要がない場合があります。逆に、データベース側の設定や更新処理が関係しているなら、ファイルだけ戻しても直りません。原因候補とバックアップの構成を照らし合わせます。
復元後の確認までを作業に含める
トップページが表示されたら完了ではありません。管理画面、投稿、固定ページ、画像、フォーム、メール、検索、ログイン、決済、会員機能、スマートフォン表示など、サイトの目的に応じた主要機能を確認します。キャッシュを再生成した後も正常か見ます。
復元により古い脆弱なバージョンへ戻った場合は、原因を解決しないまま更新を避け続けてはいけません。ステージング環境で互換性を検証し、代替プラグインやテーマ修正を含む再更新計画を作ります。
やってはいけない対処
真っ白画面では、画面から情報が得られないため、思いつく操作を次々に試したくなります。しかし、復旧しやすさと安全性を下げる操作があります。
- バックアップを取らずにファイルやデータベースを編集する
- 複数のプラグイン、テーマ、PHP設定を同時に変更する
- 原因を特定せずWordPress全体を初期化する
- wp-contentやwp-config.phpを含めて無計画に上書きする
- 公開画面へデバッグ情報を出したままにする
- 検索で見つけたコードを環境確認なしで実行する
- 認証情報やログ全体を公開の相談場所へ貼り付ける
操作ごとに、変更内容、開始時刻、結果、戻し方を記録します。一つの操作で変化がなければ、元へ戻してから次へ進むのが基本です。復旧作業そのものが新たな障害を作らないようにします。
専門家へ依頼したほうがよいケース
自分で直せるかどうかは、症状の難しさだけでは決まりません。停止による損失、バックアップの有無、扱うデータの重要性、復旧後の検証範囲を合わせて判断します。
早めの依頼が向いている状況
管理画面と公開画面の両方へ入れない、バックアップの内容や復元方法が分からない、決済や予約が止まっている、顧客情報を扱っている、サーバーやデータベースの編集が必要、改ざんや不正アクセスの疑いがある場合は、早めの依頼が安全です。
また、複数の制作会社や担当者が変更してきたサイト、独自テーマや独自プラグインを使うサイト、保守契約の範囲が不明なサイトは、単純なプラグイン停止だけでは判断できないことがあります。サイト全体の構成と変更履歴を確認できる担当者が向いています。
依頼先を選ぶときの確認事項
緊急復旧だけを行うのか、原因調査、再発防止、アップデート、バックアップ設計まで含むのかを確認します。作業前バックアップ、ステージング環境の利用、作業記録、復旧後の確認項目、追加費用が発生する条件を聞きます。
レンタルサーバー会社は、サーバー障害、PHP設定、バックアップ機能、ログの場所などには詳しい一方、テーマやプラグインのコード修正は対象外の場合があります。テーマやプラグインの提供元は自社製品の既知不具合を確認できますが、サイト全体の組み合わせまでは調査できないことがあります。WordPress制作会社や保守会社は全体の切り分けに向きますが、契約範囲を事前に確認します。
依頼時に用意すると調査が進みやすい情報
- 異常が起きているURLと正常なURL
- 最後に正常だった時刻と最初に異常を見た時刻
- 直前に更新、追加、編集した対象
- 管理画面へ入れるかどうか
- 表示されたメッセージと画面の記録
- WordPress、PHP、テーマ、プラグインのバージョン
- バックアップの有無、取得時刻、保存場所
- 自分で試した操作と、その前後の変化
ログイン情報は、メール本文やチャットへそのまま書かず、依頼先が指定する安全な共有方法を使います。作業用アカウントを必要最小限の権限で発行し、作業後に無効化する運用も検討します。
復旧後に確認したいこと
白画面が消えても、原因を記録せず通常運用へ戻すと再発しやすくなります。復旧は、表示を戻す作業と、正常性を確かめる作業の両方で完了します。
主要ページと事業機能を確認する
トップページだけでなく、投稿、固定ページ、カテゴリー、検索、404ページ、問い合わせ、ログイン、決済などを確認します。パソコンとスマートフォン、ログイン中とログアウト中でも比べます。外見だけでなく、フォーム送信やメール受信など実際の動作もテストします。
一時停止したプラグインを戻すときは、一つずつ有効化して主要機能を確認します。再び白画面になった場合に備え、戻し方を準備してから進めます。
原因と対応を運用記録へ残す
原因となった製品とバージョン、発生条件、ログの要点、行った復旧、確認結果、再発防止策を記録します。「プラグインを止めたら直った」だけでなく、どの組み合わせで起き、今後どの順序で更新するかまで残すと役立ちます。
自動更新の対象、更新前バックアップ、ステージング確認、監視、緊急連絡先も見直します。すべての更新を止めるのではなく、安全に更新できる手順を整えることが重要です。
公式情報を確認するときのポイント
WordPressの画面や設定は、バージョン、テーマ、プラグイン、レンタルサーバーによって異なります。古い個人ブログの手順をそのまま実行せず、まずWordPress公式の一般的なエラー資料と公式トラブルシューティングFAQを確認します。
デバッグが必要な場合は、WordPress公式のデバッグ解説を読み、公開画面へ情報を出さない設定と、調査後に元へ戻す手順まで理解してから作業します。wp-config.phpの編集はサイト全体へ影響するため、公式のwp-config.php資料と利用中のサーバー会社の案内を優先してください。
管理画面へ入れるなら、サイトヘルス画面の公式説明も参考になります。検索結果の回答が自分の環境へ合うか判断できない場合は、実行せず、現在の状態と公式資料を担当者へ共有します。
真っ白画面は原因を一つずつ切り分けて復旧する
WordPressが真っ白になったときは、最初に症状の範囲、発生時刻、直前の変更、管理画面へ入れるかを確認します。次に現状のバックアップを確保し、プラグイン、テーマ、PHP環境、更新失敗、サーバーやデータベースの順に、記録を残しながら原因候補を一つずつ切り分けます。
管理画面へ入れない場合は、ファイルマネージャーやSFTPでの停止、エラーログの確認が必要になることがあります。ただし、バックアップがない、重要な機能が止まっている、データベースや設定ファイルを触る必要がある場合は、無理に続けないことが大切です。
復旧後は、主要ページと事業機能を確認し、原因、対応、再発防止を記録します。画面が戻ったことだけで終わらせず、更新前バックアップ、検証環境、監視、連絡体制を整えることで、次に同じ障害が起きても落ち着いて判断できる運用へ近づきます。
