A visitor lands on your service page from Google, decides it isn’t right for them, and taps the back button. Instead of returning to the search results, they’re sent to another offer, shown an exit page, or left on the same page.
That isn’t clever conversion optimization anymore. Google now calls it spam.
Google added back button hijacking to its spam policies in April 2026 and began enforcement on June 15. According to Google’s announcement, offending pages may receive manual spam actions or automated demotions. If your website uses popups, landing-page software, redirect tools, or custom JavaScript, you need to check it now, even if you never asked anyone to manipulate browser history.
Here is what the policy means, how to audit your site in under an hour, and how to keep legitimate tracking and single-page navigation working.
What back button hijacking actually means
Google defines back button hijacking as interfering with browser navigation by manipulating browser history or other functionality so users can’t immediately return to the page they came from.
The normal journey is simple:
- A person searches Google and opens your page.
- They press or swipe back once.
- They return to the same Google results page.
A hijacked journey inserts something the visitor didn’t request. One press might open a second landing page. It might replace the current page with an ad, reload the original offer, or trigger a full-screen message that blocks navigation. Some implementations add several invisible entries to the browser’s history, forcing the visitor to press back repeatedly.
The technical culprit is often misuse of JavaScript’s History API. The API itself is legitimate. MDN’s documentation explains that pushState() adds an entry to session history while replaceState() modifies the current entry. Modern web apps need those methods to update URLs when a visitor changes a product filter, opens an item, or moves between screens without a full page reload.
The line is user intent. If the page creates history entries that reflect real navigation, that’s normal. If it creates entries to stop someone from leaving, that’s hijacking.
Why a small-business website can violate the policy by accident
Most business owners aren’t writing scripts to trap visitors. The risk usually enters through software someone installed for a reasonable marketing goal.
Exit-intent tools are an obvious place to look. A standard exit popup that appears when a desktop cursor moves toward the top of the screen doesn’t necessarily alter history. A more aggressive tool may intercept the back button on mobile and send the visitor to a special discount page.
Landing-page builders, affiliate scripts, ad networks, and redirect plugins can do the same thing. A vendor may describe the feature as a “back button redirect,” “back button offer,” “exit redirect,” “traffic recovery,” or “bounce recovery.” The label sounds useful. The behavior is what matters.
Compromised sites create another risk. Google groups the new rule with malicious practices in its official spam policies, alongside behavior such as installing unwanted software or changing a homepage without permission. A hacked plugin or injected script can redirect visitors even when the site looks normal to an administrator.
Finally, custom single-page applications can get history wrong without malicious intent. A developer may accidentally call pushState() each time a component loads. The visitor sees one page, but the browser records several entries. One tap no longer takes them back.
The SEO risk is real now
Google announced the policy on April 13 and allowed site owners until June 15, 2026, to make changes. That grace period is over. Google says enforcement can include both manual actions and automated demotions.
A manual action is not a vague warning. It means a human reviewer determined that pages on the site violate Google’s spam policies. Google documents that site owners can review manual actions in Search Console, fix every affected page, and submit a reconsideration request.
An automated demotion may be harder to diagnose because it doesn’t necessarily produce a message. Traffic can fall while Search Console shows no manual action. Google’s guidance for debugging search traffic drops specifically tells site owners who suspect a spam violation to review the spam policies and correct practices automated systems may detect.
There is also a business cost that has nothing to do with rankings. A customer who feels trapped doesn’t become more qualified. They become irritated. You may inflate page views or session duration in analytics, but those numbers don’t represent added demand.
A 45-minute back button audit
You don’t need to understand JavaScript to perform the first pass. Use a phone and a desktop computer, and test both a normal browser window and a private window. Private browsing helps reveal scripts that behave differently for first-time visitors.
1. Test your main entry pages
Start with pages that receive traffic from outside your site: the homepage, top service pages, popular blog posts, paid landing pages, and promotional pages. Search for your business or paste a Google results URL into your browser, then open the page from those results when possible.
On each page, wait at least 15 seconds. Scroll, accept or reject the cookie banner, close any popup, and then press back once. You should return directly to the page you came from. Repeat the test after submitting or dismissing any visible form, opening the mobile menu, and interacting with chat.
Run the same checks in Chrome, Safari, Firefox, and Edge if those browsers represent meaningful traffic for you. Browser engines don’t always process navigation events identically, so one clean Chrome test isn’t enough for a script-heavy site.
2. Test the paths most likely to trigger marketing scripts
Some behavior only runs when a URL contains campaign parameters or when a visitor arrives from an ad. Test links with the same UTM parameters used in your email, social, and paid campaigns. Then check:
- Discount, coupon, and limited-time offer pages
- Pages with exit popups, sticky offers, quizzes, or chat widgets
- Affiliate and partner landing pages
- Mobile pages reached from Google Ads or social ads
- Pages changed recently by a plugin, tag, or agency
Press back more than once if the first press doesn’t work. Record the page URL, device, browser, steps, and a screen recording. That evidence will save your developer from guessing.
3. Review installed tools
Open your content management system, tag manager, and landing-page platform. Search tool settings and vendor documentation for “history,” “back button,” “exit redirect,” “bounce recovery,” and “mobile exit.” Disable any feature designed to redirect a person after they press back.
In Google Tag Manager, review custom HTML tags and templates, especially those added by ad partners or short-lived campaigns. Pause unknown tags in a staging environment first. Removing a tag from production without checking can break measurement, consent controls, or lead routing.
4. Ask a developer to inspect history manipulation
Your developer should search the site’s own code and loaded third-party scripts for history.pushState, history.replaceState, popstate, window.location, and navigation event handlers. Finding those terms does not prove a violation. It identifies code that needs context.
For a single-page application, each meaningful screen or route may deserve one history entry. Opening a product and pressing back should return to the product list in its previous state. A filter change might use replaceState() if the old state has no value to the visitor. What shouldn’t happen is the silent insertion of duplicate entries simply to consume back-button presses.
Chrome DevTools can help identify the responsible script. The developer can disable third-party scripts one at a time, repeat the navigation test, and inspect event listeners and network activity. The goal is to find the smallest change that restores expected navigation without breaking real application routes.
How to fix it without wrecking conversions
First, remove any intentional back-button redirect. Don’t change its destination or add a different interruption. When the visitor asks to go back, let them go back.
Second, replace coercive recovery tactics with choices the visitor can ignore. A clearly labeled sticky call button, an inline price guide, a short quote form, or a normal exit-intent offer on desktop can still capture interest without rewriting browser history. The close button should work, and dismissing an offer shouldn’t make it reappear during the same visit.
Third, preserve legitimate application navigation. Don’t delete every call to the History API. MDN’s History API guide shows how popstate, pushState(), and replaceState() work together for actual navigation. Have the developer map every history entry to something the visitor recognizes as a distinct state.
Fourth, test analytics after the change. A back-button trap can create fake page views, duplicate landing-page visits, or misleading engagement. Compare event counts before and after the fix, then annotate the change date in your reporting. A drop in page views may simply mean the tracking is finally describing real behavior.
What to do if Google has already taken action
Check the Manual Actions report in Search Console. If a notice appears, read the scope carefully. It may affect specific URLs or the entire site.
Fix every instance, including third-party scripts and alternate templates. Test logged-in and logged-out experiences, mobile and desktop layouts, campaign URLs, and multiple browsers. Then follow Google’s reconsideration request process. Explain what caused the behavior, what you removed or changed, how you verified the correction, and what controls will prevent it from returning.
Don’t submit while the behavior is intermittent or while another template still traps users. A clean, specific request backed by a complete fix is stronger than a quick promise.
If there is no manual action but organic traffic dropped after June 15, compare landing-page performance before and after that date. Check technical changes, indexing, seasonality, security problems, and other Google updates too. Timing alone doesn’t prove the cause. Still, any broken back-button behavior should be fixed regardless of whether it caused the traffic loss.
Make navigation integrity part of website maintenance
This policy is a useful reminder: your site includes every script that runs on it, not just the code your team wrote. A five-year-old promotion tag can create a current SEO problem.
Add back-button testing to quarterly quality checks and every launch checklist. Require marketing vendors to disclose redirects and browser-history behavior. Keep a simple inventory of plugins, tags, owners, and business purposes, then remove tools nobody owns.
Conversion work should help people make a decision, not take away their controls. If you want a website audit that checks technical SEO, third-party scripts, and the path from landing page to lead, get started with Your Web Team.
