「戻るボタンハイジャック」に対する新しいスパムポリシーの導入

6/15 本施行まで残り32日（2026年5月14日時点）— バックボタンハイジャック最終チェックリスト

Google のバックボタンハイジャック新ポリシーは2026年6月15日に本施行されます。5月14日現在、残り32日です。警告メールが届いていないサイトも、アルゴリズム的降格の対象になる可能性があります。本施行前の最終自己診断を推奨します。

本施行で発動する2種類のペナルティ

サードパーティライブラリ経由の検出事例（2026年5月確認分）

自社コードに問題がなくても、以下のサードパーティ実装がバックボタンハイジャックを引き起こすことが確認されています。

• 広告SDK（Google AdSense 旧バージョン、ad-network SDK 系）: 広告クリック後に history.pushState を操作するケースあり。2024年以降のSDKバージョンで修正済みだが、キャッシュや CDN 経由で旧版が残るケースに注意
• 分析ツールの自動ページビュー追跡: SPA（Single Page Application）対応の分析スクリプトが pushState を多用するものが存在。GA4 gtag.js の設定ミスでも発生
• ChatWidget / LP用ポップアップライブラリ: モーダル表示に history を使用するライブラリが対象になった事例が複数報告（Search Engine Roundtable 2026年5月）
• WooCommerce / EC カート系プラグイン: カート遷移をSPA的に処理するプラグインで意図しない pushState が発生する事例（WordPress.org フォーラム 2026年4〜5月報告分）

本施行前 最終チェックリスト（30分でできる自己診断）

1. DevTools で history.length を確認: ページロード前後で window.history.length が意図せず増加していないか
2. Search Console でバックボタン関連の手動アクション通知を確認: 「バックボタン」「誘導」「ナビゲーション」等のキーワードでフィルタ
3. 全プラグイン・SDK のバージョンを最新に更新: 特に広告関連 / チャット Widget / カート系
4. モバイルで実機テスト: Androidの「戻る」ボタンで検索結果やリファラーページに正常に戻れるか
5. ページ遷移後のURLを確認: ランディングページ→内部ページ移動時に URL が二重に記録されていないか（Chromeの「履歴」ページで確認可能）

▼ 2026年5月15日アップデート — 施行まで残り31日、SDK別対応マトリクス + 最終チェックリスト

5/15 時点の状況：施行日 2026年6月15日まで 残り31日。4月27日からGoogle Search Console経由で警告通知の配信が本格化。「No manual action has been taken at this time. We recommend fixing this issue as soon as possible to avoid a potential manual action」── 自動アクションではなく、6/15以降に手動アクションが発動し得る段階。2026年4月17日以降に行った修正は通知に反映されないため、自社で修正の証跡を残す運用が必須。

2A. 検出方法 — Chrome DevTools 3手順 + Chromium Intervention

手順A（最速30秒で判定）— history.length チェック

1. 該当ページを開く → F12 で DevTools 起動
2. Console タブで history.length を入力 → 値を記録
3. ページ内で 2〜3 回クリック → 再度 history.length を入力
4. クリック数を大きく超えて増加していたら hijacking の疑い

手順B（popstate イベント監視）

DevTools → Sources → Event Listeners → popstate を展開 → pushState / replaceState を呼ぶスクリプトの発信源を特定 → サードパーティスクリプト（広告タグ、レコメンデーションウィジェット）が出てきたら要警戒。

手順C（戻るボタンの長押し履歴確認）

ブラウザの戻るボタンを右クリック（長押し）し、同じ URL が連続して並んでいたら hijack 確定。

Chrome の History Manipulation Intervention（2018年から稼働中）

Chromium には 2018 年から「History Manipulation Intervention」が組み込まれている：

• ユーザーアクティベーション（クリック等）なしに history.pushState() で履歴を追加した場合、戻るボタンはそのエントリを スキップ して直前ページへ戻る
• ユーザージェスチャがあれば intervention は発動しない

つまり、ユーザー操作なしに pushState を呼んでいる時点で Chrome は既に「不審」と判定している。Google ポリシーは、この技術的検出を ランキング処分 にまで踏み込ませる位置づけ。

検出用 JavaScript スニペット（コピペで使える）

// 自サイトに貼って Console で「Hijack risk」が出るか確認
(function detectHijack() {
  const initial = history.length;
  let userClicked = false;
  document.addEventListener('click', () => { userClicked = true; }, { once: true });

  const origPush = history.pushState;
  history.pushState = function() {
    if (!userClicked) {
      console.warn('[HIJACK RISK] pushState called without user gesture:',
                   new Error().stack);
    }
    return origPush.apply(this, arguments);
  };
})();

