WordPressが真っ白で表示されない原因と対処法｜白い画面を最短で直す手順

2026年7月9日

生徒

大変です…！WordPressを開いたら画面が真っ白で、何も表示されません。管理画面にも入れないかも…。どうしたらいいですか？

ペン博士

落ち着いて大丈夫だよ！その「真っ白」はよくある症状で、原因も限られてるんだ。順番に切り分ければ最短で直せるから、いっしょに直していこうね！

WordPressを運営していると、ある日突然サイトが真っ白になって何も表示されないというトラブルに出くわすことがあります。文字も画像もエラーもなく、ただ白いだけ。初めて見ると「壊れてしまったのでは」と焦りますが、落ち着いて切り分ければ多くのケースは自分で直せます。

この記事では、WordPressが真っ白になる代表的な原因を網羅し、症状の切り分けから具体的な復旧手順、そして再発を防ぐ予防策までを、未経験の方でも追えるように順番に解説します。FTPやファイルマネージャーを使った対処も、手順を1つずつ示すので安心してください。プラグイン競合・テーマ不具合・PHPメモリ不足・functions.phpの編集ミスといった原因ごとに、見分け方と直し方を具体的にお伝えします。読み終えるころには、真っ白画面を見ても落ち着いて対処できるようになっているはずです。

この記事の結論｜まず何を確認するか

先に結論からお伝えします。WordPressが真っ白になったとき、闇雲にファイルをいじるのは危険です。まずは次のポイントを上から順に確認してください。原因の切り分けさえできれば、対処はぐっと簡単になります。

管理画面（/wp-admin）が開けるかを確認する。開けるなら管理画面から、開けないならFTP・ファイルマネージャーから対処します。
サイト全体が白いのか、特定のページだけ白いのかを確認する。範囲によって疑う原因が変わります。
直前に何をしたかを思い出す。プラグイン更新・テーマ変更・コード編集など、直前の操作が原因のことが大半です。
WP_DEBUGを有効にしてエラー内容を見える化する。真っ白の裏で何が起きているかをログで確認します。
バックアップがあるかを確認する。作業前に現状を保存できると、失敗しても元に戻せます。

この5つを押さえるだけで、次に何をすべきかが見えてきます。逆に言えば、この確認を飛ばして「とりあえずファイルを消してみる」「よく分からないまま設定を変える」といった行動が、状況を悪化させる最大の原因です。真っ白になったサイトは、正しい手順を踏めば元に戻せることがほとんどですが、パニックのまま操作を重ねると復旧が難しくなることもあります。

この記事では、この結論で挙げた5つのポイントを軸に、原因ごとの見分け方と直し方を詳しく解説していきます。まずは自分のサイトがどの状態にあるのかを確認しながら読み進めてください。それでは、そもそも「真っ白」とは何が起きている状態なのかから見ていきましょう。

WordPressが真っ白になる「WSOD」とは

WSOD（White Screen of Death）とは、直訳すると「死の白い画面」。WordPressで画面に何も表示されず、真っ白になってしまう状態を指す俗称です。エラーメッセージすら出ないため原因が分かりにくく、初心者がもっとも戸惑うトラブルのひとつです。

なぜ「真っ白」になるのか

WordPressはPHPというプログラムでページを組み立て、その結果のHTMLをブラウザに返しています。ところがPHPの処理が途中で止まると、HTMLが最後まで出力されず、ブラウザには空っぽの（＝真っ白な）ページが届きます。これがWSODの正体です。

ポイントは、真っ白＝「サーバー側でPHPの実行が失敗した」サインだということ。つまり原因の多くはPHPを動かすファイル、すなわちプラグイン・テーマ・設定ファイルのどれかにあります。この視点を持つと、切り分けの見通しが良くなります。

エラー表示が出る場合との違い

最近のWordPressでは、致命的なエラーが起きたときに真っ白ではなく「このサイトで重大なエラーが発生しました」というメッセージ画面が出ることがあります。これはWordPress側がエラーを検知して表示してくれている状態で、真っ白よりも一歩進んで原因が分かりやすいケースです。この場合は管理者メール宛にエラー詳細が届くこともあるので、受信箱も確認しましょう。

逆に完全な真っ白は、エラー表示すら止まってしまった状態です。この記事の手順でWP_DEBUGを有効化して、隠れたエラーを見える化するのが第一歩になります。

真っ白のときブラウザで確認できること

真っ白の画面を見たとき、実はブラウザだけでもいくつか情報を集められます。まず、キーボードのF12（または右クリック→検証）でデベロッパーツールを開き、「Console（コンソール）」タブや「Network（ネットワーク）」タブを見てみましょう。

たとえばNetworkタブでページのURLを選ぶと、サーバーが返したステータスコードが分かります。200なら「サーバーは正常に応答したが中身が空」、500なら「サーバー側でエラーが発生」というように、状況の切り分けに役立ちます。中身が空の200なら、まさにPHPの処理が途中で止まったWSODの典型です。

また、ブラウザで「ページのソースを表示」して本当に何も出力されていないのか、それとも一部だけ出力されて途中で切れているのかを見るのも有効です。途中まで出力されている場合、その直後で処理が止まっているため、原因のヒントになります。ここまで確認できたら、いよいよ切り分けに入ります。

最初にやるべき切り分け｜2つの軸で見る

復旧作業に入る前に、まず状況を整理します。切り分けの軸は「①管理画面は開けるか」と「②白いのはサイト全体か一部か」の2つです。この2軸で見るだけで、疑うべき原因が大きく絞れます。

軸①：管理画面（wp-admin）は開けるか

ブラウザで「あなたのサイトURL/wp-admin」にアクセスしてみてください。https://example.com/wp-admin/のような形です。ここで結果が分かれます。

管理画面は開ける（ログインできる）場合：フロント（表側）だけが壊れている可能性が高く、管理画面からプラグイン停止・テーマ変更で対処できます。作業のハードルは低めです。
管理画面も真っ白／開けない場合：サイト全体に影響する原因（設定ファイル破損・全プラグインの問題・メモリ不足など）が疑われます。FTPやファイルマネージャーでの対処が必要になります。

軸②：サイト全体が白いか、特定ページだけか

トップページ・投稿ページ・固定ページ・管理画面など、いくつかのURLを開いて範囲を確認します。

サイト全体が真っ白：テーマや共通の設定ファイル、全体に効くプラグインが原因のことが多いです。
特定の投稿・固定ページだけ白い：そのページで使っているショートコードやブロック、特定プラグイン、ページ内に書いたコードが原因の可能性が高いです。
管理画面の特定の設定ページだけ白い：そのページを担当するプラグインの不具合が疑われます。

作業前に必ずやること：バックアップと記録

原因の切り分けができたら、すぐ対処に入りたくなりますが、その前に必ずやっておきたいのがバックアップと記録です。これから紹介する対処の多くは、ファイルのリネームやコードの削除を伴います。慎重に進めれば安全ですが、「元に戻せる状態」を作っておくと安心して作業できます。

バックアップは、可能ならサイトのファイル一式とデータベースの両方を取りましょう。管理画面に入れる場合はバックアッププラグイン、入れない場合はレンタルサーバーの自動バックアップやFTPでのファイルダウンロードが使えます。時間がないときでも、少なくともこれから編集する予定のファイル（functions.php、wp-config.php、.htaccessなど）だけは手元にコピーしておいてください。

