【保存版】WordPress障害発生時の初動対応チェックリスト
2025.12.15（更新: 2026.06.04）
目次
WordPress障害が起きたときは、焦って触るほど復旧が長引きます。このページは、緊急時に最初に開いて上から順番に進めるための実務用チェックリストです。ブックマーク前提で、実行確認しやすいよう - [ ] 形式で整理しています。
まずは自分のケースの緊急度を決め、その後はフェーズごとにチェックを進めてください。読み物ではなく、現場で使うツールとして設計しています。
緊急度の自己判定マトリクス
最初に「いま何が起きているか」を分類します。ここが曖昧だと、不要な操作が増えます。
| 症状 | 典型例 | 緊急度 | 初動の考え方 |
|---|---|---|---|
| サイト全停止 | トップも管理画面も開かない、500エラー、DB接続エラー | 重大 | サーバー障害か設定破損かを最優先で切り分けます |
| 改ざん・不正リダイレクト | 勝手に別サイトへ飛ぶ、不審なページが増えた | 重大 | 侵害前提で証跡保全と被害拡大防止を優先します |
| Google警告 | 「危険なサイト」「このサイトはハッキングされている可能性があります」 | 重大 | Search Console確認と改ざん有無の確認を急ぎます |
| ログイン不可 | 管理画面だけ入れない、知らない管理者がいる | 重要 | 認証情報漏えい・管理者乗っ取りを疑います |
| 動作異常 | 一部ページのみ崩れる、更新後に一部機能が動かない | 中程度 | 直前変更とプラグイン・テーマ差分を優先確認します |
| 軽微な表示不具合 | 画像欠け、CSS崩れ、特定端末のみ発生 | 軽微 | キャッシュ・配信差分・ブラウザ依存を先に見ます |
迷ったら、実害が大きいほうに寄せて判定してください。 とくに「改ざんかもしれないが断定できない」段階でも、重大インシデント扱いで動くほうが安全です。
第1フェーズ：最初の5分（状況固定）
この5分でやることは修正ではなく、事実確認と記録です。WordPress.org の hacked site FAQ でも、最初に症状・時刻・直前変更を文書化することが推奨されています。
- スマホ・別ブラウザ・シークレットウィンドウ・別IPで再現確認する
- 発生時刻を記録する（タイムゾーンも残す）
- どのURLで、どの症状が出たかを記録する
- 直前の変更内容（更新・移行・設定変更・DNS変更・広告配信開始など）を書き出す
- スクリーンショットを保存する（エラー画面・該当ページ・警告表示）
-
/wp-admin/も同じ症状か確認する - Google Search Console に入れる場合は「セキュリティの問題」レポートを確認する
- サーバー会社の障害情報ページと公式Xアカウントを確認する
- 社内・関係者に「確認中であること」だけ先に共有し、独断で触らないよう伝える
主要レンタルサーバーでは、障害情報の確認導線だけで原因が判明することがあります。少なくとも、エックスサーバー、ConoHa WING、さくら、ロリポップは先に公式の障害情報を見てください。
| サーバー | 先に見る場所 | 補足 |
|---|---|---|
| エックスサーバー | 公式の障害・メンテナンス情報 | サーバー番号単位で影響範囲が出ることがあります |
| ConoHa WING | コントロールパネル上部の「お知らせ」→「障害情報」 | サービス切替を間違えると別サービスのお知らせを見てしまいます |
| さくらのレンタルサーバ | 公式サポートのメンテナンス・障害情報 | 対象ホスト名で影響範囲が出ることがあります |
| ロリポップ！ | 公式の障害情報ページと公式SNS | phpMyAdmin や FTP まで影響範囲に含まれることがあります |
Don'ts：最初の5分でやってはいけないこと
- バックアップなしでいきなりファイルを上書きしない
- 不審ページを何度も開き直さない
- 原因未確認のままプラグインを片っ端から削除しない
- 社内チャットで推測を断定口調で流さない
- 「自分のPCだけの問題かも」と思って記録を残さないまま作業しない
第2フェーズ：5〜30分（被害拡大の防止）
ここでは「元に戻す」より先に、「これ以上悪化させない」ことを優先します。WordPress.org のFAQでは、侵害が疑われる場合のバックアップ取得、全アクセス経路の見直し、秘密鍵の更新、必要に応じたホスティング会社への確認が案内されています。
- 現在状態のバックアップを取る（感染状態でも証跡として残す）
- サーバー会社に障害・侵害の有無を確認する
- 直近バックアップの取得日時と保存先を確認する
- 全管理者パスワードを変更すべき状況か判断する
- 変更する場合は、WordPress管理者だけでなく FTP/SFTP、サーバーパネル、DB、関連メールアカウントも対象にする
- 侵害が疑われる場合は
wp-config.phpのシークレットキー再発行が必要か判断する - FTP/SFTPアクセスログ、サーバーログ、WAFログが見られるなら確認する
- 知らない管理者ユーザーが増えていないか確認する
- 作業に使っているPCもマルウェアスキャン対象に入れる
- ハッキングが疑わしい場合は、決済情報・個人情報・会員情報の漏えい可能性を確認する
- ECや会員制サイトなら、必要に応じて決済代行会社・社内法務・情報システム担当へ連絡する
バックアップは「復元用」だけでなく「証跡保全」の意味があります。 先に全部消してしまうと、原因調査と再発防止が難しくなります。
自力で進めるか迷う段階でも、停止時間が長引きそうなら早めにWordPress改善復旧を検討してください。改ざんの可能性を外部からざっと確認したい場合は、お問い合わせで初期確認の材料を揃えるのも有効です。
第3フェーズ：30分〜2時間（一次切り分け）
ここからは症状別に分岐します。全部を一度に触るのではなく、症状に合った記事へ移動して一本ずつ切り分けるのが最短です。
改ざん・不正リダイレクトが疑わしい場合
- Search Console のセキュリティ警告と例示URLを確認する
-
.htaccesswp-config.phpfunctions.phpindex.phpmu-pluginsなどの不審変更を確認する - 身に覚えのない管理者ユーザーや不審ファイルの有無を確認する
- 詳細手順は リダイレクトハック復旧記事 を参照する
真っ白画面・500系エラーの場合
- 直前に更新したプラグイン・テーマ・PHPバージョン変更がないか確認する
- エラーログが見られる場合は PHP Fatal error の有無を確認する
- 詳細手順は WSOD記事 を参照する
データベース接続エラーの場合
-
wp-config.phpのDB_NAMEDB_USERDB_PASSWORDDB_HOSTを照合する - phpMyAdmin に入れるか確認する
- サーバー側のDB障害情報を確認する
- 詳細手順は DB接続エラー記事 を参照する
Google警告が出ている場合
- Search Console の「セキュリティの問題」レポートを最優先の確認元として扱う
- 改ざんが直ったかの確認は、例示URLだけでなくサイト全体で行う
- 警告解除は、修正後に Search Console からレビュー申請を行う前提で進める
- 詳細手順は Safe Browsing警告記事 を参照する
SEOスパム・不審ページ大量生成の場合
-
site:自社ドメイン検索で不審URLが増えていないか確認する - Search Console のインデックス状況とセキュリティの問題を確認する
- 詳細手順は Japanese Keyword Hack記事 を参照する
補足として、Google のセキュリティ問題は Search Console の「審査をリクエスト」からレビュー申請を進めます。ヘルプ上はこれも reconsideration request の文脈で案内されていますが、実務では「セキュリティの問題」と「手動による対策」を混同しないことが重要です。表示されているレポートに合わせて申請先を選んでください。
第4フェーズ：2〜24時間（復旧 or 専門家への引き継ぎ判断）
2時間触っても原因が絞れない場合は、闇雲に操作を増やさないでください。ここでは「自力継続が合理的か」を判断します。
- 自力で復旧見込みが立つか判定する
- 立たない場合は、これまでの記録・スクリーンショット・時刻・直前変更・試したことを整理する
- サーバー会社から得た回答、障害情報URL、ログの有無をまとめる
- Search Console 警告の有無、管理画面ログイン可否、バックアップ世代を整理する
- 外部へ依頼する場合に必要なアクセス情報を整理する
- 依頼先へ「症状」「発生時刻」「直前変更」「現在やったこと」を一文で説明できる状態にする
次のどれかに当てはまるなら、自力継続より専門家への引き継ぎを優先してください。
| 判断基準 | 引き継ぎを急いだほうがよい理由 |
|---|---|
| バックアップがない | 失敗時に復元できず、被害が拡大しやすい |
| 改ざんが疑われる | 見えていない侵入経路や再感染要因が残りやすい |
| EC・会員情報を扱う | 情報漏えい対応が必要になる可能性がある |
| 2時間以上たっても切り分け不能 | 停止損失のほうが大きくなりやすい |
| Search Console で警告が出ている | 復旧だけでなくレビュー申請まで必要になる |
この段階なら、WordPress改善復旧へ切り替えるほうが早いケースが多いです。復旧後に監視や更新体制を整える必要があるなら、WordPress月額保守プランも合わせて検討してください。依頼時は、のちに公開予定の復旧依頼テンプレートを使うと情報整理がしやすくなります。
インシデント記録テンプレート（コピペ可）
社内記録や制作会社・復旧担当への共有には、最低限これだけあれば初動が速くなります。
## WordPress障害インシデント記録
- 発生時刻:
- 検知方法:
- 症状:
- 影響範囲:
- 直前変更:
- 取った対応:
- 結果:
- 復旧時刻:
必要に応じて「確認した環境」「障害情報URL」「Search Console 警告内容」「連絡済みの関係者」も追記してください。
フェーズ別の禁止事項まとめ
やりがちですが、復旧を遅らせる行動をまとめます。緊急時ほど、この表を見返してください。
| フェーズ | やってはいけないこと | 危険な理由 |
|---|---|---|
| 最初の5分 | 記録を残さず触り始める | 症状固定ができず、再現条件が消えます |
| 最初の5分 | エラーを見てすぐにプラグイン削除 | 原因の特定が難しくなります |
| 5〜30分 | バックアップなしで復元・上書き | 失敗時に戻せません |
| 5〜30分 | WordPress管理者だけパスワード変更して安心する | FTP/SFTP、サーバーパネル、DB、メールが残ると再侵入されます |
| 30分〜2時間 | すべての可能性を同時に触る | 何が効いたか分からず、切り分け不能になります |
| 30分〜2時間 | 改ざん疑いなのに見た目だけ直して終える | 再感染しやすく、Google警告も残りやすいです |
| 2〜24時間 | 2時間以上詰まっているのに社内だけで抱える | 停止損失とブランド毀損が拡大します |
改ざん時の注意点は、公開予定の改ざん時にやってはいけないことにも今後まとめる予定です。
ブックマーク・印刷用の使い方
このページは、障害が起きてから検索で探すのではなく、先にブックマークしておく使い方を想定しています。社内のブックマーク共有、運用マニュアル、制作会社との連携資料に組み込んでください。
印刷して使いたい場合は、ブラウザの「印刷」から「PDFで保存」を選ぶと、そのまま社内配布用のチェックシートとして使えます。とくに複数人で運用している場合は、誰が見ても同じ順番で動ける状態を作っておくと、初動のばらつきが減ります。
参考情報（公式・一次情報）
- WordPress.org: FAQ My site was hacked
https://wordpress.org/documentation/article/faq-my-site-was-hacked/ - WordPress Developer Resources: Hardening WordPress
https://developer.wordpress.org/advanced-administration/security/hardening/ - Google Search Console Help: Security issues report
https://support.google.com/webmasters/answer/9044101 - Google Search Console Help: Reconsideration requests
https://support.google.com/webmasters/answer/35843 - エックスサーバー: 障害・メンテナンス情報
https://www.xserver.ne.jp/support/information.php - ConoHaサポート: お知らせを確認する
https://support.conoha.jp/c/information/ - さくらインターネット: メンテナンス・障害情報・機能追加
https://support.sakura.ad.jp/mainte/mainteentry.php - ロリポップ！: 障害情報
https://lolipop.jp/info/obsta/
※本記事は2026年6月4日時点で確認できる公開情報に基づいて作成しています。管理画面の名称や導線は変更されることがあるため、実作業時は各社の最新画面を確認してください。
