Back Button Hijacking: Google’s New Spam Policy Is Now Enforced

Back button hijacking is now an explicit violation of Google’s spam policies. Enforcement started on June 15, 2026. So any script that stops a visitor from going back to the page they came from puts your site at risk in Search. Who is most exposed? Owners who monetise with ad networks and third-party code they never wrote themselves. Here is what the rule says, where the problem usually hides, and how to test and fix it.

What is back button hijacking under Google’s spam policy?

A site interferes with browser navigation by manipulating the history or other functionality, and the user cannot immediately get back to the page they came from. That’s back button hijacking, as defined in Google’s spam policies for web search. Instead of the previous page, people land on URLs they never visited, get unsolicited recommendations or ads, or simply cannot browse normally.

The practice now sits in the malicious practices spam policy. And it is not really new: Google points out that inserting deceptive or manipulative pages into a user’s history was already against Search Essentials.

What changed on April 13 and June 15, 2026?

Google published the policy on April 13, 2026 and started enforcing it on June 15, 2026, which gave owners a two-month notice period, as stated in Google’s announcement on back button hijacking. Pages that engage in it may be subject to manual spam actions or automated demotions.

The ask is blunt: remove or disable any script or technique that inserts or replaces deceptive or manipulative pages in the browser history.

Why ad scripts and third-party libraries are the usual source

Often the offending code is not even yours. Google says some instances originate from the site’s included libraries or its advertising platform. But responsibility does not move with the code. Whatever runs on the page is yours to answer for, so ad scripts’ back button behaviour deserves the same review as first-party JavaScript.

A script calls history.pushState or replaceState to add extra entries. Another listens for the popstate event, which fires when someone presses back, and sends them somewhere else.

Is every use of the History API a problem, then? No. Single-page apps rely on it to record real navigation states, such as an opened product or a changed filter. Trouble starts when an entry exists only to hold the visitor or to show content nobody asked for.

How to test your site for browser history manipulation

The fastest check: arrive from a search result and press back once. You should be on the results page again. Run it the way a real visitor would:

1. Open the page from Google on a phone and on a desktop.
2. Press back immediately after it loads.
3. Repeat after scrolling, then after interacting with a widget.
4. Go through the key templates: article, category, landing page.
5. Test with ads loading, then again in a clean browser profile.

Red flags? A second press being needed, a recommendations or ad page appearing, or the same URL reloading. Also look at the hops between the search click and the final URL on your own origin, because chained redirects on NGINX can leave extra steps that make the return path feel broken.

Auditing scripts, interstitials and widgets that insert history entries

Find every script that writes to the history or reacts to the back event, then remove or disable the ones that keep visitors on the site against their will. A working checklist:

• Search the codebase and the tag manager for pushState, replaceState, popstate and location changes.
• List every ad tag, recommendation widget and exit-intent tool.
• Disable them one by one and rerun the back button test.
• Ask the ad network for a setting that turns the behaviour off.
• Drop the vendor if no such option exists.

Geo or device-based interstitials need a look too, because redirecting visitors by IP adds a hop before the content appears. If an NGINX reverse proxy with EU or USA addresses, such as Jalvo, sits in front of your existing hosting, the scripts still live on the origin and in the CMS. So that is where the audit happens.

What to do after a manual action for back button hijacking

Remove or disable the responsible code, then verify with the same back button test before you contact Google. A reconsideration request only makes sense once the page behaves correctly on every template.

Write down what was removed: script name, vendor, affected templates and date. That record lets you describe the fix precisely and spot the same library if it sneaks back in through another tag.

Keeping clear of back button hijacking is just a routine: test from search, audit third-party code, and retest after every change to the ad stack.

FAQ