Back Button Hijacking: Google’s Newest Spam Policy

This is the newest of Google’s spam policies, and the one most likely to be catching site owners who have no idea they are doing it.

If your traffic fell after mid-June 2026 and nothing else explains it, this is worth ruling out.

What it looks like to a user

Someone clicks back expecting to return to search results. Instead:

• They land on a page they never visited.
• They see an advert or a recommendation feed they did not ask for.
• They have to click back several times to escape the site.

Google placed it under malicious practices, alongside malware and unwanted software. That is a serious category, not a user experience note.

The timeline

Date	Event
13 April 2026	Added to the spam policies
15 June 2026	Enforcement begins

Two months between documenting and enforcing. Site reputation abuse followed the same pattern in 2024, written in March and enforced in May.

That gap is where the cheap fixes live, and it is why the October 2026 guidance changes are worth acting on now.

Why you might be doing it without knowing

This is the part that matters most. Google acknowledged that some cases come from a site’s included libraries or advertising platform rather than the owner’s own code.

• Ad networks that insert an extra page into the browser history.
• Content recommendation widgets that intercept the back action.
• Exit-intent popups built aggressively.
• Plugins that promise to “recover” leaving visitors.

Responsibility sits with the site, wherever the script came from. Google judges what the page does, not who wrote it.

How to test your own site

1. Search for your page on Google and click through. Then press back once. You should be on the results page.
2. Turn off your ad blocker first. Most hijacking comes from ad code, and a blocker hides it.
3. Test on mobile and desktop, several page types, and more than one visit.
4. If it fails, disable third-party scripts one at a time until back works normally.

Step two catches most people out. Developers test with blockers on and never see what their visitors see.

What is not back button hijacking

Legitimate history management is fine. Single-page applications that update the address bar as you move between views are doing what browsers are designed for.

The test is intent and outcome. If back takes the user where they expect, it is not a violation. If it traps them or shows them something they never chose, it is.

If you were hit

• Check Manual Actions first. A manual action names the problem.
• Remove the script entirely, not just on some pages.
• If manual, file a reconsideration request showing what you removed. Process in how to write a reconsideration request.
• If algorithmic, spam systems reassess continuously. Results typically follow in weeks once the behaviour is gone.

The revenue question is real. Removing an aggressive ad script costs money. A demoted site earns less from every script it runs. All 16 policies are in every Google spam policy explained.

Common culprits to check first

• Ad networks with exit or interstitial formats, which show an advert when a visitor tries to leave.
• Native ad and recommendation widgets that promise to recover departing visitors.
• Push notification and subscription scripts with aggressive leave-page behaviour.
• Exit-intent popup tools set up to interfere with navigation rather than simply appear.
• Old tracking or affiliate scripts that nobody remembers adding.

Questions to ask your ad network

1. Do any of your formats change browser history or intercept the back button?
2. Which settings control that behaviour, and are they switched on for our account?
3. Have your formats been reviewed against Google’s malicious practices policy since April 2026?

Get the answers in writing. If a network cannot confirm its formats are clean, test with it switched off and compare. Revenue from one format is rarely worth the visibility of the whole site.

After you remove the script

• Test again on mobile and desktop, from a Google results page, with no ad blocker.
• Check Search Console for a manual action and its current status.
• Record the date you removed the script, so any recovery can be matched to the change.
• Add a back button test to the checklist for every new ad or widget you install.

For most sites this is a one-time fix. The risk is a new script reintroducing the behaviour months later, which a quick test on every new install prevents.

Explaining the decision to stakeholders

Removing an ad format costs visible revenue, so expect resistance. Frame it as a trade between one income stream and the whole site’s search visibility.

• What the format earns each month.
• What organic search earns each month, in traffic and revenue.
• What a demotion would cost if a large share of that organic traffic disappeared.

Put the three numbers side by side. In most cases the decision makes itself, and having it in writing protects whoever made the call.