WordPressサイト全体にアクセスできなくなった時の原因と復旧手順

WordPressサイト全体にアクセスできなくなった時の原因と復旧手順

サイトにも管理画面にもまったくアクセスできなくなった場合、最初に確認すべきはサーバーのファイル構造とWordPressのインストールパスだ。外部からの不正アクセスを受けた後にページが表示されなくなる症状では、改ざんされたプラグインの残骸や、不完全に変更された設定ファイルが読み込みを妨げている可能性が高い。

なぜサイト全体にアクセスできなくなったのか

管理画面も含めてあらゆるページが表示されない状態は、WordPressの根幹となるファイルが破損しているか、サーバーがPHPを正しく処理できなくなっていることを意味する。特に不正アクセスを受けた後であれば、攻撃者が設置した不正なコードがセキュリティプラグインや手動の復旧作業によって一部だけ削除され、不完全な状態で残っている可能性が高い。

最も厄介なのは、WordPress本体のコアファイルや設定ファイルそのものが破損しているケースだ。テーマやプラグインの不具合であれば、それらを無効化することで少なくとも管理画面にはアクセスできるようになるが、コア破損ではそれすらも不可能になる。

不正アクセスからの復旧作業で起こりやすい副次的な破損

外部から侵入を受けた後、多くのユーザーはパスワード変更やソルトキーの更新、不審なプラグインの削除といった応急処置を行う。しかしこれらの作業中に誤って重要なファイルを削除してしまったり、修正が中途半端な状態で終わってしまったりすることがある。特にソルトキーを手動で更新した場合、wp-config.php内で閉じ引用符が欠落していたり、PHPの定数定義が壊れていたりすると、WordPress全体が読み込めなくなる。

最初に試すべき緊急アクセス手順

サイトが完全に応答しなくなった場合、まずはブラウザの問題ではなくサーバー側の問題であることを確認する。シークレットウィンドウで自分のサイトURLを開く、別の端末やネットワークからアクセスしてみる、example.com/readme.htmlのような静的なHTMLファイルが表示されるか試すといった切り分けが有効だ。静的なHTMLすら表示されないなら、DNS設定やサーバー自体の停止を疑う必要がある。

上記の手順で管理画面に到達できるようになれば、あとは管理画面からプラグインを1つずつ有効化して原因を特定し、テーマを正式に切り替えればよい。

wp-config.php の破損を確認する

ソルトキーを変更した直後にアクセス不能になったなら、wp-config.phpが最も疑わしい。このファイルはWordPressのルートディレクトリにあり、データベース接続情報や認証用のユニークキーを定義している。編集時にシングルクォートが1つ抜けている、余分な文字が混入している、PHPの開始タグ<?phpが欠落しているといった単純なミスで、サイト全体が真っ白になる。

サーバーのファイルマネージャーやFTPクライアントでwp-config.phpをダウンロードし、バックアップを取った上で内容を確認する。特にソルトキーを定義しているセクション（AUTH_KEYやLOGGED_IN_KEYなどが並ぶ部分）に注目し、各行がdefine('キー名', '値');の形式を正しく守っているか、閉じ括弧とセミコロンが揃っているかを1行ずつ検証する。不安があれば、WordPressの公式ソルトキー生成ページから新しいキーセットをコピーし、該当セクションを丸ごと置き換えるのが安全だ。

プラグインを強制的に全無効化する

管理画面にさえアクセスできない状態では、データベースを直接操作するか、FTPでプラグインフォルダの名前を変更することでプラグインを無効化する。手順はシンプルで、/wp-content/plugins/ディレクトリに移動し、その中にある全プラグインのフォルダ名の先頭に「_」や「disabled_」を付け加えるだけだ。例えばwordfenceを_wordfenceにリネームすれば、WordPressはそのプラグインを認識しなくなる。

この方法の利点は、プラグイン本体のファイルを削除せずに済むため、原因特定後にすぐ元の名前に戻して復元できることだ。大量のプラグインを1つずつリネームするのが面倒な場合は、pluginsフォルダ自体をplugins_backupにリネームし、空のpluginsフォルダを新規作成すると一括で無効化できる。

WordPress コアファイルを手動で上書きする

wp-config.phpに問題がなく、プラグインをすべて無効化しても症状が改善しない場合、WordPress本体のプログラムファイルが改ざんまたは破損している。攻撃者がwp-adminやwp-includesディレクトリに仕込んだバックドアが、不完全に削除されたまま残っているケースも多い。

対処法は、WordPress公式サイトから最新版の ZIP ファイルをダウンロードし、展開した中身をFTP経由でサーバーにアップロードすることだ。このとき絶対に上書きしてはいけないファイルが2つある。wp-config.php（サイト固有の設定）と/wp-content/ディレクトリ（テーマ・プラグイン・アップロードメディア）だ。これらを除くすべてのファイルとフォルダを上書きアップロードすることで、コアファイルだけがクリーンな状態にリセットされる。

サーバー側のエラーログを確認する方法

ここまでの手順で復旧しない場合は、具体的なエラー内容を把握する必要がある。ブラウザには「重大なエラーが発生しました」としか表示されないが、サーバーには詳細なエラーログが記録されている。レンタルサーバーの管理パネル（cPanelやカスタムコントロールパネル）で「エラーログ」や「error_log」という項目を探し、直近のエントリを確認する。

エラーログには「PHP Fatal error」や「Allowed memory size exhausted」といった具体的な原因が記録されている。特に不正アクセス後によく見られるのが、改ざんされたファイルから呼び出された存在しない関数によるエラーや、不完全に削除されたコードの残骸による構文エラーだ。ログの内容を手がかりに、問題のファイルを特定して修正するか、該当プラグインを完全に削除する。

