WordPressサイトに「このサイトは危険です」と表示された時の対処法と警告解除手順

自社のWordPressサイトを開こうとした瞬間、Chrome に赤い警告画面が出て「このサイトは危険です」「Deceptive site ahead」と表示される。あるいは Google 検索結果に警告文が付き、社内外からの連絡で初めて異常に気づくことがあります。

この状態は単なる表示エラーではありません。検索流入がほぼ止まり、問い合わせや成約が消え、取引先や採用候補者からの信用にも直結する重大障害です。

本記事のゴールは次の5点です。

警告が何を意味しているかを理解する
まず何を確認すべきかを順番で把握する
自力で進められる範囲と限界を見極める
専門家に切り替える判断基準を持つ
Google Search Console の再審査リクエストまで完了させる

「このサイトは危険です」警告とは何か

この警告は、主に Google Safe Browsing（危険なサイトや不正ダウンロードを検知して警告する仕組み）によるものです。Google 公式では、Safe Browsing は危険なサイトや危険なファイルへのアクセス時に警告を出し、Search にも警告メッセージを表示すると案内しています。また、Safe Browsing のリストは Chrome を含む主要ブラウザ群で広く参照されています。

警告文は似ていても、意味は少しずつ異なります。

警告パターン	主に示す意味	最初に想定すべきこと
「このサイトは危険です」「Deceptive site ahead」	フィッシング（偽装ログイン等）やソーシャルエンジニアリング判定	偽ログインフォーム、偽決済画面、欺瞞的なポップアップ
「マルウェアを含んでいます」	マルウェア配布判定	悪性 script、iframe、外部から読み込む不正コード
「不要なソフトウェア」（Unwanted Software）	不要ソフトや危険なダウンロード誘導判定	配布ファイルやリンク先の不審判定
「このサイトはハッキングされている可能性があります」	hacked content（不正追加・改ざん）判定	スパムページ生成、コード注入、不正リダイレクト

共通しているのは、根本原因がサイト内部の改ざん、マルウェア混入、または危険コンテンツの設置にあるという点です。見た目だけ戻しても解除にはなりません。

解除の基本は一貫しています。

サイトをクリーンな状態に戻す
侵入経路や再発要因を塞ぐ
Search Console で再審査リクエストを出す

緊急時の最初の3分でやること

この段階で重要なのは、いきなりファイルを消し始めないことです。WordPress 公式の hacked site FAQ でも、侵害発覚時はまず状況を記録するよう案内されています。

1. シークレットウィンドウで再現するか確認する

まずはシークレットウィンドウでトップページ、主要下層ページ、問い合わせページなどを開き、同じ警告が出るかを見てください。

可能なら次も確認します。

別ブラウザ
スマホ
社外回線やテザリング

Google 公式でも、Safe Browsing の警告は閲覧文脈によって再現しないことがあるため、最終判断は Search Console を基準にするべきだと案内しています。

2. site:あなたのドメインで検索結果のラベルを確認する

Google 検索で site:example.com を実行し、次を見ます。

「このサイトはハッキングされている可能性があります」のラベルが付くか
自社と無関係な URL やタイトルが出ていないか
薬、通販、賭博、ログイン偽装など不自然なページがないか

3. Search Console の「セキュリティの問題」を確認する

Google Search Console の セキュリティと手動による対策 → セキュリティの問題 に進みます。ここに、Google が認識している問題種別とサンプル URL が出ます。

ここで見るべきなのは次です。

Deceptive pages
Hacked: Malware
Hacked: Code injection
Hacked: Content injection
Hacked: URL injection
Harmful downloads など

4. Safe Browsing の Site Status で直接判定を確認する

Google の Transparency Report にある Site Status 診断ツールに自社ドメインを入力し、Safe Browsing 上で危険判定が残っているかを確認します。

確認先: https://transparencyreport.google.com/safe-browsing/search

5. Search Console 未連携なら、先に所有権確認を済ませる

警告解除まで進めるには、Search Console で対象サイトの所有権確認が必要です。登録していないと再審査リクエストを出せません。最初の時点で必ず連携しておいてください。

警告メッセージのパターン別「最初に疑うこと」

警告の種類ごとに、最初に見る場所は変わります。

判定	最初に疑うこと	補足
フィッシング判定	偽装ログインフォーム、偽装決済ページ、サポート詐欺風の誘導	`wp-login.php` そっくりの偽ページや外部送信フォーム
マルウェア判定	JS による不正コード配布、悪性ファイル読込、外部 script	`script` `iframe` で外部を呼び出していないか
改ざん判定	身に覚えのないページの大量生成、不正リダイレクト、隠しリンク	`site:` 検索と Search Console のサンプル URL が有効
不審ソフトウェア判定	ダウンロード提供ファイルやリンク先ファイルが危険扱い	圧縮ファイル、実行ファイル、インストーラー配布時は要確認

