WordPress サイトが突然真っ白になったり、「500 Internal Server Error」が表示されたりすると、心臓が止まりそうになりますよね。でも安心してください。これらのエラーは WordPress ではよくあるトラブルで、適切な順序で確認していけば、ほとんどの場合は解決できます。

この記事では、WordPress のホワイトスクリーンや 500 エラーに遭遇したときに、最初に確認すべきポイントを順番に解説していきます。焦らず、一つずつチェックしていきましょう。

背景

WordPress は世界中の Web サイトの約 43% で利用されている人気の CMS（コンテンツ管理システム）です。しかし、その柔軟性と拡張性の高さゆえに、プラグインやテーマ、PHP のバージョン、サーバー設定など、多くの要素が複雑に絡み合っています。

以下の図は、WordPress サイトが正常に動作するために必要な主要コンポーネントの関係を示しています。

mermaidCopy codeflowchart TB
  user["訪問者"] -->|リクエスト| webserver["Web サーバー<br/>(Apache/Nginx)"]
  webserver -->|PHP 実行| php["PHP エンジン"]
  php -->|読み込み| wpcore["WordPress コア"]
  wpcore -->|利用| theme["テーマファイル"]
  wpcore -->|利用| plugins["プラグイン群"]
  wpcore -->|クエリ| db[("データベース<br/>(MySQL/MariaDB)")]
  db -->|データ| wpcore
  wpcore -->|HTML 生成| php
  php -->|レスポンス| webserver
  webserver -->|表示| user

図で理解できる要点：

• WordPress は複数のコンポーネント（サーバー、PHP、コア、テーマ、プラグイン、DB）が連携して動作します
• どこか 1 つでも問題が発生すると、サイト全体が表示できなくなる可能性があります
• エラー解決には、問題のある箇所を特定することが重要です

このように多くの要素が関わるため、どこか一箇所でも問題が発生すると、サイト全体が表示されなくなることがあります。

課題

WordPress でホワイトスクリーンや 500 エラーが発生する主な原因は以下の通りです。

#	原因	発生頻度	深刻度
1	PHP メモリ不足	★★★	中
2	プラグインの競合・不具合	★★★★	高
3	テーマファイルの問題	★★★	高
4	PHP バージョンの非互換	★★	中
5	データベース接続エラー	★★	高
6	ファイルパーミッション設定ミス	★	中
7	.htaccess ファイルの破損	★★	中

これらのエラーが厄介なのは、エラーメッセージが表示されないことが多い点です。真っ白な画面や、単に「500 Internal Server Error」としか表示されず、何が原因なのか分からないまま途方に暮れてしまうことがよくあります。

以下の図は、エラー発生から問題特定までの一般的な流れを示しています。

mermaidCopy codeflowchart LR
  error["エラー発生"] -->|画面確認| check1["ホワイトスクリーン?"]
  check1 -->|はい| log1["エラーログ確認"]
  check1 -->|いいえ| check2["500 エラー?"]
  check2 -->|はい| log1
  check2 -->|いいえ| other["別のエラー対応"]
  log1 -->|ログあり| identify["原因特定"]
  log1 -->|ログなし| manual["手動切り分け"]
  identify --> fix["修正作業"]
  manual --> fix

図で理解できる要点：

• エラーの種類によって対応方法が異なります
• エラーログが最も重要な手がかりになります
• ログがない場合は手動で一つずつ切り分ける必要があります

解決策

ホワイトスクリーンや 500 エラーを解決するための基本的なアプローチは、問題を段階的に切り分けていくことです。以下、優先度の高い順に確認すべきポイントを解説します。

エラーログの確認

最初に行うべきは、エラーログの確認です。エラーログには問題の原因が詳細に記録されています。

WordPress のエラーログは主に以下の場所に保存されます。

#	ログの種類	保存場所
1	WordPress デバッグログ	​/​wp-content​/​debug.log
2	PHP エラーログ	サーバー設定による（​/​var​/​log​/​php-error.log など）
3	Web サーバーログ	Apache: ​/​var​/​log​/​apache2​/​error.logNginx: ​/​var​/​log​/​nginx​/​error.log

WordPress デバッグモードの有効化

WordPress のデバッグモードを有効にすると、詳細なエラー情報を取得できます。wp-config.php ファイルを編集して、以下の設定を追加または変更してください。

phpCopy code<?php
// wp-config.php の編集（デバッグモード設定部分）

// デバッグモードを有効化
define( 'WP_DEBUG', true );

上記の設定で WordPress のデバッグモードを有効にします。これにより、エラーが発生した際に画面上に警告やエラーメッセージが表示されるようになります。

phpCopy code// エラーメッセージを画面に表示（本番環境では false 推奨）
define( 'WP_DEBUG_DISPLAY', false );

