WordPressのサイトが表示されないときは、画面に何が出ているかで原因の場所を絞り込めます。
真っ白なのか、エラーの文言が出ているのかで、調べる場所が変わります。
| 画面の見た目 | 原因の場所 | 最初に見るところ |
|---|---|---|
| 真っ白で何も出ない | PHPの構文エラー、ファイルの権限 | 直前に編集したPHPファイルと、サーバーのエラーログ |
| 「このサイトで重大なエラーが発生しました」 | プラグイン・テーマ | 管理者宛てのメール |
| 「データベース接続確立エラー」 | wp-config.phpの接続情報、データベース | wp-config.phpの4つの値 |
| サーバー会社の403・500のページ | サーバーの設定、.htaccess、権限 | 直前に書き換えた.htaccess |
| トップは見えるのに記事が開かない | キャッシュの裏で起きているエラー | ログアウトして別のURLを開く |
当方の検証用WordPress（WordPress 7.1.4、PHP 8.3、2026年10月30日）で、5つの状態を実際に起こして確かめました。
真っ白の画面は、HTMLが1文字も返っていない状態で、状態コードは500でした。
この記事は、自分で運営しているWordPressが急に表示されなくなった方に向けて書きました。
見た目ごとの原因、真っ白の調べ方、表示を戻す手順、一部だけ表示されないときの順に説明します。
WordPressが表示されないときは見た目で5つに分ける
同じ「表示されない」でも、画面に出ているものは5通りありました。
真っ白で何も出ない
wp-config.phpに構文エラーのある1行を書き足すと、表側も管理画面もこの真っ白な画面になりました。
何も出ないのは、サーバーの設定でPHPのエラーを画面に出さない（display_errorsがOff）ときです。
「重大なエラーが発生しました」と出る
プラグインやテーマが致命的なエラーを起こすと、WordPressがこの画面を出します。
管理者宛てに原因のプラグイン名を書いたメールが届くので、まずはメールを確かめてください。
詳しい直し方は、WordPressの「重大なエラー」を直す手順にまとめています。
「データベース接続確立エラー」と出る
データベースの接続先を誤ると、この1行だけの画面になり、状態コードは500でした。
直し方は、後ろの「データベースにつながらないとき」で説明します。
サーバー会社のエラーページが出る
青い403や500のページは、WordPressの手前でサーバーが出している画面です。
検証では、.htaccessに存在しない命令を1行書くと500の青いページ、権限のないファイルを開くと403の青いページになりました。
原因と直し方は、403 Forbiddenの直し方と500エラーの直し方に分けてまとめています。
真っ白になる原因を確かめる
真っ白は画面に手がかりが何も出ないので、調べる順番を決めておくのが大事です。
HTMLが空か、状態コードを見る
ブラウザーでページのソースを表示して、HTMLが空かどうかを確かめます。
状態コードは、curlコマンドか、ブラウザーの開発者ツールのネットワーク欄で見られます。
curl -I https://example.com/
# 1行目の「HTTP/2 500」などが状態コード検証で真っ白になったときは、本文が0バイト、状態コードは500でした。
当方の再現1：wp-config.phpの1行の構文エラー
wp-config.phpに次の1行を書き足すと、サイト全体が真っ白になりました。
$lab_broken = ; // 値が無いので構文エラーになるwp-config.phpはどのページでも最初のほうで読み込まれるため、表側も管理画面も同時に止まります。
複製しておいた元のファイルに戻すと、すぐに表示が戻りました。
当方の再現2：index.phpの権限を000にした
index.phpのパーミッションを000にした場合も、403ではなく真っ白の500になりました。
見た目は構文エラーのときと区別がつかないので、ファイルの権限も確かめます。
推奨されている値は、ファイルが644、フォルダーが755か705です（エックスサーバー マニュアル「パーミッション」、2026年10月30日確認）。
display_errorsがOnだと、エラーの全文が出る
サーバーのPHPの設定でdisplay_errorsがOnだと、重大なエラーの画面の上に、エラーの全文が出ました。
原因のファイルと行番号がわかる一方で、サーバー上のフォルダーの場所が訪問者にも見えます。
調べ終わったら、Offに戻すか、ログに書き出す方法に切り替えてください。
PHPの公式マニュアルも、display_errorsは開発用で、本番のシステムでは使わないよう注意しています。
出典：実行時設定（PHP マニュアル、2026年10月30日確認）
エラーログで原因のファイルを見つける
真っ白で何も出ないときは、ログに原因が残っていることがあります。
サーバーのエラーログ
エックスサーバーでは、サーバーパネルの「エラーログ」から、ドメインごとのログを表示・ダウンロードできます。
公式マニュアルによると、ログは毎日午前3時ごろに、過去7日分が日別に作られる仕組みです。
出典：エラーログ（エックスサーバー マニュアル、2026年10月30日確認）
ほかのサーバー会社でも、管理画面にエラーログを見る項目があることが多いので、名前を探してみてください。
WordPressのデバッグログ
WordPressには、エラーを画面に出さずに、ファイルへ書き出す設定があります。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );書き出し先は、標準ではwp-content/debug.logです。
公式ドキュメントは、これらの設定を公開中のサイトで使うことを勧めていないので、調べ終わったら元に戻します。
出典：Debugging in WordPress（WordPress Developer Resources、2026年10月30日確認）
wp-config.phpそのものが壊れているときは、この設定も読まれないため、サーバーのエラーログを見ます。
設定の詳しい手順とログの読み方は、WordPressのエラーログの場所と出力方法をご覧ください。
表示を戻す手順（触る前に複製を取る）
直す作業でさらに壊さないよう、触るファイルは先に複製します。
直前に触ったファイルを元に戻す
編集した直後に真っ白になったなら、そのファイルを元に戻すのが早道です。
# 触る前に複製しておく
cp wp-config.php wp-config-bak-20261030.php
cp .htaccess .htaccess.bak-20261030
# 戻すときは、複製を元の名前で上書きする
cp wp-config-bak-20261030.php wp-config.phpwp-config.phpの複製は、名前の最後を.phpのままにしておきます。
最後が.phpでないと、サーバーによってはURLから中身を読まれるおそれがあるためです。
プラグインを止める
管理画面に入れないときは、プラグインのフォルダー名を変えると、そのプラグインを読み込ませないようにできます。
WordPressの公式ドキュメントも、FTPでフォルダー名を変えて一時的に止める方法を案内しています。
出典：Recovery Mode（WordPress.org Documentation、2026年10月30日確認）
# 1つだけ止める（戻すときは元の名前にして、管理画面で有効化し直す）
mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name-off
# WP-CLIが使える場合
wp plugin deactivate plugin-nameWP-CLIもwp-config.phpを読み込むので、wp-config.phpが壊れているときは先にそちらを直します。
当方の検証では、同じ関数名を使う2つ目のプラグインを有効にしようとすると、有効化の時点で止められ、サイトは落ちませんでした。
管理画面に入れる場合は、Health Check & Troubleshootingのトラブルシューティングモードを使うと、自分だけプラグインを止めた状態で原因を探せます。
訪問者の表示には影響しないと、プラグインの画面に書かれていました。
mu-plugins（自動で読み込まれるプラグイン）は、このモードでも止まらないとも書かれています。
配布元：Health Check & Troubleshooting（WordPress.org、2026年10月30日確認）
テーマを既定のものに戻す
テーマを変えた直後や、テーマのファイルを編集した直後なら、テーマを疑います。
公式ドキュメントは、既定のテーマに切り替えるか、使っているテーマのフォルダー名を変える方法を案内しています。
出典：Common WordPress Errors（WordPress Developer Resources、2026年10月30日確認）
子テーマのfunctions.phpを編集していたなら、そのファイルだけを複製から戻すほうが早く済みます。
データベースにつながらないとき
「データベース接続確立エラー」なら、確かめるのはwp-config.phpの4つの値です。
define( 'DB_NAME', 'データベース名' );
define( 'DB_USER', 'ユーザー名' );
define( 'DB_PASSWORD', 'パスワード' );
define( 'DB_HOST', 'ホスト名' );公式ドキュメントは、値が正しい場合はデータベースの容量超過やサーバーの障害も考えられるとして、サーバー会社への問い合わせを勧めています。
当方の検証用WordPressはデータベースにSQLiteを使っているため、この画面はMySQLの誤った接続情報に向け直して再現しました。
一部の人・一部のページだけ表示されないとき
全部が止まっていなくても、見る人や見るページによって表示されないことがあります。
トップは見えるのに記事が開かない
プラグインのエラーでサイトが止まっている間も、検証用のWordPressではトップページだけが普段どおりの表示でした。
サーバーのキャッシュが、壊れる前のトップページを返していたためです。
同じ時間に記事のURLを開くと、500の重大なエラーでした。
「自分では見えるのに、ほかの人には見えない」「トップは見えるのに記事が開かない」は、こうしたときに起こりうる見え方です。
エックスサーバーのサーバーキャッシュは、ログイン中のCookieがあるアクセスや管理画面をキャッシュしないと案内されています。
出典：サーバーキャッシュ設定（エックスサーバー マニュアル、2026年10月30日確認）
確かめるときは、ログアウトした状態で、トップ以外のURLも開きます。
管理画面と表側で文言が違う
重大なエラーの文言は、表側と管理画面で違いました。
管理画面の文言は、サイト管理者のメールで手順を確かめるよう求めるものでした。
管理画面の一部だけが真っ白になる場合は、ウィジェットメニューが真っ白で表示されないときやSWELLの表示が崩れるときも参考にしてください。
記事の保存だけ失敗する
表示はできるのに、記事の保存で「返答が正しい JSON レスポンスではありません」と出ることもあります。
検証では、プラグインが出したPHPの警告がREST APIの応答の先頭に混ざり、保存が失敗しました。
警告を出しているプラグインを止めると、保存できるようになりました。
表示が戻ったあとに確かめること
表示が戻ったら、次の4つを確かめます。
- ログアウトした状態や別のブラウザーで、トップ以外のページも開けるか
- 記事の保存、問い合わせフォーム、ログインが動くか
- 一時的に止めたプラグインや、デバッグの設定を元に戻したか
- 作った複製のファイルを消したか
止めたプラグインを戻すときは1つずつ有効にして、そのたびに表示を確かめてください。
原因がわからない場合は、表示されないURL、日時、直前に変えたこと、エラーログの該当行をそろえて相談しましょう。
自分で直すのが難しいときの相談先として、MOTOKIのサービスもご利用ください。
まとめ
WordPressが表示されないときは、真っ白か、エラーの文言が出ているかで原因の場所を分けます。
- 真っ白は、PHPの構文エラーや権限の誤りで、サーバーのエラーログを見る
- 重大なエラーは、プラグインかテーマで、管理者宛てのメールを見る
- データベース接続確立エラーは、wp-config.phpの接続情報を見る
- トップだけ見えるときはキャッシュを疑い、ほかのURLも開く
どの場合も、触る前に複製を取っておけば元に戻せます。
