WordPressのよくあるエラー対処集｜サイト障害を自分で解決する方法 | WPセンターブログ

WordPressサイトを運営していると、ふとした拍子に「真っ白な画面」や「データベース接続エラー」、あるいは「HTTP 500エラー」など、思わぬトラブルに見舞われることがあります。原因は多岐にわたり、初心者はもちろん中上級者でも一旦パニックに陥りがちです。本記事では主要なエラー症状を症状確認→原因分析→具体的手順の順に深掘りし、ツール紹介・注意点・未来予測までカバー。さらに関連記事リンクを設けることで、困ったときに“このページ一冊で安心”と言っていただけるよう、トラブルシューティングのピラーページとして徹底解説します。読者の皆様が落ち着いて自力解決に取り組めるよう、平易な言葉と論理的な構成でお届けします。

データベース接続エラーの解消法

結論：データベース接続エラー（“Error Establishing a Database Connection”）は、WordPressサイトの最も致命的な障害の一つですが、原因を体系的に切り分けることで、短時間で復旧できます。

症状と確認ポイント

まずは症状の把握から始めましょう。
– 画面に「Error establishing a database connection」と表示される
– サイト全体が真っ白になるのではなく、WordPress以外の静的ファイル（例：画像やCSS）は読み込まれる
– wp-admin（管理画面）にアクセスすると同じエラーが出る

この段階で、エラーがデータベース接続に起因していると断定できます。トラブルシューティングの第一歩は、サイト全体ではなく「DB接続情報」に問題が起きているかを切り分けることです。

主な原因

wp-config.php の認証情報誤り
DB_NAME, DB_USER, DB_PASSWORD, DB_HOST のいずれかが間違っていると接続できません。
データベースサーバーの停止・過負荷
レンタルサーバーのMySQLプロセスが停止または過負荷で応答が遅延するとタイムアウトします。
テーブルの破損
プラグインの強制停止や不完全なバックアップ復元で、テーブルが壊れているケースがあります。
ホスティング環境の変更
サーバー移行時に、DBホスト名（例：localhost から内部IPアドレス）を更新し忘れることがあります。

解決手順

wp-config.phpの認証情報確認
FTP/SFTPでサイトルートに接続し、wp-config.php を開く。
定数 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST の値がサーバー提供の情報と完全一致しているか確認・修正。
修正後、ブラウザをリロードし、症状が改善するかチェック。
データベース接続テスト用PHPスクリプト実行
以下の内容で testdb.php を作成しサーバーにアップロード。
```
<?php
$link = mysqli_connect('DB_HOST','DB_USER','DB_PASSWORD','DB_NAME');
if (!$link) {
  die('接続失敗: ' . mysqli_connect_error());
}
echo '接続成功!';
?>
     
```
ブラウザで https://あなたのドメイン/testdb.php にアクセスし、接続可否を確認。
「接続成功!」が出ればWordPress設定以外に原因があると絞り込めます。
サーバーのMySQLステータス確認
レンタルサーバーのコントロールパネルでMySQLの稼働状況をチェック。
過負荷やメモリ不足が疑われる場合、サポートチケットを起票し、再起動依頼またはプラン変更を検討。
テーブル修復・最適化
phpMyAdminにアクセスし、対象データベースを選択。
画面下部の「チェック・修復」機能で破損テーブルを修復。
大規模サイトでは、WP-CLI の wp db repair コマンドを利用可能（wp-config.phpに define('WP_ALLOW_REPAIR', true); を一時追加）。
バックアップからの復元 or 専用プラグイン活用
UpdraftPlus、BackWPupなどのプラグインで直近のバックアップからDBのみを復元。
プラグインを使うとGUIで復元できるため、初心者にも導入しやすい。

真っ白（ホワイトスクリーン）対策

結論：WordPressサイトが突然真っ白になり何も表示されない「ホワイトスクリーン」は、表示崩れだけでなく業務停止のリスクも高いため、原因を素早く特定し、段階的に復旧することが重要です。

症状確認チェックリスト

まずはどの範囲で真っ白画面が発生しているかを確認します。管理画面にもアクセスできない場合と、フロントエンドだけの場合とで切り分けが必要です。フロントエンドのみの場合はテーマやプラグイン、PHPバージョンの問題が疑われます。両方真っ白の場合は、PHPエラーやメモリ制限超過など、サイト全体に関わるトラブルの可能性が高くなります。ブラウザのデベロッパーツールでコンソールエラーやネットワークエラーが出ていないか確認し、サーバーのエラーログ（Apache/nginx）に何が記録されているかをチェックしましょう。

原因別見分け方