記録も大切です。「いつ・どのファイルを・どう変えたか」をメモしながら進めると、もし途中で状況が変わっても、どの操作が効いたのかを追えます。復旧作業は「一度に1つだけ変える」のが鉄則。複数を同時に変えると、何が原因で直った（あるいは悪化した）のかが分からなくなります。

この2軸のメモとバックアップ・記録の準備ができたら、以降の手順のどこから手をつければよいかが判断しやすくなります。それでは原因を1つずつ見ていきましょう。

原因1｜プラグインの競合・不具合

真っ白トラブルの原因として最も多いのがプラグインです。プラグイン同士の相性（競合）、更新後の不具合、PHPバージョンとの非互換などで、ページの生成が止まってしまいます。

症状の特徴

「特定のプラグインを有効化・更新した直後から白くなった」「ある機能を使うページだけ白い」といった場合、プラグインが濃厚です。心当たりがあるなら、まずそのプラグインを疑います。

確認と対処：管理画面が開ける場合

管理画面にログインできるなら、話は簡単です。次の手順で犯人を探します。

「プラグイン」画面を開き、いったんすべてのプラグインを無効化する（複数選択→一括操作「無効化」）。
これでサイトが正常に戻れば、原因はプラグインで確定です。
1つずつ有効化して、どれを有効にした瞬間に白くなるかを確認する。白くなったものが犯人です。
犯人が分かったら、そのプラグインを更新・削除・代替プラグインへの乗り換えを検討します。

確認と対処：管理画面も開けない場合

管理画面にすら入れないときは、FTPソフト（FileZillaなど）かレンタルサーバーのファイルマネージャーを使います。プラグインは「wp-content/plugins」フォルダに入っているので、これを一括で無効化します。

FTP／ファイルマネージャーで/wp-content/pluginsフォルダを開く。
「plugins」フォルダ自体の名前をplugins_offなどにリネームする。これで全プラグインが一括で読み込まれなくなります。
サイトを再読み込みして、真っ白が直るか確認する。直れば原因はプラグインです。
フォルダ名を「plugins」に戻すと、プラグイン自体は「停止状態」でWordPressに認識されます。管理画面に入れるようになったら、1つずつ有効化して犯人を特定します。

フォルダ名を変えるだけでプラグインが停止するのは、WordPressが所定の名前のフォルダしか読み込まないためです。データが消えるわけではないので、落ち着いて操作すれば安全です。

個別のプラグインだけ止めたいとき

「全プラグインを止めると業務が回らない」「怪しいプラグインの見当がついている」という場合は、pluginsフォルダごとではなく、その中の個別プラグインのフォルダだけをリネームする方法もあります。たとえば「contact-form-7」フォルダを「contact-form-7_off」にすれば、そのプラグインだけが停止します。心当たりが1つに絞れているときは、こちらのほうが影響が小さく済みます。

プラグイン競合が起きる仕組み

そもそもなぜプラグイン同士が競合するのでしょうか。原因の1つは、複数のプラグインが同じ機能名（関数名）を使ってしまうケースです。PHPでは同じ名前の関数を二重に定義するとエラーになるため、両方を有効にした瞬間に致命的エラーで真っ白になります。

もう1つは、読み込みの順番や、同じ処理を奪い合う（フック競合）パターンです。単体では問題なくても、組み合わせた途端に不具合が出ます。だからこそ「1つずつ有効化して犯人を特定する」手順が有効なのです。犯人が分かったら、そのプラグインの更新を待つ、同等の別プラグインに乗り換える、といった判断をします。

なお、更新直後に白くなったなら、そのプラグインが新しいPHPバージョンや最新のWordPressに追いついていない可能性があります。この場合はプラグイン作者の対応を待つか、代替を探すのが現実的です。無理に古いバージョンへ戻すと、今度はセキュリティ上の穴が残ることがあるので注意しましょう。

犯人を効率よく絞り込むコツ

プラグインを1つずつ有効化して犯人を探す作業は、数が多いと時間がかかります。そこで役立つのが「二分探索」の考え方です。たとえばプラグインが20個あるとき、1つずつ確認すると最大20回試すことになりますが、まず半分の10個をまとめて有効化し、白くなるかどうかを見ます。白くなればその10個の中に犯人がいるので、さらにその半分の5個で確認…と絞り込めば、数回のチェックで犯人にたどり着けます。

また、有効化した瞬間ではなく「特定の操作をしたとき」だけ白くなるケースもあります。たとえば「問い合わせフォームを送信したときだけ」「特定の管理画面を開いたときだけ」白くなる場合は、その操作に関わるプラグインが怪しいと当たりをつけられます。debug.logのエラー発生時刻と自分の操作を照らし合わせると、犯人がぐっと絞りやすくなります。

プラグインを止めても直らないとき

全プラグインを停止しても真っ白のままなら、原因はプラグイン以外にあります。その場合は落ち着いて次の原因（テーマ、PHP設定、設定ファイル）に進みましょう。ここで大切なのは、プラグインを停止したまま次の検証に進むことです。プラグインを戻してしまうと、複数の原因が重なっている場合に切り分けが難しくなります。1つずつ要因を潰していく、この地道さが復旧への近道です。

原因2｜テーマの不具合・非互換

プラグインの次に多いのがテーマです。テーマの更新後や、テーマ独自のfunctions.phpにコードを書き足した直後に白くなるケースがよくあります。

確認と対処：管理画面が開ける場合

管理画面に入れるなら、いったんWordPress標準の「Twenty系」テーマ（Twenty Twenty-Four など）に切り替えてみてください。これで直れば、原因は使っていたテーマにあります。

「外観」→「テーマ」を開く。
Twenty系の標準テーマを「有効化」する（無ければ「新規追加」からインストール）。
サイトが直るか確認する。直れば元テーマが原因。テーマの更新・作者への問い合わせ・子テーマの見直しを行います。

確認と対処：管理画面が開けない場合

管理画面に入れないときは、テーマの切り替えをデータベース（wp_optionsテーブル）で行う方法もありますが、初心者には少しハードルが高い操作です。まずは次の順で試すのが安全です。

先にプラグインの一括停止（原因1）を試し、それでも直らないか確認する。
FTPで/wp-content/themesを開き、使用中テーマのフォルダ名を一時的にリネームする。WordPressはテーマが見つからないと自動的に標準テーマにフォールバックしようとします（標準テーマが残っている必要があります）。
それでも不安な場合は、phpMyAdminでwp_optionsテーブルのtemplateとstylesheetの値を標準テーマ名（例：twentytwentyfour）に書き換えます。DBを触るので、必ず事前にバックアップを取ってください。

テーマは見た目の根幹なので、いきなり本番で切り替えると印象が大きく変わります。急ぎで復旧が必要なら標準テーマで一度表示を回復し、落ち着いてから原因調査するのが現実的です。

親テーマの更新でカスタマイズが消えていた場合

よくあるのが、親テーマを直接カスタマイズしていて、更新でその変更が上書きされ、辻褄が合わなくなって白くなるパターンです。テーマ本体のファイルを直接編集していると、更新のたびに変更が消え、場合によってはエラーを招きます。

この経験をした方は、以降は必ず子テーマを使ってカスタマイズしましょう。子テーマなら親テーマを更新してもカスタマイズが残り、万一おかしくなっても子テーマを一時的に外すだけで切り分けられます。予防策の章でも詳しく触れます。

テーマのPHPバージョン対応も確認する

