Webサイトのお助け隊

アドレスを開くと、ブラウザには何も出ません。エラーメッセージすらなく、ソースを見ても中身が空。この状態が一番やっかいなのは、手がかりが画面上にゼロだからです。404や500なら、少なくとも「サーバーは動いていて何かを返している」と分かりますが、真っ白は何も教えてくれません。ただ、白い画面そのものは原因ではなく結果です。PHPが処理の途中で致命的エラーを起こして止まり、本番環境ではエラー表示がオフになっているので画面に何も出ない。それだけのことです。原因はテーマ、プラグイン、PHPのバージョン、ファイルの破損の4系統に、ほぼ収まります。上から順に潰していけば必ず当たります。実際の復旧で踏んだ順序で書きます。

まず「どこが白いか」を確定する

手を動かす前に、白くなっている範囲を確定してください。ここで切り分けの入口が変わります。フロントも管理画面も全部白いのか。フロントだけ白くて管理画面には入れるのか。管理画面は開くけれど、投稿の編集画面など特定のページだけが白いのか。この3つは原因の系統が違うので、同じ手順を踏むのは無駄です。

並行して、エラーの中身を取りにいきます。多くの共用レンタルサーバーはコントロールパネルからエラーログを参照できます。PHP Fatal error: Uncaught Error: Call to undefined function ... のような1行が出ていれば、そこにファイル名と行番号が書いてあります。これが取れた時点で、切り分けの大半は終わりです。

ログが見当たらない場合は、wp-config.php に定数を足してWordPress側に吐かせます。公開中のサイトで画面にエラーを出すと訪問者にも見えてしまうので、表示はオフのまま、ファイルに落とす設定にします。WP_DEBUG を true、WP_DEBUG_DISPLAY を false、WP_DEBUG_LOG を true にすると、wp-content/debug.log にエラーが書き出されます。調査が終わったら必ず元に戻してください。

直前に何をしたかを聞けば、探す範囲は半分になる

白画面の相談で最初に確認するのは、落ちる直前に何をしたかです。これが分かるだけで、探す範囲がまるごと半分に減ります。

「プラグインを更新している最中に落ちた」なら、犯人は直近で更新したプラグインです。他を疑う必要はありません。管理画面にも入れない状態なら、FTPかサーバーのファイルマネージャで wp-content/plugins/ を開き、該当プラグインのディレクトリ名を変えてしまいます。先頭にアンダースコアを付けて _プラグイン名 のようにするだけで十分です。WordPressは実体のないプラグインを自動的に無効化するので、これでサイトが戻ります。管理画面に入れないときの最速の復旧手段がこれです。

夜間にプラグインを更新した直後、サイトが表示されなくなり管理画面にも入れなくなった、という緊急の相談を受けたことがあります。やったのはまさにこの操作で、該当プラグインのディレクトリをリネームして強制的に無効化し、1時間ほどで表示が戻りました。復旧そのものは単純な作業です。

どのプラグインか分からない場合は、wp-content/plugins ディレクトリごとリネームします。全プラグインが一括で無効化されます。これで表示が戻れば、原因がプラグインのどれかであることが確定します。あとはディレクトリ名を元に戻し、管理画面から1つずつ有効化していけば、再現するものが必ず見つかります。手間はかかりますが、確実です。

「テーマの functions.php を編集した直後に落ちた」という申告なら、次のセクションの話になります。編集の内容そのものより、どのファイルを編集したのかを先に確認してください。

ファイルそのものが壊れている二つの型

functions.php の取り違えと、コアファイルの破損

サイトが真っ白になったという相談で調べたところ、WordPressの wp-includes/functions.php が、テーマの functions.php の内容に丸ごと置き換わっていた案件があります。テーマのファイルを編集したつもりで、階層を見誤って別のファイルを上書きしていたわけです。FTPクライアントやサーバーのファイルマネージャでディレクトリを見間違えると、驚くほど簡単に起きます。WordPressの中には functions.php という名前のファイルが複数あり、片方はコア、片方はテーマ。名前は同じです。

復旧はすぐでした。同じバージョンのWordPressを公式サイトから落としてきて、wp-includes/functions.php を正規版で上書きするだけです。数分で表示が戻りました。白画面や致命的エラーの調査では、原因を突き止めるより先に「コアファイルを正規版で上書きしたら直るか」を試すほうが早いことが多く、特に wp-includes/functions.php と wp-config.php は事故の多い場所です。差し替えるときは wp-content ディレクトリと wp-config.php だけ残して、それ以外を同一バージョンの正規ファイルで上書きします。

