WordPress障害が起きたときは、焦って触るほど復旧が長引きます。このページは、緊急時に最初に開いて上から順番に進めるための実務用チェックリストです。ブックマーク前提で、実行確認しやすいよう - [ ] 形式で整理しています。

まずは自分のケースの緊急度を決め、その後はフェーズごとにチェックを進めてください。読み物ではなく、現場で使うツールとして設計しています。

緊急度の自己判定マトリクス

最初に「いま何が起きているか」を分類します。ここが曖昧だと、不要な操作が増えます。

症状 典型例 緊急度 初動の考え方
サイト全停止 トップも管理画面も開かない、500エラー、DB接続エラー 重大 サーバー障害か設定破損かを最優先で切り分けます
改ざん・不正リダイレクト 勝手に別サイトへ飛ぶ、不審なページが増えた 重大 侵害前提で証跡保全と被害拡大防止を優先します
Google警告 「危険なサイト」「このサイトはハッキングされている可能性があります」 重大 Search Console確認と改ざん有無の確認を急ぎます
ログイン不可 管理画面だけ入れない、知らない管理者がいる 重要 認証情報漏えい・管理者乗っ取りを疑います
動作異常 一部ページのみ崩れる、更新後に一部機能が動かない 中程度 直前変更とプラグイン・テーマ差分を優先確認します
軽微な表示不具合 画像欠け、CSS崩れ、特定端末のみ発生 軽微 キャッシュ・配信差分・ブラウザ依存を先に見ます

迷ったら、実害が大きいほうに寄せて判定してください。 とくに「改ざんかもしれないが断定できない」段階でも、重大インシデント扱いで動くほうが安全です。

第1フェーズ：最初の5分（状況固定）

この5分でやることは修正ではなく、事実確認と記録です。WordPress.org の hacked site FAQ でも、最初に症状・時刻・直前変更を文書化することが推奨されています。

  • /wp-admin/

主要レンタルサーバーでは、障害情報の確認導線だけで原因が判明することがあります。少なくとも、エックスサーバー、ConoHa WING、さくら、ロリポップは先に公式の障害情報を見てください。

サーバー 先に見る場所 補足
エックスサーバー 公式の障害・メンテナンス情報 サーバー番号単位で影響範囲が出ることがあります
ConoHa WING コントロールパネル上部の「お知らせ」→「障害情報」 サービス切替を間違えると別サービスのお知らせを見てしまいます
さくらのレンタルサーバ 公式サポートのメンテナンス・障害情報 対象ホスト名で影響範囲が出ることがあります
ロリポップ！ 公式の障害情報ページと公式SNS phpMyAdmin や FTP まで影響範囲に含まれることがあります

Don’ts：最初の5分でやってはいけないこと

  • バックアップなしでいきなりファイルを上書きしない
  • 不審ページを何度も開き直さない
  • 原因未確認のままプラグインを片っ端から削除しない
  • 社内チャットで推測を断定口調で流さない
  • 「自分のPCだけの問題かも」と思って記録を残さないまま作業しない

第2フェーズ：5〜30分（被害拡大の防止）

ここでは「元に戻す」より先に、「これ以上悪化させない」ことを優先します。WordPress.org では、侵害が疑われる場合はバックアップ取得、全アクセス経路の見直し、秘密鍵の更新、ホスティング会社への確認が基本線です。

  • 侵害が疑われる場合は wp-config.php

バックアップは「復元用」だけでなく「証跡保全」の意味があります。 先に全部消してしまうと、原因調査と再発防止が難しくなります。

自力で進めるか迷う段階でも、停止時間が長引きそうなら早めに障害復旧サービスを検討してください。改ざんの可能性を外部からざっと確認したい場合は、無料セキュリティ診断で初期確認の材料を揃えるのも有効です。

第3フェーズ：30分〜2時間（一次切り分け）

ここからは症状別に分岐します。全部を一度に触るのではなく、症状に合った記事へ移動して一本ずつ切り分けるのが最短です。

改ざん・不正リダイレクトが疑わしい場合

  • .htaccess wp-config.php functions.php index.php mu-plugins
  • 詳細手順は リダイレクトハック復旧記事

