How to Audit Your Site for Back Button Hijacking Scripts

You click a search result, decide the page is not what you wanted, and press the back button. Instead of returning to Google, you land on another page of the same site, or a full-screen ad, or you simply stay put. That experience now has a name in Google's spam policies: back button hijacking. Since 2026 it sits under the "malicious practices" policy, and sites that do it risk manual actions or automated demotions.

The awkward part is that many site owners who trip this policy never wrote the offending code. It often arrives with an ad tag, a "recommended content" widget, an exit-intent popup or an old JavaScript library. If you do not audit for it, you may not know it is there until traffic or a Search Console message tells you.

This guide gives you a practical audit process: where history-manipulating code hides, how to test navigation by hand and with browser tools, how to fix what you find, and what to do if you have already been hit. For the policy background itself, read our explainer on the Google back button hijacking policy.

Key Takeaways

• Google added back button hijacking to its malicious practices spam policy in April 2026; Search Engine Journal reported enforcement from 15 June 2026.
• The behaviour usually comes from code that adds or rewrites browser history entries, or intercepts the back action, so the user cannot return to the page they came from.
• Third-party code is a common source: Google itself noted it can originate from included libraries or advertising platforms.
• Audit by testing real navigation from a Google results page on mobile and desktop, then trace any odd behaviour to the script responsible.
• If you received a manual action, fix the cause and file a reconsideration request in Search Console; algorithmic demotions have no request process.

What the policy actually says

Google's spam policies list three examples of malicious practices: malware, unwanted software and, since April 2026, back button hijacking. The definition is short and worth reading in full:

“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 for Google web search

Notice the focus on outcome rather than technique. Google does not ban the browser's History API, which single-page apps, image galleries, filters and infinite scroll legitimately use. What it targets is the result: a visitor who presses back and does not get back. That distinction matters for your audit, because you are not hunting for every pushState call, only for the ones that trap people.

Fact	Detail	Source
Policy	Back button hijacking, listed under malicious practices	Google spam policies page
Announced	April 2026 (Search Central blog post; SEJ coverage dated 13 April 2026)	Google blog, Search Engine Journal
Enforcement start	15 June 2026, according to Search Engine Journal	Search Engine Journal
Possible consequences	Manual spam actions or automated demotions	Search Engine Journal
Known sources	Site's own code, included libraries or advertising platforms	Search Engine Journal, reporting Google's post
Fix path for manual actions	Fix the issue, then submit a reconsideration request in Search Console	Search Engine Journal

Where history-manipulating code hides

Before you open any developer tools, list every piece of JavaScript that loads on your pages. On most commercial sites the list is longer than anyone expects. Search Engine Journal's coverage of the announcement put the third-party risk plainly:

“Some instances of back button hijacking may originate from the site's included libraries or advertising platform.”

— Matt G. Southern, Search Engine Journal, New Google Spam Policy Targets Back Button Hijacking

The usual suspects fall into a few groups:

• Ad tags and header bidding wrappers. Some monetisation scripts insert an extra history entry so that pressing back shows an interstitial ad or an "exit" offer before the user leaves.
• Content recommendation and "read next" widgets. Some push a recommended article into history so back sends readers deeper into the site instead of back to Google.
• Exit-intent and retention popups. Tools that detect the back action and show a discount or survey can cross the line if the visitor cannot leave on the first press.
• Old jQuery plugins and theme scripts. Unmaintained sliders, lightboxes and "smooth scroll" plugins sometimes rewrite history on every interaction.
• Redirect chains and tracking hops. Client-side redirects that leave an intermediate page in history can bounce users forward again when they press back.
• Single-page app routing bugs. A router that pushes a new entry on page load, rather than replacing the current one, creates a loop.

A step-by-step audit process

This process works for a small brochure site and scales to a large publisher if you sample templates rather than URLs. It fits naturally inside a wider technical SEO review.

1. Inventory templates. Group URLs by template (article, category, product, landing page, AMP or alternate versions). Behaviour usually follows the template, not the individual page.
2. Inventory scripts. For each template, list inline and external scripts, including those injected by a tag manager. Note owners and the date each was added.
3. Test from a real results page. Search for a query that returns your page, click through, wait a few seconds, scroll, then press back once. You should land on the results page. Repeat on Android Chrome, iOS Safari and a desktop browser, and test as a logged-out visitor with ads enabled.
4. Test entry paths that matter. Repeat from Google Discover, from social apps' in-app browsers and from a direct link, since some scripts only fire for certain referrers.
5. Watch history in developer tools. In the browser console, check history.length right after landing and again after a few seconds. A count that grows without you navigating is a red flag.
6. Search the code. Look through your own bundles and third-party files for history.pushState, history.replaceState, popstate listeners, onbeforeunload handlers and location.replace calls, then work out which ones fire on load or on back.
7. Isolate by blocking. Use the developer tools request-blocking feature, or a staging copy, to disable scripts one at a time until the behaviour stops. That identifies the culprit even when the code is minified.
8. Document and fix. Record the script, the template, the behaviour and the fix, then retest every browser from step 3.

