If your site or a third-party script inserts pages into a user’s browser history so the back button no longer returns them to the page they came from, those pages could be manually penalized or demoted in Google Search beginning June 15, 2026. Google announced on April 13, 2026 that “back button hijacking” is now an explicit violation of its malicious practices spam policy, and site owners have about two months to address any offending behavior.
What Google means by “back button hijacking”
Google describes back button hijacking as any technique that interferes with a user’s expected browser navigation so the back button does not return them to the previous page. Typical manifestations include inserting intermediate pages into history, routing users to unexpected pages, showing unsolicited recommendations or ads, or otherwise preventing normal back navigation.
The company frames the change under its existing “malicious practices” definition: a mismatch between user expectation and outcome that creates a deceptive or harmful user experience. Google says it has seen this behavior increase and is making it an explicit spam violation to protect users and preserve predictable navigation.
Why publishers and SEOs should treat this as a ranking issue
On the surface this looks like a UX problem, but Google will treat it as a search-quality and ranking issue. Pages engaging in back-button hijacking may be subject to manual spam actions or automated demotions that reduce their visibility in Search. For many sites, that translates directly into lost referral traffic and revenue.
Because enforcement affects search performance, compliance belongs on the SEO and site-quality roadmap—not just in the engineering backlog for UX fixes.
Immediate, practical steps before June 15
1) Run a focused audit. Scan your site for code that calls history manipulation APIs (history.pushState, history.replaceState), server-side redirects that inject pages into flows, or client-side flows that add intermediate pages to history.
2) Check third-party code. Google explicitly calls out libraries, ad platforms and tag managers as common sources. Audit all vendor scripts, ask partners whether they alter browser history, and disable or replace any that do.
3) Remove or reconfigure offending behaviour. If a script or configuration inserts or replaces pages in user history in a way that prevents normal back navigation, remove it or change the implementation so the back button returns users to the prior page.
4) Monitor Search Console and follow remediation processes. If your site receives a manual action and you’ve corrected the issue, submit a reconsideration request through Search Console. Use Google’s help community or social channels only for clarifying questions—do not rely on them for enforcement timelines.
Implementation notes and edge cases
Google acknowledges that legitimate navigation patterns exist—particularly for single-page applications and in-app navigation—but is drawing a line when history is manipulated to deceive or trap users. The announcement does not add new technical requirements beyond the harmful behavior definition; it does, however, put the behavior squarely into spam enforcement.
Site teams should document decisions where navigation changes are required for product reasons and ensure the UX still allows a clear, immediate path back to the previous page. Where behavior originates in a third-party component, insist on a remediation plan from the vendor or remove the component until it is fixed.
What to watch next
Expect Google to start enforcement on June 15, 2026. Look for follow-up developer guidance or examples from Google that clarify acceptable navigation patterns (for example, legitimate single-page-app routes) versus explicitly deceptive implementations. Until then, prioritize audits of first- and third-party scripts, ad integrations and tag managers.
For teams responsible for search performance: treat this as both a ranking-compliance and a user-experience task—remove the offending code, monitor Search Console, and keep a record of fixes in case you need to submit a reconsideration request.