プラグイン同様、テーマにも対応PHPバージョンがあります。サーバーのPHPを新しくした直後にテーマが原因で白くなった場合は、テーマが新PHPに対応しているかを配布元で確認しましょう。有料テーマなら、購入元のサポートやアップデート情報をチェックするのが確実です。対応版のアップデートが出ていれば、それを適用することで解決することがあります。

テーマ切替後にレイアウトが崩れたら

標準テーマに切り替えると表示は回復しますが、当然ながら元テーマ独自のデザインや設定は反映されません。トップページのレイアウトやウィジェット、メニューの配置が大きく変わって見えるはずです。これは壊れているのではなく、標準テーマが自分のデザイン情報を持っていないだけなので、慌てないでください。元テーマの問題を解決して再び有効化すれば、多くの場合デザイン設定は元に戻ります。

ただし、テーマによってはカスタマイザーの設定やウィジェットの配置がテーマ固有で、切り替えると一部が失われることがあります。だからこそ、テーマを切り替える前にバックアップを取っておくと安心です。急ぎで表示を回復したいときは標準テーマで一時対応し、落ち着いてから元テーマの原因調査に戻る、という二段構えがおすすめです。

テーマ由来か自作コード由来かを見分ける

テーマが原因のように見えても、実際にはそのテーマのfunctions.phpに自分が書き足したコードが犯人ということがよくあります。両者を見分けるには、debug.logのエラー行に書かれたファイルパスを確認します。エラーがテーマ本体のファイル（例：index.phpやheader.php）で出ていればテーマそのものの不具合、functions.phpの自分が追記した行で出ていれば自作コードのミス、と判断できます。詳しくは原因5のfunctions.phpの章も参照してください。

原因3｜PHPのメモリ不足

メモリ不足とは、PHPが1回の処理で使える最大メモリ量（memory_limit）を超えてしまい、処理が強制終了する状態です。ページ生成が途中で止まるため、真っ白になります。

症状の特徴

「重いプラグインを入れた」「画像を大量に扱うページ」「バックアップやインポート作業中」など、処理が重い場面で白くなりやすいのが特徴です。WP_DEBUGを有効にすると「Allowed memory size of … bytes exhausted」といったログが出ます。

対処：メモリ上限を引き上げる

wp-config.phpに次の1行を追記して、WordPressが使えるメモリ上限を引き上げます。追記する場所は「/* 編集が必要なのはここまでです */」より上が安全です。

define('WP_MEMORY_LIMIT', '256M');

これでWordPress全体のメモリ上限が256MBに設定されます。管理画面側でさらに多くのメモリが必要な場合は、次の行も併用できます。

define('WP_MAX_MEMORY_LIMIT', '512M');

ただし、サーバー側（php.ini）の上限を超える値を指定しても反映されません。レンタルサーバーの管理画面でPHPの「memory_limit」を確認・引き上げできる場合は、そちらも合わせて設定してください。数値はサーバーのプランによって上限が異なるため、契約中のサーバーの案内に従ってください。

メモリ不足かどうかの見分け方

メモリ不足が原因かどうかは、WP_DEBUGのログではっきり分かります。debug.logに「Allowed memory size of ○○ bytes exhausted」という行があれば、メモリ不足で確定です。「○○ bytes」の部分が現在の上限で、それを使い切って処理が止まったことを意味します。

メモリ不足は、特定のプラグインや作業（バックアップ・大量データのインポート・画像の一括処理など）と結びついていることが多いです。上限を上げれば一時的に回避できますが、そもそもなぜそんなにメモリを食っているのかを考えることも大切です。極端に重いプラグインが原因なら、軽い代替に乗り換えるほうが根本的な解決になります。

上限を上げても直らないとき

メモリ上限を上げても改善しない、あるいは上げた値が反映されない場合は、サーバー側の上限に頭打ちになっている可能性があります。共有サーバーではプランごとにメモリ上限が決まっており、それ以上は増やせないことがあります。この場合は、上位プランへの変更や、原因となっている重い処理の見直しを検討しましょう。サーバーのサポートに現状のmemory_limitを問い合わせるのも有効です。

原因4｜PHPの致命的エラー・バージョン非互換

PHPの致命的エラー（Fatal error）とは、プログラムがそれ以上実行を続けられない重大なエラーです。関数の書き間違い、存在しない関数の呼び出し、そしてPHPバージョンとの非互換が代表的な原因です。

PHPバージョン非互換とは

WordPress本体・テーマ・プラグインには、それぞれ「対応しているPHPバージョン」があります。レンタルサーバーでPHPのバージョンを上げた（または下げた）ときに、古いプラグインが新しいPHPで動かなくなり、致命的エラーで真っ白になることがあります。

逆に、新しいプラグインが古いPHPで動かないこともあります。「更新したら急に白くなった」ときは、PHPバージョンとの相性を疑うのが定石です。

確認と対処

まずはWP_DEBUGを有効にして（次章参照）、debug.logに出るエラー内容を読みます。「Uncaught Error」「Call to undefined function」などのメッセージと、その直後に書かれたファイル名と行番号が原因箇所を指しています。

特定プラグイン・テーマのファイルでエラーが出ている → そのプラグイン／テーマを停止・更新・削除する。
PHPバージョンを上げた直後なら、レンタルサーバーの管理画面でいったん元のPHPバージョンに戻して表示が回復するか確認する。回復したら、対応版が出るまで待つか、代替を探します。
自分で書いたコードのエラーなら、その編集を元に戻す（原因5・6参照）。

よくあるエラーメッセージの読み方

debug.logに出るエラーは英語ですが、パターンは限られています。代表的なものを知っておくと、原因のあたりをつけやすくなります。

エラーメッセージの例	意味	疑うポイント
Call to undefined function	存在しない関数を呼び出した	関数名のタイプミス、プラグイン無効化による関数消失
Cannot redeclare … function	同じ関数を二重に定義した	プラグイン競合、コードの貼り付け重複
syntax error, unexpected …	文法エラー（括弧やセミコロンの誤り）	functions.php等の編集ミス
Allowed memory size … exhausted	メモリ上限を使い切った	メモリ不足（原因3）
Maximum execution time exceeded	処理時間の上限を超えた	重い処理、無限ループ

エラーメッセージは、末尾に必ず「どのファイルの何行目で起きたか」が書かれています。この一行を読むだけで、犯人がプラグインか、テーマか、自作コードかを判別できます。英語に身構えず、まずはファイルパスと行番号だけでも確認してみてください。

原因5｜functions.phpの編集ミス

テーマのfunctions.phpは、WordPressにさまざまな機能を追加できる強力なファイルです。しかしその分、たった1文字の書き間違いでサイト全体が真っ白になります。ネット上のコードをコピペして貼り付けた直後に白くなる、というのが典型パターンです。

症状の特徴

「functions.phpに何かを貼り付けて保存した瞬間に真っ白になった」なら、ほぼ確実にこれです。閉じ忘れの括弧、余計な空白、全角文字の混入、PHPタグの重複などが原因になります。

対処：直前の編集を元に戻す

管理画面の「テーマファイルエディター」で編集していた場合、白くなると管理画面にも入れなくなることがあります。その場合はFTP／ファイルマネージャーで直接直します。

