自社サイトに危険なサイト警告｜原因5つと解除手順

自社サイトを開いたら、赤い画面で「危険なサイト」と出る。サーバーの管理画面にもCMSにも異常は無く、社内の別のパソコンでは普通に開く——この状態から何を確かめればよいかを、切り分けの順番どおりにまとめます。

結論から言うと、まず開くのは自社のサーバーでもCMSでもなく、Google Search Console の「セキュリティの問題」レポートです。Google は「セーフ ブラウジングは閲覧コンテキストに基づいて警告を表示するため、警告を再現できる場合とできない場合がある。信頼できる情報源として［セキュリティの問題］レポートを使用すること」と明記しています。つまり手元の画面で再現するかどうかは判断材料にならない、というのが公式の立場です。ここが緑のチェックマークなら、原因は Google の判定ではなく別の層（ブラウザ側の類似ドメイン警告・端末や回線のフィルタ・証明書）にあります。

まず「どの警告か」を文言で切り分ける

「危険なサイト警告」と一括りに呼ばれる画面は、実際には発生源の違う3種類が混ざっています。出ている文言をそのまま読み取るだけで、どこを直せばよいかが決まります。

3行目の類似ドメイン警告は、Google のサーバーに問い合わせず Chrome の中だけで判定しています（Chromium の公式ドキュメントに「これらのチェックはすべて Chrome 内で行われ、Chrome は Google と通信しない」と書かれています）。したがって Search Console には何も出ません。4行目は警告の種類がそもそも違うので、「保護されていない通信」と表示される原因と直し方のほうを先に読んでください。

自社サイトに危険なサイト警告が出る原因5つ

原因1: ハッキングによるマルウェア・コードインジェクション

もっとも多く、もっとも急ぐべき原因です。Search Console の「セキュリティの問題」では「ハッキング: マルウェア」「ハッキング: コード インジェクション」として報告されます。後者は、侵入したページに悪意のあるコードが注入され、別サイトへリダイレクトしたり、ページを開いている間にブラウザ上で暗号通貨のマイニングを走らせたりするものです。

注意点が2つあります。ひとつは、感染が疑われるページを自分のブラウザで直接開かないこと。マルウェアはブラウザの脆弱性を突いて広がるため、Google も「ブラウザを使ってサイトの感染したページを直接表示することはおやめください」と明記しています。もうひとつはクローキングで、攻撃者は管理者に見つからないよう、リファラーが Google のときだけ不正なコンテンツを出すといった細工をします。だから管理者の画面では何も起きません。確認は Search Console の URL 検査ツールで「Google が認識しているページ」を見るのが正解です。具体的な復旧の段取りはホームページが改ざんされたときの確認手順と復旧5ステップにまとめています。

原因2: 広告・外部スクリプトなど第三者の要素に巻き込まれた

サイト本体は無害でも、埋め込まれた広告やサードパーティ製の部品に不正なコンテンツが含まれていれば、ホストしているページ側のポリシー違反として扱われます。Google の説明にあるとおり、広告ネットワークは広告をローテーション表示するため「ページを数回更新しないと問題の広告が出てこない」ことがあり、さらにモバイルとパソコンで配信される広告が違うこともあります。

自社では1回も再現できないのに判定だけが続く典型がこれです。広告タグ・アクセス解析・チャットツール・フォーム埋め込みなど、外部から読み込んでいるスクリプトを一覧にして、ひとつずつ止めながら確認します。

原因3: 決済代行などのサードパーティ運営ページで、運営主体が読み取れない

見落とされがちな原因です。Google は「サードパーティがファーストパーティとの関係を明らかにせずに、その代理としてサイトを運営している場合」をソーシャル エンジニアリングに数えています。予約システムや決済ページを外部サービスに任せていて、そのページに自社名だけが出ていて運営元の表示が無い、あるいは逆に外部サービス名しか出ていない、という状態が該当します。