代表的な原因は以下の通りです。1) PHPのメモリ不足、2) テーマやプラグインの致命的エラー、3) functions.phpの誤記述。
PHPメモリ不足は、`Allowed memory size exhausted` というエラーログがサーバーに記録されるため、まずログの最終行を確認。致命的エラーは `PHP Fatal error` と表示されるため、該当するファイル名（例：`class-wp-hook.php`）を手がかりに原因ファイルを特定できます。また、テーマの `functions.php` に誤ったコードを追加した場合は、FTP上で当該行をコメントアウトするだけで復旧するケースもあります。

本格的に原因を突き止めるには、FTPで wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を一時追加し、wp-content/debug.log を確認する方法が有効です。このログにはエラーの詳細が記録され、具体的なファイルパスとエラーメッセージをもとに、どのプラグインやテーマファイルで致命的エラーが発生しているかが判別できます。

復旧手順

PHPメモリ上限の引き上げ
wp-config.php に define('WP_MEMORY_LIMIT', '256M'); を追加し、メモリ不足による表示停止を回避します。サーバー側でメモリ増量できない場合は、不要なプラグインを停止し、リクエストごとのメモリ消費を減らす工夫も欠かせません。
プラグイン・テーマの切り分け
FTPで wp-content/plugins フォルダ名を plugins_old にリネームし、全プラグインを一時停止。フロントエンドが正常に戻ったら、元の plugins フォルダに戻し、個別にフォルダ名を変えて一つずつ有効化し、問題のプラグインを特定します。同様に wp-content/themes/使用中のテーマ をバックアップし、Twenty Twenty-Three などのデフォルトテーマに切り替えて症状が消えるか確認します。
functions.php のバックアップ修正
カスタマイズで追記したコードに誤りがある場合、FTPから functions.php をダウンロードし、追加部分をコメントアウトして再アップロード。再度ブラウザをリロードし、表示が戻るかを確認します。
自動化ツールの活用
WP-CLI を導入できる環境では、wp plugin deactivate --all や wp theme activate twentytwentythree でCLIから素早く切り分けが可能です。コマンド一発で切り分けできるため、初心者でも復旧手順を簡略化できます。
注意点とリスク管理
復旧作業中も本番サイトへの影響を最小限にするため、LightStart プラグインを使って一時的にサイトをメンテナンス画面に切り替えることを推奨します。また、WP_DEBUG を有効化したまま運用すると、エラー情報が外部に漏れるリスクがあるため、復旧後は必ず元に戻しましょう。
未来予測
今後、テーマ・プラグインの自動更新やPHPバージョンアップに伴い、互換性エラーが増加傾向にあります。互換性チェックプラグインやステージング環境を常設し、事前にテスト運用することで、本番サイトでのホワイトスクリーン発生リスクを大幅に低減できます。

HTTP 500エラーの原因と対処

結論：HTTP 500エラーはサーバー内部の問題を示す汎用エラーコードですが、ログ解析と段階的トラブルシューティングで短時間に根本原因を特定し、復旧できます。

エラー発生時のログ確認

まずはサーバーのエラーログを確認しましょう。
– Apacheなら error_log、nginxなら error.log に「[crit]」「500」「PHP Fatal error」などのキーワードが出力されています。
– WordPress標準のデバッグログを利用するには、wp-config.php に以下を追加後、wp-content/debug.log を確認。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

具体的なファイル名と行番号が出力されるため、どのスクリプトで致命的なエラーが起きたかを即把握できます。

サーバー・PHP設定の調整

PHPバージョンの互換性
テーマやプラグインがPHP 8.0以上に非対応の場合、PHP 7.4などの安定版へダウングレードすると解消するケースがあります。
.htaccessの誤設定
再書き込みルールや権限設定が原因で500エラーを返すことがあります。.htaccess を一時リネームして動作確認し、問題がなければ書き戻し→ルールを修正します。
ファイル／ディレクトリのパーミッション
誤って wp-content やテーマフォルダの権限を 777 以上にしていると、セキュリティ保護機能がHTTP 500を返すケースがあります。正しくは 755（フォルダ）/644（ファイル）へ設定。

トラブルシューティング手順

プラグイン・テーマの一時無効化
FTPで plugins フォルダをリネームし、すべて無効化後にサイトを確認。500エラーが消えたらプラグインが原因。
テーマ切り替え
デフォルトテーマ（Twenty Twenty-Threeなど）へ切り替え、500エラーの有無を確認。
PHPメモリ割当の調整
エラーログに Allowed memory size exhausted があれば、wp-config.php に define('WP_MEMORY_LIMIT', '256M'); を追加し再試行。
サーバー再起動・キャッシュクリア
VPS／専用サーバーの場合はSSHから sudo service apache2 restart（または nginx restart）を実行。共有ホスティングならコントロールパネルの「再起動」ボタンを利用。
WP-CLIでの再インストール
コアファイル破損が疑われる場合、wp core download --force コマンドでWordPress本体を再取得し、破損ファイルを上書き。