Signal during testing	Likely cause	What to do
Back press shows another page of your site	Script pushes an extra history entry on load	Remove the script or change it to replace, not push, the current entry
Back press shows a full-screen ad or offer	Ad or retention tool intercepts the back action	Disable that ad format or feature; ask the vendor to confirm in writing
Several back presses needed to leave	Multiple entries added on scroll or on timers	Audit infinite scroll and slider plugins; only update URLs on deliberate user actions
Back press reloads the same page	Client-side redirect left in history	Use server-side 301 redirects instead of JavaScript hops
Problem appears only on mobile or only from Discover	Referrer- or device-specific ad logic	Test with the same user agent and referrer; raise it with the ad partner

Fixing what you find

Fixes are usually simple once you know the cause. Remove the feature, swap the vendor, or reconfigure it. If your developers need history updates for legitimate reasons, such as filters that change the URL, the rule of thumb is that only a deliberate user action should create a new history entry, and the first back press should always be honoured. For deeper JavaScript issues, our JavaScript SEO guide covers how Google renders and processes scripts.

Vendor management matters as much as code. Put a clause in ad and widget contracts that their code must not alter browser history or intercept navigation, and ask for notice before format changes. Re-run the audit after any new tag goes live, because a single tag manager change can reintroduce the problem.

Back button hijacking also tends to travel with other aggressive patterns. If you are cleaning up history manipulation, check for overlays that cover content on arrival too; our guide to fixing intrusive interstitials walks through that side.

If you were already hit

Start by checking the Manual actions report in Search Console. If there is a message, it is a manual action, and Search Engine Journal's report notes that sites can submit a reconsideration request after fixing the issue. Describe what you found, which scripts you removed and how you verified the fix. Our guide to Google manual actions covers how to write a clear request.

If there is no message but rankings fell after June 2026, you may be looking at an automated demotion, or at something unrelated, such as a core update or a spam update running at the same time. Read our breakdown of algorithmic demotion versus manual action and check the timeline of 2026 spam updates before drawing conclusions. There is no reconsideration form for algorithmic effects; you fix the issue and let systems reprocess your pages over time. Our general spam update recovery guide explains what to expect, without promises on timing.

Common mistakes

• Testing only on desktop while logged in. Many ad scripts behave differently for anonymous mobile visitors, which is exactly who arrives from Google.
• Ripping out all History API usage. Legitimate uses such as filters, tabs and galleries are fine; removing them can break your site's usability for no gain.
• Trusting a vendor's word without testing. Ask for written confirmation, but verify it yourself in the browser.
• Fixing one template and forgetting the rest. AMP pages, landing pages and old microsites often run different tags.
• Assuming every ranking drop since June 2026 is this policy. Check confirmed update dates and your own changes first.
• Filing a reconsideration request before the fix is live everywhere. Reviewers test the site; partial fixes waste time.

Related Guides

• Local Rankings Dropped After an Update? A Diagnosis Guide
• Diagnosing a Google Discover Traffic Drop After an Update
• Ranking Loss or AI Overview CTR Loss? Reading Stable Positions With Falling Clicks

Frequently Asked Questions

Is using history.pushState against Google's rules?

No. The policy targets the outcome, not the API. Using history updates for filters, tabs or galleries is normal; the problem is when a visitor presses back and cannot immediately return to the page they came from.

When did Google start enforcing the back button hijacking policy?

Google announced the policy in April 2026, and Search Engine Journal reported that enforcement would begin on 15 June 2026, giving sites two months to make changes.

My ad network caused it. Am I still responsible?

Google treats what happens on your site as your site's behaviour. Its announcement acknowledged that third-party libraries and ad platforms can be the source, which is why auditing and controlling vendor code matters.

How do I know if I have a manual action?

Check the Manual actions report in Search Console. If it is empty but rankings dropped, the cause is either algorithmic or unrelated to this policy, so compare your timeline against confirmed updates.

How long does recovery take after fixing it?

Google does not publish a timeline. Manual actions are reviewed after a reconsideration request; algorithmic effects depend on Google reprocessing your pages. Fix thoroughly and avoid guessing at dates.

Conclusion

Back button hijacking is one of the easier spam issues to fix, once you find it. Inventory your scripts, test real navigation from Google on real devices, block scripts until the behaviour stops, and put vendor rules in writing so it does not come back. If you would like a second pair of eyes on a suspected demotion, our penalty recovery service can audit your templates and third-party code, or you can request a quote for a full technical review.

References

1. Spam policies for Google web search — Google Search Central
2. Introducing a new spam policy for "back button hijacking" — Google Search Central Blog
3. New Google Spam Policy Targets Back Button Hijacking — Search Engine Journal
4. Debugging drops in Google Search traffic — Google Search Central
5. Google Algorithm Updates Timeline — Semrush Blog