このスクリプトをステージング環境で 1 度走らせ、[HIJACK RISK] ログが出るスクリプトを全て洗い出す。サードパーティタグ（広告、レコメンデーション、A/B テストツール）の中で犯人を特定できる。

2B. SDK / プラットフォーム別 対応マトリクス

WordPress 系プラグイン対応

• Yoast SEO / Rank Math / AIOSEO: SEO プラグインそのものに hijack コードはない
• 真の犯人になりやすい: ポップアップ系（OptinMonster, Popup Maker, Convert Pro）、関連記事レコメンデーション系（Yuzo Related Posts, Contextual Related Posts）、AMP プラグイン、広告ローテーター
• チェック手順: WP Admin → Plugins → 過去 6 ヶ月以内に更新されていない広告系プラグインを全停止 → 上記検出スクリプトで再検証

JavaScript フレームワーク別の罠

• Next.js: useRouter().push() を useEffect で無条件に呼ぶと、再レンダリングごとに pushState が走る。ユーザーアクション起点の場合のみ push する
• React Router: <Navigate> を render 中に使わない。effect 内で条件付きで使う
• Vue Router: beforeEach ガード内で next({ path: '...' }) を無条件に呼ぶ実装は intervention 対象
• 共通鉄則: 「ルートが変わるのは、ユーザーがクリック・タップ・キー押下したときだけ」をルール化する

2C. 業界別影響度予測（高→低）

罰則の二次被害：D2i Technology と The Ad Firm の分析によれば、ランキング下落は以下の二次被害を引き起こす：

• 有料広告のリターゲティング母集団縮小（オーガニック流入減 → リマーケティング pool 縮小）
• クロールバジェット減少（再評価まで時間がかかる）
• 平均セッション時間の悪化（hijack 自体がユーザー体験を壊している）

2D. 6/15 施行までの最終チェックリスト（31日プラン）

【今日〜7日後 = 5/15〜5/22】緊急（48〜72時間で着手）

• ☐ Search Console を毎日確認（メッセージタブの新着通知）— 通知が来ていたら即対応モード
• ☐ 上記検出スクリプトをステージングに投入し、[HIJACK RISK] ログを全件出力
• ☐ サードパーティタグのインベントリ作成（広告、レコメンデーション、ポップアップ、A/B テスト、CMP の全件）
• ☐ 主要テンプレート 3 種（記事詳細、商品詳細、カテゴリ一覧）で手動の戻るボタンテスト（PC + iOS Safari + Android Chrome）
• ☐ PR 担当・開発・広告運用にアラート発信（リスク該当者全員に「6/15 デッドライン」を周知）

【1〜2週間 = 5/22〜5/29】重要（修正・検証フェーズ）

• ☐ 検出された全 pushState / replaceState をコードレビュー → ユーザージェスチャ依存に書き換え
• ☐ サードパーティスクリプトのうち hijack を起こすベンダーを停止 or 別ベンダーへ切替
• ☐ AdSense / Ad Manager 利用サイトは「Allow additional triggers for vignette ads」のオプトイン状態をそのまま放置で OK（Google 側で自動対応）
• ☐ WordPress 系: 関連記事プラグイン・ポップアップ系プラグインを最新版に更新、または無効化検証
• ☐ Next.js / React / Vue: ルーター呼び出し箇所を grep し、useEffect 内の無条件 push を全て条件分岐化
• ☐ 修正前後の動画記録（戻るボタンの挙動）を保存 — 後の reconsideration 用エビデンス

【6/8〜6/15】最終確認（直前1週間）

• ☐ 全テンプレートで再度の戻るボタンテスト（PC・モバイル・WebView 内ブラウザを含む）
• ☐ Chrome DevTools Console で [HIJACK RISK] ログがゼロであることを確認
• ☐ history.length の増加がユーザーアクション数と一致することを確認
• ☐ Search Console の手動対策レポートを 1 日 1 回チェック
• ☐ 修正完了の社内記録（日付・担当者・修正コミット）を残す
• ☐ 仮に警告が消えていなくても、再検証は Google 側が自動で行うため慌てて reconsideration を送らない
• ☐ 6/15 当日: 順位・トラフィックモニタを通常の 2 倍頻度で監視

2E. 万一 manual action を受けた場合の復旧手順