プラグイン起因の致命的エラー対策

結論：プラグイン同士の競合や、古いバージョンによる致命的エラーは、一括無効化→切り分け→再有効化の手順で原因特定し、安全に復旧できます。

プラグイン競合の見分け方

最後に追加・更新したプラグインに絞って優先的に疑う
ログの PHP Fatal error に「プラグイン名」「関数名」が示される場合、そのプラグインが直接の原因
デベロッパーツールのNetworkタブで、特定のAJAXリクエストが500エラーを返すケースもあり

一括無効化と切り分け手順

一括無効化
FTP/SFTPで wp-content/plugins フォルダ名を plugins-disabled に変更し、全プラグインを停止
正常性確認
フロント・管理画面両方でサイトが正常表示されるかをチェック
切り分け
元の plugins フォルダ名に戻し、プラグインを一つずつフォルダ名をリネームして有効化。問題が再現した時点で、直前に有効化したプラグインが原因と断定
互換性チェック
原因プラグインのWordPress公式ディレクトリや開発者サイトで、対応バージョンの記載を再確認。アップデートが提供されていれば最新版に更新、提供されていなければ代替プラグインを検討

安全な再有効化とバックアップ

ステージング環境で事前テスト：すべてのプラグイン更新後は、必ずステージング環境で動作確認し本番適用
定期バックアップ：UpdraftPlusやBackWPupで「プラグイン更新前のスナップショット」を取得し、何かあれば即時ロールバック
注意点：無効化時に設定が失われるプラグインもあるため、事前に設定内容をエクスポート。カスタムコードをfunctions.phpへ直書きしている場合は、プラグイン化して管理することで競合リスクを低減

関連：プラグイン致命的エラーの切り分けと対策

パーマリンク・404エラーの解消

結論：パーマリンク設定の不備や .htaccess の誤設定が原因で発生する404エラーは、設定の再保存とリダイレクト設定で迅速に解消できます。

設定確認と再保存

WordPress管理画面＞設定＞パーマリンクで、何も変更せずに「変更を保存」をクリック
カスタム構造を使っている場合は、構造タグ（%postname% など）が正しいか再確認

.htaccess の調整

サイトルートの .htaccess をFTPでダウンロードし、以下の基本コードが含まれているかチェック：

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

独自ルール追加時はWordPressタグの外側に記述し、優先順やパス誤りを見直し。

リダイレクトプラグイン活用術

Redirectionプラグインで301リダイレクトを設定し、404ログを自動検出
開始URL・ターゲットURLを正確に入力し、無限ループ防止のためテスト環境で確認

その他のよくあるエラー一覧と対策

結論：SSL混在、メモリ不足、タイムアウトなどのサブ的エラーも、環境設定と定期メンテナンスで未然防止・迅速解消ができます。

SSL/HTTPS混在コンテンツ

症状：鍵マークが外れる、ブラウザ警告
原因：サイト内にhttp://の画像・スクリプト混在
対策：Really Simple SSLプラグインで自動修正、またはSearch Regexで全リンクをhttps://に一括置換

メモリ不足・タイムアウト

症状：「Allowed memory size exhausted」や「Maximum execution time of 30 seconds exceeded」
対策：
1. wp-config.phpにdefine('WP_MEMORY_LIMIT','256M');を追加
2. サーバー側php.iniでmemory_limitとmax_execution_timeを調整
3. 重いプラグインの実行時間を限定

未来予測：WordPressエラーの傾向

自動更新の普及により、コア・プラグイン間の互換性エラーが増加。PHP 8.x系への移行で非推奨関数や古いコードによる致命的エラーが増える可能性があります。ステージング環境を用意し、更新前に互換性チェックを自動化するツール（WP Rollback, VersionPressなど）を導入しましょう。

まとめ

WordPressの主要エラー対処は「原因の見極め→段階的な切り分け→再発防止策」の３ステップが基本です。本ガイドではデータベース接続エラー、ホワイトスクリーン、HTTP 500、プラグイン競合、パーマリンク＆404、サブエラーまで包括的に深掘りし、具体手順やツール、注意点、未来予測を網羅しました。まずはステージング環境で手順を試し、本番サイトへの影響を最小化しながら復旧に取り組みましょう。今すぐサイトのバックアップ体制とステージング環境を整え、万一のトラブルに備えることが、安心した運営の第一歩です。

今すぐ取り組むべき理由：問題が長引くほどSEO評価やユーザー信頼が低下し、機会損失につながります。
まずはバックアップ＆ステージング環境構築から始め、メンテナンスプランを策定しましょう。