Google 公式の Security issues report では、Deceptive pages は訪問者をだまして危険な操作をさせるページ、Harmful downloads は危険なダウンロードを提供している状態、Hacked: URL injection は攻撃者が新規ページを生成している状態として整理されています。

改ざん箇所・マルウェアの特定

ここからが復旧の本体です。Google 公式は「問題の一部だけでなく、サイト全体で直す必要がある」と明記しています。

サイト全体のファイル変更日時を確認する

最近更新していないはずのテーマやプラグイン、wp-config.php、.htaccess、ルート直下ファイルの更新日時が急に新しくなっていないか確認します。

uploads 配下などに不審な .php がないかを見る

wp-content/uploads/ は本来、画像や PDF などの保存が中心です。ここに見覚えのない .php がある場合は強い違和感です。

難読化コードや不審な script を検索する

Google 公式は hacked content の確認方法として、ソースやレスポンス内で次のようなコードを探すよう案内しています。

eval
base64_decode
unescape
不審な外部 script
不審な iframe

調査対象は次の順で考えると進めやすいです。

テーマの functions.php header.php footer.php
ルートの index.php
.htaccess
wp-config.php
mu-plugins
データベース内の本文・オプション

WordPress 本体・テーマ・プラグインの更新状況を確認する

WordPress 公式の hardening ガイドでは、旧バージョンの放置を大きなリスクとして扱っています。古い本体、長期間更新されていないプラグイン、出所不明のテーマや nulled テーマ（不正配布テーマ）が残っていないかを確認してください。

認証情報の漏えい可能性を確認する

WordPress 公式 FAQ では、ローカル PC のマルウェア感染も確認対象です。過去に次がなかったかを洗い出してください。

フィッシングメールへの誤入力
FTP 情報の共有や使い回し
退職者アカウントの放置
PC のウイルス・マルウェア感染

phpMyAdmin で wp_users wp_options を確認する

phpMyAdmin（ピーエイチピーマイアドミン: データベースをブラウザから操作するツール）を使えるなら、少なくとも次は確認します。

wp_users
- 覚えのない管理者ユーザーが追加されていないか
wp_options
- siteurl home が書き換わっていないか
- 不審な自動読込オプションがないか

必要に応じて wp_posts も見て、偽装ページや不審本文が生成されていないかを確認します。

やってはいけない対応

復旧を長引かせる対応には共通点があります。表面だけ整えて、根本原因を残すことです。

警告画面が消えた瞬間に「直った」と判断する

Google 公式でも、Safe Browsing とブラウザ、Search Console の反映には時間差があると案内されています。見た目で警告が一時的に出なくなっても、再審査リクエストが終わっていなければ解除完了ではありません。

不審ファイルだけ削除して侵入経路を残す

攻撃者が使った脆弱性や漏えい認証情報が残っていれば再生成されます。

サーバーを別環境へ引っ越して逃げる

同じファイルや DB をそのまま移せば、判定の根本は変わりません。

Search Console に登録せず放置する

Search Console 未登録のままでは、Google が何を問題視しているか把握しにくく、再審査も出せません。これは実務上かなり大きなロスです。

復旧の基本手順

復旧の流れは「保全 → 認証変更 → クリーン化 → 再確認 → 再審査」です。

1. 全ファイルを保全する

最初に、感染済みの状態でも構わないので全ファイルと DB のコピーを取ります。これは復元用というより、比較とフォレンジック（侵入経路調査）のためです。

2. すべての認証情報を変更する

変更対象は次です。

WordPress 管理者
FTP / SFTP
データベース
サーバー管理画面
関連メールアカウント

WordPress 公式では、強く長い一意のパスワードと二要素認証が推奨されています。

3. WordPress 本体・テーマ・プラグインを最新化する

WordPress 公式の hardening ガイドは、旧バージョンを主要リスクとしています。正規配布元からクリーンなファイルを取得し、本体、テーマ、プラグインを見直してください。

4. 不審なファイル・コードを除去する

ここは知識が必要です。Google 公式も、コード注入やマルウェア対応は「コードやサーバー設定を読めるか」が前提になりやすいと明記しています。自信がなければ、この時点で障害復旧サービスに切り替えたほうが安全です。

5. wp-config.php のシークレットキーを再発行する

WordPress 公式 FAQ では、AUTH_KEY などの secret keys（秘密鍵）を更新して既存セッションを無効化するよう案内しています。侵害時に盗まれたログイン状態を切りたい場面では重要です。

6. サイト全体を再スキャンして痕跡がないか確認する

Search Console のサンプル URL だけ直して終わりにせず、次を横断で確認します。

Search Console の例示 URL
site: 検索
主要テンプレート
uploads 配下
wp_users wp_options
不審なダウンロードファイル

