A new spam policy for “back button hijacking”
Google’s new spam policy targeting “back button hijacking” — where sites manipulate browser history so users can’t easily return to previous pages — is widely welcomed as overdue, but many argue it should have been solved at the browser or standards level instead of via search-ranking penalties. Commenters debate the legitimate use of the History API in single-page applications versus its abuse in dark patterns, and connect the issue to broader frustrations with JavaScript-heavy sites, intrusive overlays, hijacked keyboard shortcuts, and the general “enshittification” of the web. Some also question Google’s motives and consistency, pointing out that its own products and ad ecosystem often degrade user experience in similar ways.
Overall reaction to Google’s new policy
- Many welcome the change and say it’s long overdue; back-button traps are described as one of the most hated modern web dark patterns.
- Others are skeptical it will be effective, seeing SEO rules as yet another cat-and-mouse game spammers will route around.
- Some point out the irony that Google’s own products (YouTube, AMP, News, “open in app” prompts) already degrade navigation and UX.
Browser-level fix vs. search-policy fix
- A recurring view: browsers should have been designed so back-button hijacking is impossible, or fixed directly now (e.g., special handling of history, permissions, or “previous origin” navigation).
- A counterargument (including from someone citing Chrome’s prior attempts): technical heuristics are fragile in an adversarial setting; a policy hammer via search ranking is more realistic.
- Suggestions include: history APIs as explicit permissions, distinguishing “web app” APIs, detecting frantic back-press patterns, or building immutable/tree-like history.
Legitimate vs abusive uses of the History API
- Defenders cite valid uses:
- SPAs like mail, chat, or video sites maintaining in-app navigation without full reloads.
- E‑commerce variants, filters, and galleries that make specific states bookmarkable and shareable.
- Modals, image viewers, map position, game state, multi-step forms.
- Critics argue SPAs often abuse history, break true “back” semantics, and add complexity and bugs; many say SPAs should have their own in-app back buttons instead.
- Concern: how will Google distinguish legitimate SPA navigation from deceptive history stuffing or redirect loops? Fear of false positives, especially for common routers and libraries.
Wider “web encrapification” complaints
- Thread broadens into frustration with:
- Overlays, cookie banners, surveys, “are you sure you want to leave?” prompts.
- Scroll hijacking, Ctrl‑F / keyboard shortcut hijacking, right-click blocking.
- Paywalls showing up in search and 3rd‑party ad scripts manipulating UX.
- Many argue that JavaScript-heavy, ad-driven designs and tracking incentives are the root problem; some pine for a simpler, document-centric web.
Workarounds and user tools
- Users share coping strategies: opening everything in new tabs, long-press/right-click back history, ad blockers and “annoyance” filters, reader mode, or disabling JS per site.
- Some note Firefox- or userscript-based tweaks to limit pushState or prevent shortcut takeover, but these are seen as expert-only workarounds rather than real fixes.