Google just banned back-button hijacking. How's your site doing on that?
Google Search Central quietly, without any fanfare, added a new item to its spam policies — "back button hijacking." Let me translate that from corporate-speak: if your site hijacks the browser's back button and won't let a user properly leave the page — that's now officially spam. Not a "bad practice." Not a "UX flaw." Spam. With penalties attached.
And you know what? About time.
What actually happened
It used to be a gray area. A script would catch the back-button press, mess with the history using history.pushState() or history.replaceState(), and instead of leaving the page, the user either got stuck in place or got flung somewhere else — another page on the same site, a popup, a redirect to a casino, or a fresh offer landing page. Technically, there was nothing to point at — the guidelines said nothing. Now the silence is over. Google called it out by name and put it on the record as a manipulative practice.
Why this hits iGaming first
Let's be honest — in betting and gambling, this trick has been exploited for years. A user lands on an affiliate page, wants to hit back to return to search — and instead gets bounced to a different offer, redirected into another affiliate program, or stuck on the same page under a popup screaming "wait, we've got a discount." Classic move. Some called it "user retention." Others called it what it actually is — forcing people to stay.
Before, the worst you'd get was a pissed-off user and a high bounce rate. Now you can get hit with Google penalties. That changes the math. If a good chunk of your traffic comes from organic search, not just paid and email — losing rankings over a script someone wrote years ago "to boost retention" isn't some abstract risk anymore. It's real.
What to actually check
No magic here, it's straightforward:
- The browser's back button should take the user back to where they actually came from. Really back there — not to whatever page you'd prefer to show them.
- If
history.pushState()orhistory.replaceState()shows up anywhere in your code — figure out why it's there. There are legitimate reasons (SPA navigation, for one), but if it's being used to hide the real URL or manipulate history — rip it out. - Walk through every navigation path on the site by hand. And I mean by hand — actually pressing back at every key step: from a bonus card, from a landing page, from a blog post. Automated tests often miss this, because it's not a bug — it's deliberately built-in behavior.
- Check for scripts that swap or mask the page address. If one URL shows in the address bar while content loads from somewhere else — that's exactly the gray zone that just got shut down.
My take
A lot of SEOs in iGaming spent years building funnels on navigation manipulation, because it worked and nobody punished them for it. But playing the long game isn't about squeezing out a conversion today with a script that tanks your entire organic traffic tomorrow. Google doesn't throw around wording like this for no reason — if a policy shows up explicitly, it means the algorithms can already catch it, and manual reviews are coming next.
Sit down and answer honestly: if Google ran a manual review on your site tomorrow, would the back button behave the way a user expects? If not — this isn't a "I'll fix it someday" issue. It's a "how much traffic am I willing to lose before I fix it" issue.
If you're not sure your site is clean of these manipulative patterns, we can run a technical audit and pin down exactly what Google might flag — check our services.