FTPで/wp-content/themes/（使用中テーマ）/functions.phpを開く。
直前に追記した部分を削除する（または、コピペ元の正しいコードと見比べて誤りを直す）。
特に最初の<?phpより前や、最後の?>より後ろに余計な空白・空行がないかを確認する。ここに1文字でも余分があると真っ白になります。
保存してサイトを再読み込みし、回復を確認する。

編集前に必ず元のfunctions.phpをコピーして手元に残しておくと、いざというとき丸ごと戻せます。今後は子テーマを使う・コードスニペット管理プラグインを使うなど、functions.phpを直接触らない運用に切り替えるのが安全です。

なぜ空白1つで真っ白になるのか

「たった1つの空白でサイト全体が壊れる」というのは、初心者には理不尽に感じるかもしれません。これはPHPの仕組みによるものです。PHPは<?phpと?>の外側に書かれた文字を、そのままブラウザに出力しようとする性質があります。

WordPressはページを組み立てる途中で、まだブラウザに何も送っていない状態を保っています。ところがfunctions.phpの末尾に余計な空白があると、その瞬間に「何かを出力した」とみなされ、後続の重要な処理（Cookieの送信やリダイレクトなど）が失敗し、結果として真っ白やエラーを招きます。だからこそファイルの先頭・末尾に余計な文字を残さないことが鉄則なのです。

貼り付けたコードで気をつける点

ネットからコードをコピペするときは、次の点に注意しましょう。全角スペースや全角の記号が混ざっていないか、括弧やクォートがきちんと閉じているか、そして既存のコードと関数名が重複していないか。特に全角文字は見た目では気づきにくく、エラーの温床です。エディタで「全角スペースを可視化」する設定にしておくと安全です。

原因6｜.htaccessの破損

.htaccessは、Apacheサーバーの動作を制御する設定ファイルです。パーマリンク（URLの形）やリダイレクトの設定が書かれており、ここが壊れると特定のページや全体が表示されなくなります。プラグインが自動で書き換えて壊れることもあります。

症状の特徴

「トップページは出るのに個別記事だけ真っ白／404になる」「パーマリンク設定を変えたあとから不調」といった場合、.htaccessを疑います。

対処：リネームして再生成する

.htaccessはWordPressが自動生成できるので、壊れた場合は一度リネームして作り直させます。

FTPでサイトのルート（wp-config.phpと同じ階層）にある.htaccessを探す（先頭がドットの隠しファイルなので、隠しファイル表示をオンにします）。
ファイル名を.htaccess_bakなどにリネームして退避する（削除ではなく退避が安全）。
サイトが直るか確認する。直れば原因は.htaccessです。
管理画面に入れるようになったら、「設定」→「パーマリンク設定」を開いて何も変えずに「変更を保存」を押す。これでWordPressが正しい.htaccessを再生成します。

なお、.htaccessに自分やプラグインが追加した独自の記述（リダイレクトなど）があった場合は、退避したファイルから必要な部分だけ書き戻してください。

WordPressの標準.htaccessはどんな内容か

WordPressが自動生成する.htaccessは、パーマリンクを機能させるための書き換えルールが中心です。パーマリンク設定を再保存すると、WordPressが「# BEGIN WordPress」から「# END WordPress」までのブロックを自動で書き込みます。この標準ブロック以外の記述（キャッシュ設定やセキュリティ設定など）は、プラグインや手動で追加されたものです。

そのため、.htaccessをリネームして再生成すると標準ブロックは復活しますが、独自に追加した記述は復活しません。リダイレクト設定などが消えて困る場合に備え、退避したファイルの中身は必ず控えておきましょう。

Nginx環境の場合

なお、.htaccessが効くのはApacheというサーバーソフトを使っている場合です。近年は高速な「Nginx」を採用するサーバーも増えており、その場合.htaccessは使われず、設定はサーバー側の別ファイルで管理されます。自分のサーバーがどちらかは、契約中のレンタルサーバーの仕様で確認できます。Nginx環境で.htaccessをいじっても効果がない場合は、パーマリンク関連の不具合はサーバーのサポートに相談するのが早道です。

原因7｜wp-config.phpの破損

wp-config.phpは、データベース接続情報など、WordPressの根幹となる設定を書いたファイルです。ここを編集して書き間違えると、サイト全体が真っ白になります。functions.php同様、余計な空白や閉じ忘れが致命傷になります。

症状の特徴

「wp-config.phpを編集した直後から全ページ・管理画面ともに真っ白」なら、これが濃厚です。デバッグ設定の追記ミスや、コピペ時の文字化けが原因になりがちです。

対処のポイント

FTPで開き、直前に追記・変更した箇所を元に戻す。
ファイル冒頭の<?phpより前に空白・BOM・空行がないか確認する。
追記したdefine()行のセミコロン;やクォートの閉じ忘れがないか確認する。
編集前のバックアップがあれば、それに差し替えるのが確実。

wp-config.phpは最重要ファイルです。触る前に必ずコピーを取り、1箇所ずつ・少しずつ編集する習慣をつけましょう。

wp-config.phpを編集する正しい位置

この記事では何度か「wp-config.phpにdefine()を追記する」場面が出てきます。追記する場所には決まりがあります。ファイルの中ほどに「/* 編集が必要なのはここまでです。がんばってください！ */」という日本語コメント（英語版では「That’s all, stop editing!」）があります。追記は、必ずこの行より上に入れてください。

この行より下にはWordPressの読み込み処理が書かれており、そこに設定を追記すると意図どおりに反映されなかったり、エラーを招いたりします。逆に、ファイル冒頭の<?phpのすぐ後ろあたりに追記すれば、まず間違いありません。

機密情報の取り扱いに注意

wp-config.phpにはデータベースのユーザー名やパスワードといった機密情報が含まれています。編集内容を人に見せたり、掲示板やチャットに貼り付けたりするときは、これらの情報を含めないよう十分注意してください。サポートに問い合わせる際も、パスワード部分は伏せて伝えるのが安全です。万一どこかに貼り付けてしまった場合は、パスワードを変更することをおすすめします。

紛らわしい類似トラブル｜データベース接続エラー

真っ白と混同されやすいのがデータベース接続確立エラー（Error establishing a database connection）です。厳密には真っ白ではなく、このメッセージが1行だけ表示される状態ですが、「ほぼ何も出ていない」ように見えるため混同されがちです。

何が起きているか

WordPressは記事や設定をデータベース（MySQL）に保存しており、そのデータベースに接続できないと、このエラーになります。原因は、wp-config.phpの接続情報の誤り、データベースサーバーの停止・過負荷、レンタルサーバー側の障害などです。

確認と対処

wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTが正しいか確認する（サーバーの管理画面の情報と突き合わせる）。
レンタルサーバーの障害情報・メンテナンス情報を確認する。サーバー側の一時的な問題であれば、時間をおくと復旧することがあります。
アクセス集中でDBが処理落ちしている場合もあるため、キャッシュ系プラグインやサーバーのプラン見直しも検討する。

接続情報を触るときは機密性が高いので、パスワードなどを画面に貼り付けたり、公開ファイルに残したりしないよう注意してください。

DB接続エラーと真っ白の見分け方

両者は原因も対処も違うので、見分けが大切です。ポイントはシンプルで、画面にメッセージが出ているかどうかです。「データベース接続確立エラー」という文字が出ていればDB接続の問題、完全に何も出ていなければPHPの処理が止まったWSODです。

