Google検索コンソールのセキュリティ&手動対策警告は、Googleがあなたのサイトにスパム、不正なソフトウェア、ハッキングされたコンテンツ、詐欺ページ、または品質ガイドライン違反を検出したことを示します。復旧のためにはまず警告の種類を正確に読み取り、影響を受けたURLやサーバーログを調査し、脆弱性を修正、悪質・ガイドライン違反のコンテンツを除去、技術的SEOチェックを完了し、その後Google検索コンソールから証拠を添えて再審査リクエストを送信します。
このガイドはHostragonsブログ向けの実践的な復旧プランです。目的は警告を消すことだけでなく、同じ問題が再発しないよう、ホスティング・CMS・プラグイン・SSL・バックアップ・アクセス権・コンテンツ管理まで永続的に安全な運用体制を構築することです。特にWordPressや独自開発サイト、ECサイト、企業サイトを管理している方向けに、実施可能・計測可能・SEOへの影響を抑えたステップを整理しました。
Google検索コンソール「セキュリティ&手動対策」警告とは?
このセクションは主に2つの警告をカバーします:セキュリティ問題と手動対策。セキュリティ問題は、サイトがユーザーにリスクを与える状況で表示されます。例えばマルウェア、不正ダウンロード、フィッシング、ハッキングされたコンテンツ、詐欺的リダイレクトなどが検出される場合です。手動対策は、Google品質チームがサイトの一部または全体にペナルティを課したことを示します。これにより自然検索での露出が激減する可能性があります。
両者は似ていますが、対応のアプローチが異なります。セキュリティ問題ではまず攻撃の停止・ファイルのクリーンアップ・ユーザー保護が最優先。手動対策ではガイドライン違反の修正、スパムシグナルの排除、Googleへの具体的な修正報告が求められます。どちらの場合も「ただ再審査リクエストを急いで送る」だけでは不十分です。まず根本原因を特定し、恒久的な対策を施しましょう。
警告の種類とSEOへの影響
警告を受け取ったら、まず検索コンソールの通知文と範囲を正確に確認しましょう。一部URLだけが影響を受ける場合もあれば、全サイトが対象となる場合もあります。サイト全体の手動対策が課されると、トラフィックが数日間で30%〜90%も減少することがあります。セキュリティ警告の場合はGoogle検索やChromeで赤い警告画面が表示され、クリック率はほぼゼロに近づきます。
| 警告の種類 | 主な原因 | SEOへの影響 | 初動対応 |
|---|---|---|---|
| マルウェア | 悪意あるファイル、スクリプト、壊れたプラグイン | 検索結果の警告、トラフィック減 | ファイルスキャン&クリーンバックアップとの比較 |
| ハッキングされたコンテンツ | 隠しスパムページ、Japanese keyword hack、クローク | インデックス汚染・順位低下 | URLチェック、サイトマップ・サーバーログ分析 |
| 詐欺ページ | フィッシング、偽ログイン、詐欺フォーム | ブラウザブロック・信頼失墜 | 疑わしいページ・フォームコード除去 |
| 人工リンク | 購入リンク、リンクネットワーク、過剰アンカー | 順位低下(手動ペナルティ) | バックリンク精査・除去またはdisavow |
| スパムコンテンツ | 自動生成ページ、ドアウェイページ、コピー | ページまたはサイト全体ペナルティ | コンテンツ削除、noindex、書き直し |
1. 焦らず証拠を集める
警告を見た瞬間にサイトを無計画に削除したり、全プラグインを停止したり、すぐ再審査リクエストを送るのはNGです。まず現状を記録しましょう。検索コンソールの警告画面をスクショ、警告日時の記録、影響URLリストの作成、過去30日間のサイト変更履歴をまとめます。新規プラグイン導入、テーマ更新、ホスティング移転、広告コード追加、エディターアクセス、バックリンク施策、外部業者の介入などもリストアップしましょう。
復旧経験者にとって最重要データは「時系列」です。例:3/12にプラグイン更新、3/14に不明なPHPファイル出現、3/16にGoogleの警告発生→原因はプラグインの脆弱性やFTPアクセスが有力。修正開始前にログ・ファイルのタイムスタンプ・アクセス履歴を保存しましょう。
チェックリスト
- 検索コンソール警告文とサンプルURLの保存
- 直近7・14・30日のオーガニックトラフィック推移確認
- ホスティングパネルでファイル変更日時チェック
- FTP、SSH、CMS管理者、DBユーザーのリストアップ
- 最新バックアップの日時とクリーン状態の確認
- サイトマップ、robots.txt、.htaccessのバックアップ
2. セキュリティ問題時はサーバー&ファイル解析を
セキュリティ警告の場合、CMSパネルだけでは不十分です。攻撃者は多くの場合wp-content/uploadsフォルダにPHPファイルを追加、.htaccessに隠しリダイレクトを記述、index.phpへ難読化JavaScript埋め込み、DBのコンテンツ欄に悪意iframeを挿入します。WordPressならコアファイルを公式パッケージと比較、独自開発ならGitやクリーンバックアップでdiff分析を。
サーバー側では200, 301, 302, 403, 500の各ステータスコードを確認。あるURLが一般ユーザーには正常でもGooglebotには異なるコンテンツを返す場合、クロークと呼ばれ、セキュリティ・手動対策両方のリスク増大。ログに不明IPの大量POST、admin-ajax.phpの過剰利用、wp-login.phpへのブルートフォース、ランダムPHPへのアクセスがあれば攻撃継続中の可能性。
要チェックファイル・領域
- index.php、wp-config.php、functions.php、.htaccess
- Uploadsフォルダ内の実行可能PHP/phtml/疑わしいjsファイル
- DB内のbase64、eval、script、iframe、不明外部ドメインレコード
- テーマのheader、footer、テンプレートファイル
- Cron、未知ユーザー、APIキー
- Google Tag Manager、広告スクリプト、外部ウィジェットコード
この段階で高品質なホスティングは大きな差を生みます。アカウント分離構造、最新PHP、WAF、マルウェアスキャン、定期バックアップで復旧時間は数時間に短縮。詳細は Hostragons ウェブホスティング およびコントロール重視プロジェクトには Hostragons VPSサーバー をご覧ください。
3. ハッキングコンテンツ&インデックス汚染のクリア
ハッキングされたコンテンツ警告は必ずしもトップページに現れません。サイト下層に数千のスパムURLが生成される場合も。特に日本語、ギャンブル、医薬品、偽サポート、クーポン系が頻出。検索コンソールの「ページインデックス」レポート、site:yourdomain.com検索、サーバーログ、サイトマップで総合チェック。サイトマップに自分が作成していないURLがあれば攻撃者が自動生成している可能性。
クリーニングの目標は3つ:悪質コンテンツ除去、再生成防止、Googleへの正しいシグナル。完全削除したスパムページは404または410返却。価値あるページのスパムコードは除去し、200で維持。全スパムURLをトップページへ301リダイレクトするのは逆効果。品質シグナルがさらに低下します。
インデックスクリア実践ステップ
- スパムURLリスト作成&カテゴリ分け
- 実ページはクリーニング、偽ページは410 Goneで削除
- サイトマップをクリーン&正規URLのみで再構築
- robots.txtで重要クリーニング領域を誤ってブロックしない
- 検索コンソールURL検査で主要ページの再クロール申請
- スパム生成ファイルやDBレコードを発見しない限り完了と見なさない
4. 手動対策時は品質ガイドラインに沿った修正を
手動対策は主にコンテンツやリンク品質の問題です。Googleの目的はユーザーを操作的な結果から守ること。よって表面的な症状だけでなく、操作の原因となるプロセス自体を変える必要あり。人工リンクペナルティの場合、数件のバックリンク除去では不十分。リンク購入施策の停止、スポンサードリンクのrel="sponsored"設定、不自然なアンカーテキストの除去が求められます。
薄いコンテンツや自動生成コンテンツ警告ではページ数も鍵。1万ページ中7千ページがユーザー価値を持たない場合、Googleはサイト全体を低品質と認識。各URLごとに決断:改善・統合・noindex・削除。商品バリエーション、タグアーカイブ、検索結果ページ、フィルターURLなどで問題が頻発。
手動対策修正例
- 不自然な被リンク:Ahrefs、Semrush、検索コンソール、サーバーリファラーでリンク元収集。除去可能なものは除去、残りはdisavowファイルへ。
- 不自然な発リンク:販売・相互リンク除去。広告的リンクはsponsoredまたはnofollowへ。
- スパムコンテンツ:自動生成・コピー・価値のないページは削除または専門編集で書き直し。
- 隠しテキスト・キーワード詰め込み:CSS隠しテキスト、無関係キーワードブロック、操作的フッターリンク除去。
- ユーザー生成スパム:コメント・フォーラム・プロフィールでモデレーション、captcha、nofollowルール適用。
5. アクセス権のリセット&インフラ強化

