Back Button Hijacking: Google's April 2026 Spam Rule That Targets Your Ad Scripts

What is back button hijacking according to Google?

Google defines it in its spam policies as a site interfering with the user's navigation by manipulating the browser history or other functionality, which prevents users from using the back button to immediately return to the page they came from^[2]. The practice falls under the malicious practices category.

In its April 13 post, Google describes the symptoms: users land on pages they never visited, are shown unsolicited recommendations or ads, or find themselves stuck in their navigation^[1]. The typical case: you arrive from Google, you hit back, and instead of getting your search results again, you end up on a page of articles “you might also like”.

What penalties apply since June 15, 2026?

Google published the rule two months before enforcing it, which is rare and left time to fix things. Since June 15, 2026, affected pages can be subject to manual spam actions or automated demotions^[1]. The two are not equally visible to you.

A manual action shows up in Search Console, in its dedicated report, and is lifted after you fix the issue and submit a reconsideration request^[1]. An automated demotion, on the other hand, comes with no notification at all: you simply see a drop in visibility, which you may wrongly blame on an algorithm update. That's the most dangerous scenario for a small business that doesn't keep an eye on its scripts.

Why could your site be affected without you knowing?

This is the most important sentence in Google's post: the hijacking may come from libraries included on the site or from its advertising platform^[1]. Google therefore asks site owners to review their implementation and to remove or disable the code, imports or settings responsible.

In the audits I carry out, the usual suspects are always the same: ad networks that add “recirculation” modules, sponsored content widgets, WordPress exit pop-up plugins, Shopify retention apps, badly configured A/B testing scripts. None of these tools is banned in itself. It's how they behave with the back button that causes the problem.

The trap is that this behavior often shows up only on mobile, or only for visitors coming from a search engine, or only every other time. A quick test from your desktop computer, landing directly on your site, won't reveal it.

Can spam reports trigger a manual action?

Yes, since April 2026. On April 14, Google updated its documentation to say that it “may now use spam report submissions to take manual action”, then clarified on April 23 when and why, in response to the reactions this caused^[3]. Previously, these reports were officially used to improve detection systems.

The reporting page adds an important detail: if a manual action is taken, the text of the report is shared with the site owner to help them understand the context^[4]. Google also rejects reports that contain personal data. In practice, a competitor or an annoyed visitor can now report your site, and that report can lead to a penalty if it describes a genuine violation.

My reading: this doesn't turn Search Console into a tool for competitors to snitch on each other, because Google verifies the violation before acting. But a practice that annoys visitors, such as back button hijacking, is exactly the kind of thing people report. The two April announcements go hand in hand.

What do I make of it?

I think this rule is a healthy one. Hijacking the back button artificially inflates metrics (page views, ad impressions) at the expense of the experience. A trapped visitor doesn't come back, and they remember the brand for the wrong reasons. For a small business website, the ad revenue gained is almost always negligible compared with the risk.

The real issue is script governance. Many of the sites I audit load ten, fifteen, twenty third-party scripts, and nobody remembers who added them. This rule is a good opportunity to take stock. A lightweight, server-rendered site with few dependencies, like the ones built on Éclair CMS, mechanically reduces this risk. The June spam update, which I cover in my June 2026 technical checklist, showed that Google isn't letting up^[5].

What should you do in practice?

• Test under real conditions: a Google search on a smartphone, a click on your result, the back button. Repeat on an article page, a product page and the home page.
• Ask your ad network, in writing, whether its scripts modify the browser history, and disable recirculation modules if in doubt.
• On WordPress or Shopify, review the exit pop-up and retention plugins or apps added over the past few years.
• Check the Manual actions report in Search Console and, if you've been penalized, fix the issue and then submit a reconsideration request.

A crawler alone can't detect this problem, because it depends on real behavior in a browser. However, our Arachnide crawler helps you inventory the scripts loaded on every page, which is the first step.

Sources

1. Google Search Central Blog, new spam policy on back button hijacking (April 13, 2026)
2. Google Search Central, spam policies for Google web search (malicious practices)
3. Google Search Central, documentation updates log (entries for April 14 and 23, 2026)
4. Google Search Central, report a quality or spam issue
5. Google Search Status Dashboard, June 2026 spam update