Back button hijacking on your website: Google calls it spam
Google has officially treated back button hijacking as spam since 13 April 2026 and has been enforcing it since 15 June 2026. If a visitor gets stuck on your site when they tap back, you risk a manual action or an algorithmic demotion, even if a plugin or an advertising script is the cause. With a simple test on your phone, you'll know within a minute whether your website is in the clear.
Why this has suddenly become a real problem
On 13 April 2026, Google officially labelled back button hijacking as spam. If a visitor taps back and doesn't return to where they came from, that feels untrustworthy. Google now holds your website accountable for that behaviour. Enforcement has been running since 15 June 2026, so a site that still does this is at risk today.
Source: the announcement on the Google Search Central Blog of 13 April 2026, last checked on 25 August 2026: the post is still there and 15 June 2026 as the enforcement start date has not moved, and the spam policy itself, where Google describes it like this: Back button hijacking is when a site interferes with user browser navigation by manipulating the browser history or other functionalities, preventing them from using their back button to immediately get back to the page they came from (Google Search Central, spam policies, checked on 24 August 2026).
This is especially relevant for small business websites, and on mobile people tap the back button as a reflex
We deliberately don't quote a share of mobile traffic here: the figure that used to be here carried no source, so it's gone. On top of that, WordPress runs 40.7 per cent of all websites, as at 19 August 2026 according to W3Techs, and Elementor sits on roughly one in three of those WordPress sites, derived from the same W3Techs figures. Many small business websites are therefore a stack of theme, page builder and plugins, exactly the combination this problem sneaks into unnoticed.
Notice who the policy holds accountable
Google frames the rule around the site, not the code: what matters is that a site interferes with user browser navigation. In our own experience, that code often comes from a third-party library or an advertising script that the owner never deliberately added, and that changes nothing about who gets held responsible.
It fits a wider pattern, because Google is also working on fake reviews NL and on the question of how it views AI-written articles
The common thread sits in the same policy text: malicious practices are practices that create a mismatch between user expectations and the actual outcome. So Google judges what the visitor experiences, not what you intended.
What happens with back button hijacking
Technically, it's simple. Code adds extra steps to your visitor's browser history. When they tap back, they don't land on Google but on an interstitial page, a popup, or the same page again. The visitor is stuck.
This happens with functions that alter the browser history, such as history.pushState and history.replaceState
Those functions aren't forbidden in themselves; modern websites use them for normal navigation. Google doesn't look at your intention, but at the effect on the user. If the visitor gets stuck somewhere they wanted to leave, it counts as manipulation.
How to check your website on your phone
The test takes a minute and needs no technical knowledge:
- Open a private window on your phone.
- Search for your business name in Google.
- Click your own result.
- Wait until the page has fully loaded.
- Tap back once. You should see Google straight away.
If you don't see Google straight away, you have a problem
Then don't just test your homepage. Also check your contact pages, your advert landing pages and pages that load lots of components, because that's where scripts pile up. Repeat the test in Chrome and in Safari, because behaviour can differ per browser.
Where it often comes from
Back button hijacking is rarely a deliberate choice by a small business owner. It arises from combinations of themes, page builders, popups, chat widgets, tag managers and advertising scripts. Each component does something useful on its own, but together they can pollute the browser history.
WordPress itself is not the problem.
The combination of components needs to stay clean. The more plugins and external scripts you stack up, the greater the chance that one of them hijacks the back button without you noticing.
What to ask your web developer
If you find a problem, or you just want certainty, ask your web developer three questions:
- Can we test whether the back button goes straight back to Google, on mobile and on desktop?
- Are there scripts that alter the browser history through functions such as history.pushState or history.replaceState?
- Can I get a list of all the components that load on the most important pages?
Then work in a targeted way
Have suspect code disabled and test again, rather than panicking and removing everything. That way you know exactly which component is the culprit and you keep the functions that do work well. If you'd like someone who understands these technical signals to take a look, we're happy to help through Improve your SEO.
The four places it comes from on small business sites
If the test on your phone fails, you don't want to tear apart half your site to find where it's coming from. In practice, on small business websites it almost always comes from one of four corners. Go through them in this order, because this is also the order from most to least likely.
1. The cookie banner or consent layer
By far the most common source of trouble, and at the same time the least suspected. A consent layer needs to remember something on first display and often shows itself again when the visitor comes back. Some implementations add a step to the history for this, so that dismissing the banner can be undone. The result is that the first tap back brings the banner back instead of sending the visitor to Google. Test this specifically: run through the test from this article once with the banner accepted, and once with a clean private window where the banner still appears. If the result differs, you know enough.
2. The popup that appears when you try to leave
An exit intent popup is exactly what the name says: it pops up the moment your visitor leaves. That used to be a mouse movement to the top edge of the screen. On mobile, that movement doesn't exist, so some variants hook into the back button itself. That's by definition the behaviour Google now labels as spam, even if the popup itself shows a perfectly respectable discount code. A popup that appears on a timer or at a certain scroll depth is not a problem. A popup that appears on back is.
3. Third-party advertising and tracking scripts
Scripts you didn't write yourself and that you load through a tag manager are the trickiest category, because they change without you doing anything. A script that was well-behaved last month can have a new version this month. That's why this test belongs on the calendar, every quarter, and not in a one-off project: you're not testing your code, you're testing what gets loaded onto your site today. If you have a suspicion, temporarily put your tag manager into a preview mode without the suspect tag and repeat the test.
4. The page builder and its anchor links
Page builders love smooth scrolling to a section further down the page. Each of those jumps can add a step to the history. On a long page with a menu full of anchor links, after a minute of scrolling there can easily be eight steps between your visitor and Google. The visitor taps back eight times, gives up after two, and your site feels like a maze. Of all the variants, this is by far the friendliest, because there's no intent behind it at all, and it's also the variant most often overlooked.
What these four have in common: none of them was placed with bad intent, and none of them is in the text of your page. They sit in the layer around it. That's exactly why the test on your phone is so valuable, because it looks at the outcome, not the intention. And that's exactly why this check belongs with the rest of your technical maintenance, alongside the things covered on technical SEO NL.
What's still allowed: the back button isn't forbidden territory
After an announcement like this, there's always a risk of overreaction: strip out everything that touches the browser history, just to be safe. That's not necessary, and it makes some sites outright worse. The functions this is about are ordinary building blocks of the modern web, and they exist precisely to make navigation better. The distinction Google draws is in the policy text itself: it's about a site that gets in the way of the visitor's navigation. Not about a site that does something sensible with it.
Three examples of use that are perfectly fine:
Filters in an online shop
A visitor picks a size, a colour and a price range. Each choice changes the list of products. If each choice is also a step in the history, the visitor can undo their last filter with back. That's exactly what they expect. The test still holds up: once they've undone their filters, they end up back at Google.A multi-step form
With a three-screen quote request, a step back in the browser is the same as a step back in the form. That's tidy, and it stops someone losing all their input. What's not tidy is a form that only lets you leave once you've finished it.Tabs and accordions on a long page
A visitor who opens a chapter and then taps back can quite reasonably end up at the closed chapter. That only becomes a problem if they've collected twelve of those steps on the way in and have to tap twelve times on the way out.The rule of thumb you can take from this is usable without reading a single line of code. A step in the history is allowed if the visitor caused that step themselves and remembers it. Turning on a filter, they remember. A step the system added unasked, they don't remember, and that's why it feels like an obstacle. If you want to give your developer a limit: at most one step per deliberate action by the visitor, and zero steps they didn't cause themselves.
There's also a side to this that has little to do with Google
On mobile, the back button is the most used button in the whole browser, and on many Android devices it's even a swipe gesture from the edge that people make dozens of times a day. A site that doesn't respond to that as expected loses the visitor instantly, even if Google never notices. That's ultimately the stronger argument: fixing this is customer-friendliness, and the fact that there's now also a spam rule attached to it is the trigger, not the reason.
What to do if something has already happened
Suppose you're too late. Your rankings are dropping, or there's a notice in Search Console. Then order matters more than speed, because most of the damage from this kind of notice comes from panicked work that can't be unpicked afterwards.
Step 1: check whether there's a notice, and what kind
Open the manual actions section in Google Search Console. If there's nothing there, there's no manual action and you're dealing with an algorithmic assessment at most. That difference matters, because a manual action needs to be actively lifted, while an algorithmic assessment doesn't: it corrects itself once the cause is gone and the pages have been reviewed again. If there is a notice, read exactly which pages are named. Sometimes it applies to your whole domain, sometimes to part of it.
Step 2: fix it first, then gather evidence
Fix the problem and record what you did: which component it was, when you switched it off, and which test you used to confirm the back button now works. Take screenshots of the test on mobile and on desktop. This isn't bureaucracy: if you later request a reconsideration, this is exactly what should go in that request.
Step 3: check your whole site, not just the reported page
This is the step that gets skipped most often. If the problem comes from a script or a plugin, it's on every page where that component loads. Go through at least your homepage, your main service page, your contact page and an advert landing page. If you find another one, your first fix wasn't complete, and a reconsideration request would only have cost you time.
Step 4: only after that, and only for a manual action, the reconsideration request
For a manual action, you request a reconsideration in Search Console. Write down plainly what was going on, what you changed and how you checked that it's gone. No excuses, no explanation of who was responsible. The reviewer wants to know whether it's fixed. A reconsideration takes time, and a second request after a half-fixed problem sets you back further than patiently waiting for the first one. We won't quote a timeframe here: Google doesn't publish one as a firm commitment.
And the most important lesson is in the order itself: measure first, then fix, then prove it, and only then request anything. Anyone who reverses that ends up changing twenty things at once and can no longer work out afterwards which one was the problem. If you'd like someone beside you who's done this before, that's part of our work on Improve your SEO. You can also get a first impression of your site for free with the free SEO scan.
Put the test in your calendar, not on your to-do list
A website is never a finished product. Your plugins get updated, your theme gets an update, your marketer adds a new script to the tag manager, and your cookie banner switches supplier. Any of those moments can break the back button again, without anyone noticing. That's why this check doesn't belong on a list of one-off jobs, but in your maintenance rhythm.
A workable rhythm for a small business site looks like this:
Every time something changes on the outside
New cookie banner, new popup, new advertising script, new theme, or a major update to your page builder: do the one-minute test before you sign off. This is the moment the problem is created, and therefore the cheapest moment to find it.A round of five pages every quarter
Homepage, main service page, contact page, a blog article and your busiest advert landing page. On mobile and on desktop, in two browsers. Takes fifteen minutes and covers the places where most visitors arrive.Whenever there's an unexplained drop
If your rankings or your traffic drop for no clear reason, run this test before you start on your content. It's one of the few causes you can rule out in a minute, and that's worth doing before you spend weeks on content for a problem that sits somewhere else.What you're buying with this isn't just peace of mind about a spam rule. You're buying the certainty that your visitor's most used button does what they expect. That's one of the few things on a website that has to work one hundred per cent, because there's no middle ground: it works, or your visitor is stuck.
Frequently asked questions
Is back button hijacking always done deliberately?
No. It can also come from extensions, advertising code or third-party libraries. Google still holds you responsible for it, so testing remains necessary.
Can this make my WordPress website rank lower in Google?
Yes. Manual actions and algorithmic demotions are possible consequences of spam behaviour. Enforcement has been running since 15 June 2026, so a site that still does this today is at risk.
Should I remove all popups straight away?
No. Test first to see what's actually happening. Normal popups are different from back button hijacking code. Only remove what demonstrably hijacks the back button.
How often should I test this?
Test after every major change to your theme, page builder, advertising scripts or cookie banner. You can read more practical explanations about Google and your visibility in our Knowledge base.
Do the one-minute test, today
If you take just one thing from this whole page: grab your phone, open a private window, search for your own business name, click your result and tap back once. If you see Google, you're fine and you're done. If you don't see Google, you now know where to look and in what order. For most sites this is fixed within an hour, and the hour you put in now is considerably cheaper than the weeks a manual action costs.
If you get stuck at step three or four, or you just want to be sure you're not missing anything: send us your address and what the test did on your end, and we'll take a look with you at which component is polluting the history and what can safely come out. That's possible through the contact page, where you can pick a slot in the calendar straight away. We'll also simply tell you nothing's wrong if that's the honest answer.