ただし前述のとおり、メッセージが1行だけだと「ほぼ真っ白」に見えて混同しがちです。ブラウザで「ページのソースを表示」すると、メッセージが出力されているかどうかを確実に確認できます。ソースにエラー文が含まれていればDB接続の問題として、この章の対処に進んでください。

修復モードを試す

WordPressには、DB接続エラーやテーブル破損に対応するためのデータベース修復機能が備わっています。wp-config.phpにdefine('WP_ALLOW_REPAIR', true);を追記すると、「サイトURL/wp-admin/maint/repair.php」から修復を試せます。修復が終わったら、必ずこの記述を削除してください。誰でもアクセスできる状態で残すのは危険です。データを扱う操作なので、実行前のバックアップも忘れないようにしましょう。

原因8｜大量のリビジョン・データの肥大化

リビジョンとは、投稿を保存するたびに自動でたまっていく「過去の版」です。長く運営しているサイトでは、これが1記事あたり数十〜数百件たまり、データベースが肥大化することがあります。

症状の特徴

「投稿一覧や特定記事の編集画面だけ極端に重い・白くなる」「サイト全体の表示がじわじわ遅くなり、ときどき真っ白になる」場合、データの肥大化やそれに伴うメモリ不足（原因3）が絡んでいることがあります。

対処と予防

まずは原因3のメモリ上限引き上げで一時的に回避できることが多い。
リビジョンの保存件数を制限するには、wp-config.phpに次の設定を追記する。

define('WP_POST_REVISIONS', 10);

これで1記事あたりのリビジョンが最大10件までに制限され、無限にたまるのを防げます。既存の大量リビジョンの整理には最適化プラグインも使えますが、実行前には必ずデータベースのバックアップを取ってください。

自動保存の間隔を伸ばす

リビジョンとは別に、WordPressには編集中の内容を一定間隔で自動保存する機能があります。この間隔が短いとサーバーへの負荷が増えることがあります。次の設定で間隔を伸ばせます（単位は秒）。

define('AUTOSAVE_INTERVAL', 300);

これで自動保存が5分（300秒）ごとになります。ただし自動保存は不意の消失を防ぐ大切な機能でもあるので、伸ばしすぎには注意しましょう。データの肥大化が気になる場合は、リビジョン制限とあわせて調整するのがおすすめです。

肥大化の根本対策

データの肥大化は、真っ白の直接原因というより「じわじわ重くなり、メモリ不足を誘発する」間接的な要因です。根本対策としては、不要なリビジョン・スパムコメント・使っていないプラグインやテーマの削除が有効です。定期的にデータベースを最適化する習慣をつけると、表示速度の改善にもつながり、真っ白トラブルの予防にもなります。

原因9｜キャッシュの不整合

キャッシュとは、表示を速くするために一時保存されたページのコピーです。サイトの構成を変えたのに古いキャッシュが残っていると、壊れた状態のページが表示され続け、真っ白に見えることがあります。

症状の特徴

「自分のPCでは白いのに、スマホや別の端末では正常に見える」「シークレットウィンドウなら表示される」といった場合は、キャッシュが原因の可能性が高いです。デザインやプラグインを変更した直後に一部のページだけ崩れるケースも、キャッシュを疑います。

クリアすべきキャッシュの種類

キャッシュは1か所だけでなく、複数の場所に存在します。次の順に、それぞれクリアしていきましょう。

キャッシュの種類	クリア方法
ブラウザキャッシュ	スーパーリロード（Windowsは Ctrl+F5、Macは Cmd+Shift+R）／シークレットウィンドウで確認
キャッシュ系プラグイン	プラグインの設定画面から「キャッシュを削除」を実行
サーバーキャッシュ	レンタルサーバーの管理画面から該当ドメインのキャッシュを削除
CDNキャッシュ	Cloudflareなどを使っている場合、管理画面から「Purge Cache」を実行

まずは手軽なブラウザ側から疑い、シークレットウィンドウ（プライベートモード）で開いてみてください。そこで正常に見えるなら、原因はほぼキャッシュです。その後、上の表を上から順にクリアしていけば、たいてい解消します。

原因10｜SSL設定・リダイレクトループ

サイトのURL設定やSSL（https化）の設定に食い違いがあると、ページが同じ場所を行き来し続けるリダイレクトループに陥り、真っ白や「リダイレクトが繰り返し行われました」というエラーになります。独自SSLを導入した直後や、常時SSL化プラグインを入れた後に起きやすい原因です。

WordPressアドレスとサイトアドレスをそろえる

wp-config.phpにサイトのURLを直接指定すると、設定の食い違いを解消できます。httpとhttpsの別、wwwの有無を、実際に使っているURLに正しくそろえてください。

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

「example.com」の部分を自分の実際のドメインに置き換えます。この2行はデータベース側の設定より優先されるため、URLの不整合によるループを止めやすくなります。設定後は、前述のキャッシュのクリアも忘れずに行いましょう。

リダイレクトが二重になっていないか確認する

リダイレクトループのもう1つの典型は、同じ「httpsへ飛ばす設定」が複数の場所に重複しているケースです。次の場所に、httpsへのリダイレクトが二重に書かれていないか確認してください。

.htaccessに手動やプラグインで追加されたhttpsリダイレクト。
常時SSL化プラグインによるリダイレクト設定。
レンタルサーバー側の「常時SSL（https強制）」設定。
CloudflareなどCDNのSSL/TLSモード（フレキシブル／フルの設定違い）。

これらが複数同時に効いていると、リダイレクトが無限に繰り返されます。1か所ずつ無効にして、どこで二重になっているかを切り分けましょう。基本は「サーバー側かプラグインのどちらか一方だけ」でhttps化するのが安全です。

復旧作業の道具｜FTP・ファイルマネージャー・phpMyAdminの基本

管理画面が開けない真っ白トラブルでは、サーバーのファイルを直接操作する道具が欠かせません。この記事でも繰り返し登場するFTPソフト・ファイルマネージャー・phpMyAdminの3つについて、初めての方向けに基本操作をまとめておきます。ここを押さえておくと、以降の手順がスムーズに進められます。

FTPソフト（FileZilla）の使い方

FTPソフトは、自分のパソコンとサーバーの間でファイルをやり取りするための道具です。無料で定番のFileZillaを例に、基本の流れを示します。

FileZillaをインストールして起動する。
上部の入力欄に、レンタルサーバーから発行されたホスト名・ユーザー名・パスワードを入力し、「クイック接続」を押す。
接続できると、画面右側にサーバー上のフォルダが表示される。WordPressを設置したフォルダ（public_htmlやwwwなど）を開く。
編集したいファイルを右クリック→「表示/編集」で開くか、いったんダウンロードして手元で編集し、アップロードで上書きする。

FTPの接続情報はサーバーへの鍵にあたる重要な機密情報です。第三者に知られると乗っ取りにつながるため、メモの扱いには十分注意し、公開の場所に貼り付けたりしないでください。可能なら、より安全な「SFTP」接続に対応しているかもサーバーの案内で確認しましょう。

ファイルマネージャー（FTPソフト不要）

FTPソフトの設定が難しいと感じる方には、ブラウザだけで使えるファイルマネージャーがおすすめです。多くのレンタルサーバーが、管理画面の中にこの機能を用意しています。

レンタルサーバーの管理画面（サーバーパネルなど）にログインする。
「ファイル管理」「ファイルマネージャー」といったメニューを開く。
WordPressを設置したドメインのフォルダを開く。
ファイルを選んで「編集」「名前の変更」「ダウンロード」などの操作を行う。