本番環境では、エラーメッセージを訪問者に見せないため false に設定します。

phpCopy code// エラーをログファイルに記録
define( 'WP_DEBUG_LOG', true );

エラー情報を ​/​wp-content​/​debug.log ファイルに記録します。このファイルを確認することで、エラーの詳細を把握できます。

phpCopy code// WordPress のスクリプトとスタイルの圧縮版を使わない（デバッグ用）
define( 'SCRIPT_DEBUG', true );

JavaScript や CSS の圧縮されていないバージョンを読み込むため、フロントエンドのデバッグが容易になります。

エラーコード例：

javascriptCopy codePHP Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in /var/www/html/wp-includes/plugin.php:555

このようなエラーが debug.log に記録されていれば、プラグインファイルの 555 行目で未定義の関数が呼ばれていることがわかります。

プラグインの無効化

エラーログから原因が特定できない場合、次に疑うべきはプラグインの競合や不具合です。

すべてのプラグインを一括無効化する方法

管理画面にアクセスできない場合は、FTP や SSH でサーバーに接続し、プラグインフォルダの名前を変更します。

bashCopy code# SSH でサーバーに接続後、WordPress ルートディレクトリへ移動
cd /var/www/html

WordPress のインストールディレクトリに移動します。環境によってパスが異なる場合があるため、適宜変更してください。

bashCopy code# プラグインフォルダの名前を変更（一括無効化）
mv wp-content/plugins wp-content/plugins-disabled

plugins フォルダを plugins-disabled にリネームすることで、すべてのプラグインが一時的に無効化されます。

bashCopy code# サイトが復旧するか確認
# ブラウザでサイトにアクセスして確認

サイトにアクセスして、ホワイトスクリーンや 500 エラーが解消されたかチェックします。

原因プラグインの特定

サイトが復旧した場合、原因はプラグインにあります。次の手順で問題のあるプラグインを特定しましょう。

bashCopy code# プラグインフォルダを元に戻す
mv wp-content/plugins-disabled wp-content/plugins

まず、プラグインフォルダの名前を元に戻します。

bashCopy code# 個々のプラグインフォルダを一つずつリネーム
cd wp-content/plugins
mv suspicious-plugin suspicious-plugin-disabled

疑わしいプラグインを一つずつ無効化していきます。各プラグインを無効化するたびにサイトにアクセスし、エラーが再現するかを確認してください。

エラーコード例：

csharpCopy codePHP Fatal error: Cannot redeclare function custom_function() in /var/www/html/wp-content/plugins/my-plugin/my-plugin.php on line 42

この場合、my-plugin プラグインの 42 行目で関数の重複宣言が発生しています。該当プラグインを無効化することで問題が解決します。

テーマの切り替え

プラグインが原因でない場合、次はテーマファイルの問題を疑います。

データベースから直接テーマを変更

管理画面にアクセスできない場合、データベースを直接編集してデフォルトテーマに切り替えます。

sqlCopy code-- phpMyAdmin または MySQL コマンドラインで実行
-- まず現在のテーマを確認
SELECT * FROM wp_options WHERE option_name = 'template' OR option_name = 'stylesheet';

現在使用中のテーマを確認します。wp_options テーブルには WordPress のすべての設定が保存されています。

sqlCopy code-- テーマを WordPress デフォルトテーマ（Twenty Twenty-Four）に変更
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

template と stylesheet の両方を変更することで、親テーマと子テーマの両方がデフォルトテーマに切り替わります。

sqlCopy code-- 変更が反映されたか確認
SELECT * FROM wp_options WHERE option_name = 'template' OR option_name = 'stylesheet';

変更が正しく適用されたかを確認した後、サイトにアクセスしてエラーが解消されたかチェックします。

エラーコード例：

goCopy codePHP Parse error: syntax error, unexpected '}' in /var/www/html/wp-content/themes/my-theme/functions.php on line 128

テーマの functions.php に構文エラーがある場合、このようなエラーが発生します。

PHP メモリ制限の引き上げ

WordPress が処理中にメモリ不足になると、ホワイトスクリーンが発生することがあります。

wp-config.php でメモリ制限を増やす

phpCopy code<?php
// wp-config.php の編集（メモリ制限設定）
// 「編集が必要なのはここまでです」の直前に追加

// WordPress のメモリ制限を 256MB に設定
define( 'WP_MEMORY_LIMIT', '256M' );

WordPress が使用できるメモリの上限を 256MB に引き上げます。デフォルトは 40MB ですが、プラグインを多数使用している場合は不足することがあります。

phpCopy code// 管理画面のメモリ制限を 512MB に設定
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

管理画面では、より多くのメモリが必要になる場合があるため、上限を 512MB に設定します。

