セキュリティ 2025.12.03 2025.12.03
【保存版】WordPressのトラブル発生時の初動対応をわかりやすく解説

WordPressは世界中で利用されているCMSですが、更新や設定変更のタイミングで突然トラブルが発生することがあります。サイトが表示されない、管理画面に入れない、プラグインが動作しないなど…。
そうしたトラブルの初動対応を誤ると復旧が遅れるだけでなく、さらなる不具合やデータ損失につながる可能性もあります。本記事では、WordPressでトラブルが起きた際に押さえておくべき基本的な対応手順を、わかりやすく解説します。
WordPressでトラブルが発生した時の基本対応は?
WordPressで不具合やトラブルが発生した際に重要なのは、慌てずに原因の切り分けと影響範囲の確認を行うことです。
初動対応は、現状把握 → 切り分け → 暫定対応 → 記録 の順番が基本です。これらのフローの後に、問題の根本的な原因を特定して原因を排除する恒久対応を行います。
| 現状を把握する | ・どんな問題が起きているのかを把握する |
|---|---|
| 切り分け | ・何が原因なのかを特定する ・影響範囲を確認する |
| 暫定対応 | ・緊急で問題を解消するために必要な対応を行う |
| 記録 | ・今後の参考にするために記録する |
【ステップ1】現状を把握する
第一に、Webサイトにどのような問題が生じているかを整理します。
以下のようなWordPressで起こりやすい症状を確認したら、エラーメッセージや画面をスクリーンショットなどで記録しておきましょう。
①致命的なエラーが発生しました/「500 internal server error」が出る
WordPress内のファイルを更新したり、プラグインをアップデートした後に「致命的なエラーが発生しました」というエラー画面が表示される場合があります。
また、古いバージョンのWordPressを使用していた場合は、画面上に何も表示されない場合もあります。このWebサイトが表示されず真っ白な画面になる状態を「ホワイトスクリーン」や「WSoD(White Screen of Death)」などと呼びます。
これは、主にPHPでの構文エラーやメモリ制限、プラグイン上の欠陥に関連して生じるエラーです。
直前にPHPコードを修正していたといったケースであればすぐに原因に気づけますが、プラグインの自動アップデートが原因だった場合は、すぐに原因に思い至らないケースも少なくありません。
「500 internal server error」の場合は、直前のファイル修正やアップデートが原因の場合がありますが、サーバー側で不具合が発生している可能性もあります。
もし「致命的なエラーが発生しました」や「500 internal server error」と表示された場合、暫定対応の後に行うべき対応については以下の記事で詳しく解説しています。
WordPressの画面が真っ白!原因別の対処法まとめ【初心者向け】
②管理画面にログインできない
WordPressの管理画面へアクセスしてもログイン画面が表示されなくなってしまう場合は、プラグインやテーマに関連した原因で問題が生じた可能性があります。
過去の例では、2025年の4月ごろにバックアッププラグインの「BackWPup」でアップデートが行われたことが原因で、管理画面にログインできなくなったり、Webサイトそのものが表示されなくなったケースがありました。(参考:さくらインターネット「WordPressのWebサイト・管理画面が見れなくなったお客様へ(4/30速報)」)
もう一つの可能性として考えられるのは、マルウェアに感染してログイン画面が表示されなくなった場合です。ログインURLにアクセスすると、「アクセス禁止」を意味する403エラーが表示されログインできない場合、マルウェアがファイルを改ざんして正規のユーザーがログインできないようにした可能性があります。
マルウェアの感染が疑われる場合は、他のトラブルとは別の対応が必要です。
※【ステップ3】の対応2へ進んでください。
③WordPressからのメールが届かなくなる
WordPressから届くべきメールが届かなくなった場合は、プラグインで競合が発生していたり、サーバーでメール送信の設定が誤っているためメールが送信されていない可能性があります。
それ以外に、メール自体は送信されているものの、メールサーバー側で迷惑メールだと判断されて迷惑メールフォルダにメールが入ってしまっているケースもあります。
メールが届いていない場合は、どのような状況か、エラーメッセージは届いていないかなど、状況を正確に把握することが重要です。
④サイトの表示速度が突然遅くなる
今までスムーズに動いていたWebサイトの動作が遅くなった場合は、サーバー負荷が大きくなっている、プラグインによる影響、などの可能性があります。
また、プラグインなどに変更がないにも関わらず突然サイトの表示速度が遅くなった場合には、以下のような原因が考えられます。
- 使用中のデバイスの不具合
- 通信環境の悪化
- サーバーのリソース不足
- WordPress本体、プラグインの自動アップデートによる影響
- アクセス数の急増(Dos/DDos攻撃の可能性)
- マルウェア感染
マルウェア感染が疑われる場合は、他のトラブルとは別の対応が必要です。
※【ステップ3】の対応2へ進んでください。
⑤サイト内に不審な兆候が見られる
Webサイトに外国語の書き込みがある、勝手にページがリダイレクトされる、など不審な兆候が見られた場合は、サイトへの改ざんや不正アクセスの疑いがあります。
Webサイトから判断できる不正ログイン・改ざんの兆候には、以下のようなものがあります。
- 外国語の書き込みがある
- 勝手にページがリダイレクトされる
- Google検索結果上に「このサイトは第三者によってハッキングされている可能性があります」というメッセージが表示される
また、不正アクセスが起きた場合には、WordPress管理画面でもさまざまな不正改ざんが起きている可能性があります。WordPress管理画面から判断できる不正ログイン・改ざんの兆候には、以下のようなものがあります。
- 不審な管理者ユーザーが追加されている
- 記事内に不正リンクが挿入されている
- 不審なページにリダイレクトされる
- 入れた覚えのないプラグインがインストールされている
- サイトが Google で「危険なサイト」と表示される(セーフブラウジング警告)
これらの症状が見つかったら、他のトラブルとは別の対応が必要です。
※【ステップ3】の対応2へ進んでください。
⑥「503エラー」「502エラー」が表示される
サイトURLにアクセスしてもページが表示されず、「502 Bad Gateway」や「503 Error Service Unavailable」といったエラーが出る場合、以下のような原因が考えられます。
- サーバーの過負荷、メンテナンス中、またはネットワーク障害
- ファイアウォール設定などセキュリティ関連の問題
- CDN(コンテンツ配信ネットワーク)に起因する不具合
このように原因は複数あり、すぐに特定するのは難しいケースが多いです。
なお、「502 Bad Gateway」はネットワークを中継するゲートウェイが正しくないレスポンスを受け取り、リクエストを拒否している状態を示します。 一方、「503 Error Service Unavailable」はウェブサーバーが一時的にリクエストを処理できない状態を表すエラーコードです。
【ステップ2】切り分け
不具合を発見したら、次に行うべきは「切り分け」です。切り分けとは、問題の原因や影響範囲を分類・特定するプロセスのことです。
基本的なフローは、再現性のチェック→影響範囲の確認→原因の特定です。
| 再現性のチェック | 同じ操作で不具合が再現するかを確認し、恒常的な問題か一時的なエラーかを切り分けます。 |
|---|---|
| 影響範囲の確認 | サイト全体に影響しているのか、特定ページや機能だけなのかを確認します。影響範囲を明確にすることで、緊急度や対応優先度を判断できます。 |
| 原因の特定 | プラグイン更新、テーマ変更、サーバー環境、外部サービス連携など、発生要因を一つひとつ検証します。 |
再現性のチェック方法
発生した問題が一時的なものか、継続的に起きるものかを確認します。具体的には、問題が発生した際の手順や環境をできるだけ詳しく把握し、同じ条件で操作を繰り返して同じ症状が再現するかを検証します。
また、後から確認できるようにするために内容を記録しておくことが重要です。チェックした手順や表示されたメッセージ内容、発生頻度、デバイス環境情報などを記録に残しておくようにしましょう。
影響範囲のチェック方法
不具合がサイト全体に影響しているのか、特定のページや機能に限定されているのかを確認します。影響範囲を把握することで、優先度や対応方針を決めやすくなるだけでなく、原因の特定にも役立ちます。
影響範囲を調べる際は、全てのページをチェックする必要はなく、ページの種類ごとに順番にチェックしていくと効率的です。
- 管理画面
- トップページ
- 投稿一覧ページ
- 投稿詳細ページ
- カテゴリー一覧ページ
- タグ一覧ページ
- 固定ページ
- カスタム投稿タイプの一覧ページ
- カスタム投稿タイプの詳細ページ
- 特定のテンプレートが読み込まれているページ
- 特定のプラグインが動作しているページ
原因の特定方法
原因を特定する方法としては、以下のような方法があります。
基本的には上から順番に試していくと良いかと思います。
【特定方法1】キャッシュクリア/シークレットモードで確認
WordPressではキャッシュが残っていると、直前の変更内容が反映されない場合があります。そのため、「WP Super Cache」などのキャッシュプラグインを利用してキャッシュを削除し、問題が解消するかを試します。レンタルサーバーによっては、管理画面から直接キャッシュをクリアできる機能が備わっている場合もあります。
さらに、WordPress側のキャッシュだけでなく、ブラウザのキャッシュが影響している可能性もあります。ブラウザのシークレットモードでアクセスするとキャッシュが適用されない状態で表示されるため、挙動を確認する際に有効です。
【特定方法2】ブラウザ、デバイスを変更して確認
特定のブラウザやデバイス依存の不具合かどうかを切り分けるため、別のブラウザやスマートフォン・PCで同じ操作を試します。これにより現在起きている問題が、操作環境に起因するか、Webサーバーに起因するかを特定できます。
【特定方法3】通信環境を変更して確認
問題の原因がネットワーク環境にある場合もあります。LANからWi-Fi、またはWi-Fiからモバイル回線に切り替えるなど、通信環境を変えて同じ操作を試して挙動を確認します。これにより現在起きている問題が、ネットワークに起因するかどうかを特定できます。
ネットワークの問題であれば、システム担当者や保守委託先に連絡して対応を依頼する必要があります。
【特定方法4】ログイン状態を切り替えて確認
ログイン状態によって挙動が変わるケースがあります。
WordPressにログインした状態とログアウトした状態で同じ操作を試し、差異を確認します。
不具合が起きているケースに加えて、不正改ざんされている場合にWebサイト管理者への発覚を遅らせるために、WordPressログイン中のユーザーの場合は正常に動いているように見せる、といった場合も考えられます。
【特定方法5】ログインユーザーを切り替えて確認
ユーザー権限やアカウント設定が原因となる場合があります。管理者アカウントと一般ユーザーアカウントなど、権限の異なるアカウントで同じ操作を行い挙動の違いを確認します。
これにより、現在発生している問題がアカウント依存のものかどうかを特定できます。
【特定方法6】プラグインを無効化する
現在利用しているプラグインを全て無効化して、状況が改善するかどうかを確認します。以下の手順で行います。
- 全てのプラグインを一時的に無効化して状況が改善するかどうかを確認する。状況が改善した場合は、いずれかのプラグインに問題があることがわかります。
- 次に、1つずつプラグインを順番に有効化して、状況が改善するかどうかを確認します。これにより、どのプラグインが原因かを特定できます。
【特定方法7】テーマをデフォルトテーマに戻す
現在のサイトで適用しているWordPressテーマを無効化して、「Twenty Twenty-Five」などのデフォルトテーマを適用します。これで状況が改善した場合は、テーマに問題があるということがわかります。
【特定方法8】デバッグモード「WP_DEBUG」を有効にする
デバッグモードとは、アプリケーション開発においてエラーを特定したり、プログラムの動作を確認したりするために使用するモードです。WordPressは初期状態ではデバッグモードが無効になっているため、特定のスイッチを有効にすることで有効にします。
具体的には、wp-config.php内にある「WP_DEBUG」を有効にします。デバッグモードではwp-content内にあるdebug.logファイルにエラーが出力されるため、内容を確認することで、原因を特定しやすくなります。
|
1 2 3 4 5 6 |
// デバッグモードを有効にする define('WP_DEBUG', true); // エラーや警告を「ログファイル」に記録する設定を有効にする define('WP_DEBUG_LOG', true); // デバッグ情報を画面上に表示する設定を無効にする define('WP_DEBUG_DISPLAY', false); |
【ステップ3】トラブルが起きた際の暫定対応
切り分けによって原因や影響範囲がある程度見えてきたら、次に行うべきは暫定対応です。暫定とは「正式に決定するまでの仮の措置」といった意味合いで、障害対応においては応急措置的な対応を指します。
ここでは、根本的な原因を取り除くのではなく、被害を最小限に抑えつつ復旧への道筋を立てることが目的です。
【対応1】バックアップから復元する
Webサイトのバックアップを取得していれば、トラブルが発生する前の状態に戻すことが可能です。最新のバックアップがあるかを確認し、必要に応じて復元を行います。
エックスサーバーなど、一定期間のバックアップを自動で取得してくれているサーバーがあります。
また、事前に「BackWPup」や「All-in-One WP Migration」などのプラグインを使用してバックアップを取得していた場合は、プラグインを使用してデータを復元できます。
ただし、セキュリティ関連のトラブルでは復元が最善策ではないケース(バックアップ元にも既にバックドアが仕掛けられている場合など)もあります。
一時的に正常に戻ったように見えたとしても、同じトラブルが再発しないか、十分にチェックしましょう。
特に原因がわからない場合には、「現在のエラーが出ている状況のバックアップ」を取得しておくと良いでしょう。正常なバックアップから復元した後に、ファイルを見比べるなどして原因特定することに繋がります。
【対応2】ネットワークから切り離す ※マルウェア感染が疑われる場合
問題の原因として不正アクセスやマルウェア感染が疑われる場合は、被害拡大を防ぐために対象のWordPressサイトやサーバーを一時的にネットワークから切り離すことが有効です。
ネットワークから切り離す対応は「被害を広げないための防御策」として位置づけられ、特にセキュリティ関連のトラブルでは必須のステップとなります。自社で対応することが困難な場合は、セキュリティの専門家や信頼できる制作会社などに相談することをおすすめします。
具体的な方法としては以下が挙げられます。
方法1:レンタルサーバーの機能を使う(最も簡単で確実)
- サーバー管理画面にログインする
- サイト閉鎖機能を探す
「サイト設定」「ドメイン設定」「アクセス制御」「サイト停止」といった項目を探す - アクセスを制限・停止する
サイト全体をパスワード保護したり、「メンテナンス中」画面に切り替えたりする機能があれば利用する。IP制限機能があれば、すべてのIPアドレスからのアクセスを拒否する設定や、自分のIPアドレス(作業を行うPCのIP)のみを許可する設定に変更。
方法2:.htaccessファイルを編集する
FTPソフトなどでサーバーにアクセスし、「.htaccess」のファイルを探し、以下のコードをファイル冒頭に記述します。
|
1 2 |
# すべてのアクセスを拒否する Deny from all |
自分のIPアドレスだけ許可したい場合は以下のコードを記述します。[your_ip_address] の部分を、ご自身のグローバルIPアドレスに置き換えてください(IPアドレスはこちらのサイトなどで確認できます)。
|
1 2 3 4 |
# 自分のIPアドレスのみ許可し、他を拒否 Order Deny,Allow Deny from all Allow from [your_ip_address] |
その他の方法・注意点について
上記以外の方法として、ネームサーバー(DNS)の設定を変更する方法もありますが、復旧時に手間と時間がかかるため推奨はしません。
専門家に判断を仰ぎ、必要な場合のみ実施すると良いでしょう。
なお注意点として、一時的に「メンテナンス中」などの表示にしておくとユーザーに不要な不安を与えずに済みます。
【ステップ4】組織内で経緯を共有する
Webサイトで問題が生じた場合、組織内で状況を共有することが重要です。
どのようなトラブルが起きて、どの程度影響があったのか、などを把握することで関係者が正しい判断ができ、再発防止などの対策にも繋がります。
このような状況を共有するための文書をインシデント報告書と呼びます。
インシデント報告書のテンプレート
インシデント報告書には、以下の内容を記入します。
| 項目名 | 記入内容 |
|---|---|
| インシデント名 | どのような問題だったかがわかる名前を記載します。 |
| 報告者 | 誰が問題を報告したのかを記載します。 |
| 報告日 | 報告した日を記載します。 |
| 発生日時 | いつ問題が発生したのか、またはいつ問題が発覚したのかを、できる限り正確に記載します。 |
| インシデント種類 | システム障害/セキュリティ被害/ヒューマンエラー/その他、など事前にカテゴリを設定しておき、選択できるようにします。 |
| 概要(対応) | どんな問題が起きたのか、具体的に内容を記載します。どのような対応をしたかもできるだけ正確に記載します。 |
| 影響範囲 | 問題が発生したことで、どのような影響が起きたかを記載します。 |
| 発生原因 | なぜ問題が発生したのか、原因を記載します。 |
| 今後の防止策 | 発生原因を踏まえて、今後同じ問題が起きないように防止策を記載します。 |
| 備考 | 上記で書ききれなかった内容があれば記載します。 |
【インシデント報告書の記載例】
「対応して終わり」ではなく再発防止策を立てることが重要
組織内で経緯を共有する際には、問題が起きた状況や原因だけでなく考えられる再発防止策を立てることが重要です。再発防止策を立てることで、今後類似の状況が起きた際に問題が発生するのを防止できます。
例えば、「スタッフがWordPressを誤操作して問題が発生した」といったヒューマンエラーが発生した場合には、再発防止策として「スタッフの操作研修を定期的に行う」「アクセス権限を厳格にして管理職のみが更新できるようにする」などの再発防止策が考えられます。
なぜ恒久対応する前に暫定対応が必要なのか?
WordPressに限らずシステム障害対応の現場では、「恒久対応の前に暫定対応を行う」ことが重要視されます。その理由を整理すると以下のようになります。
被害拡大を防ぐため
トラブルが発生したまま放置すると、ユーザーが誤った操作を続けたり、外部からのアクセスでさらに不具合が広がる可能性があります。暫定対応で一時的に機能を止めたり制限することで、被害範囲を最小化できます。
サービス継続性の確保
サイトが完全に停止している状態では、ユーザーや顧客への影響が大きくなります。暫定対応で最低限の機能を復旧させることで、業務やサービスを継続しながら原因調査を進められます。
原因調査の時間を確保するため
恒久対応には詳細な原因分析や修正作業が必要ですが、それには時間がかかります。暫定対応で「応急処置」をしておけば、その間に落ち着いて調査・修正が可能になります。
信頼維持のため
障害が長時間続くと、ユーザーや顧客からの信頼を損なうリスクがあります。暫定対応で「すぐに動いた」という事実を示すことは、社内外への説明責任を果たす上でも重要です。
wp.geek編集部 解説:トラブルに備えて事前に準備・社内で共有しておくことが重要
WordPressでトラブルが発生した際には、慌てずに「初動対応の流れ」を踏むことで被害を最小限に抑えることができます。そのためには、問題発生時のルールを事前に策定して組織内で共有すると、スムーズに対応できます。
きちんとルールを共有できていないと、担当者が独断で問題を解決しようとして問題を悪化させてしまう可能性もあります。定期的に研修を行うなど確実に周知する工夫も必要です。
WordPress保守・運用のパートナーなら「wp.support」にお任せ!
WordPressサイトを運用していて、以下のようなお悩みはありませんか?
- 管理画面を使いやすくしたいけれど、カスタマイズする時間や技術がない…
- サイトのUI/UXを改善したいけれど、自社内では難しい…
- WordPressサイトを高速化したいけれど、ノウハウがない…
- セキュリティ対策をしたいけれど、知識のある人材がいない…
- 日々の業務に追われて、バージョンアップなどの保守業務が放置気味…
- ちょっとしたトラブルを気軽に相談できる相手が欲しい…
「wp.support」は、WordPressのプロフェッショナル集団によるWordPress保守サービスです。
「セキュリティ対策」「バージョンアップ対応」「定期バックアップ」はもちろん、「電話サポートが無制限」なのでカスタマイズの方法やトラブル発生時にも気軽にプロに相談できます。
既に導入済みのお客様からも、
「些細なことでも気軽に相談できるパートナー的な存在」
「困ったら相談していいんだ、と気持ちが楽になった」
と大変ご好評をいただいています。
WordPress保守・運用のパートナーをお探しなら、ぜひお気軽にお問合せください。
バージョンアップが面倒だと思ったら WordPress保守・セキュリティ対策は『wp.support』にお任せ!
WordPressのバージョンアップやセキュリティ対策にお悩みではないですか?
面倒な保守・運用作業は全て任せて、コア事業に集中してください。
大手・上場企業100社以上のWebサイトの安全を守る、WordPressのプロフェッショナル集団が、あなたのWordPressサイトを守ります!
【対応範囲】
・WordPress、プラグインのバージョンアップ ・セキュリティ対策 ・継続的なバックアップ ・緊急時の復旧対応 ・技術サポート・電話/メールサポート無制限 etc...
WordPressに関することなら何でもご相談ください!