1. 完全除去（部分修正は再発リスクあり）
2. ユーザー選択型の recirculation に書き換え（強制的な引き止めをやめる）
3. 隣接 UX フローの回帰テスト（モーダル、フィルター、検索状態）
4. Search Console から reconsideration request 送信（修正内容と日付を明記）
5. 自動的な解除はない。修正してから審査開始まで数日〜数週間、ランキング回復まで数週間〜数ヶ月

2F. 数字で押さえる(2026-05-15時点)

• 2026-04-13: Google Search Central 公式アナウンス
• 2026-04-27: Search Console 警告通知の配信開始
• 2026-04-17 以降: この日以降の修正は通知文面に反映されないが、再検証で評価される
• 2026-06-15: 施行日（残り 31 日）
• 2018年〜: Chrome の History Manipulation Intervention は既に稼働中（今回のポリシーは「検出」を「処分」に格上げ）

📌 関連コンテンツ

• タイトル変更の前に、内容を足せ — CTR改善の実証データ
• Google の数字は 11 ヶ月、壊れていた — 3層計測 OS の話
• Googleコアアップデート2025-2026全史
• 2026年3月コアアップデートの現在地
• バックボタンハイジャック関連記事
• Back Button Hijacking 警告メール送信開始
• AI対応診断ツール — 構造化データ・UX・SEO 20項目一括診断
• Google が求める 4 層整合性 — sitemap・canonical・内部リンク

出典: Google Search Central「Back Button Hijacking Policy」2026年4月更新 / Google AdSense Help 2026年5月 / Search Engine Roundtable 2026年5月 / Search Engine Land 2026年4-5月 / PPC Land 2026年4月27日 / Chromium History Manipulation Intervention Docs / WordPress.org フォーラム 2026年4〜5月 / 当サイト独自調査 2026年5月15日

【2026年5月18日 追記】6/15 施行 28 日前の現在地 — 警告メールはすでに 4/27 から送信中、AdSense Vignette 広告は Google 自身が全面廃止

警告メール送信開始（4/27 〜）と「スナップショット日付：4/17」というルール

本記事を更新している 2026 年 5 月 18 日時点で、施行日 6 月 15 日まで残り 28 日となった。重要なのは、施行は突然始まるのではなく、すでに 4/27 (火) から Google Search Console 経由で警告メール送信が開始されているという点である。Glenn Gabe 氏 (G-Squared Interactive LLC President) が最初に公表し、警告メールには違反が検出された代表的なサンプル URL リスト、スパムポリシー公式ブログへのリンク、Search Console の該当レポートへの導線の 3 つが含まれる。

警告メールの本文には次の一節が含まれる：「We've detected that a portion of your site may exhibit back button hijacking behavior. No manual action has been taken at this time. We recommend fixing this issue as soon as possible to avoid a potential manual action that could negatively impact your site's performance on Search. Enforcement of this policy is scheduled to begin on June 15, 2026.」つまり、警告段階では手動対策はまだ適用されていない。猶予期間内に修正すれば、ペナルティは回避できる設計になっている。

ただし注意すべき技術仕様が 1 つある。それは「スナップショット日付：4/17 (金)」というルールだ。4/17 より後に修正したサイトの状態は、初回警告通知には反映されていない。Google は施行 6/15 前に自動で再検証を行うため、現時点で警告メールを受け取っていなくても、4/17 時点で違反コードを抱えていたサイトは引き続き監視対象になっている可能性がある。

もう 1 つの重要な業界シグナルは、Google 自身が AdSense の「ブラウザの戻るボタンでトリガーされる全面広告（Vignette ads）」を全面廃止したことだ（鈴木謙一氏「海外SEO情報ブログ」報告）。これは Google が自社の収益化プロダクトを真っ先に対応させた事実であり、6/15 が「本気の施行日」であることを業界に対して明示した形になる。猶予期間が業界標準の 30 日より長い 60 日に設定されているのも、Google が「自前ライブラリだけでなく第三者 SDK も洗い直せ」と要求している証拠だ。

危ない 7 業種と、3 大違反コードパターン

ALM Corp の 5 月後半分析によれば、違反検出の高リスク業種は次の順位で示されている。第 1 位が広告依存パブリッシャー、第 2 位がコンテンツファーム・リサイクル運営サイト、第 3 位がエンタメ・芸能ニュース系、第 4 位がレシピ・トリビアなどリサーキュレーション設計サイト、第 5 位がアフィリエイト中心サイト、第 6 位が外部マネタイズバンドルを購入しているサイト、第 7 位がフロントエンドスクリプトが緩い統制で配布されているマルチサイトネットワークである。最後の 2 つが重要で、「自分でコードを書いた覚えがなくても違反になる」典型パターンが含まれている。