ファイルマネージャーなら、インストールも接続設定も不要で、この記事のFTP手順（フォルダのリネームやファイル編集）がそのまま実行できます。先頭がドットの隠しファイル（.htaccessなど）を表示する設定がある場合は、忘れずにオンにしておきましょう。

phpMyAdmin（データベースの操作）

phpMyAdminは、WordPressのデータ（投稿・設定など）が保存されているデータベースを、ブラウザから操作するための道具です。テーマの強制切り替えやDBの修復・バックアップなど、一歩進んだ復旧作業で使います。

レンタルサーバーの管理画面から「phpMyAdmin」を開く（データベースのユーザー名・パスワードを求められることがあります）。
左側の一覧から、WordPressが使っているデータベースを選ぶ。
バックアップを取るなら「エクスポート」タブから実行する。
設定を確認するなら、wp_optionsテーブルのsiteurlやhomeなどの値を見る。

データベースはサイトの心臓部です。値を書き換える操作はミスがそのまま致命傷になるため、必ず事前にエクスポート（バックアップ）を取り、自信がないときは無理に触らず、バックアップからの復元やサポートへの相談を検討してください。

最重要手順｜WP_DEBUGでエラーを見える化する

ここまで原因を紹介してきましたが、真っ白の状態では「どれが原因か」が見えません。そこで欠かせないのがWP_DEBUG（デバッグモード）です。これを有効にすると、画面には出ていなかったエラーの中身をログに記録できます。

WP_DEBUGとは

WP_DEBUGは、WordPressの開発・調査用の設定です。有効にすると、通常は隠れているPHPのエラーや警告が表示・記録されるようになり、真っ白の裏で何が起きているかを突き止められます。

設定方法

FTP／ファイルマネージャーでwp-config.phpを開き、次の3行を追記します。「/* 編集が必要なのはここまでです */」の行より上に入れてください。すでにWP_DEBUGの行がある場合は、その値を書き換えます。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

それぞれの意味は次のとおりです。

WP_DEBUG：デバッグモードのオン／オフ。trueで有効になります。
WP_DEBUG_LOG：エラー内容をファイル（debug.log）に書き出します。
WP_DEBUG_DISPLAY：エラーを画面に表示するかどうか。公開中のサイトではfalseにして、来訪者にエラーを見せないようにします。

debug.logの場所と読み方

WP_DEBUG_LOGを有効にすると、エラーは/wp-content/debug.logに記録されます。FTPでこのファイルを開くと、次のような行が並びます。

PHP Fatal error:  Uncaught Error: Call to undefined function
example_function() in /home/user/example.com/public_html/
wp-content/themes/mytheme/functions.php on line 128

見るべきは「Fatal error（致命的エラー）」の行と、その末尾のファイル名・行番号です。上の例なら、mytheme（自作テーマ）のfunctions.phpの128行目が原因だと分かります。ファイル名から、プラグイン・テーマ・自作コードのどれが犯人かも判別できます。

調査が終わったら、必ずWP_DEBUGをfalseに戻してください。公開サイトでデバッグを有効のままにするのは、情報がログにたまり続けるうえ、思わぬ情報露出のリスクにもつながります。

画面にエラーを出して調べたいとき

管理画面にも入れず、debug.logの読み方に自信がない場合は、一時的にエラーを画面に直接表示する設定にする方法もあります。先ほどのWP_DEBUG_DISPLAYをtrueにすると、真っ白だった画面にエラー内容が表示されます。

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

これなら、真っ白だった画面に「どのファイルの何行目でエラーが起きたか」が直接表示されます。ただしこれは来訪者にもエラーが見えてしまう状態なので、公開中のサイトで使うのは調査のあいだだけにし、原因が分かったらすぐfalseに戻してください。誰にも見られたくない場合は、深夜など人が少ない時間帯にサッと確認するのがおすすめです。

debug.logが見当たらないとき

WP_DEBUG_LOGを有効にしたのにdebug.logが見つからない場合、いくつか原因が考えられます。1つはまだエラーが発生していないこと。ログはエラーが起きて初めて生成されるので、真っ白のページを一度読み込んでから確認しましょう。もう1つは書き込み権限がないことで、wp-contentフォルダの権限が原因のこともあります。それでも見つからないときは、サーバー側のエラーログを確認するか、サポートに相談してください。

復旧のおすすめ手順（フローまとめ）

ここまでの内容を、実際に上から順に試せる形にまとめます。この順番で進めれば、多くの真っ白トラブルは自力で切り分け・復旧できます。

状況を記録：管理画面が開けるか／全体か一部か／直前の操作を書き出す。
バックアップ：可能なら現状のファイルとDBを保存しておく。
WP_DEBUGを有効化し、debug.logでエラー内容とファイル名を確認する。
プラグインを一括停止（管理画面 or pluginsフォルダのリネーム）。直れば1つずつ有効化で犯人特定。
テーマを標準テーマに切替。直れば元テーマが原因。
functions.php・wp-config.phpの直前編集を元に戻す。
.htaccessをリネームし、パーマリンク設定を再保存して再生成。
メモリ上限を引き上げ（WP_MEMORY_LIMIT）。
それでも直らなければ、debug.logの内容を添えてレンタルサーバーのサポートに問い合わせる。

1つ試すごとにサイトを再読み込みして、どの操作で直ったかを確認するのがコツです。原因が特定できれば、同じトラブルの再発も防ぎやすくなります。

症状・きっかけ	まず疑う原因	対処の入口
プラグイン更新・有効化の直後	プラグイン競合	全プラグイン一括停止
テーマ更新・切替の直後	テーマ不具合	標準テーマに切替
コードを貼り付けた直後	functions.php／wp-config.phpの編集ミス	FTPで直前編集を戻す
個別記事だけ白い・404	.htaccess破損	.htaccessをリネーム→再生成
重い処理・大量画像で白い	メモリ不足	WP_MEMORY_LIMIT引き上げ
PHPバージョンを変えた直後	PHP非互換・致命的エラー	PHPバージョンを戻す／対応版へ
1行のエラーメッセージ表示	DB接続エラー	wp-config.phpのDB情報確認

レンタルサーバー別のヒント（一般論）

多くのレンタルサーバーには、真っ白トラブルの調査に役立つ機能が用意されています。画面名やメニュー構成はサーバーやプランによって異なるため、ここでは一般的な考え方だけ紹介します。詳細は必ず契約中のサーバーの公式マニュアルを確認してください。

PHPバージョンの切り替え

エックスサーバー・ConoHa WING・ロリポップなど、多くのサーバーにはPHPバージョンを切り替えるメニューがあります。更新後に白くなった場合、一時的に元のPHPバージョンへ戻すと表示が回復することがあります。回復したら、原因のプラグイン・テーマが新しいPHPに対応するまで待つか、代替を検討します。

サーバー側のエラーログ

サーバーの管理画面には、PHPやApacheのエラーログを閲覧できる画面が用意されていることが多いです。WordPressのdebug.logと合わせて見ると、原因の特定が早まります。ログの場所や取得方法はサーバーごとに違うため、公式マニュアルの案内に従ってください。

なお、この記事では特定サーバーの具体的な数値や手順を断定することは避けています。管理画面の名称や上限値は改定されることがあるため、必ず最新の公式情報で確認するのが安全です。

再発を防ぐ予防策

