WordPressサイトが真っ白になった時：「技術的な問題が発生しています」エラー
サイトにアクセスしてコンテンツが表示されることを期待しているのに、真っ白なページが表示されたときの心臓が止まるような瞬間ほど恐ろしいものはありません。時には、もう少し情報量が多くてもやはり不吉なメッセージ「ウェブサイトで技術的な問題が発生しています。」が表示されることもあります。この悪名高い「ホワイトスクリーンオブデス」(WSOD) は、非常にイライラさせられるものです。
何が問題だったのか、すぐに手がかりが得られないことがよくあります。ITエンジニアとして、私はこの問題に何度も遭遇してきました。悲惨に見えますが、ほとんどの場合解決可能です。
WSODは通常、致命的なPHPエラーを示しています。これは、PHPがページの処理を続行できないことを意味します。根本的な原因は、欠陥のあるプラグイン、競合するテーマ、PHPメモリの枯渇、あるいはコードスニペットの小さなタイプミスであることさえあります。これを修正するには、体系的なデバッグアプローチが必要です。これにより、正確な問題点を特定できます。
デバッグの旅：犯人を見つける
ステップ1：WordPressデバッグを有効にする（あなたの最も強力な味方）
最初で最も重要なステップは、WordPressにその秘密を明らかにさせることです。デフォルトでは、WordPressはセキュリティと見た目の理由からエラーメッセージを非表示にしていることがよくあります。これを一時的に無効にする必要があります。FTP、SFTP、またはホスティングコントロールパネルのファイルマネージャーを使用してサイトのファイルにアクセスします。WordPressインストールのルートディレクトリに移動し、wp-config.phpファイルを見つけます。このファイルを開いて編集します。
define( 'WP_DEBUG', false );という行を見つけて、falseをtrueに変更します。この行が見つからない場合は、コメント/* That's all, stop editing! Happy publishing. */の直前に追加してください。
define( 'WP_DEBUG', true );
// オプション：エラーを画面に表示する代わりにファイルにログを記録する
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
WP_DEBUG_LOGとWP_DEBUG_DISPLAYの行は、特にライブサイトでは強く推奨されます。WP_DEBUG_DISPLAYをfalseに、WP_DEBUG_LOGをtrueに設定すると、エラーメッセージが公開サイトに直接表示されるのを防ぎます。代わりに、これらのエラーはwp-contentディレクトリ内のdebug.logファイルに記録されます。このアプローチははるかに安全です。
wp-config.phpファイルを保存した後、ウェブサイトを更新します。WSODが解消しない場合は、/wp-content/内にあるdebug.logファイルを確認してください。このログには、ファイルパスや行番号を含む正確なPHPエラーの詳細が含まれていることがよくあります。この情報は診断に非常に役立ちます。
ステップ2：問題を特定する（プラグイン vs テーマ）
ほとんどのWSOD問題は、最近インストールまたは更新されたプラグイン、またはテーマとの競合から発生します。
すべてのプラグインを無効にする
WordPressの管理ダッシュボードにアクセスできない場合（WSODではよくあるシナリオ）は、手動でプラグインを無効にする必要があります。
- FTP/SFTP/ファイルマネージャーを使用して、
/wp-content/ディレクトリに移動します。 pluginsフォルダの名前をplugins_oldなどに変更します。- ウェブサイトを更新します。正しく読み込まれた場合、実際にプラグインが原因でした。
次に、plugins_oldをpluginsに戻します。WordPressの管理ダッシュボードにアクセスし、「プラグイン」セクションに移動します。すべてのプラグインが無効になっていることがわかります。1つずつ再有効化し、それぞれの有効化後にサイトを更新します。WSODが再び表示された瞬間、最後に有効化したプラグインが原因です。その後、それを削除するか、代替手段を探すことができます。
デフォルトテーマに切り替える
プラグインを無効にしても問題が解決しない場合は、使用中のテーマが問題である可能性があります。
- FTP/SFTP/ファイルマネージャーを介して、
/wp-content/themes/に移動します。 - 現在アクティブなテーマのフォルダ名を変更します（例：
mythemeをmytheme_oldに変更）。 - WordPressは、Twenty Twenty-FourやTwenty Twenty-Threeなどのデフォルトテーマに自動的に切り替わります。
- ウェブサイトを更新します。オンラインに戻った場合、カスタムテーマが問題の原因でした。
その後、テーマを再インストールするか、開発者にサポートを依頼することができます。管理エリアにアクセスできない場合は、手動でデフォルトテーマをインストールする必要があるかもしれません。これを行うには、新しいデフォルトテーマ（Twenty Twenty-Fourなど）をダウンロードし、そのフォルダを/wp-content/themes/にアップロードしてから、問題のあるテーマのフォルダ名を変更します。
ステップ3：PHPのメモリ制限を増やす
複雑な操作、特に大規模なプラグインやリソースを大量に消費するテーマを使用する場合、PHPに現在割り当てられているメモリよりも多くのメモリが必要になることがあります。これによりWSODが発生することがあります。この問題は通常、debug.logに「Allowed memory size of X bytes exhausted」というエラーとして表示され、「X」は「128MB」や「256MB」のような値であることがよくあります。
これらのオプションのいずれかを使用してメモリ制限を増やすことができます。
オプションA：wp-config.phpを編集する
「That's all, stop editing!」コメントの上に以下の行を追加します（または既に存在する場合は変更します）。
define('WP_MEMORY_LIMIT', '256M');
オプションB：php.iniを修正する
サーバーのphp.iniファイルに直接アクセスできる場合（多くの場合cPanelまたはホスティングコントロールパネル経由）、この行を見つけて更新します。
memory_limit = 256M ; スクリプトが消費できるメモリの最大量 (256MB)
重要な点として、変更を有効にするには、php.iniを直接編集した後、ウェブサーバー（Apache/Nginx）を再起動することを忘れないでください。
オプションC：.htaccessを調整する
この行を、WordPressルートディレクトリにある.htaccessファイルに追加します。
php_value memory_limit 256M
これらの方法のいずれか1つだけを選択してください。まず256Mから始め、問題が解決しない場合は、徐々に512Mに増やしてください。
ステップ4：ファイルパーミッションを確認する
不適切なファイルパーミッションは、WordPressが重要なファイルを読み書きするのを妨げ、エラーを引き起こす可能性があります。WSODの直接的な原因としてはあまり一般的ではありませんが、特に最近サイトを移行したり、サーバー構成を変更したりした場合は、調査する価値は十分にあります。
WordPressのファイルとディレクトリに推奨されるパーミッションは次のとおりです。
- ファイル： 644
- ディレクトリ： 755
wp-config.php： 644 または 440（後者の方が制限が厳しく、セキュリティ強化のために推奨されることが多い）
これらのパーミッションは、通常FTPクライアントまたはファイルマネージャー経由で調整できます。SSHアクセスがある場合は、WordPressルートディレクトリから直接これらのコマンドを実行できます。
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 644 wp-config.php
また、ウェブサーバーを実行しているユーザー（例：Debian/Ubuntu上のApacheの場合はwww-data、CentOS/RHEL上のApacheの場合はapache）がファイルを所有していることを確認してください。以下のコマンドを使用して所有権を調整する必要があるかもしれません。
sudo chown -R www-data:www-data .
www-dataを、お使いのウェブサーバーのユーザー名とグループ名が異なる場合は、それに置き換えることを忘れないでください。
ステップ5：破損したWordPressコアファイルを置き換える
まれに、手動での更新やサーバーの不具合によってWordPressのコアファイルが破損することがあります。このような場合、新しいファイルに置き換えてみることができます。
- wordpress.org/download/releases/から、お使いの正確なWordPressバージョンの新しいコピーをダウンロードします。
- zipファイルをローカルコンピューターに抽出します。
- FTP/SFTPを使用して、ダウンロードした新しい
wp-adminおよびwp-includesフォルダをサイトにアップロードし、既存のものを上書きします。 - 次に、ダウンロードした新しいファイルのルートから個々のファイル（例：
index.php、wp-login.php）をアップロードします。ただし、wp-contentフォルダや重要なwp-config.phpファイルは上書きしないでください。
修正の確認：うまくいったか？
潜在的な解決策を実装したら：
- ウェブサイトを更新する： サイトのフロントエンドとWordPress管理ダッシュボード（
yourdomain.com/wp-admin）の両方を確認します。 - エラーログを調査する：
WP_DEBUG_LOGを有効にした場合、wp-content/debug.logファイルを確認します。新しいエラーや残っているメッセージがないか確認してください。 - 機能を徐々に復元する： 以前にプラグインやテーマを無効にした場合は、サイトが安定していることを確認するために、1つずつ再有効化します（安全だと確信できる場合のみ）。
- デバッグを無効にする： サイトが完全に機能するようになったら、
wp-config.phpでWP_DEBUGをfalseに戻すことが非常に重要です。これにより、エラーメッセージが一般公開されるのを防ぎ、セキュリティとパフォーマンスを維持するのに役立ちます。
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false ); // こちらもfalseに設定
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
今後の安定性のための重要なポイント
- バックアップは命綱です： 常に、常にWordPressファイルとデータベースの両方の最新バックアップを保持してください。これは、いかなる危機においても究極のセーフティネットです。
- ステージング環境を活用する： プラグイン、テーマ、またはWordPressコアの更新をライブサイトにプッシュする前に、ステージングサイトで徹底的にテストしてください。これにより、予期せぬ問題を防ぐことができます。
- 体系的なデバッグを受け入れる： 問題が発生してもパニックにならないでください。代わりに、問題に系統的にアプローチしてください。まずデバッグログを確認し、次にプラグインやテーマなどのコンポーネントを体系的に特定します。
- ログをマスターする： PHPエラーログとWordPressデバッグログは、非常に貴重な情報源です。それらを読み解き、理解する能力を身につけることは、トラブルシューティングスキルを大幅に向上させます。
- ライブファイルを盲目的に編集しない：
wp-config.phpのような重要なファイルを変更する前に、常にバックアップコピーを作成してください。これにより、問題が発生した場合でも簡単に元に戻すことができます。
「ウェブサイトで技術的な問題が発生しています。」というメッセージは、最初は威圧的に感じるかもしれませんが、単にWordPressサイトが少し注意を求めているだけです。これらの体系的な手順に従うことで、サイトを迅速にオンラインに戻すことができるでしょう。また、一般的なWordPressの問題を効果的にトラブルシューティングする方法についてより深く理解し、より自信のあるサイト管理者になることができます。