You've felt it. You click through from a Google search, read for a moment, then hit the back button to return to the results. The page reloads. Or it sends you somewhere else. Or it pops an ad. You hit back again. Same thing. Eventually you give up and close the tab.
Most people don't know there's a name for it. It's called back button hijacking, and it has been one of the web's most common deceptive tricks for at least thirteen years, since Google first warned against it in 2013. Sites do it because every extra moment a user is stuck on the page is more ad revenue. The cost to the user is somebody else's problem.
As of April 2026, that calculation changed.
What Google did
Google has classified back button hijacking as a violation of its "malicious practices" spam policy. That is the same category Google uses for malware and unwanted software downloads.
Google says the behavior happens when a site interferes with browser navigation and stops a user from using the back button to return to the previous page. The result, per Google: users get sent to pages they never visited, served unsolicited recommendations or ads, or simply prevented from browsing the web normally.
The category placement is the news. This isn't filed as a quality issue or a UX guideline. It sits with malware. Google defines malicious practices as behaviors that create a gap between what a user expects and what actually happens, in ways that are deceptive or that compromise security or privacy.
What happens next
Google announced the policy in April with a two-month grace period. Enforcement begins June 15, 2026. After that, sites engaged in back button hijacking can face manual spam actions or automated ranking demotions in Google Search.
A few things to know if you run a site:
- Third-party code is your problem. Google called out that many instances of back button hijacking originate from included libraries or advertising platforms. Responsibility to audit and remove that code sits with the site owner. If your ad network or recommendation widget is doing this, your domain takes the hit.
- It applies to existing scripts. Nothing is grandfathered. If the code is on your site on June 15, you are exposed.
- Reconsideration requests are available for sites that get hit with a manual action, but only after the offending code is gone.
Ad-tech vendors and content recommendation platforms that lean on history manipulation are about to lose a tactic. Publishers who integrated those vendors without auditing them will pay for it in search rankings.
How to check your URLs
The natural question after reading a policy like this is: how do I know whether my site, or a vendor on my site, is doing it?
That is what our URL Detonator is for. Detonator opens a URL in an isolated browser environment and records what happens: redirects, JavaScript execution, downloaded payloads, network calls.
It now tests for back button hijacking. When a URL is detonated, Detonator simulates browser navigation and back-button behavior, then flags the patterns Google has classified as malicious: history manipulation, navigation interception, redirect-on-back, and forced page replacement. The same URL produces the same result every time, and the report names the specific technique observed.
For SOC analysts triaging suspicious links, that is a new signal to act on. For site owners auditing their own properties before June 15, it is a way to find out what your site is doing before Google does.
Where this lands
For thirteen years, back button hijacking was one of those things the web lived with. Everyone hated it. Almost nobody could name it. The vendors doing it had no real downside. That ends in June.
Google has decided that breaking the back button belongs with malware. We agree, and we built the testing for it.
If you want to try URL Detonator, get in touch. We are still in early access and would rather work with practitioners who use the tool than collect newsletter signups.