真っ白トラブルは、日ごろの運用でかなり防げます。「壊れてから直す」より「壊れにくくする」ほうが、結果的にずっと楽です。次の5つを習慣にしましょう。

更新前にバックアップを取る

WordPress本体・テーマ・プラグインの更新前には、ファイルとデータベースのバックアップを取りましょう。多くのレンタルサーバーには自動バックアップ機能があり、バックアップ用プラグインもあります。「更新して白くなっても、すぐ戻せる」状態を作っておくのが最強の保険です。

ステージング環境で先に試す

ステージング環境とは、本番とそっくりのテスト用サイトのことです。更新や大きな変更を先にステージングで試し、問題がないことを確認してから本番に反映すれば、来訪者に真っ白を見せずに済みます。ステージング機能を提供しているサーバーも増えています。

子テーマを使う

テーマをカスタマイズするときは、直接ではなく子テーマを使いましょう。子テーマなら、親テーマの更新でカスタマイズが消えることもなく、functions.phpの編集ミスがあっても影響範囲を切り分けやすくなります。

コードは管理画面で直接編集しない

管理画面の「テーマファイルエディター」でfunctions.phpを直接編集すると、ミスした瞬間に管理画面ごとロックアウトされる危険があります。編集はFTPで行うか、コードスニペット管理プラグインを使い、いつでも元に戻せる状態で作業しましょう。

メモリと環境に余裕を持たせる

プラグインを増やす・大きな画像を扱う予定があるなら、あらかじめメモリ上限やサーバーのプランに余裕を持たせておくと、ある日突然の真っ白を防げます。

プラグインを入れすぎない

便利だからといってプラグインをむやみに増やすと、競合のリスクとメモリ消費が増え、真っ白トラブルの温床になります。同じような機能のプラグインを複数入れていないか、もう使っていないプラグインが残っていないかを定期的に見直しましょう。使わないプラグインは停止ではなく削除するのが安全です。数を絞るほど、原因の切り分けも楽になります。

信頼できるプラグイン・テーマを選ぶ

導入する前に、最終更新日・有効インストール数・対応WordPressバージョン・レビューを確認しましょう。長く更新されていないプラグインは、新しいPHPやWordPressで動かなくなるリスクが高くなります。公式ディレクトリや信頼できる配布元から入手し、出所の分からないものは避けるのが鉄則です。これはセキュリティ面でも重要です。

復旧できたら「後始末」を忘れずに

無事にサイトが表示されても、そこで終わりではありません。調査のために加えた設定を放置すると、別のトラブルや情報露出の原因になります。復旧後は次の後始末を必ず行いましょう。

調査のために追記したWP_DEBUGをfalseに戻す（ログだけ残す運用にする場合も、DISPLAYは必ずfalseに）。
確認が済んだdebug.logは削除するか、外部から直接アクセスできない状態にする（機密情報が含まれることがあるため）。
退避のためにリネームしたフォルダ・ファイル（plugins_off、.htaccess_bakなど）を整理する。
原因になったプラグイン・テーマ・コードを最新化するか、代替に切り替える。
今回の原因と対処をメモに残しておく。同じトラブルが起きたとき、次はすぐに直せます。

特に、デバッグ表示を出したままにしたり、debug.logを誰でも見られる状態で放置したりすると、サーバーのパスや内部構造といった情報が漏れる恐れがあります。復旧の達成感でつい忘れがちですが、この後始末までがワンセットだと覚えておいてください。

エラー通知を受け取れるようにする

最近のWordPressは、致命的エラーが起きたときに管理者メール宛に通知を送る機能を備えています。管理画面の管理者メールアドレスが有効なものになっているか確認しておきましょう。エラー通知には復旧用のリンクが含まれることもあり、真っ白になったときの初動が早くなります。監視系プラグインやサーバーの死活監視を併用すると、より早く異常に気づけます。

予防策	防げるトラブル	手軽さ
更新前バックアップ	更新起因の真っ白全般	★★★（プラグイン等で簡単）
ステージング環境で検証	本番での真っ白を未然に防ぐ	★★（対応サーバーが必要）
子テーマの利用	テーマ更新・編集ミス起因	★★（最初の設定のみ）
FTP／スニペット管理で編集	functions.php編集ミス	★★★（習慣づけ）
プラグインの整理	競合・メモリ不足	★★★（定期的な見直し）
メモリ・プランの余裕	メモリ不足起因	★★（プラン次第）

公式サイトから無料カウンセリングに申し込む →

「自分でコードを直せるようになりたい」「トラブルの原因を自力で読めるようになりたい」という方は、基礎から体系的に学ぶのが近道です。

公式サイトから無料カウンセリングに申し込む →

独学でつまずきやすいのが、まさにこうした「エラーの読み方」や「切り分けの考え方」です。手を動かしながら学べる環境があると、習得スピードが大きく変わります。

公式サイトから無料カウンセリングに申し込む →

初心者がやりがちな失敗と、その回避法

最後に、真っ白トラブルの復旧で初心者がやりがちな失敗をまとめておきます。ここを避けるだけで、復旧の成功率がぐっと上がります。編集部でも、サポートの現場でよく見かけるパターンです。

失敗1：バックアップを取らずに作業する

いちばん多いのがこれです。焦って復旧作業に入り、あとで「元に戻したいのに戻せない」となるパターン。触る前のバックアップ、あるいは編集ファイルのコピーは、たとえ数分でも必ず取りましょう。ファイルはリネームで退避するクセをつけると、削除による取り返しのつかない失敗を防げます。

失敗2：一度に複数の変更をする

「プラグインも止めて、テーマも変えて、コードも直して…」と一気にやると、どれが効いたのか分からなくなります。復旧は1つ変えるごとにサイトを確認し、直ったかどうかを見極めるのが鉄則です。遠回りに見えて、これが最短ルートです。

失敗3：エラーを見ずに手当たり次第に試す

WP_DEBUGを有効にすれば原因のファイルが分かるのに、それを飛ばして手当たり次第に試すと時間を浪費します。まずログを見て、当たりをつけてから対処する。debug.logの1行が、何時間もの試行錯誤を省いてくれます。

失敗4：公開サイトでデバッグ表示を出しっぱなしにする

調査のためにWP_DEBUG_DISPLAYをtrueにしたまま忘れると、来訪者にエラーが見え続け、内部情報が露出します。調査が終わったら必ずfalseに戻す、この一手間を習慣にしましょう。

失敗5：原因を放置して上限だけ上げ続ける

メモリ不足のたびに上限を上げるだけでは、根本原因（重すぎるプラグインなど）が残り、いずれまた白くなります。なぜメモリを食っているのかを一度は考えることで、再発を断ち切れます。

失敗6：本番サイトでいきなり試す

復旧作業に限らず、更新やコード変更を本番サイトでぶっつけ本番で試すのは危険です。特にアクセスの多いサイトでは、真っ白の時間がそのまま機会損失や信頼低下につながります。可能なら、ステージング環境やローカル環境で先に試し、問題がないことを確認してから本番に反映しましょう。ステージングが使えない場合でも、せめてアクセスの少ない時間帯を選び、バックアップを取ってから作業するだけで、リスクは大きく下げられます。

失敗7：焦ってサポートに丸投げする（情報不足で）

