In short: Google is classifying “back button hijacking” as spam, targeting sites that abuse the browser History API to trap users when they try to navigate away. Enforcement begins 15 June 2026, with penalties ranging from manual spam actions to algorithmic ranking demotions. Site owners are liable even when the offending code comes from third-party ad networks or engagement scripts.

Google is taking aim at one of the web’s most persistent irritations: sites that hijack your browser’s back button so you cannot leave. A new spam policy, announced on the Google Search Central blog and set to take effect on 15 June, will classify “back button hijacking” as a violation that can trigger manual penalties or automated ranking demotions.

The tactic works by abusing the browser’s History API. When a page loads, a script quietly injects fake entries into the browsing history using methods such as history.pushState or history.replaceState. When the user presses back, instead of returning to the previous page, they land on an interstitial, an ad, a recommendation feed, or simply the same page they were trying to escape. In some cases, users must tap back a dozen times before they break free.

What counts as a violation

Google’s policy is broad. Any technique that inserts or replaces “deceptive or manipulative pages” into a user’s browser history, preventing them from immediately returning to the page they came from, now falls under the company’s malicious-practices umbrella. That includes exit-intent overlays triggered by back navigation, popunder ad scripts, and recommendation widgets that intercept the popstate event to redirect users rather than releasing them.

Crucially, site owners are on the hook even when the offending code belongs to a third party. Google’s blog post explicitly warns that some instances of back button hijacking “may originate from the site’s included libraries or advertising platform” and instructs webmasters to audit their entire technical stack, including ad networks, A/B testing tools, consent modules, and engagement widgets. If a monetisation script bundled into your analytics package is manipulating browser history, the penalty lands on your domain.

A two-month grace period

Google is publishing the policy two months ahead of enforcement, giving site owners until 15 June to identify and strip out non-compliant code. After that date, pages caught hijacking the back button face manual spam actions from Google’s webspam team or algorithmic demotions that could tank a site’s visibility in search results. For publishers that depend on organic traffic, the stakes are existential.

The announcement fits a pattern of Google steadily expanding its spam playbook. In March 2024, the company introduced policies against site reputation abuse, scaled content abuse, and expired domain abuse. An August 2025 spam update refined detection further. Back button hijacking is the latest addition, and it targets a behaviour that sits squarely at the intersection of deceptive web practices and poor user experience.

Why now

The timing is not accidental. Back button hijacking has grown more prevalent as publishers scramble for engagement metrics and ad revenue in a landscape reshaped by AI overviews, zero-click searches, and declining referral traffic. A cottage industry of monetisation scripts now packages history manipulation alongside legitimate-sounding features like “scroll-depth analytics” or “exit-intent recovery.” A recent cybersecurity report flagged a malvertising threat actor dubbed “D-Shortiez” that exploited a WebKit vulnerability to force browser redirects at scale, suggesting the technique has moved beyond scrappy affiliate sites into organised ad fraud.

For users, the change cannot come soon enough. Back button hijacking breaks a fundamental expectation of how browsers work. You click back because you want to leave. When that action is subverted, trust erodes, not just in the offending site, but in the broader web. Google’s own blog post acknowledges this: people who encounter hijacking report feeling “manipulated” and become less willing to visit unfamiliar sites at all.

What site owners need to do

Google’s guidance is straightforward. Remove any code that adds history states on page load solely to intercept back navigation. Remove any code that redirects users when back is pressed. Remove any overlay that appears specifically because the user tried to navigate away. And audit every third-party script running on the site, because ignorance is not a defence.

The policy applies globally and covers all pages indexed by Google Search. Sites that have already received a manual action can request a review through Google Search Console once they have resolved the issue.

For the wider ecosystem, the move raises a question that has dogged web governance for years: who is responsible when the rules of the open web are enforced primarily by one company’s search engine? Google’s spam policies function as de facto regulation for any site that relies on organic traffic, which is to say, most of the web. When the company decides a practice is unacceptable, the economic incentive to comply is immediate, arguably more so than any legislation. The EU’s Digital Services Act obliges platforms to tackle deceptive design patterns, but enforcement timelines stretch into years. Google’s deadline is eight weeks away.

Whether that concentration of power is a feature or a bug depends on where you sit. For the billion-plus people who use Google Search daily, a web where the back button works as expected is an unambiguous improvement. For publishers navigating an ever-tightening set of algorithmic rules, it is one more thing to get right, or risk losing the traffic that keeps the lights on.