対処は技術ではなく表示の問題です。Google が推奨しているのは、サードパーティのページには全ページにそのブランドを明示すること、そして自社ブランドが載るページには「このサービスは ○○ が △△ の代理として提供しています」のように関係を明記して詳細ページへリンクすることです。

原因4: ドメインが有名サイトに似ている／別ドメインに自社サイトの複製がある

「もしかして: ○○」「偽のサイトにアクセスしようとしています」が出ている場合は、ハッキングではなく Chrome の類似ドメイン判定です。Chromium のドキュメントは、引っかかるパターンとして他ドメインとの編集距離が近いもの（goog0le.com のような1文字違い）、ホスト名の中に他のドメイン名を含むもの（google.com.example.com のような形）、IDN ホモグラフ（goögle.com）を挙げています。

自社に心当たりが無くても起こりうるのが、同じ中身のサイトが別のドメインにも存在しているケースです。テスト環境をパスワード無しで公開したまま、制作会社の確認用URLが生きたまま、移転前の旧ドメインが残ったまま——いずれも「同じ見た目のサイトが2つのドメインに在る」状態を作ります。旧ドメインや管理会社が分からなくなっている場合は、ドメインとサーバーの管理会社がわからない時の調べ方から辿れます。

原因5: そもそも Google の判定ではなく、端末や回線のフィルタ

セキュリティソフト、ブラウザ拡張機能、学校や会社のネットワークフィルタ、社内DNSのブロックリスト。これらはいずれも Google とは無関係に、独自の基準で「危険」と表示します。この場合 Search Console は緑のままで、何を直せばよいかの手がかりがゼロになります。

判別の目安は警告のデザインと文言です。Chrome 標準の警告なら「危険なサイト」「この安全でないサイトにアクセスする」といった決まった文言が出ます。そうでない文言や、見慣れないロゴが入った遮断画面が出ていれば、それはブラウザではなく手前の何かです。特定の人だけに起きているなら、自分だけサイトが表示されないときの切り分け方と同じ手順（別回線・別端末・シークレットウィンドウ）で層を分けられます。

原因が特定できても、社内に直せる人がいない／もう一度同じことが起きないようにしたい、という段階で止まってしまうことはよくあります。Mihata ではホームページ制作とあわせて、こうした復旧と再発防止のご相談も承っています。記事の途中で恐縮ですが、よろしければあわせてご覧いただけたら嬉しいです。

解除までの手順5ステップ

順番を飛ばすと、直っていない状態で審査を出してしまい、かえって時間がかかります。Google は「問題を修正していない時点で再審査リクエストを送信すると、次のリクエストの結果連絡までの時間が長くなったり、違反を繰り返すサイトとしてマークされたりする可能性がある」と注意しています。

1. Search Console の「セキュリティの問題」を開く。ここが唯一の信頼できる情報源です。問題があれば件数と、検出された日付・カテゴリ・影響を受けている URL のサンプルが出ます。ただしこの URL 一覧は網羅的ではありません（サンプルが1件も出ないこともあります）。
2. 所有者の一覧を確認する。Google が手順の筆頭に挙げているのが、Search Console に身に覚えのない所有者が追加されていないかの確認です。侵入されている場合、攻撃者が自分を所有者として登録していることがあります。
3. サイト全体で直す。「一部のページでのみ問題を解決しても、検索結果は変わりません」と明記されています。サンプルに挙がった URL だけを直して終わりにしないこと。複数の問題が報告されていれば、そのすべてを直します。
4. 修正をテストし、審査をリクエストする。リクエスト文には ①問題の内容 ②修正のために行った手順 ③その結果 の3点を書きます。
5. 結果を待つ。Google の案内では、ほとんどの再審査は数日から数週間。審査開始と完了はそれぞれメールで通知されます。決定が届く前にリクエストを再送しないこと。

類似ドメイン警告（原因4）の場合は経路が別で、Search Console ではなく Chrome の類似ドメイン警告の窓口から申請します。Chromium のドキュメントによると、この受付は新しいチェックの導入後しばらくの期間に限って行われ、また企業内の端末については管理者がポリシーで特定ドメインを除外できる仕組みも用意されています。