エラーコード例：

vbnetCopy codePHP Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/wp-includes/plugin.php on line 428

このエラーは、PHP のメモリ制限に達したことを示しています。上記の設定で解決できます。

データベース接続の確認

データベースに接続できない場合も、ホワイトスクリーンや 500 エラーが発生します。

wp-config.php の設定確認

phpCopy code<?php
// wp-config.php のデータベース設定部分を確認

// データベース名
define( 'DB_NAME', 'wordpress_db' );

データベース名が正しいかを確認します。レンタルサーバーのコントロールパネルで確認できます。

phpCopy code// データベースユーザー名
define( 'DB_USER', 'wordpress_user' );

データベースに接続するためのユーザー名を確認します。

phpCopy code// データベースパスワード
define( 'DB_PASSWORD', 'your_strong_password' );

パスワードが正しいか、特に最近変更していないか確認してください。

phpCopy code// データベースホスト
define( 'DB_HOST', 'localhost' );

多くの共有サーバーでは localhost ですが、専用サーバーやクラウドサービスでは異なる場合があります。

エラーコード例：

cssCopy codeError establishing a database connection

この画面が表示される場合、データベース接続情報が間違っているか、データベースサーバーがダウンしています。

.htaccess ファイルの確認

.htaccess ファイルが破損していると、500 エラーが発生することがあります。

.htaccess ファイルのリセット

bashCopy code# SSH でサーバーに接続後、WordPress ルートディレクトリへ移動
cd /var/www/html

WordPress のルートディレクトリに移動します。

bashCopy code# 現在の .htaccess をバックアップ
mv .htaccess .htaccess.backup

念のため、現在の .htaccess ファイルをバックアップします。

bashCopy code# サイトが復旧するか確認
# ブラウザでサイトにアクセスして確認

.htaccess がない状態でサイトが表示されるか確認します。表示される場合、.htaccess に問題があります。

復旧した場合は、WordPress 管理画面から「設定」→「パーマリンク設定」を開き、「変更を保存」ボタンをクリックすることで、新しい .htaccess ファイルが自動生成されます。

エラーコード例（サーバーログ）：

cssCopy code[alert] [client 192.168.1.1] /var/www/html/.htaccess: Invalid command 'RewriteEnginee', perhaps misspelled or defined by a module not included in the server configuration

.htaccess 内にスペルミスがある場合、このようなエラーが発生します。

具体例

実際のトラブルシューティングの流れを、ケーススタディとして見ていきましょう。

ケース 1：プラグイン更新後のホワイトスクリーン

発生状況

あるユーザーが SEO プラグインを最新版に更新した直後、サイトが真っ白になりました。

問題の特定と解決

bashCopy code# ステップ 1: エラーログの確認
cd /var/www/html/wp-content
cat debug.log

まず、WordPress のデバッグログを確認します。

vbnetCopy code# ログに記録されたエラー内容
PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/www/html/wp-content/plugins/seo-plugin/includes/utils.php on line 234

ログから、SEO プラグインで mb_convert_encoding() 関数が呼び出せないことがわかりました。これは PHP の mbstring 拡張がインストールされていないことを示しています。

bashCopy code# ステップ 2: PHP 拡張の確認
php -m | grep mbstring

mbstring がインストールされているかを確認します。何も表示されない場合、インストールされていません。

bashCopy code# ステップ 3: mbstring のインストール（Ubuntu/Debian の場合）
sudo apt-get update
sudo apt-get install php-mbstring

mbstring 拡張をインストールします。

bashCopy code# ステップ 4: Web サーバーの再起動
sudo systemctl restart apache2
# または Nginx の場合
# sudo systemctl restart nginx
# sudo systemctl restart php-fpm

PHP 拡張を有効化するため、Web サーバーを再起動します。

サイトにアクセスすると、正常に表示されるようになりました。

以下の図は、このケースの問題解決フローを示しています。

mermaidCopy codeflowchart TD
  start["プラグイン更新"] -->|サイト確認| error["ホワイトスクリーン発生"]
  error --> check["エラーログ確認"]
  check -->|Fatal Error 検出| identify["mbstring 未インストール判明"]
  identify --> install["mbstring インストール"]
  install --> restart["Web サーバー再起動"]
  restart --> verify["動作確認"]
  verify -->|正常表示| resolved["問題解決"]

図で理解できる要点：

• エラーログから具体的な原因を特定できました
• PHP 拡張の不足が原因だったため、インストールで解決しました
• サーバー再起動で変更を反映させる必要がありました

ケース 2：テーマカスタマイズ後の 500 エラー

発生状況

テーマの functions.php にカスタムコードを追加した後、500 エラーが発生しました。

問題の特定と解決