真っ白画面・500系エラーの場合

  • 詳細手順は WSOD記事

データベース接続エラーの場合

  • wp-config.php の DB_NAME DB_USER DB_PASSWORD DB_HOST
  • 詳細手順は DB接続エラー記事

Google警告が出ている場合

  • 詳細手順は Safe Browsing警告記事

SEOスパム・不審ページ大量生成の場合

  • site:自社ドメイン
  • 詳細手順は Japanese Keyword Hack記事

補足として、Google のセキュリティ問題は Search Console の「Request Review」からレビュー申請を進めます。ヘルプ上はこれも reconsideration request の文脈で案内されていますが、実務では「セキュリティの問題」と「手動による対策」を混同しないことが重要です。表示されているレポートに合わせて申請先を選んでください。

第4フェーズ：2〜24時間（復旧 or 専門家への引き継ぎ判断）

2時間触っても原因が絞れない場合は、闇雲に操作を増やさないでください。ここでは「自力継続が合理的か」を判断します。

次のどれかに当てはまるなら、自力継続より専門家への引き継ぎを優先してください。

判断基準 引き継ぎを急いだほうがよい理由
バックアップがない 失敗時に復元できず、被害が拡大しやすい
改ざんが疑われる 見えていない侵入経路や再感染要因が残りやすい
EC・会員情報を扱う 情報漏えい対応が必要になる可能性がある
2時間以上たっても切り分け不能 停止損失のほうが大きくなりやすい
Search Console で警告が出ている 復旧だけでなくレビュー申請まで必要になる

この段階なら、障害復旧サービスへ切り替えるほうが早いケースが多いです。復旧後に監視や更新体制を整える必要があるなら、運用保守サービスも合わせて検討してください。依頼時は、のちに公開予定の復旧依頼テンプレートを使うと情報整理がしやすくなります。

インシデント記録テンプレート（コピペ可）

社内記録や制作会社・復旧担当への共有には、最低限これだけあれば初動が速くなります。

## WordPress障害インシデント記録

- 発生時刻:
- 検知方法:
- 症状:
- 影響範囲:
- 直前変更:
- 取った対応:
- 結果:
- 復旧時刻:

必要に応じて「確認した環境」「障害情報URL」「Search Console 警告内容」「連絡済みの関係者」も追記してください。

フェーズ別の禁止事項まとめ

やりがちですが、復旧を遅らせる行動をまとめます。緊急時ほど、この表を見返してください。

フェーズ やってはいけないこと 危険な理由
最初の5分 記録を残さず触り始める 症状固定ができず、再現条件が消えます
最初の5分 エラーを見てすぐにプラグイン削除 原因の特定が難しくなります
5〜30分 バックアップなしで復元・上書き 失敗時に戻せません
5〜30分 WordPress管理者だけパスワード変更して安心する FTP/SFTP、サーバーパネル、DB、メールが残ると再侵入されます
30分〜2時間 すべての可能性を同時に触る 何が効いたか分からず、切り分け不能になります
30分〜2時間 改ざん疑いなのに見た目だけ直して終える 再感染しやすく、Google警告も残りやすいです
2〜24時間 2時間以上詰まっているのに社内だけで抱える 停止損失とブランド毀損が拡大します

改ざん時の注意点は、公開予定の改ざん時にやってはいけないことにも今後まとめる予定です。

ブックマーク・印刷用の使い方

このページは、障害が起きてから検索で探すのではなく、先にブックマークしておく使い方を想定しています。社内のブックマーク共有、運用マニュアル、制作会社との連携資料に組み込んでください。

印刷して使いたい場合は、ブラウザの「印刷」から「PDFで保存」を選ぶと、そのまま社内配布用のチェックシートとして使えます。とくに複数人で運用している場合は、誰が見ても同じ順番で動ける状態を作っておくと、初動のばらつきが減ります。

参考情報（公式・一次情報）

※本記事は2026年4月27日時点で確認できる公開情報に基づいて作成しています。管理画面の名称や導線は変更されることがあるため、実作業時は各社の最新画面を確認してください。