WordPressのサイト停止後に最初に確認すること｜サーバー・DNS・マルウェアの切り分け

WordPressサイトが突然表示されなくなり、「サーバー障害なのか、DNSなのか、マルウェア感染なのか分からない」と焦っていませんか？
問い合わせや販売を受け付けるサイトほど、停止時間が長引くほど影響が広がります。

しかし、画面が開かないという症状だけで原因は決められません。利用中の端末、通信経路、DNS、サーバー、WordPress、外部からの攻撃という順に範囲を狭めると、無関係な設定を壊さずに復旧へ近づけます。

結論から言うと、最初に行うべきことは「直す操作」ではなく、停止範囲と正常な層を確定することです。
サーバーが動いているのにDNSを変更したり、感染が疑われるのにバックアップを上書きしたりすると、復旧を難しくする恐れがあります。

以下の順番なら、初心者でも今どこまで確認できたかを整理できます。変更を加える前に、まず現状を記録するところから始めましょう。

WordPressのサイト停止は最初の10分で範囲を切り分ける

WordPressのサイト停止を確認したら、最初の10分は復旧操作より「誰に、どのURLで、どのように起きているか」の確認を優先します。
自分のブラウザだけの問題と、訪問者全員に起きている停止では、調べる場所がまったく違うからです。

停止画面と時刻を変更前に保存する

まず、エラー画面全体のスクリーンショット、発生に気づいた時刻、対象URL、直前に行った更新や設定変更を保存してください。
表示されたHTTPステータス、ブラウザの警告、ホスティング会社からの通知も、原因を絞る重要な手掛かりです。

たとえば「500」と表示されるなら、サーバーへ到達した後の処理に失敗している可能性があります。「名前を解決できない」ならDNS経路が優先候補です。接続がタイムアウトするなら、停止、過負荷、通信遮断などを調べます。

別回線と別端末で同じURLを確認する

次に、同じURLをパソコンとスマートフォン、Wi-Fiとモバイル回線で確認します。シークレットウィンドウも使い、ログイン状態やブラウザキャッシュの影響を外してください。

一つの端末だけで開かないなら、端末のDNSキャッシュ、セキュリティソフト、VPN、ブラウザ拡張機能などが候補です。複数端末・複数回線で同じなら、サイト側またはドメイン側の確認へ進みます。

エラー番号ごとの意味を先に整理したい場合は、公開済みの「400系・500系エラーの違いと対処法」が役立ちます。番号だけで原因を断定せず、どの層まで通信できているかを読むために使ってください。

この段階では、DNSの書き換え、プラグインの一括削除、バックアップ復元はまだ行いません。症状を再現できる状態を残し、どこから先が異常なのかを確定することが先です。

作業窓口を一本化して変更を止める

複数人でサイトを管理している場合は、担当者ごとの復旧操作をいったん止め、記録と判断の窓口を一本化します。誰かがDNSを変え、別の人がプラグインを消し、さらに別の人がバックアップを戻すと、元の原因と各操作の影響を区別できません。

「確認しただけ」と「実際に変更したこと」を分け、時刻、担当者、対象、変更前後の値を時系列へ残してください。障害が長引いた場合も、この記録があればサーバー会社や復旧担当へ同じ説明を繰り返さずに済みます。

利用者への案内が必要な場合は、確認できた事実、影響する機能、次回更新予定だけを簡潔に伝えます。調査中の攻撃手法や管理情報を詳しく公開せず、「復旧済み」と断定するのも最終確認後にしてください。

WordPressのサイト停止でサーバーを確認する

複数環境でサイト停止を再現できたら、次はサーバーが契約上・設備上・資源上の理由で止まっていないかを確認します。
WordPressを触る前にサーバーの正常性を見るのが、最短で安全な順番です。

障害情報・メンテナンス・契約状態を見る

ホスティング会社の障害情報と管理パネルを開き、対象リージョンやサーバー番号に障害がないか確認します。契約期限、支払い失敗、利用規約違反による制限、転送量超過の通知も見落とさないでください。

管理パネル自体へ入れない場合でも、公式の障害ページやサポート窓口は別の基盤で動いていることがあります。SNS上の未確認情報だけに頼らず、契約先が示す一次情報と自分のサーバー識別情報を照合します。

ディスク・inode・CPU・メモリを確認する

サーバー自体が稼働していても、ディスク容量やinodeを使い切ると、キャッシュ、セッション、ログ、アップロードファイルを書き込めなくなります。結果として500エラー、管理画面停止、データベース処理失敗が起きることがあります。

CPUやメモリが上限に張り付いている場合は、急なアクセス増加、重い処理、ボット攻撃、不具合を起こしたプラグインなどを分けて考えます。数値が高いという事実だけでマルウェアと断定してはいけません。

ログは削除せず時刻をそろえて読む

アクセスログ、エラーログ、PHPログ、データベースログを確認する時は、サイト停止の時刻とタイムゾーンをそろえます。大量の警告より、停止時刻の直前に初めて現れた致命的エラーや接続失敗を優先してください。

容量を空けるためにログを先に消すと、原因と攻撃の痕跡を失う恐れがあります。必要なら先にダウンロードまたは別領域へ保全し、その後で安全な削減方法を検討します。