違反コードの実装レベルでの 3 大パターンも特定されている。1 つ目は history.pushState() および history.replaceState() による偽の履歴エントリの注入。2 つ目は setTimeout() によるリダイレクトの遅延実行で、これはトラッキングピクセルや Cookie 同意バナーの中に隠れているケースが多い。3 つ目は beforeunload イベントへの attach で、ユーザーのナビゲーションをキャンセルしたり、モーダル表示でリダイレクトしたりする実装である。

第三者ライブラリで業界記事に繰り返し名指しされている要注意カテゴリは 5 つある。コンテンツレコメンドウィジェット（Taboola、Outbrain 型）、AdTech プラットフォーム（特に動画広告系のインタースティシャル）、A/B テストツール（履歴 API を操作する実装が多い）、Cookie 同意モジュール（CMP）の一部実装、エンゲージメントウィジェット（離脱防止ポップアップ系）である。WEBディレクターは自社サイトの JavaScript を直接書いていなくても、第三者ライブラリにこれらの記述が含まれていないか必ず確認すべきだ。

自己診断の決定的な方法は DevTools の Console で history.length を確認することだ。ページに着地直後の値を記録し、ページ内で数回クリックした後の値と比較する。数値が異常に膨れ上がっている、あるいは何もクリックしていないのに増えているなら、ハイジャック実装が動いている可能性が高い。また手動テストでは、着地直後ではなく、広告がロードされた後（post-ad-load）および Cookie 同意ボタンを押した後（post-consent）のタイミングで必ず Back ボタンを押して挙動を確認する。違反コードはこの 2 つのタイミングで発火するケースが圧倒的に多いためである。

施行後のシナリオ予測 — 4-8 週間で戻れる人と、次のコアアプデまで戻れない人

業界の回復タイムライン分析はコンセンサスがある。手動アクションを受けた場合、違反コードを完全に除去した上で Search Console で再審査リクエストを送信すると、4 週間から 8 週間で回復するとされる。ただし条件は厳しく、「全ての違反が完全に解消されている」場合のみ承認される。複数の業界記事が一致して指摘するのは「Partial fixes typically result in rejection」── 部分修正は却下されるという点だ。第三者 SDK の修正版がリリースされるのを待っている、というのは Google にとって正当な理由にはならない。

アルゴリズミック降格を受けた場合の回復はさらに長い。違反コード除去後、再クロール → 再評価のプロセスを経て、多くは「次のコアアップデートのロールアウトに合わせて回復」する。これは数ヶ月単位の時間軸を意味する。さらに厄介なのは、アルゴリズミック降格には事前警告が出ない可能性が高いことだ。Search Console で通知されるのは手動アクションのみであり、自動降格を受けたサイトは「気づいたら順位が落ちていた」状態になる。

Glenn Gabe 氏の重要な指摘は、Google が施行前に再検証を実行することだ：「Google will recheck sites before the June 15 deadline」。つまり、警告メールを受け取った後でも、6/15 までに完全修正できれば、ペナルティは回避できる設計になっている。逆に言えば、5/18 時点（残り 28 日）で警告メールを受け取っているサイトは、次の 4 週間が「猶予期間の正念場」となる。

WEBディレクターが施行前に必ず実施すべき行動は 4 つに集約される。第 1 に、Search Console を毎日チェックして警告メールの受信有無を確認する。第 2 に、警告を受け取った場合は 4/17 以降の修正は初回警告に反映されていない可能性があるため、すでに修正済みであっても改めて再検証用のテスト URL を準備する。第 3 に、第三者 SDK・広告ネットワーク・CMP・A/B テストツール・エンゲージメントウィジェットの全てについて、ベンダーに「バックボタンハイジャックに該当するコードが含まれていないか」を文書で確認する。第 4 に、6/15 を過ぎてからアルゴリズミック降格に気づいた場合、回復は「次のコアアップデートまで」となる可能性が高いため、施行前の対応が圧倒的に有利という事実を経営層に共有する。

追加出典: Google Sends Notices On Back Button Hijacking Spam Penalty (Search Engine Roundtable) | Google starts sending Search Console warnings for back button hijacking (PPC Land) | AdSense Vignette 広告廃止（鈴木謙一） | Google Will Penalize Back Button Hijacking (ALM Corp)