2026年4月13日、GoogleはBack Button Hijackingをスパムポリシーの「Malicious Practices（悪意ある行為）」に追加しました。施行日は2026年6月15日です。

本記事では、技術的な仕組みと具体的なチェック方法を解説します。

Back Button Hijackingとは

ブラウザの戻るボタンを押したときに、ユーザーが意図しないページへ誘導したり、戻れなくしたりする実装の総称です。

Googleの定義では、以下のいずれかに該当するものが対象です。

  • ユーザーが来た元のページに戻れない状態を作ること
  • 意図しないページへ強制遷移させること
  • ブラウザ履歴に偽のエントリを挿入・置換すること

技術的な仕組み：History API

JavaScriptのHistory APIを使うことで、ブラウザの履歴スタックをコードから操作できます。


// 履歴にエントリを追加する
history.pushState(stateObj, title, url);

// 現在のエントリを書き換える
history.replaceState(stateObj, title, url);

// 戻る操作を検知する
window.addEventListener("popstate", (e) => {
  // ここで任意の処理を実行できる
});

このAPIはSPAのルーティング（React RouterやVue Routerなど）に正当に使われる技術です。問題は、これを欺く目的で使う実装です。

違反となる実装パターン

パターン①：偽履歴の大量スタック

ページ読み込み時に偽のエントリを積み、戻れなくする最も単純な手法です。


window.addEventListener("load", () => {
  for (let i = 0; i < 10; i++) {
    history.pushState(null, "", location.href);
  }
});

window.addEventListener("popstate", () => {
  history.pushState(null, "", location.href);
});

パターン②：戻る検知→広告LPへリダイレクト

ユーザーの離脱意図を広告収益に変換する手法です。


history.pushState({ trap: true }, "", location.href);

window.addEventListener("popstate", () => {
  window.location.href = "https://ad-lp.example.com/";
});

パターン③：来訪元URLの上書き

Googleからの流入であることを隠蔽し、戻り先を検索結果でなくダミーページにすり替えます。


history.replaceState(null, "", "/dummy");
history.pushState(null, "", location.href);

パターン④：離脱ブロックモーダル＋再ロック

ポップアップを表示しながら、同時に履歴を再操作してロックを維持します。


window.addEventListener("popstate", () => {
  document.getElementById("exit-modal").style.display = "block";
  history.pushState(null, "", location.href); // ← ここが問題
});

合法的な使い方との境界線

History APIの使用そのものは違反ではありません。判断基準は「ユーザーの期待を裏切るか否か」です。

合法的な使い方の例です。

  • SPAのルーティング管理（React Router、Vue Routerなど）
  • フォーム入力の途中離脱確認ダイアログ（再pushStateしない）
  • モーダルやドロワーの開閉をURLに反映する

違反となる使い方の例です。

  • 意図的に複数の偽エントリを積む
  • 戻るを検知して外部URLへリダイレクトする
  • 元の来訪元を履歴から消す

サードパーティスクリプトへの注意

Googleは以下のように明示しています。

広告プラットフォームや外部ライブラリが原因であっても、そのサイトオーナーに責任がある

特に注意が必要なカテゴリはこれらです。

  • アドネットワークのタグ（アフィリエイト広告を含む）
  • コンテンツレコメンドウィジェット（Outbrain等）
  • 古いSEO系のエンゲージメント改善ツール
  • WordPressの一部プラグイン（回遊率改善系）

確認方法

Chrome DevToolsでの確認

DevToolsを開いて（F12）、Consoleタブで以下を実行します。


console.log("history.length:", window.history.length);

ページ読み込み直後に数値が異常に大きい場合、何らかのスクリプトが履歴を操作している可能性があります。

popstateの監視確認

ページ読み込み前にConsoleで以下を実行することで、後から登録されるpopstateリスナーを検知できます。


const originalAddEventListener = window.addEventListener;
window.addEventListener = function(type, listener, options) {
  if (type === "popstate") {
    console.warn("popstateリスナーが登録されました:", listener);
  }
  originalAddEventListener.call(this, type, listener, options);
};

ペナルティの種類と影響範囲

Googleが明示しているペナルティは2種類あります。

手動スパムアクション（Manual Action）

Search Consoleに通知が届きます。対象ページまたはサイト全体の検索除外・降格が発生します。

自動降格（Automated Demotion）

通知なしでランキングが下がります。SpamBrainによるアルゴリズム処理です。

また、2024年12月以降、手動スパムアクションはGoogle広告の配信資格とも連動しています。検索流入と広告流入の両方に影響が及ぶ可能性があります。

対応チェックリスト

6月15日までに以下を確認してください。

  • ページ読み込み時にpushStateを呼び出すスクリプトがないか
  • popstateイベントでリダイレクト処理をしていないか
  • 広告タグ・アフィリエイトタグのHistory API操作の有無
  • 外部ウィジェットの動作確認（実際に戻るボタンを押してテスト）
  • WordPressプラグインのアップデートまたは無効化

まとめ

Back Button Hijackingは2026年6月15日からGoogleスパムポリシーの「Malicious Practices」違反になります。

自社実装でなく、広告タグや外部ライブラリが原因であっても責任はサイトオーナーにあります。

History APIの使用自体は問題ありません。「ユーザーの期待する戻る動作を妨げているか」が判断の基準です。

参考：Google Search Central Blog "Introducing a new spam policy for back button hijacking"（2026年4月13日）