契約先やIPなどサーバーの基本情報が分からない場合は、公開中のサーバー調査ツールの記事を確認してください。調査対象を特定する入口として使い、管理権限のないサーバーへ操作を加えないことが重要です。

WordPressのサイト停止でDNSとSSLを確認する

サーバーが稼働しているのにドメイン名で開けない場合は、DNSとSSLを分けて確認します。
DNSはドメイン名を接続先へ案内する仕組みで、SSLは到達後の通信相手と暗号化を確認する仕組みです。

ネームサーバーとA・AAAAレコードを照合する

ドメイン管理会社で、現在指定しているネームサーバーを確認します。そのうえでDNS管理画面のAレコードやAAAAレコードが、意図したWebサーバーへ向いているかを照合してください。

直前にサーバー移転、CDN導入、DNS切り替えを行った場合は、古い値と新しい値が場所によって混在する時間があります。反映待ちを障害と誤認して値を何度も変えると、切り替え完了がさらに分かりにくくなります。

AAAAレコードだけが古いサーバーを指し、IPv6を優先する環境だけ停止するケースもあります。パソコンでは開くのに特定のスマートフォン回線で開かない時は、AとAAAAの両方を確認する価値があります。

DNSの変更履歴とドメイン期限を確認する

DNSが意図しない値へ変わっている場合は、管理画面の操作履歴、通知メール、管理者アカウントのログイン履歴を保存します。単純な設定ミスだけでなく、ドメイン管理アカウントの侵害も考える必要があるためです。

ドメイン期限切れやレジストラ側の保留状態でも、Webサーバーが正常なままサイトへ到達できなくなります。自動更新の設定だけを信じず、実際の有効期限と支払い結果を確認してください。

SSL証明書は期限と対象ドメインを見る

サーバーへ到達しても、SSL証明書が期限切れ、対象ドメイン不一致、更新失敗の状態なら、ブラウザは安全でない接続として停止させます。wwwあり・なし、サブドメイン、CDN経由など、実際に開くホスト名が証明書の対象か確認します。

証明書警告を無視して利用者へアクセスを促すのは避けてください。先にDNSが正しい接続先へ向いているかを確かめ、その接続先で証明書を再発行または正しく設定します。

サーバー移転後のDNS・SSL・環境差を詳しく確認したい場合は、移転時の安全確認を扱う公開記事も参考になります。今回が移転作業でなくても、接続経路を分解する考え方は同じです。

WordPressのサイト停止で本体・プラグイン・データベースを確認する

サーバーとDNSが正常で、WordPressだけが応答しないなら、WordPressの実行層を確認します。
更新直後、プラグイン衝突、テーマのPHPエラー、データベース接続失敗、メンテナンス状態の残存が主な候補です。

直前の変更を一つずつ戻せる状態にする

WordPress本体、テーマ、プラグイン、PHPバージョン、独自コードのうち、停止直前に変えたものを時系列で並べます。原因候補を一度に全部無効化すると、どれが原因だったか分からず、再発防止につながりません。

管理画面へ入れるなら、更新履歴とサイトヘルスを確認します。入れない場合は、サーバーのファイル管理やFTPを使う前にバックアップを取得し、変更対象を限定してください。

エラーログから停止した処理を特定する

PHPの致命的エラーには、発生ファイルと行番号が記録されることがあります。プラグイン名やテーマ名が出ていても、呼び出し元と根本原因が別の場合があるため、停止時刻の前後をまとめて読みます。

「データベース接続確立エラー」なら、データベースサーバーの稼働、接続上限、認証情報、容量を確認します。慌ててデータベースを再作成すると、投稿や設定を失う恐れがあるため、既存データの保全が先です。

WordPressのサイト停止とマルウェア感染を見分ける

サイト停止だけではマルウェア感染の証拠になりませんが、停止に加えて複数の不審な変化があるなら、通常障害と分けて調査します。
感染時は「表示を直す」だけでなく、被害拡大の停止、証拠保全、侵入口の特定が必要です。

通常障害だけでは説明しにくい兆候を見る

知らない海外サイトへ飛ぶ、検索経由だけ別ページになる、身に覚えのない管理者が増える、不審なPHPファイルが作られる、DNSが勝手に変わるなどは、侵害を疑う重要な兆候です。

一方、プラグイン更新直後のPHPエラーや、サーバー会社が公表している設備障害だけなら、マルウェアとは限りません。単一の警告やファイル名だけで削除を決めず、複数の証拠を突き合わせます。

感染が疑われてもすぐ全削除しない

不審なファイルを見つけても、すぐ削除すると設置時刻、改変内容、侵入口を調べにくくなります。まずファイル名、パス、更新時刻、ハッシュ、所有者や権限を記録し、安全な場所へ隔離できるか検討します。

WordPress本体だけを初期化しても、サーバーアカウント、SSH・FTP、データベース、ドメイン管理、メールに侵入が残れば再感染します。停止原因の復旧と、侵害範囲の調査は別の作業として管理してください。

