Back button hijacking is when a page interferes with a visitor's browser navigation so that pressing "back" doesn't return them to where they came from - instead they're trapped, redirected to a page they never chose to visit, or shown an unexpected ad or recommendation screen first. Google added it to the malicious practices section of its spam policies on 13 April 2026, and enforcement has been live since 15 June 2026: pages caught doing it can face manual spam actions or automated ranking demotions.
How It Actually Works
The technical mechanism is the browser's History API - specifically history.pushState() and history.replaceState(), the same functions legitimate single-page apps use to update the URL without a full page reload. The abuse is calling them to insert fake entries into a visitor's browser history rather than in response to a real navigation, effectively trapping them inside the site to rack up extra pageviews and ad impressions. Common patterns:
- Redirect loops - pressing back reloads the same page instead of leaving it.
- Ad detours - an unexpected ad-filled page gets inserted into the back-history before the real previous page.
- Multi-click traps - every back-press adds another fake history entry, so escaping takes several tries instead of one.
Why This Often Isn't the Site Owner's Own Code
This is the detail that matters most for small business sites: Google has explicitly said back button hijacking commonly originates from third-party libraries or ad networks, not code the site owner wrote themselves - and the site is still held responsible regardless of where the offending script came from. A WordPress site running an ad network plugin, an affiliate widget, or a bundled analytics/monetisation script picked up years ago could be doing this without anyone on the team having written a line of the responsible code.
How to Check Your Own Site
- The real-world test. Arrive at a page on your site by clicking through from an actual Google search result (not typing the URL directly), browse normally, then press the browser's back button. You should land back on the Google results page immediately. If you land on a different page of your own site first, or the same page reloads instead of leaving, something is inserting extra history entries.
- Check DevTools. In your browser's developer tools, the Sources panel lets you watch for
pushStateorreplaceStatecalls - if any fire automatically on page load rather than in response to an actual click or navigation, that's the signal to investigate further. - Audit third-party scripts specifically, not just your own code - ad network tags, affiliate widgets, and any bundled monetisation or "engagement" scripts are the most likely source per Google's own guidance.
What to Do If You Find It
Remove or disable the responsible script, whether it's your own code or a third-party inclusion. If it's coming from an ad network or plugin, that's worth raising directly with the vendor - Google's policy holds the site responsible either way, so waiting on someone else to fix it isn't a safe strategy once enforcement is live. Google published the policy two months ahead of enforcement specifically to give site owners time to audit and remove offending code; that grace period has already passed, so this is worth checking now rather than after a ranking drop prompts the question.
The Fast Way to Check the Rest
Spotting a rogue pushState call buried in a third-party script isn't something most site owners can eyeball confidently. AuditCrow's free scan checks the technical fundamentals of your site as part of its review, and our technical SEO checklist covers the rest of what's worth auditing alongside this.