自力で難しいときにサポートへ頼るのは正しい判断ですが、「真っ白になりました」とだけ伝えると、原因の特定に時間がかかってしまいます。問い合わせる前に、「いつから」「直前に何をしたか」「管理画面は開けるか」「debug.logのエラー内容」の4点をメモしておきましょう。この情報があるだけで、サポートの対応スピードは格段に上がり、結果的に早く復旧できます。

よくある質問

Q. 管理画面（wp-admin）も真っ白で入れません。どうすればいいですか？

A. 管理画面まで真っ白な場合は、サイト全体に影響する原因（設定ファイルの破損・全プラグインの問題・メモリ不足など）が疑われます。FTPやファイルマネージャーを使い、まずはpluginsフォルダのリネームで全プラグインを停止してみてください。それでも直らなければ、functions.php・wp-config.php・.htaccessの直前編集を戻す、メモリ上限を上げる、と順に試します。WP_DEBUGを有効にしてdebug.logを読むと、原因のファイルが分かります。

Q. スマホやタブレットだけ白くて、PCでは表示されます。なぜですか？

A. 特定の端末・ブラウザだけ白い場合は、サーバー側の完全なWSODというより、キャッシュや一部のJavaScript・レスポンシブ表示の不具合が疑われます。まずはそのブラウザのキャッシュを消して再読み込みし、キャッシュ系プラグインを使っているならキャッシュを削除してみてください。それでも改善しない場合は、モバイル向けの表示を切り替えているプラグインやテーマ設定を確認します。

Q. WordPressやプラグインを更新したら白くなりました。元に戻せますか？

A. はい、可能です。更新後の真っ白はプラグイン・テーマの不具合、またはPHPバージョンとの非互換がほとんどです。まずは更新したプラグイン・テーマを停止して直るか確認し、直ればそれが原因です。バックアップがあれば更新前の状態に戻せます。PHPバージョンを上げた直後なら、サーバーの管理画面でいったん元のバージョンに戻すと回復することがあります。

Q. 記事の画像だけが表示されず、白く（空白に）なります。

A. ページ自体は表示されているのに画像だけ出ない場合は、WSODとは別の問題です。画像ファイルのパスの誤り・アップロード漏れ・パーミッション（権限）の問題・外部リンク切れなどが考えられます。画像URLに直接アクセスして表示されるか、メディアライブラリに画像が存在するかを確認しましょう。

Q. 「500 Internal Server Error」と真っ白は何が違うのですか？

A. どちらもサーバー側の不具合ですが、真っ白（WSOD）はPHPの処理が途中で止まって空のページが返る状態、500エラーはサーバーがエラーを検知してエラーページを返す状態です。原因が重なることも多く（.htaccess破損はどちらも起こしえます）、対処の入口も似ています。500エラーの場合はサーバーのエラーログにより詳しい情報が残るので、まずはそちらを確認するとよいでしょう。

Q. FTPソフトを持っていません。ファイルを触る方法はありますか？

A. あります。多くのレンタルサーバーにはブラウザから使える「ファイルマネージャー（Webファイルマネージャ）」が用意されています。サーバーの管理画面にログインすれば、FTPソフトなしでフォルダのリネームやファイルの編集ができます。この記事のFTP手順は、すべてファイルマネージャーでも同様に実行できます。

Q. どうしても自分で直せません。どうすればいいですか？

A. WP_DEBUGを有効にして得たdebug.logのエラー内容を控えたうえで、契約中のレンタルサーバーのサポートに問い合わせるのが確実です。エラーメッセージとファイル名・行番号を伝えると、原因の特定がスムーズになります。バックアップがあれば、直前の正常な状態に復元してもらえる場合もあります。

Q. WP_DEBUGを有効にしたのに、エラーログ（debug.log）が出てきません。

A. いくつか原因が考えられます。まず、WP_DEBUGとWP_DEBUG_LOGの両方がtrueになっているか確認してください。次に、debug.logはエラーが起きて初めて生成されるので、真っ白のページを一度読み込んでから/wp-content/フォルダを見てください。それでも無い場合は、wp-contentフォルダに書き込み権限がない、あるいはwp-config.phpの記述位置が間違っている（「編集が必要なのはここまで」の行より下に書いてしまった）可能性があります。どうしても出ない場合は、サーバーの管理画面にあるPHPのエラーログを確認する方法もあります。

Q. 「このサイトで重大なエラーが発生しました」という画面が出ます。真っ白とは違うのですか？

A. これは、WordPress自身が致命的エラーを検知して表示している画面で、完全な真っ白よりも一歩進んで原因が分かりやすい状態です。多くの場合、管理者メール宛に「どのプラグイン・テーマが原因か」と、一時的に問題のプラグインを止めて管理画面へ入れる復旧用リンクが届きます。まずは管理者メールの受信箱を確認してください。メールが届いていない場合は、この記事の手順（プラグイン停止・テーマ切替・WP_DEBUGでのログ確認）で同じように原因を切り分けられます。

Q. 作業が怖いです。安全に進めるコツはありますか？

A. いちばんのコツは「触る前にコピーを取る」「1箇所ずつ変える」「変えたらすぐ確認する」の3つです。ファイルはリネーム（退避）で無効化すれば、いつでも元に戻せます。削除ではなく退避を選ぶ、変更前のファイルを手元に保存しておく、という慎重な進め方なら、失敗しても取り返しがつきます。

まとめ

WordPressが真っ白になるトラブルは、初めて見ると強い不安を感じますが、原因は限られており、順番に切り分ければ多くは自力で直せます。大切なのは、焦ってやみくもにファイルをいじらず、まず「管理画面は開けるか」「全体か一部か」「直前に何をしたか」を整理することです。

そのうえでWP_DEBUGを有効にしてエラーを見える化し、プラグイン停止・テーマ切替・コードの復旧・.htaccess再生成・メモリ調整と、この記事の手順を上から試していけば、原因にたどり着けます。そして何より、更新前バックアップ・ステージング・子テーマといった予防策を習慣にすることで、真っ白トラブルそのものを減らせます。

・切り分けが最優先：まず「管理画面は開けるか」「全体か一部か」「直前の操作は何か」を整理する。原因が絞れれば対処は簡単。
・WP_DEBUGで見える化：真っ白の裏で起きているエラーは、WP_DEBUGを有効にしてdebug.logを読めば分かる。ファイル名と行番号が犯人を教えてくれる。
・予防が最強：更新前バックアップ・ステージング・子テーマ・FTPでの編集を習慣にすれば、そもそも真っ白になりにくい。

エラーを自分で読み解き、原因を切り分けて直せる力は、WordPress運営はもちろん、Web制作全般で一生役立つスキルです。「なんとなくコピペ」から一歩進んで、コードの意味を理解できるようになると、トラブルは怖くなくなります。この記事で紹介したdebug.logの読み方やFTPでの操作も、その第一歩です。

とはいえ、独学ではこうした「エラーの読み方」や「切り分けの考え方」でつまずきやすいのも事実です。手を動かしながら、体系立てて学べる環境があると、習得のスピードは大きく変わります。WithCodeでは、こうしたトラブル対応の前提になる実践的なスキルを、未経験からでも段階的に身につけられます。真っ白トラブルを「自分で直せた」という経験は、確かな自信につながるはずです。

WithCodeを体験できる初級コース公開中！

初級コース(¥49,800)が完全無料に！

期間：1週間
学習内容：
ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
→ 正しい学習方法で「確かな成長」を実感できるカリキュラム。

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！

公式サイトから無料カウンセリングに申し込む →

この記事を書いた人

田中誠

WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。