Back button hijacking becomes a Google spam violation: how to audit your website before June 15

Starting on June 15, 2026, Google will treat back button hijacking as a violation of its spam policies.

Back button hijacking happens when a page prevents users from returning to the search results after they press Back. Instead of going back to Google, the visitor may be redirected to another page, trapped in a loop or forced to press Back several times.

Google says this behavior harms users and can result in manual actions, algorithmic demotions or removal from search results.

The deadline is close. If your website uses redirect scripts, aggressive pop-ups, ad networks or third-party libraries that have not been reviewed recently, audit them now.

What is back button hijacking?

Back button hijacking occurs when a website manipulates browser history so the Back button no longer does what the user expects.

A typical scenario looks like this:

a user searches on Google;
they open your page;
they decide the result is not useful and press Back;
a script sends them to another URL, reloads the page or keeps them on the site;
the user must close the tab or press Back repeatedly.

Using the History API is not automatically a problem. Many legitimate web applications use history.pushState() and history.replaceState() to provide navigation without fully reloading the page.

The violation occurs when an implementation intentionally interferes with backward navigation or prevents users from returning to the previous page.

What Google announced

Google announced the change on April 14, 2026, giving site owners 60 days to fix affected implementations. Enforcement begins on June 15, 2026.

According to the Google Search Central announcement:

back button hijacking is now explicitly covered by Google’s spam policies;
websites may be affected by manual actions or automated systems;
pages may rank lower or disappear completely from search results;
website owners remain responsible when a third-party library or advertising platform causes the behavior.

That last point matters. Not writing the script yourself does not remove the SEO risk.

Why this behavior is a real problem

A useful website helps people make a decision. It does not force them to stay.

Back button hijacking does the opposite:

it blocks a normal browser action;
it destroys trust in the website;
it can hide unwanted redirects or deceptive pages;
it is especially disruptive for mobile users;
it can be introduced by compromised scripts or aggressive ad networks;
it turns a UX problem into a direct organic visibility risk.

If the site already has technical issues, start with an SEO audit for a presentation website and include browser navigation testing in the review.

How to audit your website before June 15

The audit should combine manual testing, code inspection and a review of third-party scripts. A conventional SEO crawler may miss the issue because the behavior occurs in the browser after user interaction.

1. Manually test important pages

Open an incognito window and search Google for your brand, services or important website pages.

For each result:

open the page from Google;
wait a few seconds;
scroll and interact with the main elements;
close any pop-ups;
press Back once.

You should return directly to Google’s results. Repeat the test on desktop and mobile in multiple browsers.

Do not test only the homepage. Check:

service pages;
landing pages used in advertising;
blog posts;
pages that display pop-ups;
pages with different scripts, widgets or ads;
pages receiving the most organic traffic.

2. Inspect browser history

Open the console in Chrome DevTools and run:

history.length

Note the value when you enter the page, then run the command again after a few seconds and after interactions. An unexpected increase without genuine navigation may indicate that a script is adding artificial history entries.

This alone does not prove a violation. It is a signal that should be investigated.

3. Find code that modifies browser history

Search your code and the JavaScript files loaded by the page for:

history.pushState
history.replaceState
window.onpopstate
addEventListener("popstate"
location.replace
location.href

These functions have legitimate uses. The important question is what happens when the user presses Back:

is a new history entry immediately added?
is the user sent to a promotional page?
does the page reload and keep the user on the same URL?
does navigation enter a loop?
is the behavior different when the page is opened from Google?

Do not automatically remove every use of the History API. Fix the logic that interferes with normal navigation.

4. Audit third-party scripts

Google explicitly warns that third-party libraries and advertising platforms can cause the problem.

Create an inventory of:

Google Tag Manager tags;
chat widgets;
pop-up and exit-intent tools;
affiliate scripts;
ad networks;
lesser-known analytics tools;
CMS plugins and themes;
scripts loaded from external domains.

The Network panel in DevTools helps identify loaded domains and files. Temporarily disable suspicious scripts in a test environment and repeat the audit.

If the problem disappears after disabling a provider, remove the integration or request a fixed version before enabling it again.

5. Test conditions that may hide the behavior

Some implementations do not appear during every visit. They may depend on:

device or browser;
traffic source;
country;
first visit;
cookie consent;
a specific delay;
an advertising campaign;
an A/B test.

Test with and without cookie consent, on mobile and desktop, while signed in and signed out, and from multiple traffic sources.

6. Check Google Search Console

After June 15, monitor the Manual actions section in Google Search Console and watch for unusual organic traffic changes.

The absence of a manual action does not guarantee that everything is fine. Google may also use automated systems, and these do not necessarily generate an individual notification.

Compare:

clicks and impressions before and after June 15;
pages with the largest declines;
affected queries;
devices and countries;
recent code, tag and plugin changes.

Our guide on what to do after a Google core update explains how to distinguish a normal fluctuation from a problem that requires intervention.

Quick checklist for website owners

Before June 15, confirm that:

one press of Back returns to the previous page;
navigation works correctly on mobile and desktop;
no redirect occurs when users press Back;
pop-ups and exit-intent messages do not block navigation;
third-party scripts and tags have been inventoried;
plugins and libraries are up to date;
the History API is used only for legitimate navigation;
changes are tested in a staging environment;
Search Console is monitored;
someone is responsible for remediation.

What to do if you find the issue

First, stop the script or integration that causes the behavior. Do not try to hide it only from Googlebot or create user-agent exceptions. That can introduce further risks and does not repair the user experience.

Then:

identify the exact source;
remove or correct the history manipulation logic;
test every navigation path;
deploy the fix;
monitor Search Console and analytics data.

If you have already received a manual action, fix the problem across the entire website and submit a reconsideration request through Search Console.

Conclusion

This policy change does not ban modern web applications or legitimate use of the History API. Google is targeting deceptive behavior that prevents users from leaving.

Before June 15, 2026, focus on pages with third-party scripts, advertising, pop-ups and custom navigation logic. A few minutes of manual testing can reveal an issue that might otherwise damage user trust and Google visibility.

For a broader technical review, see our SEO and online presence service. We can review the implementation, third-party scripts, indexing and technical risks, then prioritize the fixes. For issues that require website changes, see our web development service or send us your project details.