6月15日から順位が突然落ちるかも。Googleが警告する「バックボタン乗っ取り」の正体と今すぐやる確認
この記事のポイント
2026 年 6 月 15 日から Google がバックボタン乗っ取りをスパムポリシー違反として執行開始。対策は、スマホ実機で戻るボタンテスト、DevTools の Console と Network で不審なリダイレクトを確認、Search Console の手動による対策ページを週 1 で点検するの 3 つです。

バックボタン乗っ取り(back button hijacking)とは、ユーザーがブラウザの戻るボタンを押したときに、直前のページへ戻れないように妨害したり、別の URL へ強制的に誘導したりする挙動のことです。2026 年 4 月 13 日、Google はこの挙動を新しいスパムポリシー違反として明記し、執行開始日を 2026 年 6 月 15 日と発表しました。心当たりがなくても、サイトに組み込んだ広告タグが原因で違反扱いになるケースがあります。この記事では、何をどう確認すれば良いかを 5 分で分かる手順で整理します。
まず結論。あなたのサイトでやるべきこと 3 つ
6 月 15 日の執行開始まで残り約 2 ヶ月。細かい技術論に入る前に、今日のうちに済ませておくべき最低限のアクションを先に示します。時間がない方は、このセクションだけでも実行してください。
スマホで自分のサイトを開いて戻るを押す
PC の Chrome ではなく、必ずスマートフォン実機で確認します。なぜなら、バックボタン乗っ取りはモバイル広告経由で発生するケースが圧倒的に多いからです。Google や SNS の検索結果から自社サイトの記事を開き、読み終えたつもりで戻るボタンを押してみてください。直前の検索結果やタイムラインにそのまま戻れれば正常です。別のページに飛ばされたり、同じページに留まり続けたり、広告インタースティシャルが表示されたりした場合は、6 月 15 日までに原因を特定する必要があります。
広告タグや計測タグの更新履歴を確認する
直近 3 ヶ月以内に広告配信タグ、レコメンドウィジェット、離脱防止ポップアップ、アフィリエイト中継スクリプトを追加・更新していないかを確認します。自社の開発履歴だけでなく、マーケ部門や外部代理店が裏で差し込んでいるタグも含めて棚卸しします。6 月 15 日のポリシー執行後は、これらの外部スクリプトが原因でも自社サイトのランキングが下がります。
Search Console の手動による対策をブックマークする
Google のスパムポリシー違反で手動対応が入ると、Search Console の「手動による対策」セクションに通知が届きます。6 月 15 日以降はこのページを週 1 回は確認する運用にしておくと、問題が起きたときの発見が早まります。通知が来てから修正するまでの時間を短くすることが、順位への影響を最小化する最大のコツです。
バックボタン乗っ取り(back button hijacking)とは
ここから、改めて Google の定義と背景を押さえていきます。言葉としては新しいですが、挙動そのものは Web 広告の世界では以前から知られていた迷惑行為です。
Google の定義
Google Search Central Blog の 2026 年 4 月 13 日付の公式記事によると、バックボタン乗っ取りは「ユーザーがブラウザの戻るボタンを押したときに、期待される前のページへ戻れないように、ページまたはスクリプトが干渉する行為」と定義されています。投稿者は Google Search Quality team の Chris Nelson 氏です。具体的には、強制的に現在のページに留めたり、別の URL にリダイレクトしたり、フル画面広告を差し込んだりする挙動が対象です。
具体的にどんな挙動が対象か
以下のような挙動は、6 月 15 日以降は明確にスパムポリシー違反として扱われます。
| 挙動パターン | 説明 |
|---|---|
| リダイレクト型 | 戻るボタンを押すと別ドメインの広告ページへ飛ばされる |
| ループ型 | 何度戻るを押しても同じページが再表示される |
| インタースティシャル型 | 戻るを押すと離脱防止のフル画面広告が割り込む |
| 偽フィード型 | 戻るボタンで偽の Discover フィードが表示され、さらに別記事へ誘導される |
いずれもユーザー体験を大きく損なう挙動で、Google は「検索結果から流入したユーザーが元の検索結果画面に戻れないことが問題の本質」と説明しています。
Google Search Essentials の既存方針との関係
今回の発表は、まったく新しいルールが追加されたわけではありません。Google Search Essentials の既存の「スパム的挙動」セクションには、以前からユーザーを欺く誘導行為全般が禁止されていました。2026 年 4 月 13 日の発表は、その中でもバックボタン乗っ取りを個別項目として明文化し、6 月 15 日から執行を厳格化すると宣言したものです。つまり「もともと駄目だったことを、改めて取り締まる」という位置づけになります。
なぜ今、Google が明文化したのか
もともと禁止されていた挙動を、なぜこのタイミングで項目として切り出したのか。背景を理解しておくと、自社サイトのリスク判断がしやすくなります。
マルバタイジング業者の悪用事例
2025 年後半から、広告ネットワーク経由で配信されるスクリプトに、意図的にバックボタンを妨害するコードを仕込む事例が急増したとセキュリティ業界で報告されています。マルバタイジング(広告を悪用したマルウェア的行為)の一種で、正規メディアの記事ページを経由してユーザーを広告主サイトへ強制的に送り込む手口です。正規サイトの運営者が気づかないうちに加害者側に立ってしまう点が問題視されていました。
偽の Discover フィードを表示して回遊させる手口
特に 2026 年に入ってから目立っているのが、戻るボタンを押すと偽の Google Discover 風フィードが表示され、そこから広告記事へ誘導する手口です。ユーザーは「元の検索結果に戻れた」と錯覚するため、広告をタップしてしまいやすく、コンバージョン率が高いとされています。Google が特にこのパターンを警戒している理由は、自社製品である Discover のブランドが悪用されているためと見られます。
ユーザー体験の悪化と検索品質への影響
Google の検索品質にとって、戻るボタンが効かないという体験は最悪の部類に入ります。検索結果から流入したユーザーが元の場所に戻れないと、ユーザーは検索そのものに不信感を抱きます。Google は検索体験の品質を守るため、こうした挙動を明確にスパムとして扱う方針を打ち出したと考えられます。
技術的な正体。history.pushState が悪用されるパターン
ここからは開発者向けに、やや技術寄りの説明を入れます。仕組みを理解しておくと、自社サイトの点検がぐっと早くなります。
正常な SPA での使い方
まず大前提として、ブラウザの History API(history.pushState や history.replaceState)そのものは悪ではありません。シングルページアプリケーション(SPA)では、ページ遷移のたびに URL を書き換えてブラウザ履歴に反映するために不可欠な技術です。Next.js、React Router、Vue Router など、主要なフレームワークは内部的にこの API を使っています。通常の SPA ルーティングは 6 月 15 日以降も問題なく動作します。
悪用パターン 1 履歴を大量追加して戻れなくする
典型的な悪用パターンの 1 つ目は、ページロード時に history.pushState を大量に実行して、同じ URL を履歴スタックに何十個も積むものです。ユーザーが戻るボタンを押しても、積まれたダミー履歴を 1 つずつ戻るだけで、実際の直前ページにはなかなか到達できません。手動で連打して抜け出そうとするユーザーをそのまま広告に留めることが目的です。
悪用パターン 2 popstate をフックして別 URL にリダイレクト
2 つ目のパターンは、popstate イベント(戻るボタンが押されたときに発火するイベント)をフックして、発火した瞬間に window.location.replace で別ドメインへ飛ばすものです。ユーザーは戻ったつもりが、まったく別の広告サイトに到着します。正規の SPA が popstate を使うのはルート切り替えのためなので、外部 URL へのリダイレクトが入っている時点で異常と判断できます。
ブラウザ側介入との違い
Chrome や Firefox も、こうした悪質な履歴操作を自動検出してブロックする試みを進めています。ただしブラウザ側の対策は完璧ではなく、新しい手口が出るたびにすり抜けられてきました。Google が今回、検索ランキング側からもペナルティを課す方針を打ち出したのは、ブラウザだけでは対応しきれないという現実的な判断と読み取れます。
自覚なく違反になるケース。犯人は外部スクリプトかもしれない
ここが今回のポリシー変更でもっとも重要なポイントです。自社の開発チームが問題のあるコードを書いていなくても、違反扱いになる可能性があります。
広告ネットワークの redirect 系スクリプト
一部の広告ネットワーク、特に海外発の中小規模ネットワークでは、配信される広告タグの中に戻るボタン乗っ取りのコードが含まれているケースが報告されています。広告タグは外部サーバーから動的にロードされるため、自社サーバー上には問題のコードが存在しません。導入時には問題なかったタグが、ある日から挙動を変えるということも起きます。
レコメンドウィジェット
記事末尾に「おすすめの記事」を表示するレコメンドウィジェットの中にも、戻るボタンの挙動に介入するものがあります。特に広告と記事を織り交ぜて表示するタイプのウィジェットは要注意です。
アフィリエイト中継・ポップアンダー系のタグ
アフィリエイトリンクを中継ドメイン経由で管理するスクリプトや、新しいウィンドウを開くポップアンダー系のタグも、バックボタンの挙動を書き換えることがあります。
古い A/B テストツールや離脱防止ポップアップ
2 〜 3 年以上前に導入したまま放置している A/B テストツールや離脱防止ポップアップは、現在のポリシー基準では違反になる挙動を含んでいる可能性があります。ベンダーが対応アップデートを出しているか確認し、使っていないなら 6 月 15 日までに外してしまうのが安全です。
自社のコードを 1 行も書き換えていなくても、外部スクリプトが原因でランキングが下がる可能性があります。広告配信系のタグを入れているサイトは、全件棚卸しを強く推奨します。
5 分でできる確認手順
ここからは、実際に自社サイトが違反していないかを確かめる具体的な手順です。ツールは特別なものを使いません。スマホと Chrome DevTools、そして Search Console だけで完結します。
手順 1 本番サイトで戻るボタンテスト
最初にやるのは実機テストです。Google で自社サイトのキーワードを検索し、検索結果から記事を開きます。ページを 5 秒ほど読んでから戻るボタンを押してください。検索結果に正常に戻れれば、そのページは問題ありません。代表的な記事 5 〜 10 本で同じテストを繰り返し、どこでも正常に戻れるかを確認します。
手順 2 History スタックを観察する
PC Chrome の DevTools を開き、Console で window.history.length を実行してみてください。ページをロードした直後に値が極端に大きい(10 以上など)場合、ダミー履歴が積まれている可能性があります。正常なページロードなら通常は 1 〜 2 です。
手順 3 performance.getEntriesByType でリダイレクトを探す
Console で以下のコードを実行すると、ページロード時のナビゲーション情報が取得できます。
performance.getEntriesByType('navigation').forEach(n => {
console.log(n.redirectCount, n.redirectStart, n.redirectEnd);
});
redirectCount が 0 であるのが正常です。意図していないリダイレクトが挟まっていないかを確認します。Network パネルでも、ページロード時に 302 / 301 の連鎖が起きていないかチェックしてください。
手順 4 外部スクリプトを一時的に無効化して切り分け
問題の挙動が再現したら、DevTools の Network パネルで広告タグや外部スクリプトのドメインを右クリックし、「Block request domain」で一時的にブロックします。ブロック後に再度戻るボタンテストを実施して、挙動が正常に戻るかを確認します。正常に戻れば、そのドメインから配信されているスクリプトが原因です。
手順 5 Search Console の手動による対策をブックマーク
最後に、Search Console の「セキュリティと手動による対策」>「手動による対策」ページをブックマークしておきます。6 月 15 日以降、ここに通知が届いていないかを週 1 回確認する運用を決めておきます。
6 月 15 日までのタイムライン
いつまでに何をやるべきかを時系列で整理しておきます。
| 日付 | 内容 |
|---|---|
| 2026 年 4 月 13 日 | Google がポリシーを公開 |
| 2026 年 4 月 14 日 〜 5 月 31 日 | 自社サイトの点検・修正期間 |
| 2026 年 6 月 1 日 〜 6 月 14 日 | 最終確認期間。外部スクリプトの再テスト |
| 2026 年 6 月 15 日 | 執行開始。違反サイトは降格対象になる |
ポイントは、ポリシー公開から執行までの約 2 ヶ月の間に、確認と修正を完了させる必要があるということです。6 月 15 日を過ぎてから気づいても、ランキングが下がってから慌てて対応する形になります。
もし違反通知が来てしまった場合は、以下の手順で対応します。まず Search Console の「手動による対策」ページで違反内容を確認し、該当する外部スクリプトや自社コードを修正します。修正完了後、同ページから再審査リクエストを送信します。Google は通常数日〜数週間以内に再審査結果を返してきます。修正が認められれば手動対応は解除され、順位の回復が始まります。
記事の品質を磨いているのに順位が落ちる、を防ぐには
ここまで読んで気づいた方もいると思いますが、今回のスパムポリシーはコンテンツの品質とはまったく別の軸で順位に影響します。いくら良い記事を書いても、サイトの技術的な衛生管理が疎かだと、6 月 15 日以降に順位を落とす可能性があるということです。
コンテンツ品質とサイト衛生は別軸の話
コアアップデートで順位が下がったときの対応で扱っているような E-E-A-T の観点と、今回のバックボタン乗っ取りポリシーはまったく別の話です。前者は「コンテンツが良いか」、後者は「サイトの挙動が正しいか」を評価しています。両方を満たして初めて、安定した検索流入が得られます。
記事制作に工数を取られるほど、サイト側の点検が後回しになる
少人数のマーケティングチームでよくある失敗は、記事制作に時間を取られすぎて、こうしたサイトの衛生管理が後回しになることです。広告タグの棚卸し、外部スクリプトの動作確認、Search Console の通知チェックといった地味な作業は、緊急度が低く見えるため、記事を書く時間と天秤にかけると常に負けます。しかし、6 月 15 日のようなポリシー執行タイミングが来たときに、点検を怠っていたサイトが一気に順位を落とします。
記事制作の仕組み化で点検に時間を回す体制を作る
そもそも記事制作自体にかかる時間を減らせれば、浮いた時間をサイトの衛生管理に回せます。spotyou は AI が記事の生成からコンプライアンスチェックまでを一貫して支援するサービスで、少人数チームでも記事制作の工数を大きく削減できます。インプレッション数の急減のような Search Console のノイズに振り回されないためにも、日頃からサイトの状態を把握する余裕を作っておくことが重要です。また、Googlebot のクロール挙動に関する最新情報と合わせて、サイト全体の技術的な健全性を定期的にチェックする運用を組んでおくと、今回のようなポリシー変更にも慌てずに対応できます。
まとめ
最後に、この記事の要点を整理します。
- 2026 年 6 月 15 日から、Google は「バックボタン乗っ取り」をスパムポリシー違反として執行する
- 自社のコードを書き換えていなくても、導入した広告タグや外部スクリプトが原因で違反扱いになるケースがある
- 5 分でできる確認手順は、スマホ実機での戻るボタンテストと、DevTools の Console と Network パネルでのチェック
- Search Console の「手動による対策」ページをブックマークし、6 月 15 日以降は週 1 回確認する運用を決めておく
- コンテンツ品質の改善とサイトの技術的な衛生管理は別軸の課題。どちらも並行して回す必要がある
6 月 15 日までに残された時間は約 2 ヶ月です。記事を書く時間に追われて点検が後回しになっているなら、記事制作の仕組み化から見直すのが結果的な近道です。サイトの健全性を守る時間を、意識的に確保してください。
よくある質問
バックボタン乗っ取りはいつから違反になりますか
2026 年 6 月 15 日から執行開始です。公開は 4 月 13 日で、約 2 ヶ月の猶予があります。この期間中に自社サイトを点検し、問題があれば修正を済ませてください。
自分のサイトのコードはいじっていません。それでも違反になる可能性はありますか
あります。Google は公式ブログで、サイト本体のコードだけでなく、組み込んだ広告ライブラリや外部スクリプトが原因になる場合もあると明記しています。広告タグやレコメンドウィジェットを導入している場合は注意が必要です。
違反したらどうなりますか
該当ページが手動対応または自動降格の対象になります。手動対応の場合は Search Console に通知が届き、修正後に再審査リクエストで解除申請が可能です。
SPA で history.pushState を使っていますが、これも違反になりますか
いいえ。history.pushState 自体は正常な技術です。Google が問題視しているのは、戻るボタンを押したユーザーを直前のページ以外に誘導する挙動です。通常の SPA ルーティングは対象外です。
どうやって自分のサイトが違反していないか確認できますか
スマホ実機で外部サイトから流入したつもりで戻るボタンを押すテストが最も確実です。DevTools の Console で window.history.length を実行し、ロード直後の履歴数が極端に多くないか確認するのも有効です。