bashCopy code# ステップ 1: エラーログの確認
tail -f /var/log/apache2/error.log

Apache のエラーログをリアルタイムで監視します。

csharpCopy code# ログに記録されたエラー内容
PHP Parse error: syntax error, unexpected end of file, expecting '>' or ',' in /var/www/html/wp-content/themes/custom-theme/functions.php on line 458

functions.php の 458 行目に構文エラーがあることがわかりました。

bashCopy code# ステップ 2: FTP でテーマフォルダにアクセス
# functions.php をダウンロードしてバックアップ
# バックアップファイル名: functions.php.backup

FTP クライアントを使って、問題のあるファイルをダウンロードし、バックアップを作成します。

phpCopy code// ステップ 3: functions.php の問題箇所を修正
// 457-458 行目付近（修正前）

function custom_excerpt_length( $length ) {
    return 50
// } ← 閉じ括弧が抜けている

関数の閉じ括弧とセミコロンが抜けていました。

phpCopy code// 修正後

function custom_excerpt_length( $length ) {
    return 50;
}

正しい構文に修正します。

bashCopy code# ステップ 4: 修正したファイルをアップロード
# FTP で functions.php をサーバーに上書きアップロード

修正したファイルをサーバーにアップロードします。

サイトにアクセスすると、正常に表示されるようになりました。

ケース 3：メモリ不足によるホワイトスクリーン

発生状況

画像を大量にアップロードした後、メディアライブラリを開くとホワイトスクリーンになりました。

問題の特定と解決

bashCopy code# ステップ 1: エラーログの確認
cat /var/www/html/wp-content/debug.log

WordPress のデバッグログを確認します。

yamlCopy code# ログに記録されたエラー内容
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8192 bytes) in /var/www/html/wp-includes/media.php on line 1542

128MB のメモリ制限に達していることがわかりました。

phpCopy code// ステップ 2: wp-config.php にメモリ制限を追加

// WordPress のメモリ制限を 512MB に引き上げ
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

メモリ制限を 512MB に引き上げることで、大量の画像処理にも対応できるようになります。

bashCopy code# ステップ 3: PHP 設定でもメモリ制限を確認（オプション）
php -i | grep memory_limit

PHP 全体のメモリ制限も確認します。

iniCopy codememory_limit => 256M => 256M

PHP のメモリ制限が 256M の場合、WordPress で 512M を設定しても 256M までしか使えません。

bashCopy code# ステップ 4: PHP のメモリ制限を引き上げ（必要な場合）
# php.ini ファイルを編集（場所はサーバー環境により異なる）
sudo nano /etc/php/8.1/apache2/php.ini

php.ini ファイルを開きます。

iniCopy code; memory_limit の設定を変更
memory_limit = 512M

PHP 全体のメモリ制限を 512M に変更します。

bashCopy code# ステップ 5: Web サーバーの再起動
sudo systemctl restart apache2

設定を反映させるため、Web サーバーを再起動します。

サイトのメディアライブラリにアクセスすると、正常に表示されるようになりました。

まとめ

WordPress のホワイトスクリーンや 500 エラーは、最初は恐ろしく感じるかもしれませんが、体系的にアプローチすればほとんどの場合解決できます。

重要なポイントを振り返りましょう。

最初に確認すべきポイント：

1. エラーログを必ず確認 - デバッグモードを有効化し、debug.log や PHP エラーログをチェックする
2. プラグインを疑う - すべてのプラグインを一時的に無効化し、一つずつ有効化して原因を特定する
3. テーマを切り替える - データベースから直接デフォルトテーマに変更して確認する
4. メモリ制限を確認 - WP_MEMORY_LIMIT を 256MB 以上に設定する
5. データベース接続をチェック - wp-config.php の設定情報が正しいか確認する
6. .htaccess をリセット - バックアップしてから削除し、WordPress で再生成する

トラブルシューティングの基本姿勢：

• 焦らず、一つずつ確認していくことが重要です
• 変更を加える前に、必ずバックアップを取りましょう
• エラーログは問題解決の最大の手がかりになります
• 解決した後も、デバッグモードは本番環境では無効化しておきましょう

これらの手順を順番に試していけば、大半のホワイトスクリーンや 500 エラーは解決できるはずです。それでも解決しない場合は、サーバーログやホスティング会社のサポートに相談することをおすすめします。

WordPress サイトの運営には、こうしたトラブルシューティングのスキルが欠かせません。今回の経験を通じて、WordPress の仕組みへの理解も深まったのではないでしょうか。

関連リンク

• WordPress 公式サポート - デバッグ
• WordPress Codex - wp-config.php の編集
• PHP 公式マニュアル - エラー処理
• WordPress 公式サポート - よくあるエラー