エラーの概要
WordPressサイトまたは管理画面を開くと、空白ページまたは以下のようなブラウザメッセージが表示されます：
500 Internal Server Error
ブラウザに汎用的なページが表示されることもあれば、ApacheまたはNginx独自のエラー画面が表示されることもあります。いずれにせよ、サーバーが正常なレスポンスを返せずにクラッシュした状態です。これは包括的なエラーで、サーバーは何かが問題だとわかっていても、具体的な原因を示しません。
WordPressの500エラーのほぼすべては、5つの原因のいずれかにたどり着きます。どれも再インストール不要で修正できます。
主な原因
- 破損または無効な
.htaccessファイル - 壊れたまたは互換性のないプラグイン
- ファイル／ディレクトリのパーミッション設定が誤っている
- PHPの致命的エラー（構文ミス、非互換の拡張機能）
- PHPメモリ制限の超過（まずエラーログを確認）
ステップ1：PHPエラーログを確認する
何かを変更する前に、実際のエラーメッセージを確認しましょう。500エラーページには何も情報がありませんが、ログにはすべてが記録されています。
wp-config.phpの/* That's all, stop editing! */コメントより上に、以下の3行を追加します：
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
エラーが発生したページをリロードし、ログを確認します：
# WordPressデバッグログ
cat /var/www/html/wp-content/debug.log
# またはサーバーのPHPエラーログ（パスはディストリビューションによって異なります）
tail -50 /var/log/php/error.log
tail -50 /var/log/apache2/error.log
通常、Fatal error: Uncaught Error: Call to undefined function...やParse error: syntax error in /wp-content/plugins/some-plugin/file.php on line 42のようなメッセージが表示されます。その1行が原因を直接示しています。
ステップ2：.htaccessファイルをリセットする
破損した.htaccessは、突然の500エラーの最も一般的な原因です。特にWordPressコアのアップデート後や、URLルールを書き換えるプラグインのインストール後に発生しやすいです。
FTPまたはSSHで接続し、既存のファイルをリネームします：
cd /var/www/html
mv .htaccess .htaccess.bak
WordPressのデフォルト内容で新しいファイルを作成します：
cat > .htaccess <<'EOF'
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF
サイトをリロードします。正常に表示されれば、古い.htaccessが原因でした。バックアップを削除して次に進みましょう。
後からWordPressの管理画面で.htaccessを再生成することもできます：設定 → パーマリンクに移動し、何も変更せずに変更を保存をクリックします。
ステップ3：すべてのプラグインを無効化する
プラグインは2番目に多い原因です。最も素早い診断方法は、すべてのプラグインを一度に無効化することです。管理画面にアクセスできない場合でも対応できます。
SSHまたはFTPでプラグインフォルダをリネームします：
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled
サイトをリロードします。正常に動作した場合、プラグインが原因です。フォルダを元に戻します：
mv /var/www/html/wp-content/plugins_disabled /var/www/html/wp-content/plugins
管理画面のプラグイン → インストール済みプラグインに移動し、1つずつ無効化してはリロードを繰り返します。エラーが再発したとき、直前に無効化したプラグインが原因です。
よくある問題プラグイン：PHPアップグレード後のキャッシュプラグイン、複雑なリライトルールを持つSEOプラグイン、initやshutdownにフックするプラグインなどです。
ステップ4：ファイルとディレクトリのパーミッションを修正する
WordPressのファイルはWebサーバーから読み取り可能である必要がありますが、すべてのユーザーへの書き込み権限は不要です。777のような過剰なパーミッションは、セキュリティが強化されたサーバーで500エラーを引き起こします。
正しいパーミッション設定：
- ディレクトリ：
755 - ファイル：
644 wp-config.php：600（より安全）
一括で修正するコマンド：
# ディレクトリのパーミッションを修正
find /var/www/html -type d -exec chmod 755 {} \;
# ファイルのパーミッションを修正
find /var/www/html -type f -exec chmod 644 {} \;
# wp-config.phpを保護
chmod 600 /var/www/html/wp-config.php
所有者も確認してください。Ubuntu/Debianではwebサーバーのユーザーはwww-data、CentOS/RHELでは通常apacheです：
chown -R www-data:www-data /var/www/html
ステップ5：デフォルトテーマに切り替える
テーマも見落としがちな原因です。最近更新または手動編集されたテーマは、壊れたプラグインと同様にサイトをクラッシュさせることがあります。特にサーバー上で直接functions.phpを編集した場合は要注意です。
有効なテーマフォルダをリネームして、WordPressに強制的に切り替えさせます：
mv /var/www/html/wp-content/themes/your-theme /var/www/html/wp-content/themes/your-theme_bak
WordPressは自動的にバンドルされたデフォルトテーマ（Twenty Twenty-Fourなど）にフォールバックします。サイトが正常に動作するようになった場合、テーマのfunctions.phpにPHP構文エラーがないか確認しましょう。問題はほぼそこに潜んでいます。
ステップ6：PHPバージョンの互換性を確認する
ホスティング会社はPHPをひっそりとアップグレードすることがあります。サーバーがPHP 7.4から8.1や8.2に移行した場合、古いPHP向けに作られたプラグインやテーマが突然動かなくなることがあります。
現在のバージョンを確認します：
php -v
エラーログでDeprecated、Fatal error、Call to undefined functionを検索します。ログに記載されているファイルパスが調査対象です。
共有ホスティングの場合、cPanelまたはPleskのPHPセレクターを探してみてください。プラグイン作者が修正をリリースするまでの間、PHP 7.4に一時的に戻すか、積極的にメンテナンスされている代替プラグインへの切り替えを検討してください。
動作確認
各修正を試みた後：
- キャッシュされたエラーページを回避するため、プライベート／シークレットウィンドウでサイトを開く
- トップページ（
https://yoursite.com/）と管理画面（https://yoursite.com/wp-admin/）の両方をテストする - PHPエラーログを確認し、新しいエントリがなければ修正完了
- 修正後は
wp-config.phpのWP_DEBUGをfalseに戻してデバッグモードをオフにする
再発防止策
- **本番環境ではなくステージングでテストする。**プラグイン、テーマ、PHPのアップデートは、まずステージング環境で試しましょう。ステージングでの1時間の作業で、ほとんどの500エラーは防げます。
- **新しいプラグインをインストールする前に.htaccessをバックアップする。**パフォーマンス向上やページキャッシュを謳うプラグインは、予告なくURLルールを書き換えることがあります。
- デバッグログを静かに有効化しておく。
WP_DEBUG_LOGを有効にしたまま、WP_DEBUG_DISPLAYはオフに保ちましょう。訪問者より先に問題を把握できます。 - **定期的にヘルスチェックを実行する。**WordPressの組み込みサイトヘルスツール（ツール → サイトヘルス）は、500エラーになる前に設定上の問題を表面化させてくれます。