Google's Back Button Hijacking Spam Policy (2026)

You click a search result, decide the page isn't for you, and press the back button. Instead of returning to Google, you land on a page you never visited, a wall of ads, or the same page again. That behaviour has a name, back button hijacking, and in April 2026 Google made it an explicit violation of its spam policies.

Google announced the change on 13 April 2026 and set an enforcement date of 15 June 2026, giving site owners about two months to remove offending code. Sites that keep doing it can face manual actions or automated demotions in Google Search. Crucially, Google acknowledged that the behaviour may come from third-party libraries or advertising platforms, not just a site's own code.

This guide explains the definition, where it sits in Google's spam policies, the enforcement timeline, the risk from third-party scripts, the possible penalties, and a practical audit you can run on your own site.

Key Takeaways

• Google announced a back button hijacking spam policy on 13 April 2026, listing it under “malicious practices”.
• Back button hijacking is when a site interferes with browser navigation, for example by manipulating browser history, so users cannot use the back button to return to the page they came from.
• Enforcement started on 15 June 2026; violations can lead to manual spam actions or automated demotions.
• Google said the behaviour may originate from a site's included libraries or advertising platform, so third-party scripts need auditing.
• Sites with a manual action can request reconsideration in Search Console after fixing the problem.

The policy at a glance

Item	Detail	Source
Name	Back button hijacking (spam policy)	Google Search Central Blog; Spam policies
Announced	13 April 2026	Search Engine Journal; Search Central Blog (April 2026)
Policy category	Malicious practices, alongside malware and unwanted software	Google spam policies
Enforcement date	15 June 2026	Search Engine Journal, reporting Google's post
Grace period	About two months	Search Engine Journal
Possible consequences	Manual spam actions or automated demotions	Search Engine Journal, reporting Google's post
Third-party code	May originate from included libraries or advertising platforms	Search Engine Journal, quoting Google
Type	Spam policy change, not an algorithm update with a rollout window	Google spam policies

What counts as back button hijacking?

Google's spam policies now describe back button hijacking as a site interfering with user browser navigation by manipulating browser history or other functions, so that people cannot use the back button to immediately return to the page they came from. It sits under “malicious practices”, which Google's policy introduces with a clear principle:

“Malicious practices create a mismatch between user expectations and the actual outcome.”

— Google Search Central, Spam policies for Google web search

According to Search Engine Journal's coverage of Google's announcement, examples of what users experience include:

• Being sent to pages they never visited.
• Being shown unsolicited recommendations or ads when they try to leave.
• Being unable to navigate back at all.

Google's reasoning is straightforward. As Search Engine Journal reported, Google said that “Back button hijacking breaks this fundamental expectation” that pressing back takes you back. Google also said people report feeling manipulated and less willing to visit unfamiliar sites. Google noted it had seen an increase in the behaviour and that it had warned against deceptive history manipulation as far back as 2013.

Enforcement timeline

Unlike a core or spam update, this was a policy change with a fixed start date rather than a rollout window.

• 13 April 2026: Google announces the policy on the Search Central Blog and updates its spam policies.
• 13 April to 15 June 2026: grace period to find and remove offending code.
• From 15 June 2026: enforcement through manual actions or automated demotions.

Search Engine Journal noted that Google did not specify whether enforcement would come through a dedicated spam update or through ongoing systems such as SpamBrain and manual review. Google did release the May 2026 core update shortly before enforcement and a June 2026 spam update from 24 to 26 June, but did not say either was related to this policy, so don't assume a link. You can follow later spam activity in our roundup of Google's 2026 spam updates.

The third-party script risk

This is the part that catches well-meaning sites. Google acknowledged that back button hijacking “may originate from the site's included libraries or advertising platform,” as quoted by Search Engine Journal. In other words, you might not have written the code, but it still runs on your pages, and you are still responsible for what users experience.

Common places to look include:

