Google has added a new practice to its spam policies: back button hijacking, where a site stops visitors from using the back button to return to the page they came from. The change sits under the existing malicious practices policy and was logged in Google’s documentation on 13 April 2026. If your Arabic site uses aggressive ad, popup or “recommended articles” scripts, this is a good week to test them.
What happened
On 13 April 2026, Google’s Search Central documentation changelog recorded a new entry: “Added a new section to the malicious practices spam policy to address back button hijacking”. Google also announced the change this month on the Search Central blog, in a post titled “Introducing a new spam policy for ‘back button hijacking'”.
Most readers have met the behavior even if they never had a name for it. You arrive on a page from Google, decide it is not what you wanted, press back, and land on another page of the same site, or on a full-screen ad, or on the same page again. On phones, where the back gesture is the main way out of a page, it is especially irritating.
What Google said
The new section in the spam policies defines the practice this way:
“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.”
Two phrases in that definition carry the weight. “Manipulating the browser history or other functionalities” covers the techniques, not just one script. “Immediately get back to the page they came from” describes the user expectation Google is protecting: one press of back should return you to where you were, often the Google results page.
The spam policies page also explains how Google handles violations in general. Google says it detects policy-violating practices “both through automated systems and, as needed, human review that can result in a manual action,” and that “sites that violate our policies may rank lower in results or not appear in results at all.”
What caught my attention is the placement. Google did not create a standalone policy; it added a section to malicious practices. My reading is that Google treats this less as annoying design and more as a question of the user’s control over their own browser.
By the numbers
| Item | Detail | Source |
|---|---|---|
| Date logged in documentation | 13 April 2026 | Search Central documentation updates |
| Policy it belongs to | Malicious practices spam policy | Search Central documentation updates |
| Blog announcement | “Introducing a new spam policy for ‘back button hijacking'” | Search Central blog, April 2026 |
| How violations are detected | Automated systems and, as needed, human review | Google spam policies |
| Possible outcome of human review | A manual action | Google spam policies |
| Possible effect on a violating site | May rank lower or not appear in results | Google spam policies |
What site owners should do
My view: very few site owners write back button tricks themselves on purpose. The risk usually comes from something installed and forgotten. Here is a practical audit.
- Test the back button yourself. Search Google for one of your pages on a phone and on a desktop, open it, then press back once. You should land on the results page. Repeat on your homepage, a popular article and a category page.
- Test from an internal link too. Open an article from your homepage, then press back. You should return to the homepage in one step.
- List every third-party script. Ad networks, popup and exit-intent tools, push notification prompts, “you may also like” widgets and some analytics add-ons run code on your pages. Check each one for features that add entries to the browser history or intercept the back action, and switch those features off.
- Check your own code. If your developers use browser history functions, for example in a single-page app or an infinite scroll, make sure they reflect real navigation by the user and never trap the user on the site.
- Review monetization settings. Some ad or content partners offer “engagement” or “retention” options. Read what they do before you enable them, and ask the provider directly if the description is vague.
- Document what you changed. Keep a short note of scripts you removed or reconfigured and the date. If you ever need to explain your site’s history to Google, you will have it.
For bilingual sites, run the tests on both the Arabic and English sections. Different templates often load different scripts, and the Arabic side of a site sometimes runs an older theme with plugins nobody has reviewed in years.
What to watch
The policy text is now public, and the safest assumption is to fix problems now rather than wait. For Google’s own details on how and when the policy is applied, read the Search Central blog post and the spam policies page directly, and check them again for any added examples.
Also keep an eye on the documentation changelog. It is where this change first appeared, and any clarification to the new section is likely to be recorded there too.
For readers, the change is simple good news: a press of back should take you back. For site owners, it is a reminder to know exactly what every script on your pages is doing.
Sources
- Google Search Central blog, “Introducing a new spam policy for ‘back button hijacking'”, April 2026, https://developers.google.com/search/blog/2026/04/back-button-hijacking
- Google Search Central, spam policies for Google web search, section on malicious practices, consulted 14 April 2026, https://developers.google.com/search/docs/essentials/spam-policies
- Google Search Central, documentation updates changelog (entry dated 13 April 2026), consulted 14 April 2026, https://developers.google.com/search/updates