クリーニング後、最も重要なステップは再感染防止。攻撃者の経路が残れば、警告を消しても数日後再発します。全管理者のパスワード変更、不要アカウント削除、2段階認証設定、FTP→できればSFTP利用。DBユーザー権限も必要最小限に。
CMS、テーマ、プラグインの更新は後回し厳禁。ただし更新前に完全バックアップを。古いPHPバージョンも重大リスク。2026年以降、セキュリティサポート終了PHPはパフォーマンス・安全性両面で弱点。SSL証明書も必須。HTTPSは順位シグナルだけでなく、ユーザー信頼・データ整合性の基盤。SSLの詳細は Hostragons SSL証明書 で確認できます。
恒久的セキュリティ対策
- 週次ファイル・DBバックアップ、重要サイトは日次バックアップ
- WAF&マルウェアスキャン導入
- 管理パネルログイン試行回数制限
- ファイル書き込み権限を最小、777パーミッション禁止
- PHPバージョンは最新、不要モジュール停止
- ドメインDNS記録を定期チェック。ドメイン管理には Hostragons ドメイン検索 を利用可能。
6. 技術的SEOチェックの完了
セキュリティ復旧後、検索エンジンが正しくクロールできる状態かを確認。robots.txtが全サイトを誤ってブロック、noindexタグ残存、canonicalタグミスなどがあれば警告が消えてもトラフィック回復しません。復旧プランに技術SEOチェックを組み込みましょう。
まずトップページ、カテゴリページ、主要コンテンツ、コンバージョンページでURL検査ツールを活用。Googleが見ているHTMLとユーザーが見るHTMLが同じか確認。次にサイトマップを再提出。余計なパラメータURLのインデックス化防止。404, 410, 301, 302の各ステータスコードを論理的に整理。復旧後2週間はクロール統計・インデックスレポート・パフォーマンスグラフを日次で追跡。
復旧後モニターすべき指標
- 「セキュリティ&手動対策」セクションの警告状況
- インデックス済クリーンページ数&除外スパムURL数
- オーガニッククリック数・表示回数・平均順位・CTR推移
- サーバー応答速度&5xxエラー率
- Googlebotクロール頻度&クロール目的
- ブランド検索時に警告が表示されていないか
7. 再審査リクエストの書き方
再審査リクエストはGoogleへ送る短く明確な修正報告です。この文章で防御的・曖昧・マーケティング的表現はNG。Google担当者は「何が起きたか」「原因は何か」「どのURLが直ったか」「再発防止策は何か」を知りたい。早すぎるリクエスト送信は通常却下されます。却下後再申請は可能ですが、その度審査期間が延びます。
良い再審査リクエストは4部構成。1:問題を認める、2:根本原因説明、3:修正内容を箇条書き、4:再発防止策提示。被リンクペナルティなら除去努力・連絡日時・disavow説明。セキュリティ問題ならクリーニング済ファイル種・削除ユーザー・更新プラグイン・導入済セキュリティ対策を書く。
再審査リクエスト例文(骨組み)
当サイトでGoogleガイドライン違反のセキュリティ問題が発生しました。調査で古いプラグイン経由の不正ファイルアップロードと、一部URLでスパム生成が判明。関連プラグインを削除、コアファイルをクリーンバックアップと比較、スパムURLは410で削除、サイトマップを再構築、全管理者パスワード変更・二段階認証導入。サーバーログを精査し、不審IPをブロック、定期マルウェアスキャンを開始。今後再発防止のため更新・バックアップ・アクセス管理ポリシーを策定しました。再審査をお願いいたします。
自身の状況に合わせ、一般的表現ではなくファイルパス・日時・URL数・修正数など具体データを追加すると信頼感が高まります。例:326件のスパムURLを410化、4件の不正ユーザー削除、17件のプラグイン更新、2件の不要テーマ除去など。E-E-A-T観点からも強いシグナルとなります。
8. トラフィックはいつ回復する?
警告が消える=トラフィック完全復活ではありません。セキュリティ問題ならGoogle再クロール後数日〜数週間で警告解除。手動対策は審査期間が長め。警告解除後Googleがページを再クロール、品質シグナル再計算、ユーザー行動データ再集計が必要。競合状況・サイト規模・被害度合いによって2週間〜3ヶ月かかることも。
回復期間中は過激なSEO施策は避けましょう。大量新規コンテンツの一斉公開、急激なバックリンク取得、URL構造の全面変更などは復活を困難にします。優先すべきは「信頼性・速度・技術的クリーンさ・ユーザー価値」。収益やリードに直結するページの更新、専門性を示すコンテンツ追加、内部リンクの自然強化、ブランド信頼を高める会社概要・プライバシーポリシー・サポートページの充実を図りましょう。
9. よくある失敗例
対応ミスは警告解除遅延・オーガニックパフォーマンスへの深刻なダメージを招きます。最も多いのは「根本原因を特定せず見える悪質コードだけ削除」。次に「スパムURLを全てトップページへリダイレクト」。三つ目は「手動対策で表面的な説明のみで再審査申請」。Google担当者は曖昧・証拠なしの申請をほぼ却下します。
- クリーンでないバックアップ復元=問題再発
- robots.txtでGoogleに悪質ページを隠し、クリーニング確認を妨げる
- disavowファイルに全バックリンク追加→自然な権威も喪失
- トップページのみチェック、下層ディレクトリのスパム見落とし
- 古いテーマやプラグインを停止状態で放置→攻撃面の拡大
- SSL・DNS・ホスティングの安全性をSEOと切り離して考える
Hostragonsならより安全な復旧プロセスへ
Google検索コンソール警告はSEO問題だけでなく、インフラ・運用問題として捉えるべきです。安全なホスティング、定期バックアップ、最新PHP、SSL、ドメイン管理、アクセス権ポリシーが揃えば復旧スピードは格段に上がり、再発リスクも大幅減。サイト基盤を強化するには 安全なウェブホスティング選択、WordPressセキュリティ対策、SSL証明書とは、ウェブサイトバックアップガイド など内部リンク設計もおすすめです。
要点まとめ:警告を正しく分類、証拠収集、ファイル&コンテンツのクリーニング、アクセス権リセット、技術SEOチェック、そして「すべて本当に直った」段階で再審査リクエスト。堅牢なホスティングと定期的なセキュリティルーチンこそ、復旧プロセスの最強の保険。Hostragonsでニーズに合ったホスティング・ドメイン・SSLをチェックし、安全なスタートを切りましょう。
よくある質問
Google検索コンソール「セキュリティ&手動対策」警告は即順位ダウンを招きますか?
はい。特にサイト全体の手動対策やマルウェア警告の場合、順位・クリック率は急速に低下します。一部URLのみの警告なら影響は限定的ですが、迅速な対応が必須です。
警告時にサイトを完全閉鎖すべきですか?
必ずしも必要ありません。ユーザー安全が危険な場合はメンテナンスモードが妥当ですが、Googleがクリーニングを確認できるよう修正済みページは公開しておくべきです。判断は警告種類ごとに。
再審査リクエストの審査期間は?
明確な期間はありません。セキュリティ問題なら数日で回答、手動対策は数週間かかることも。クリーニング不足や曖昧な説明は却下&追加待機期間を招きます。
disavowファイルは全ての手動対策で使うべきですか?
いいえ。不自然な被リンク問題で除去不可のリンクがある場合のみ利用。誤った使用はサイトの自然なリンク力を弱めます。
警告解除後、同じ問題が再発する可能性は?
根本原因が残れば再発します。古いプラグイン、弱いパスワード、開放FTP、危険なテーマ、劣悪ホスティング分離が続くとGoogle警告は再出現します。