公開画面、検索結果、管理画面、ファイル、データベースを順に確認する方法は「WordPressが改ざんされたか確認する方法」で整理しています。見た目だけで感染を断定しないための確認表として利用できます。

すでに不審ファイルが見つかっている場合は、場所、正規版との差分、コード、ログから危険度を評価する手順も確認してください。ファイル名の印象だけで正常ファイルを消す事故を防げます。

WordPressのサイト停止から安全に復旧する順番

原因候補を絞れたら、証拠保全、被害拡大の停止、基盤復旧、WordPress復旧、認証情報変更、動作確認の順に進めます。
「とにかく表示させる」だけを完了条件にしないことが、再停止と再感染を防ぐポイントです。

復旧前の状態を別保存する

現在のファイル、データベース、ログ、DNS設定、管理者一覧を別保存します。感染が疑われるバックアップは、そのまま本番へ戻すためではなく、調査と正規データ救出の資料として扱います。

バックアップが複数ある場合は、取得日時だけでなく、その時点で不審症状が始まっていなかったかを確認します。古ければ安全、新しければ危険と単純に判断できません。

外部被害を抑えてから正常な層を戻す

フィッシング、悪質なリダイレクト、情報送信が疑われる場合は、利用者への被害を抑える一時停止やアクセス制限を検討します。その後、サーバー・DNS・SSLを正常化し、クリーンなWordPress本体、テーマ、プラグインへ戻します。

復旧後は、WordPress管理者、サーバー、データベース、FTP・SSH、ドメイン、メール、CDNの認証情報を範囲に応じて変更します。変更前に侵入者のセッションや不審な管理者を残さないことも必要です。

表示以外も完了確認する

トップページが開いただけでは復旧完了ではありません。主要ページ、管理画面、ログイン、フォーム送信、メール受信、決済、検索結果、モバイル表示、定期処理を確認します。

さらにアクセスログとエラーログを一定期間監視し、不審な管理者やファイルが再び作られないかを見ます。DNS、SSL、バックアップ、監視通知も見直し、同じ停止を早く検知できる状態にしてください。

問い合わせフォームや決済を使うサイトでは、停止中に受け取れなかったデータがないかも確認します。フォームの送信履歴、メールサーバーの配送結果、決済サービス側の取引履歴を照合し、利用者が送信済みだと思っている依頼を見落とさないようにします。

復旧時刻、確認した機能、残っている制限、監視期間を関係者へ共有し、更新作業の再開条件も決めてください。技術的に表示が戻っても、業務上の欠落を確認するまでがサイト停止対応です。

自力復旧を続けるか迷う場合は、公開被害、管理権限、バックアップの信頼性、再発の有無で判断します。「自分で復旧できない時の危険サイン」を使うと、作業を止めて相談すべき境界を確認できます。

WordPressのサイト停止でよくある質問

サイト停止を確認したら、最初に再起動してもよいですか？

障害情報とログを確認できるなら、先に記録を残してください。再起動で一時復旧しても、原因を示す情報が消えたり、同じ停止が再発したりすることがあります。契約先が公式に再起動を案内している場合は、その手順と記録に従います。

DNSを変えればWordPressサイトはすぐ直りますか？

DNSが原因だと確認できた場合だけ変更します。サーバーやWordPressが原因なのにDNSを変えると、メールや別サービスまで止める恐れがあります。現在値、正しい接続先、変更履歴を確認してから作業してください。

サイト停止はマルウェア感染の証拠ですか？

停止だけでは証拠になりません。障害、契約制限、容量不足、更新失敗、DNS、SSLなどでも停止します。不審な転送、知らない管理者、改変ファイル、認証情報変更など複数の兆候を確認して判断します。

バックアップを戻せば調査は不要ですか？

不要にはなりません。バックアップ自体が感染後の可能性があり、サーバー、DNS、認証情報、外部サービスの侵入はWordPressの復元だけでは戻りません。停止原因と侵入範囲を確認し、復元後の再発検証まで行います。

WordPressのサイト停止は層ごとの切り分けで復旧を早める

WordPressサイトが止まった時は、端末と回線、サーバー、DNSとSSL、WordPress、マルウェアの順に確認するのが安全です。
正常な層を一つずつ確定すれば、関係のない設定を変えず、原因へ近づけます。

最初に画面・時刻・変更履歴・ログを残し、複数環境で停止範囲を確認してください。次にサーバー資源と契約状態、DNS経路と証明書、WordPressの更新・PHP・データベースを調べます。

感染兆候がある場合は、表示復旧だけで終わらせず、外部被害の停止、証拠保全、クリーンな構成への復旧、認証情報変更、再発監視まで行います。判断できない操作を無理に続けず、現状を保ったまま専門家へ渡すことも、立派な初動対応です。

WordPressのサイト停止原因を自分で切り分けられない時は

サーバー障害、DNS設定、WordPressエラー、マルウェア感染のどこに原因があるか判断できない場合は、
クイックレスキューへご相談ください。現在の証拠を残しながら、停止範囲と復旧方法を確認します。

原因調査から復旧、再発防止までまとめて確認できます。
変更を重ねる前に、停止時の画面と時刻を添えてご相談ください。