2026年5月21日

2026年5月21日

WordPressのページが真っ白でHTMLが出ないときの原因の調べ方と直し方

WordPress のページが真っ白になり、ブラウザで「ページのソースを表示」しても HTML がほとんど出ていない状態は、多くの場合 PHP の処理が途中で止まっています。PHP のエラーが画面に出ない設定(本番サーバーの通常の設定)だと、エラーの内容が見えないまま白い画面だけが残ります。

この記事では、原因を推測で直すのではなく、エラーの記録を見て原因を特定する順番で説明します。

まず状態を確認する

HTTP ステータスを見る

白い画面でも、サーバーが返しているステータスによって調べる場所が変わります。ブラウザの開発者ツールの「ネットワーク」タブか、curl で確認します。

# レスポンスのヘッダーだけを表示する(example.com は自分のサイトに置き換える)
curl -I https://example.com/
ステータス 考えられること
500 PHP の致命的なエラー、.htaccess の書き間違いなど。サーバー側のエラーログに記録がある
200 で本文が空 PHP は最後まで動いたが何も出力していない(テーマのテンプレートが空、キャッシュに空のページが保存されたなど)
502 / 503 / 504 PHP-FPM の停止や処理の時間切れ。WordPress より手前のサーバー側の問題

「重大なエラー」の表示とメールを確認する

WordPress 5.2 以降には致命的なエラーから守る仕組み(リカバリーモード)があり、PHP の致命的なエラーが起きると、真っ白な画面ではなく「このサイトで重大なエラーが発生しました」という表示になります。同時に、サイトの管理者メールアドレス(「設定」→「一般」)に、原因のプラグインやテーマの名前と、リカバリーモードでログインするためのリンクが届きます。

メールが届いていれば、リンクからログインして、原因として書かれたプラグインやテーマを停止します。メールが届かない、あるいは本当に真っ白な画面の場合は、次のエラーログの確認に進みます。

エラーの記録を見る

WordPress のデバッグログを有効にする

wp-config.php を FTP やファイルマネージャーで開き、/* That's all, stop editing! Happy publishing. */(「編集が必要なのはここまでです」)の行より前に次の行を加えます。すでに define( 'WP_DEBUG', false ); がある場合は、その行を書き換えます(同じ定数を2回定義すると警告が出ます)。

<?php
// デバッグを有効にする
define( 'WP_DEBUG', true );
// エラーを wp-content/debug.log に記録する
define( 'WP_DEBUG_LOG', true );
// エラーを画面には出さない(訪問者に内部の情報を見せないため)
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

保存したら、白くなるページをもう一度開きます。wp-content/debug.log に記録が追加されるので、最後のほうにある PHP Fatal error の行を探します。

PHP Fatal error:  Uncaught Error: Call to undefined function example_function() in /var/www/html/wp-content/plugins/example-plugin/example.php:25

この例なら、example-plugin プラグインの example.php の25行目が原因です。パスに含まれる plugins/プラグイン名 や themes/テーマ名 から、どのプラグイン・テーマかが分かります。

debug.log は初期設定ではブラウザから開ける場所に作られます。原因が分かったら、上の行を元に戻し(WP_DEBUG を false にする)、debug.log を削除してください。

サーバーのエラーログを見る

debug.log に何も記録されない場合は、WordPress が読み込まれる前(wp-config.php の書き間違いなど)か、WordPress の外(.htaccess、PHP の設定)でエラーが起きています。サーバーのエラーログを確認します。

  • レンタルサーバー: コントロールパネルの「エラーログ」「アクセス解析」などのメニュー
  • Apache(Debian / Ubuntu): /var/log/apache2/error.log
  • nginx: /var/log/nginx/error.log(PHP-FPM 自体のログは別のファイル)
# 最後の50行を表示する(パスはサーバーに合わせる)
sudo tail -n 50 /var/log/apache2/error.log

原因を切り分ける

エラーログで原因が分からない場合や、管理画面に入れない場合は、プラグインとテーマを順に外して切り分けます。

プラグインをすべて止める

FTP などで wp-content/plugins フォルダーの名前を plugins_off のように変えると、すべてのプラグインが読み込まれなくなります。これでページが表示されれば、原因はプラグインです。

フォルダー名を変えたまま管理画面の「プラグイン」を開くと、ファイルが見つからないプラグインは WordPress が無効にします(「エラーのためプラグインを停止しました」という表示が出ます)。そのあとフォルダー名を plugins に戻すと、プラグインは無効の状態で一覧に戻るので、1つずつ有効にし、白い画面に戻ったところが原因です。

特定のプラグインが疑わしい場合は、そのプラグインのフォルダー(wp-content/plugins/プラグイン名)だけ名前を変えます。

WP-CLI が使えるサーバーなら、コマンドでも同じことができます。

# プラグインとテーマを読み込まずに、有効なプラグインの一覧を表示する
wp plugin list --status=active --skip-plugins --skip-themes

# すべてのプラグインを無効にする
wp plugin deactivate --all --skip-plugins --skip-themes

# 疑わしいプラグインだけを無効にする(example-plugin は実際の名前に置き換える)
wp plugin deactivate example-plugin --skip-plugins --skip-themes

テーマを標準テーマに切り替える

プラグインを止めても直らない場合は、テーマを疑います。使用中のテーマのフォルダー(wp-content/themes/テーマ名)の名前を変えてから管理画面の「外観」→「テーマ」を開くと、WordPress はテーマが壊れていると判断し、インストール済みの標準テーマ(Twenty Twenty-Five など)に切り替えます。標準テーマが1つも入っていないと切り替わらないので、その場合は FTP で WordPress.org の標準テーマを wp-content/themes にアップロードしておきます。

WP-CLI では次のように切り替えます。

# インストール済みのテーマを確認する
wp theme list --skip-plugins --skip-themes

# 標準テーマに切り替える(一覧にあるテーマ名を指定する)
wp theme activate twentytwentyfive --skip-plugins --skip-themes

子テーマを使っている場合は、子テーマの functions.php に追加したコードが原因のこともあります。

よくある原因と直し方

PHP のバージョンを上げた直後

古いプラグインやテーマが、新しい PHP で削除された関数や書き方を使っていると、致命的なエラーになります。エラーログに出たプラグイン・テーマを更新するか、更新が止まっているものは代わりのものに入れ替えます。すぐに直せない場合は、サーバーのコントロールパネルで PHP のバージョンを一時的に元に戻し、その間に入れ替えを進めます。

メモリ不足

ログに Allowed memory size of ... bytes exhausted と出ている場合は、PHP が使えるメモリの上限に達しています。wp-config.php で WordPress が使う上限を上げられます(PHP 側の memory_limit より大きくはできません)。

<?php
define( 'WP_MEMORY_LIMIT', '256M' );

上限を上げても繰り返す場合は、メモリを大量に使っているプラグインがないかを切り分けで確認します。

.htaccess の書き間違い

Apache のサーバーで、すべてのページが 500 エラーになる場合は .htaccess を確認します。WordPress の部分の標準の内容は次のとおりです(WordPress を公開ディレクトリの直下に置いている場合)。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

切り分けるときは、.htaccess を .htaccess_old のように名前を変えて退避し、トップページが表示されるかを確かめます。表示されたら、管理画面の「設定」→「パーマリンク」で何も変えずに「変更を保存」を押すと、WordPress が .htaccess を書き直します(ファイルに書き込める権限がある場合)。nginx のサーバーでは .htaccess は使われません。

ファイルの権限と所有者

ファイルを移行したあとや、サーバーの設定を変えたあとに白くなった場合は、権限を確認します。一般的な値は、ファイルが 644、ディレクトリが 755 です。

# WordPress のディレクトリで実行する(/var/www/html は実際の場所に置き換える)
cd /var/www/html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

所有者をウェブサーバーのユーザーにするかどうか(www-data など)はサーバーの構成によって変わります。レンタルサーバーでは所有者を変える必要はなく、変えられないことがほとんどです。

キャッシュに空のページが残っている

ステータスが 200 で本文が空の場合、キャッシュプラグインやサーバーのキャッシュに、エラー中の空のページが保存されていることがあります。原因を直したあとも白いままなら、キャッシュを削除してから確認します。

注意事項

  • wp-config.php やフォルダー名を変える前に、元のファイルをパソコンにコピーしておいてください。
  • WP_DEBUG_DISPLAY を true にすると、エラーの中のファイルのパスなどが訪問者にも見えます。本番サイトでは画面に出さず、ログに記録する設定で調べます。
  • 調べ終わったら WP_DEBUG を false に戻し、debug.log を削除します。

まとめ

  • curl -I などで HTTP ステータスを見て、500 ならエラーログ、200 で空ならテーマやキャッシュを疑う。
  • WP_DEBUG_LOG で wp-content/debug.log に記録し、PHP Fatal error の行からプラグイン・テーマを特定する。記録が無ければサーバーのエラーログを見る。
  • 管理画面に入れなければ、フォルダー名の変更か WP-CLI の --skip-plugins --skip-themes で切り分ける。
  • 原因が分かったら、デバッグの設定を元に戻す。

関連記事:

お気軽にご相談ください

お見積りへ お問い合わせへ
▲