戻るボタンの乗っ取り（back button hijacking）は、ブラウザの履歴を操作して、ユーザーが戻るボタンで元のページへすぐ戻れないようにする行為です。Googleは2026年4月13日にこれをスパムポリシーの「悪意のある行為」へ明示的に加え、2026年6月15日から取り締まりを始めました。現在はSearch Consoleの手動対策にも「[戻る] ボタンのハイジャック」という専用の項目があります。この記事では、Googleの定義と制裁の範囲、主要ブラウザが既定で防いでいる型とすり抜ける型（Chrome for Testing 156での実測）、自サイトの点検手順、戻れなくなったときの抜け方を順に説明します。
まとめ：戻るボタンの乗っ取りで押さえる要点
- 2026年6月15日から施行済み。スパムポリシーの「悪意のある行為」に、マルウェア・望ましくないソフトウェアと並んで定義が載っています。
- 制裁は手動対策と自動降格の2つ。手動対策は現時点では違反を含むページが対象で、繰り返し違反するとサイト全体の順位に及ぶ可能性があるとGoogleは説明しています。
- 広告やライブラリが原因でもサイト側の責任。Googleは原因のコード・インポート・設定の削除か無効化を求めています。
- ユーザー操作なしで足した履歴は、Chrome・Safari・Firefoxが既に戻る操作で飛ばします。ただしChromeでは、ページが1回タップされると、その前後に足した履歴は飛ばされなくなり、3回押さないと戻れない状態が残りました。
- 点検はDevToolsのIssuesパネルと、pushStateの呼び出し元の記録。読み込み直後と1回操作した後の両方で、戻る操作が直前の画面に戻るかを確かめます。
戻るボタンの乗っ取りの定義と2026年6月15日の施行
スパムポリシー「悪意のある行為」に入った定義文
Google検索のスパムに関するポリシーの「悪意のある行為」の節に、次の1文が加わりました（日本語版の最終更新日は2026年9月2日、英語版は2026年8月28日）。
[戻る] ボタンのハイジャックとは、サイトでブラウザの閲覧履歴やその他の機能を操作してユーザーのブラウザ ナビゲーションを妨害し、ユーザーが [戻る] ボタンを使用して元のページにすぐに戻れないようにすることです。
注目すべきは「閲覧履歴やその他の機能」という書き方です。history.pushState() だけでなく、リダイレクトや画面全体を覆う要素など、結果として戻れなくするものは手段を問わず含まれると読めます。同じ節の前の2項目はマルウェアと望ましくないソフトウェアで、この3つが「悪意のある行為の一般的な例」として並んでいます。
公式ブログが挙げた症状と第三者コードの扱い
発表元のGoogle検索セントラルブログ（2026年4月13日）は、乗っ取りに遭ったユーザーの症状を3つ挙げています。訪れたことのないページへ送られる、頼んでいないおすすめや広告を見せられる、普通に閲覧を続けられなくなる、の3つです。あわせて、ユーザーの閲覧履歴へ欺瞞的・操作的なページを挿入することは以前からGoogle検索の基本事項に反していたと書き、近年この行為が増えたので明示的な違反にしたと説明しています。
サイト運営者への要求は「remove or disable」、つまり該当するスクリプトや手法の削除か無効化です。さらに、乗っ取りの一部はサイトが読み込んでいるライブラリや広告プラットフォームから生じる場合があると明記し、原因となるコード・インポート・設定を見直すよう求めています。自社で書いたコードでなくても、そのページを配信しているサイトが対応する前提です。施行日を2か月先の6月15日にしたのは、運営者が修正する時間を取るためでした。
施行後の手動対策の対象範囲と繰り返し違反への対応
Search Consoleのヘルプでは、現在の手動対策は違反するページが対象で、繰り返し違反するとサイト全体のランキングに影響する可能性があると説明しています。施行前に多かった「違反すればサイト全体が落ちる」という説明より段階的です。
Search Consoleに追加された「[戻る] ボタンのハイジャック」
[手動による対策] レポートのヘルプの一覧に、「[戻る] ボタンのハイジャック」が独立した項目として載っています。通知文は「[戻る] ボタンのハイジャック行為がサイトの一部で確認されました」で、範囲について次のように書かれています。
現在、手動による対策は、Google のポリシーに違反するコンテンツが含まれているページに対して行われています。サイトが [戻る] ボタンのハイジャックに関するポリシーに繰り返し違反している場合は、手動による対策がさらに進んだり、サイトの全体的なランキングに影響したりする可能性があります。
つまり最初の手動対策は、違反しているページに絞って掛かります。テンプレート単位で広告タグを入れているサイトなら、その「ページ」は記事全体になり得るので、範囲が狭いと安心はできません。レポートの説明を開くと影響を受けるURLのパターン（例 https://example.com/real-estate/*）が出るので、どのテンプレートが対象かはそこで判断します。
解除の手順は、原因のコードやインポートを無効化または削除し、レポートの「審査をリクエスト」を押すことです。審査は多くの場合数日から数週間で、結果が届くまで再送信しないようヘルプは求めています。再審査の文面には、どのスクリプトを、いつ、どう外したか、どのテンプレートで確認したかを書くと、審査担当者が再現確認しやすくなります。
手動対策と自動降格の通知・回復の違い
ブログは手動対策と並べて「automated demotions」（自動的な順位の引き下げ）も制裁として挙げています。どのシステムが判定するかは公表されていません。手動対策と違って Search Console に通知は出ないため、6月15日以降にテンプレート単位で表示回数が落ちたのに手動対策レポートが空なら、自動降格も候補に入れて点検します。ただし表示回数の低下だけでは原因を特定できません。Googleのスパムアップデートの説明は、修正後にポリシーを守っていることを自動システムが学習するまで数か月かかることがあると書いています。スパム対策の自動システムの全体像はSpamBrainの公表実績と仕組み、定期的なスパム更新の履歴はスパムアップデートの定義と実施履歴にまとめています。
なお、Googleは2026年4月14日にドキュメントの更新履歴で、ユーザーからのスパム報告を手動対策に使う場合があると明記しました。乗っ取りは訪問者が体感で気づく違反なので、報告から審査に回る経路も現実的です。
ブラウザが既に防いでいる型と防げない型
戻るボタンの乗っ取りは、ブラウザ側でも以前から対策されています。ブラウザが止める範囲を知ると、自サイトで何を点検すべきかがはっきりします。
Chrome・Safari・Firefoxの履歴スキップの仕組み
3つのブラウザはいずれも、ユーザーが一度も操作していないページが追加した履歴を、戻るボタンで飛ばします。Chromiumの設計文書History manipulation interventionは、ユーザー操作（user activation）を一度も受けずに pushState やリダイレクトで履歴を足したページを、戻るボタンの移動先から外すと説明しています。
| ブラウザ | 仕組み | 確認した根拠 |
|---|---|---|
| Chrome・Edge（Chromium） | 操作なしで足した履歴に skippable 印 | Chromium設計文書 |
| Safari（WebKit） | wasCreatedByJSWithoutUserInteraction | WebBackForwardList.cpp |
| Firefox | browser.navigation.requireUserInteraction | StaticPrefList.yaml（既定 true） |
Safariの実装はWebKitのWebBackForwardList.cppで、JavaScriptがユーザー操作なしに作った履歴項目を飛ばす処理が入っています。WebKitの開発者もBug 248303で、これを意図した動作だと説明しています。FirefoxはBug 1515073（2020年6月に修正済み）で同じ考え方を実装し、設定 browser.navigation.requireUserInteraction は、releaseブランチとesr140ブランチのStaticPrefList.yamlのどちらでも既定 true です（2026年10月20日に確認）。
ここで言うユーザー操作は、HTML標準のactivation triggering input eventで決まっています。キー入力（Escとブラウザ予約のショートカットを除く）、マウスボタンの押下、タッチの指離しなどが該当し、スクロールだけでは操作になりません。どの操作でスキップを外すかはブラウザごとに違います。Chromiumの設計文書は、ページが操作を受けると、履歴を足す前に受けた場合も後に受けた場合も、そのページの履歴をスキップ対象から外すと書いています。WebKitは履歴を足した時点の操作の有無で判定します。
この仕組みはブラウザの戻るボタン（と進むボタン）にだけ効き、JavaScriptの history.back() には効きません。Chromiumの設計文書は、デスクトップでは戻るボタンが押せる表示のまま何もしない状態になり、長押しの一覧から飛ばされた項目を明示的に選べる、Androidでは戻る操作でタブが閉じる、とも書いています。
Chrome for Testing 156での実測：タップの有無と戻る回数
4つの型のページを作り、別オリジンのページAからリンクで遷移したあと、ブラウザ側の戻る操作（拡張機能の chrome.tabs.goBack()。ブラウザの戻るボタンと同じ経路）を繰り返しました。環境はmacOS上のChrome for Testing 156.0.8078.4、記録とスクリプトは2026年10月20日に取得したものです。
| ページの挙動 | 戻る1回目 | 戻る2回目 | 結果 |
|---|---|---|---|
| 読み込み時に pushState 2回（操作なし） | ページA | － | ブラウザが防ぐ |
| 読み込み時に pushState 2回、その後1回タップ | 同じページ #e1 | 同じページ | 3回押さないと抜けない |
| 1回タップした直後に pushState 2回 | 同じページ #c1 | 同じページ | 3回押さないと抜けない |
| タップ後 pushState 1回＋popstate で再 push | 同じページ #trap | ページA | 2回目で抜ける |
読み込み時に操作なしで足した2件の履歴は、戻る1回で丸ごと飛ばされ、元のページAへ戻りました。同じページでも history.back() を呼ぶと飛ばされず #b1 に戻ったので、スキップがブラウザの戻る操作だけに掛かることも確認できます。
一方、読み込み時に履歴を2件足したあとページを1回クリックすると、足した履歴は飛ばされなくなり、元のページへ戻るには3回押す必要がありました。クリック処理の中で履歴を2件足した場合も同じです。広告やおすすめの表示を、最初のタップや「閉じる」ボタンの押下に合わせて仕込む実装はこの型です。Chromeでは、ユーザーがページを操作すると、それまでに足した履歴もスキップの対象から外れました。例外は次に述べる、戻る・進む操作のあと新たな操作を受けずに履歴を足した場合です。Googleのポリシーは履歴を足すタイミングを問わず、戻る操作を妨げる行為全般が対象なので、ブラウザが防ぐ型も含めて自サイトから取り除いておくべきです。
popstate で戻る操作を検知して履歴を足し直す無限ループ型は、2回目の戻る操作で抜けられました。Chromiumは同一ドキュメント内の戻る・進む操作のあと、新しい操作を受けるまで以前の操作を履歴追加の根拠として認めない（crbug.com/1248529）ためです。現行のChromeでは「何度押しても永久に戻れない」状態は作りにくく、実害として残るのは、数回余分に押させる型と、戻り先に広告ページを差し込む型です。
Chromeが準備しているBack-to-ad intervention
同じ設計文書には、ユーザー操作があっても、広告スクリプトが差し込んだ履歴項目を戻る操作で飛ばす「Back-to-ad intervention」も載っています。広告スクリプトが replaceState で作った項目から、さらに pushState で次の項目を作ると広告由来と判定する仕組みで、2026年10月時点では既定で無効（機能フラグ BackToAdIntervention）です。戻り先が同じオリジンのページになる場合は適用しない例外もあり、有効になっても自社スクリプトによる乗っ取りや同一オリジン内の誘導は残ります。
乗っ取りを起こすコードの型とSPAとの境界
History APIは、SPA（シングルページアプリケーション）がURLと画面の状態を履歴に反映するために使う標準機能で、違反になるのは使い方です。境界は「ユーザーが戻るボタンで期待する移動先を奪っているか」です。
pushState・replaceState・popstateを使う3つの手口
乗っ取りの実装は、ほぼ次の3つの組み合わせです。
- 履歴の水増し：
history.pushState()で、画面が変わらないまま履歴を増やす。戻る操作が増えた分だけ空振りする。 - 戻り先の差し替え：
history.replaceState()で現在の項目を書き換え、次の項目を足す。戻ると広告やおすすめの一覧が表示される。 - 戻る操作の横取り：
popstateイベントで戻る操作を検知し、広告の表示や履歴の再追加を実行する。
次は、最初の操作に合わせて履歴を操作する説明用の抜粋です。おすすめ一覧を描画する関数 showRecommendFeed() の実装は省略しています。前節の実測のとおり、操作の後なのでブラウザの防御をすり抜けます。
document.addEventListener('click', () => {
const here = location.href;
history.replaceState({ ad: true }, '', '/recommend');
history.pushState({}, '', here);
}, { once: true });
window.addEventListener('popstate', (e) => {
if (e.state && e.state.ad) showRecommendFeed();
});このコードは、ユーザーが最初にどこかをクリックした時点で、現在の項目のURLと状態を /recommend の「おすすめ一覧」に書き換え、退避しておいた元のURLで項目を1つ足します。replaceState() はURLも書き換えるので、元のURLは先に退避しないと失われます。Chrome for Testing 156で試すと、戻る1回目は /recommend に移って popstate の処理が動き、元のページへは2回目で戻りました。ページを離れようとした操作で、ユーザーが頼んでいないおすすめを見せるので、公式ブログが挙げた症状にそのまま当たります。
SPAの正当なルーティングと違反の分かれ目
SPAのルーターがリンクのクリックに応じて pushState で履歴を足し、戻る操作で直前の画面を復元するのは、ユーザーの期待どおりの動きです。判断は次の2点で足ります。
- 履歴1件が、ユーザーから見て1回の画面遷移に対応しているか。画面が変わらないのに履歴だけ増えるなら水増しです。
- 戻った先が、ユーザーが直前に見ていた画面か。見ていない広告・おすすめ・別記事に着くなら差し替えです。
モーダルの開閉やタブの切り替えで履歴を足す実装は、戻る操作でモーダルが閉じるならユーザーの期待と合うことが多く、直ちに違反とは言えません。迷う場合は、検索結果から入った後に自分が何を操作したかを控え、戻るボタンで直前の画面や状態が復元されるかを確かめます。自分で開いたモーダルや遷移先からなら、検索結果へ1回で戻らないのが正常です。SPAとMPAの設計の違いはSPAとは？MPA・SSRとの違いで整理しています。
beforeunloadの離脱確認ダイアログの扱い
ページを離れる前に「このサイトを離れますか？」と出す beforeunload の確認ダイアログは、履歴を水増しする仕組みではありません。ただしGoogleの定義は履歴以外の機能による妨害も含むので、APIの種類ではなく使い方で判断します。HTML標準では、このダイアログはページがユーザー操作を一度受けた（sticky activation）場合に限って表示されます。フォームの入力途中など、ユーザーのデータを守る用途に限って使い、広告を見せるために離脱を引き留める「離脱防止ポップアップ」は、ページ内の画面を覆う表示で戻る操作を妨げる作りにしないことです。後者はGoogleの定義にある「その他の機能」の操作に当たり得ます。
自サイトの戻るボタン乗っ取りを点検する手順
点検の要点は、読み込み直後だけでなく、1回操作したあとも見ることです。ブラウザの防御が外れるのは操作の後なので、読み込むだけのテストでは違反が見えません。
DevToolsのIssuesパネルによる「Marked Skippable」の確認
Chromeは、ユーザー操作なしに履歴を足したページを検知すると、DevToolsのIssuesパネルに「Session History Item Has Been Marked Skippable」を記録します。実測でも、操作なしの pushState 2回に対して、この警告（プロトコル上の種別は NavigationEntryMarkedSkippable）が2件出ました。検索結果からのリンクでページを開き、DevToolsのIssuesパネルを確認するだけで、ブラウザが「乗っ取りの疑い」と見なした挙動を拾えます。
ただし、この警告は履歴を足した時点で操作がなかったことを示すだけです。読み込み時に履歴を足し、その後タップされたページでは警告が出たうえで、実際には履歴が飛ばされませんでした。逆に、タップの直後に履歴を足す型では警告が出ません。警告の有無はGoogleの違反判定とも別物なので、次の手順と組み合わせます。
pushStateの呼び出し元を記録するスクリプト
どのスクリプトが履歴を足しているかを特定するには、pushState と replaceState を包んで、呼び出し元とその時点の操作状態を記録します。次はNode.jsとplaywright-coreで、ページの読み込み前に記録用のコードを差し込むmacOS用の例です。作業用ディレクトリで npm install playwright-core を実行し、コードを audit.mjs として保存して、node audit.mjs https://example.com/ のように対象URLを渡します。Chromeの配置が異なる環境では executablePath を書き換え、page.mouse.click(5, 5) の座標は対象ページでリンクやボタンのない位置に合わせてください。Google Chrome 155.0.8059.85 で動かしました。
import { chromium } from 'playwright-core';
const url = process.argv[2];
const browser = await chromium.launch({
executablePath: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
});
const page = await browser.newPage();
const cdp = await page.context().newCDPSession(page);
await cdp.send('Audits.enable');
cdp.on('Audits.issueAdded', (e) => {
const d = e.issue.details.genericIssueDetails;
if (d) console.log('[DevTools Issue]', d.errorType, d.request?.url ?? '');
});
page.on('console', (m) => {
if (m.text().startsWith('[history')) console.log(m.text());
});
await page.addInitScript(() => {
for (const name of ['pushState', 'replaceState']) {
const orig = History.prototype[name];
History.prototype[name] = function (state, title, u) {
const caller = (new Error().stack.split('\n')[2] || '').trim();
console.log(`[history.${name}] url=${u} isActive=${navigator.userActivation.isActive} hasBeenActive=${navigator.userActivation.hasBeenActive} ${caller}`);
return orig.call(this, state, title, u);
};
}
});
await page.goto(url, { waitUntil: 'load' });
await page.waitForTimeout(3000);
await page.mouse.click(5, 5);
await page.waitForTimeout(3000);
await browser.close();isActive は直前の操作から間もない状態か、hasBeenActive はページが一度でも操作されたかを表します。読み込み時に履歴を足すページでは、次のように両方が false の行と呼び出し元の行番号、DevToolsの警告が並びます。
[history.pushState] url=#b1 isActive=false hasBeenActive=false at http://localhost:18791/b.html:3:38
[DevTools Issue] NavigationEntryMarkedSkippable http://localhost:18791/b.html
[history.pushState] url=#b2 isActive=false hasBeenActive=false at http://localhost:18791/b.html:3:72クリックの直後に履歴を足すページでは警告が出ず、両方が true の行が出ます。ただし操作状態の値も警告も、違反かどうかの判定ではありません。記録に出た履歴追加のうち、画面が変わらないまま履歴だけを増やすもの、戻った先をユーザーが見ていない画面にするものが乗っ取りの候補です。行末のURLは、自社のファイルか広告・レコメンドの配信元かを調べる手掛かりになります。共通のラッパー関数を経由するとそのファイルが表示されるので、必要に応じて console.trace() でスタック全体を確認し、タグを止める試験と突き合わせます。addInitScript() は子フレームにも先回りして適用されますが、location.hash の書き換えや location.assign() による遷移、Navigation APIの navigation.navigate() のようにHistory APIを通らない履歴追加と、観測時間の6秒より後に動く処理は記録できません。結果が空でも次の手順は省かないでください。
広告・レコメンド・タグマネージャー経由の原因スクリプトの切り分け
手元で再現した乗っ取りの原因を絞り込むには、DevToolsの横断検索（Macは Command+Option+F、Windows・Linuxは Control+Shift+F）で pushState・replaceState・popstate を検索し、ヒットしたファイルの配信元を確認します。Google Tag Managerなどから配信されるタグはHTMLのソースに現れないので、この検索か前節の記録で拾います。
原因が見つかったら、タグを1つずつ止めて戻る操作を試し、挙動が消えたタグを特定します。疑う順番は、離脱時に広告を出す機能を持つ広告タグ、「戻るとおすすめ記事を表示」といった設定を持つレコメンドウィジェット、離脱防止ポップアップ系のツールです。これらは管理画面の設定で履歴の操作をオンにできる製品があり、ベンダーの更新で挙動が変わることもあるため、導入時だけでなくタグを追加・更新したときにも同じ確認をします。広告の量そのものが評価に響く話はページレイアウトアルゴリズムの仕組みを参照してください。
検索結果からの流入とタップ後の戻る動作の確認
最後に、ユーザーと同じ導線で手で確かめます。シークレットウィンドウでGoogle検索から自サイトのページを開き、リンクやボタンのない本文の余白を1回タップ（クリック）してから、戻るボタンを1回だけ押します。画面遷移やモーダルを開く操作をしていないので、検索結果に戻れば、その試行では戻る操作の妨害は確認されなかったことになります。同じページに留まる、見ていないページや広告が出る、のどちらかなら原因を調べます。広告の配信条件や遅れて動く処理で挙動が変わることもあるため、日時を変えて複数回試します。テンプレートごとに広告タグの構成が違うサイトでは、記事・一覧・トップなど、テンプレートの種類ごとに1ページずつ試します。スマホではChromeとSafariで、タップの有無の両方を試してください。
乗っ取りで回遊率や滞在時間が見かけ上増えていた場合、修正後に数字が下がることがあります。その増えた分は離脱を妨げた結果なので、離脱率と直帰率の見方を踏まえて、修正前後を同じ指標で比べ直すのが現実的です。検索流入の落ち込みが乗っ取り以外の要因と重なっていて切り分けが難しい場合は、SEO内部施策の支援で原因の特定から一緒に進めることもできます。
戻るボタンで前のページに戻れないときの抜け方
ここからは、乗っ取りをしているサイトに当たってしまったユーザー側の対処です。
長押しの履歴一覧による元のページへの復帰
パソコンのChrome・Edge・Firefoxでは、戻るボタンを長押しするか右クリックすると、戻れる履歴の一覧が出ます。乗っ取りで足された項目は同じページ名が並ぶので、その下にある検索結果や元のページを直接選べば、一度で戻れます。Chromiumの設計文書のとおり、ブラウザが飛ばした項目もこの一覧からは選べるので、戻るボタンを押しても何も起きないときに有効です。
一覧を使わない場合は、ページに触れずに続けて2〜3回押してみてください。前節の実測では、足された履歴が飛ばされない型は2件の追加に対して3回、popstate で足し直す型は2回で抜けられました。途中でページをタップすると、そのページは再び履歴を足せる状態に戻ります。
長押しで履歴が出ないスマホでの対処
スマホでは、戻る操作がOSのジェスチャーやボタンに割り当てられていて、長押しで一覧が出ない環境が多くあります。その場合は次の順に試します。
- ブラウザのメニューから「履歴」を開き、元の検索結果やページを選ぶ。
- 新しいタブを開き、検索をやり直す。
- 乗っ取られたタブを閉じる。Android版Chromeは、全ての履歴項目が飛ばす対象になっていると、戻る操作でタブ自体を閉じる動きになります。
どのサイトでも同じ症状が出る場合は、サイトではなくブラウザの拡張機能やアプリ側の問題を疑い、拡張機能を止めて試します。
Googleへの乗っ取りサイトのスパム報告
検索結果から開いたページで乗っ取りに遭ったら、Googleのスパムの報告ページから報告できます。前述のとおり、Googleは報告を手動対策に使う場合があると明記しています。スパムポリシーの別の項目で、検索順位の操作やユーザーを欺く目的で検索エンジンとユーザーに異なる内容を見せる行為についてはクローキングの定義と手動対策で解説しています。
よくある質問
戻るボタンを長押ししても履歴が出ないのはなぜですか？
スマホでは戻る操作がOSのジェスチャーに割り当てられ、長押しの一覧がない環境が多いためです。乗っ取りサイトそのものが一覧を消しているわけではありません。ブラウザのメニューの「履歴」から元のページを選ぶか、タブを閉じて抜けてください。
離脱防止のポップアップはGoogleのスパムになりますか？
ブラウザ標準の beforeunload の確認ダイアログは、入力途中のデータを守る用途で使われ、ページが操作されていないと表示されないなどブラウザ側の制限もあります。ただし、履歴を操作しないという理由だけでポリシーの対象外とは言い切れません。戻る操作を検知して画面を覆う広告やおすすめを出す作りは、Googleの定義にある「閲覧履歴やその他の機能」の操作に当たり得ます。離脱時に広告を出す機能は止めておくのが安全です。
SPAでhistory.pushStateを使うと違反になりますか？
リンクのクリックに応じて履歴を足し、戻る操作で直前の画面を復元する通常のルーティングは違反ではありません。画面が変わらないまま履歴だけを増やす、戻った先が見ていない画面になる、のどちらかに当たる実装が問題です。
広告のスクリプトが原因でも自分のサイトが対象になりますか？
対象になります。Googleの公式ブログは、乗っ取りがライブラリや広告プラットフォームから生じる場合があると認めたうえで、原因のコード・インポート・設定を削除か無効化するよう運営者に求めています。手動対策を受けた場合は、修正してからSearch Consoleで審査をリクエストします。
施行日の6月15日以降、手動対策はサイト全体に掛かりますか？
Search Consoleのヘルプでは、現時点の手動対策は違反するコンテンツを含むページが対象です。繰り返し違反した場合は、対策がさらに進んだり、サイト全体の順位に影響したりする可能性があると書かれています。