WP_DEBUG を一時的に有効化して詳細を表示する

サーバーのエラーログが見つからない場合は、WordPressのデバッグモードを有効にしてエラーを画面に直接表示させる。これはwp-config.phpに以下の定数を追加または変更することで実現できる。

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

WP_DEBUGをtrueにするとWordPressがエラーを表示するようになり、WP_DEBUG_LOGで/wp-content/debug.logにエラーが記録される。WP_DEBUG_DISPLAYをtrueにすると、ブラウザ上にもエラーメッセージが直接表示される。なお、作業が終わったらこれらの定数をfalseに戻すか削除すること。本番サイトでデバッグ表示を有効にしたままにすると、訪問者にもエラー内容が見えてしまいセキュリティリスクになる。

.htaccess ファイルの破損を疑う

不正アクセスの痕跡として、.htaccessファイルが改ざんされているケースも多い。このファイルはWebサーバー（Apache）の挙動を制御しており、ここに不正なリダイレクトルールやアクセス制限が書き込まれていると、サイト全体にアクセスできなくなる。

WordPressルートディレクトリの.htaccessをダウンロードしてバックアップを取り、一度ファイル名を.htaccess_backupに変更して無効化する。その後、WordPress管理画面の「設定」→「パーマリンク設定」で「変更を保存」をクリックすれば、クリーンな.htaccessが自動生成される。ただし管理画面にアクセスできない現状では、以下の内容で新規に.htaccessを作成してもよい。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

これでサイトが表示されるようになれば、原因は.htaccessの改ざんだったと特定できる。旧ファイルは内容を精査し、不審な行（知らないドメインへのリダイレクトや、怪しいIPアドレスからのアクセス許可ルールなど）がないか確認してから削除する。

バックアップからの復元がうまくいかない場合の対処

サーバー会社のサポートからバックアップ復元を提案されたが失敗したという状況は、バックアップデータ自体が破損しているか、復元先の環境に不整合があることを示している。特に多いのが、バックアップを上書き復元した後にデータベースの接続情報が古いままになっているケースだ。

バックアップ復元後にサイトが表示されない場合、まずwp-config.php内のデータベース名・ユーザー名・パスワード・ホスト名が、現在のサーバー環境と一致しているか確認する。バックアップが別のサーバーや別のデータベースインスタンスの情報を持ったまま復元されると、WordPressはデータベースに接続できず「データベース接続確立エラー」を返す。

もうひとつの可能性は、バックアップに不正アクセス後の改ざんファイルが含まれていたケースだ。攻撃を受けた後の状態をバックアップしてしまい、それを復元しても問題が再発するだけという悪循環に陥っている。この場合、バックアップからwp-content/uploads/（メディアファイル）とデータベースのダンプファイルだけを取り出し、WordPressのコアファイルとプラグインは公式のクリーンなファイルで置き換える方法が有効だ。

よくある質問

FTPの接続情報がわからない場合はどうすればよいか

多くのレンタルサーバーでは、契約時に送られてくる「サーバーアカウント情報」メールにFTPのホスト名・ユーザー名・パスワードが記載されている。見つからない場合はサーバーの管理パネルにログインし、「FTPアカウント」や「ファイルマネージャー」の項目から確認できる。管理パネル自体にログインできない場合は、サーバー会社のサポートに連絡してFTP情報を再発行してもらう必要がある。

「このサイトで重大なエラーが発生しました」のメールが届いたが確認できない

WordPress 5.2以降では、サイトに致命的なエラーが発生すると管理者メールアドレスに自動通知が届く。このメールには「リカバリーモード」へのリンクが含まれており、クリックするとプラグインを無効化した状態で管理画面にログインできる。メールが届いていない場合は、サーバーのPHPバージョンが古くてメール送信機能が動作していない、または管理者メールアドレスが間違って設定されている可能性がある。

不正アクセスを受けた後、どのプラグインを疑うべきか

攻撃者は多くの場合、更新が長期間止まっている脆弱なプラグインや、公式リポジトリ以外から入手したnulledプラグイン（正規ライセンスを回避した改変版）を経由して侵入する。/wp-content/plugins/内で更新日時が不自然に新しいファイル、プラグイン名とは無関係なファイル名（config.bakやabout.phpなど）が紛れ込んでいないか確認する。また、長期間更新されていないプラグインは、たとえ攻撃の経路でなかったとしても今後のリスクになるため、代替プラグインへの移行を検討すべきだ。

すべて試しても復旧しない場合の最終手段は

サーバー上の全ファイルをローカルにバックアップし、データベースをエクスポートした上で、WordPressを新規インストールする。その後、エクスポートしたデータベースのうちwp_posts（投稿・固定ページ）とwp_postmeta（カスタムフィールド）、wp_options（サイト設定）のテーブルだけをインポートし直す。この方法ではテーマやプラグインの設定の一部が失われる可能性があるが、コンテンツを救出できる可能性が最も高い。作業前には必ず現状の完全バックアップを取っておくことが大前提だ。

この記事のポイント

• 管理画面もサイトも表示されない場合、まずは静的なHTMLファイルが表示されるか確認し、問題の切り分けを行う
• wt-config.phpの文法ミスやプラグインの強制無効化、.htaccessのリセットで多くのケースが解決する
• 不正アクセス後はコアファイルが改ざんされている可能性があるため、wp-content以外をクリーンなファイルで上書きする
• バックアップ復元に失敗したら、データベース接続情報の不一致やバックアップ自体の破損を疑う
• エラーログやWP_DEBUGで具体的なエラー内容を特定し、根本原因に対処するのが最も確実な復旧手順である

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている