WordPressが真っ白になる原因と修正依頼の考え方

公開：2025.09.04 / 更新：2025.09.05

この記事はこんな人向けです

WordPressの画面が突然「真っ白」になり、ダッシュボードにも入れずに困っている
テーマやプラグインを更新した直後から表示されない／500エラーっぽい挙動が出ている
自分で直すべきか、外注して安全に戻すべきかを客観的に判断したい

WordPressレベル別対応難易度

Lv1 Lv2 Lv3 Lv4 Lv5 Lv6 Lv7

レベル判断は、右のレベル表（スマホは画面下）を参考にしてください。

赤：外注推奨オレンジ：条件付き自力可緑：自力対応可

WordPressで画面が真っ白になったときの全体像と対応方針

いわゆる「White Screen of Death（WSOD）」は、PHPの致命的エラー・プラグイン/テーマの競合・メモリ不足・.htaccessやWAFの干渉・キャッシュの不整合などが主因です。
まずは原因の切り分けをして、無理のない範囲で進める、原因がわからない場合には早めに外注するのを判断しましょう。
作業前にはバックアップ（少なくともファイルとDBのどちらか）を確保するのが鉄則です。

画面が真っ白になったとき～WordPressレベルごとのおすすめ対応

まずは落ち着いて情報整理 ※無理は禁物

サイトが真っ白になると焦りますが、初心者ほど焦らず冷静になることが大切です。誤操作で症状を悪化させると、すぐ直るはずのものが長期化したり、影響が広がり外注する場合に費用が跳ね上がったりします。

やっておきたいのは、状況のメモとスクリーンショットです。
・真っ白なのは「トップページだけ」か「その他の投稿、固定ページも」か、
・さらには「管理画面も真っ白になっている」か
・直前にやったこと（更新／新規プラグイン追加／テーマ切替／サーバー移転など）の整理
・レンタルサーバー側の障害情報やPHPバージョン変更の有無はないか

また、サイトヘルスを普段から確認していた方は、以前から警告（REST API・ループバック・必須モジュール）が出ていなかったか思い出してみてください。放置していた警告が「たまたま今日」顕在化することもあります。

赤レベルの方は、ここまで整理できたら、外注が無難です。
整理しておくと、原因特定が早まり、余計な費用も抑えられます。
逆に、ネット上の情報を鵜呑みにし、むやみにFTPでファイルを消したり、.htaccessをいじったり、セキュリティ系プラグインを無効化しようとして弾かれたり…は典型的な「悪化コース」ですので注意が必要です。

基本の切り分けで原因をしぼる

日頃から投稿やメディア管理をしている人・レンタルサーバーのファイルマネージャーが使える人などは、低リスクの切り分けならトライ可。

1) 自動更新直後の発症か？
コア／テーマ／プラグインの自動更新後に真っ白なら、互換性の不整合が濃厚です。特定できれば、その要素の一時停止・元のバージョンに戻す判断ができます（対応は自力or外注）。

2) プラグイン競合の切り分け
管理画面に入れない場合は、pluginsフォルダ名を一時変更して全停止状態を再現し、表示が戻るかの確認ができます。
もし戻るなら、競合の線が強いので、フォルダを元名に戻してから、疑わしいプラグインを一つずつ停止→確認…の順で原因を特定します。

3) テーマ起因のチェック
子テーマのfunctions.phpやテンプレート修正後に発症しているなら、テーマフォルダを一時的に退避し、デフォルトテーマにフォールバックさせて変化を見るのが有効です。
ファイル特定ができたら、関数を削除するなどで、原因箇所の特定も可能です。

4) サーバー側の要因
・PHPエラーログに Fatal error / memory exhausted などが出ていないか
・PHPバージョンの上げ下げ直後でないか（7.4→8.1→8.2で非推奨関数に当たるなど）
・WAF（mod_security）やCDN（Cloudflare）の設定が誤検知していないか
・キャッシュ（プラグイン・サーバー・CDN・OPcache）の整合性が崩れていないか

注意：ここから先（wp-config.phpでデバッグ有効化やメモリ割当の調整、DBのオプション修復、パーミッション見直し等）はミスすると復旧難度が上がります。「切り分けまで」で止めて外注する判断も十分アリです。

本格トリアージと恒久対策

サーバー/DB/SSH/WP-CLIに慣れている人は、再現→隔離→復旧→恒久化の順で落ち着いて進めます。

トリアージ：表示が真っ白でも、HTTPステータスやログは手がかりの宝庫。Fatal error / Parse error / Allowed memory size / Class not found / Call to undefined function 等を起点に、ピンポイントで犯人（特定のプラグイン・テーマ・カスタムコード）を隔離します。

隔離：プラグイン全停止→疑わしいものから順に有効化、テーマはデフォルトで検証。オブジェクトキャッシュ・OPcache・サーバー/アプリケーションキャッシュ・CDNの多層キャッシュを同時に整合させます。
.htaccessの書き換え、画像最適化・セキュリティ系プラグインのリライトルール、Basic認証やWAF設定などの干渉も疑います。

復旧：バックアップからの部分復元（テーマ/プラグイン単位）や、改変差分のロールバックで一旦の可用性を確保。必要に応じてコア/テーマ/プラグインを手動再配置し、破損ファイルを排除します。

恒久化：検証環境（ステージング）で更新の事前テスト、PHPバージョン/拡張モジュールの整備、Site Healthの警告ゼロ化、自動更新ポリシーの見直し、WAF・CDN・キャッシュの設計（順番とTTL）、ログ監視の常設などを行い、再発確率を下げます。

上級者でも「時間コスト」が大きい案件はあります。早く確実に戻す必要があるなら、外注のほうが合理的な場面も多いです。

外注する場合のポイント

「今日中に復旧したい」「今は触るのが怖い」というときは、専門家に任せるのが近道。費用感と進め方、事前準備を押さえておきましょう。

項目	ポイント
費用の目安	・軽微（プラグイン競合の特定～復旧）… 10,000～30,000円・テーマ/カスタムコード起因の修正… 30,000～80,000円・サーバー設定/DB修復/移転絡み… 50,000円～・特急対応（当日復旧）や深夜作業は割増になることがあります
依頼の流れ	1. 症状共有（真っ白の画面/URL・直前の操作・使用中テーマ/主なプラグイン・サーバー名・PHPバージョン） 2. 概算見積と進め方の合意（まずは暫定復旧→原因究明→恒久対策の順がおすすめ） 3. バックアップの確保→作業（停止・ロールバック・ログ解析・設定調整等） 4. 復旧確認と再発防止の提案（自動更新の設計/ステージング運用/監視の導入）
準備しておくと便利	・WordPressログイン情報（2段階認証があればコード手段も）・レンタルサーバーの管理パネル/FTPまたはSSH、phpMyAdminのアクセス情報・CDN/WAF（例：Cloudflare）、キャッシュ/セキュリティ系プラグインの設定情報・発生時刻・直前の変更点・エラーメッセージのスクショ（可能ならエラーログ）・商用/個人の連絡先（緊急時の確認フローを決めておくと速い）