Source of risk	Why it matters	What to check
Ad network and header-bidding scripts	Some ad code may push extra history entries or intercept exits	Behaviour of the back button on pages with ads enabled vs disabled
Content recommendation widgets	Exit-intent or “before you go” features may redirect users	Whether pressing back shows a recommendation page instead of the previous page
Engagement or pop-up tools	Exit-intent overlays can tamper with navigation	Any script calling the History API on page load
Single-page app routing	Legitimate routing uses history too; bugs can trap users	That each back press returns to a real prior view
Tag managers	Can load many vendors at once, some unknown to the site team	Full list of tags firing on landing pages

Legitimate use of the browser History API is not the problem. Single-page applications use it so that back and forward work properly. The issue is using it to stop people leaving. Our guides to managing third-party scripts and JavaScript SEO cover the wider technical picture.

Step-by-step audit

1. Test real journeys. From a Google results page, open your key landing pages on mobile and desktop, then press back. You should return to the results immediately.
2. Repeat with ads on and off. If the problem disappears with ads disabled, the cause is likely an ad or partner script.
3. Inventory scripts. List every third-party script and tag on landing pages, including those loaded by your tag manager.
4. Search your code. Look for calls such as history.pushState or history.replaceState that run on page load or on exit, and check what triggers them.
5. Talk to vendors. Ask ad and widget providers to confirm in writing that they do not manipulate browser history to block exits.
6. Remove or replace offenders. Turn off the feature or vendor responsible.
7. Monitor Search Console. Check the Manual actions report and organic performance after 15 June 2026.

Our dedicated back button hijacking audit guide goes deeper into testing methods.

Penalties and recovery

Google said violations can lead to manual spam actions or automated demotions, either of which can reduce visibility in Search. The two are handled differently:

• Manual action: shown in Search Console's Manual actions report. Fix the issue, then submit a reconsideration request. See our guide to Google manual actions.
• Automated demotion: no notification. Fix the issue and allow time for Google's systems to recognise the change. Learn more in algorithmic demotion vs manual action.

Common mistakes

• Assuming “we did not write it” is a defence. Google said the behaviour can come from libraries or ad platforms, and site owners are expected to deal with it.
• Testing only on desktop. Mobile ad stacks often behave differently.
• Removing legitimate routing. Don't break your single-page app's navigation; fix only the manipulation.
• Ignoring tag manager sprawl. Old, forgotten tags are a common source of surprises.
• Linking every June ranking change to this policy. Google didn't tie any specific update to it.

Related Guides

• Google's 2026 Site Reputation Policy Change for the EEA
• Google's 2026 Spam Updates: March, June and August Explained
• Google's September 2026 Spam Update

Frequently Asked Questions

What is back button hijacking?

It is when a site interferes with browser navigation, for example by manipulating browser history, so that users cannot use the back button to return to the page they came from.

When did Google start enforcing the policy?

Google announced it on 13 April 2026 and said enforcement would start on 15 June 2026.

What happens to sites that violate it?

They can receive manual spam actions or automated demotions, which can lower their visibility in Google Search.

Am I responsible if an ad script causes it?

Google acknowledged the behaviour may originate from a site's included libraries or advertising platform. Site owners should audit and remove such code.

How do I recover from a manual action for back button hijacking?

Remove the offending code, confirm the back button works normally, then submit a reconsideration request in Search Console.

Conclusion

Google's back button hijacking policy turns a long-standing user frustration into an explicit spam violation, enforced since 15 June 2026. Because the cause is often third-party code, the fix starts with a careful audit of every script on your landing pages. If you need help auditing scripts or responding to a manual action, our penalty recovery service can help, or you can request a quote. For the full list of rules, see our Google spam policies guide.

References

1. Google Search Central Blog: Introducing a new spam policy for back button hijacking
2. Search Engine Journal: New Google spam policy targets back button hijacking
3. Google Search Central: Spam policies for Google web search
4. Google Search Status Dashboard: Ranking incident history
5. Search Console Help: Manual actions report