7. Search Console で「再審査リクエスト」を提出する

これが最重要です。Google 公式でも、問題を修正したら Security Issues report から Request Review を実行するよう明記しています。これをしない限り、警告解除が完了しないケースがあります。

8. 判定再確認まで待つ

Google 公式では、審査は数日から数週間かかることがあります。

Search Console での再審査リクエスト手順

ここは「掃除したので見てください」だけでは弱いです。Google 公式も、良い審査依頼には3要素が必要だとしています。

手順

Search Console を開く
セキュリティと手動による対策 → セキュリティの問題 に進む
各問題項目を展開する
審査をリクエスト（英語UIでは “Request Review”）を押す

書くべき内容

何が問題だったか
どのように除去したか
侵入経路として何を疑い、何を塞いだか
再発防止として何をしたか

実務上は、次のような粒度で十分です。

不審な PHP ファイルと注入コードを除去
旧プラグインを削除し、WordPress 本体・テーマ・プラグインを更新
すべての認証情報を変更
wp-config.php のシークレットキーを更新
Search Console のサンプル URL とサイト全体を再確認し、問題が残っていないことを確認

提出後の結果は Search Console のメッセージで通知されます。不承認なら、残存箇所を調査して再提出します。

自力対応の限界を判断する基準

次のいずれかに当てはまるなら、自力継続より外部支援に切り替えるべき段階です。

ファイルを直しても警告が消えない
何が改ざんされているのか自分で特定できない
不審ファイルを削除しても再生成される
再審査リクエストを2回出しても承認されない
フィッシングやマルウェア配布判定で、顧客や取引先から連絡が来ている

この状態は、すでに対外影響を伴う障害対応です。判断に迷うなら、障害復旧サービスのように Google 警告解除まで含めて対応できる体制へ切り替えたほうが現実的です。

また、公開状態から見える範囲のリスクを急ぎで整理したい場合は、無料セキュリティ診断で初期確認をしておくと、社内説明もしやすくなります。

再発防止：このタイプの被害を起こさない運用設計

警告解除が終わっても、元の運用に戻すだけでは再発します。WordPress 公式の hardening ガイドに沿うと、最低限の再発防止は次の通りです。

自動バックアップを世代管理で複線化する

1世代だけでは、気づいた時点で汚染済みの可能性があります。ファイルと DB を複数世代で保持し、可能なら保存先も分散します。

WordPress 本体・プラグインの定期更新フローを作る

担当者の気分で更新する運用ではなく、月次や隔週で確認する定例業務に落とし込みます。古いプラグインやテーマを放置しないことが重要です。

ログイン保護を強化する

WordPress 公式では強いパスワードと二要素認証が推奨されています。加えて、次を検討します。

/wp-login.php への IP 制限
Basic 認証
二要素認証

不要プラグイン・nulled テーマを棚卸しする

使っていないプラグインを「停止中だから安全」と考えないことです。不要なら削除し、出所不明のテーマやプラグインは残さないようにします。

サーバー側でファイル変更検知を入れる

WordPress 公式の hardening ガイドでも、ログ監視とファイル変更監視の重要性が説明されています。少なくとも .php などの実行ファイルの追加・変更を検知できる状態にしておくと、初動が速くなります。

uploads ディレクトリでの PHP 実行禁止を検討する

画像アップロード用ディレクトリに PHP 実行が不要な構成なら、サーバー設定側で制限する価値があります。これだけで万能ではありませんが、被害の広がりを抑える一手になります。

Search Console の「セキュリティの問題」を月次確認する

月次で セキュリティと手動による対策 を確認し、site: 検索も定期点検に組み込んでください。

社内でこの運用を継続しにくいなら、復旧後の再発防止フェーズとして運用保守サービスに移すのも現実的です。

まとめ

WordPress サイトに「このサイトは危険です」と表示されたとき、本当に重要なのは、その背後にある改ざんやマルウェア混入を取り切ることです。

警告が見えなくなっても、Search Console の再審査リクエストが承認されるまで解除完了ではありません。一度 Safe Browsing の対象になると流入回復には時間がかかるため、侵入経路の遮断、認証情報の更新、監視設計まで含めた再発防止が最重要です。

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

Google Safe Browsing
https://safebrowsing.google.com/
Google Safe Browsing Transparency Report（自サイトの判定確認）
https://transparencyreport.google.com/safe-browsing/search
Google Safe Browsing API ドキュメント
https://developers.google.com/safe-browsing
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
Mozilla Support: How does built-in Phishing and Malware Protection work?
https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work
WordPress 公式 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/

※本記事は2026年4月時点の公開情報を基に作成しています。各サービスのUI・仕様は変更されることがあるため、最新情報は各公式ページで確認してください。