「自社では再現しない」が普通に起きる——Mihata の実体験

この種の問題がやっかいなのは、自社の画面は最後まで無傷のまま、外側の評価だけが落ちることです。Mihata 自身のサイト運用でも、形は違えど同じ構造の出来事を3回踏んでいます。

別ホスト名にした途端、そのホスト名だけが遮断された

Mihata が運営している集中時計アプリの音源と背景動画を、一時期 media.mihata.jp という別ホスト名から配信していました。すると、学校や社内のネットワークフィルタがそのホスト名だけを遮断し、「サイトは開くのに音だけ鳴らない」という状態が発生しました。自社の回線ではどうやっても再現できず、2026年8月30日に配信元を同一オリジンへ戻して解消しています。

ここから言えることは遮断はホスト名単位で下りるということです。本体ドメインが無事でも、サブドメインやCDN用の別ホスト名だけが弾かれることがあり、しかもそれは自社の回線からは観測できません。Chromium のドキュメントも「あなたに警告が表示されるサイトが、別のユーザーには表示されないことがある」と、閲覧履歴に応じて警告の出方が変わることを認めています。「うちでは出ないから大丈夫」は成り立ちません。

サイトは正常なのに、メールだけが迷惑判定されていた

2026年8月19日の DNS 移行の際、apex の SPF レコードと google._domainkey（DKIM）が欠落したまま運用が続いていました。サイトの表示には一切影響が無く、管理画面にも何も出ません。にもかかわらず、送信したメールだけが外部で迷惑メール判定を受けていました。8月26日に認証レコードを揃え直して解消しています。

これも自社の画面は無傷のまま、外側の評価だけが落ちていた例です。危険なサイト警告も同じで、自分の画面を何度眺めても答えは出ません。だからこそ、外側が何を見ているか（＝Search Console）を先に開く必要があります。

自サイトのコピーが別ドメインに在ると、偽サイト判定の芽になる

Mihata のサイトは、ホスティングの切り替え経緯から *.vercel.app 上にも同じ内容が出てしまう状態になり得たため、middleware.ts と X-Robots-Tag: noindex の二重で塞いであります。目的は重複インデックスの防止ですが、同じ対策は「同じ中身のサイトが2つのドメインに在る」状態そのものを減らします。

制作段階のテスト環境、移転前の旧ドメイン、CMSが自動で生やすプレビュー用URL。自社サイトの複製がどこに何枚あるかを把握していない会社は少なくありません。会社名で検索すると別の会社が出てくる状態と根っこは同じで、「どのURLが自社の正規版か」が外から見て一意に決まっていないことが問題を生みます。

再発させないためにやっておくこと

• Search Console を登録し、通知メールを受け取れる宛先にしておく。セキュリティの問題は最初にメールで届きます。退職者のアドレスのままになっていると、誰も気づけません。
• 公開しているホスト名を棚卸しする。本番・テスト環境・旧ドメイン・サブドメイン。使っていないものは止めるか、少なくとも noindex とアクセス制限をかけます。
• ドメインの有効期限を管理する。失効したドメインが第三者に取得されると、自社名のまま別の内容が出る最悪の形になります。期限切れの実害はドメイン更新忘れでサイトが消えたときの復旧期限にまとめています。
• CMS・プラグイン・サーバーの更新を止めない。ハッキング経由の警告は、基本的な保守で大半を防げます。最低限やることは中小企業がやるべきホームページのセキュリティ対策5つにあります。
• 公開後に「表示されない・出てこない」の一次切り分けができる状態にしておく。誰が何をどこまで見られるのかを記録しておくだけで、次に何か起きたときの復旧時間が変わります。警告ではなくページが見つからないだけ、という取り違えも多いので、ホームページで404エラーが出る原因と直し方とあわせて確認してください。

いま出ている警告をどう読めばよいか分からない、Search Console に誰もアクセスできない、といった段階からのご相談もお受けしています。状況をお伺いしたうえで、まず何を確認すべきかをお伝えします。