ちなみに、置き換わっていたファイルの中身からは元のテーマ名も特定できました。テーマのファイルにはヘッダーコメントが入っていますし、関数名にテーマ固有の接頭辞が付いています。hestia_ のような形です。何が起きたかを説明する材料としては十分でした。

ただ、この復旧には副作用があります。コアファイルが差し替えられていたということは、元のテーマ側に書いてあった編集内容が失われているということです。「サイトは動くようになったが、見た目が前と違う」という状態になりえます。実際この案件でも、復旧の直後にトップページの見た目が変わったという指摘を受けました。それが復旧作業によるものなのか、もともとそうだったのかを客観的に示すには、着手前の記録が要ります。障害対応では、触る前に画面のスクリーンショットとファイルのバックアップを取っておいてください。数十秒の作業で、後の押し問答がなくなります。

なお、この案件では誰がいつファイルを差し替えたのかは特定できていません。依頼者本人なのか、別の作業者なのかは分からないままです。分からないことを推測で断定して伝えると、あとで話がこじれます。

1文字の混入でサイト全体が止まる

もうひとつ、原因の規模と症状の重さが釣り合わない例を挙げます。「サイトの表示がおかしい、身に覚えのない文字が出ている」という相談で、原因は wp-config.php に紛れ込んだ1文字でした。

PHPファイルの中で、PHPの終了タグ ?> より後ろに書かれた文字や、ファイル冒頭のBOM・空白・記号は、PHPコードとして解釈されません。そのままHTMLとして出力されます。結果として、ページの一番上に点や記号が表示される。あるいは Warning: Cannot modify header information - headers already sent by ... が出て、リダイレクトやCookieの発行が効かなくなる。ログインもできなくなり、サイト全体が使えない状態になります。数文字の混入でここまで行きます。

この種の症状が出たとき、テーマファイルを延々と追うのは遠回りです。犯人になりやすい場所には優先順があります。

1. wp-config.php の、PHPタグの外にある文字
2. テーマの functions.php の末尾、?> より後ろの空行や文字
3. プラグインファイルの同様の混入
4. BOM付きUTF-8で保存されたPHPファイル

見つけ方は単純で、差分を見ることです。設定ファイルを編集する前にコピーを取っておき、編集後に差分だけを確認すれば、この種の混入は一瞬で見つかります。バックアップがないと、目視で全行を追うか、ファイルの末尾に不要な空行がないかを1ファイルずつ確かめることになります。編集の前にコピーを取る、という習慣だけで防げます。予防としてもうひとつ、PHPだけが書かれたファイルの末尾には終了タグを書かない、という書き方があります。WordPressのコーディング規約でも推奨されている形で、書かなければ後ろに文字が混入する余地がなくなります。

この案件では、なぜその1文字が入ったのかまでは特定できていません。設定ファイルを触った作業の記録が残っていれば、いつ入ったかの切り分けができます。複数の人がサーバーに触れる体制なら、なおさら記録が要ります。

投稿画面だけが真っ白になるとき

フロントは問題なく表示され、管理画面のダッシュボードにも入れる。ところが投稿の編集画面を開いた瞬間だけ真っ白になる。この相談を受けたことがあります。

この形は、そのページで読み込まれるコードが、いま動いているPHPのバージョンで致命的エラーを起こしているパターンです。テーマやプラグインが古いまま止まっているところに、サーバー側のPHPが上がると起きます。全体が落ちないのは、そのコードが編集画面でしか読み込まれないからです。管理画面の一部だけが白い、という症状を見たら、テーマとプラグインのバージョン、そして現在のPHPバージョンの組み合わせを最初に疑ってください。

この案件は、使っていたテーマを最新版に更新することで解消しました。ただし、ここには注意点があります。テーマのメジャーバージョンアップは、デザインの変更を伴います。文字や色合いが変わる可能性があり、その復元は不具合の修正とは別の作業になる、と事前に伝えておく必要がありました。実際、更新後に色合いが変わったという指摘を受けています。さらに、テーマの設定画面から従来できていたカスタマイズ、たとえば文字色の変更ができなくなることもあります。新旧で設定項目の場所や仕様が変わるためです。更新する前に、テーマ設定でどんなカスタマイズをしていたかを控えておいてください。

依頼者自身に作業してもらう場合は、「バックアップを取る」「更新する」「確認する」の3ステップに分解して、バックアップと復元の手段を具体的な名前で示します。この案件では、All-in-One WP Migration のバックアップ作成機能でファイルを作ってもらい、万が一のときはインポートで戻す、という形にしました。手順を抽象的に伝えるより、画面上のボタンの名前まで指定したほうが確実に完了します。

上から順に潰す順序と、繰り返さないための運用

ここまでの内容を、実際に手を動かす順番に並べ直します。上から試して、直った時点でそこが原因です。

7番まで到達しても直らない、あるいは直したはずのものが元に戻る場合は、系統が違う可能性があります。身に覚えのないファイルが増えていないか、.htaccess が書き換えられていないかを確認してください。白画面に見えて実体が改ざんだった、という例は珍しくありません。画面が白ではなくサーバーのエラー画面として返っているなら500 Internal Server Errorの原因を絞り込む順番、ログイン画面の周辺で止まっているならwp-adminに入れない時の対処、リダイレクトループと白紙の画面、アクセス自体が拒否されているなら403 Forbiddenが出る時の原因、サーバーWAFとパーミッションが、それぞれ対応する切り分けになります。

同じことを繰り返さないための運用

白画面の相談の多くは、更新作業がきっかけです。だから予防策も更新の仕方に集約されます。プラグインの更新は、バックアップを取ってから、1つずつ行ってください。まとめて更新すると、落ちたときに犯人が分からず、結局すべてを退避して1つずつ戻す作業が発生します。1つずつ更新して都度表示を確認すれば、壊れた瞬間にどれが原因か確定します。

入れるプラグインの数そのものを減らすことも効きます。プラグインは1つ増えるごとに、更新のたびに壊れる可能性が増えます。検索からの流入をあまり重視していないサイトにSEO関連のプラグインを入れておくような場合、得られる機能より障害のリスクのほうが上回ることがあります。入れておけば安心、というものではありません。使っていないプラグインは無効化ではなく削除してください。

それでも、更新を止めるという選択肢は取れません。古いバージョンを放置すれば別のリスクが増えます。更新作業を自分でやりたくないなら、まとめて引き受ける形にするのが現実的です。WordPress保守の対応内容では、更新前のバックアップ取得と更新後の表示確認までを一続きで行っています。

よくある質問

管理画面にも入れません。どこから手を付けますか

FTPかサーバーのファイルマネージャが使えるかどうかで分かれます。使えるなら wp-content/plugins のリネームが最速で、これで戻ればプラグイン起因が確定します。使えないなら、まずサーバーのコントロールパネルにログインしてエラーログを確認するところからです。どちらにもアクセスできない状態なら、サーバー会社に契約者としてアカウントの再発行を依頼するのが先で、ここで時間を取られるケースが実際にあります。

エラーログに何も出ていません

PHPの致命的エラーではなく、メモリの上限や実行時間の超過で途中終了している可能性があります。ログの出力先がコントロールパネルから見える場所とは限らないので、WP_DEBUG_LOG を有効にして wp-content/debug.log に出させてください。それでも空なら、PHPまで処理が届いていないことも考えられます。白い画面ではなくブラウザがエラーページを表示している場合は、系統が違います。

プラグインを無効化したら直りました。入れ直すべきですか

そのプラグインが本当に必要かどうかから考えてください。実際、無効化したまま入れ直さずに解決した案件があります。必要な機能なら、なぜ更新で壊れたのかを先に調べます。多くはPHPのバージョンとの相性か、他のプラグインとの競合です。原因を確かめずに同じものを入れ直せば、次の更新でまた同じことが起きます。

PHPのバージョンを戻せば直りますか

一時的には直ることが多いです。応急処置としては有効なので、公開中のサイトを急いで戻す場面では選択肢になります。ただし恒久策にはできません。サポートの終わったPHPを使い続けると、脆弱性の修正が提供されなくなり、別の問題を抱え込みます。バージョンを戻すのは時間を稼ぐためと割り切って、その間にテーマとプラグインを新しいPHPで動くものに揃えるのが本筋です。