Google warns sites before back button hijacking penalty

What happened

Google has started sending email warnings through Search Console to sites that hijack the browser’s back button. The notifications include sample URLs, links to the spam policy, and a reminder that enforcement begins June 15, 2026. SE Roundtable reported on the warnings on April 28.

Glenn Gabe shared a screenshot of the email on X. He noted that Google is sending these to “sites that are actively hijacking the back button” and that the emails include sample URLs along with links to the blog post about the new spam policy.

The email’s subject line reads: “Warning: Your site may be in violation of Google’s Back Button Hijacking policy.” It tells site owners that Google has detected pages exhibiting back button hijacking behavior, which violates a newly launched spam policy on malicious practices. No manual action has been taken yet, but the email urges sites to fix the issue before the June 15 enforcement date.

One important detail from the email: changes made on or after April 17, 2026 are not reflected in the notification. Google says it will re-verify compliance before taking any manual action.

Why it matters

Back button hijacking is a pattern where a site interferes with browser navigation, preventing users from returning to the page they came from. Google’s definition covers scenarios where users get sent to pages they never visited, are shown unsolicited ads, or are otherwise blocked from normal browsing.

The technique typically abuses the browser’s History API. Sites can call history.pushState() to inject fake entries into the session history stack. When a user hits the back button, the browser traverses to one of these injected entries instead of returning to the previous page. Some implementations use popstate event listeners to intercept back-button presses and redirect users elsewhere.

The WHATWG HTML spec defines how session history entries and traversal work. The spec was designed to let single-page applications manage navigation state. Back button hijacking exploits that flexibility for deceptive purposes.

SE Roundtable’s Barry Schwartz noted that “a number of SEOs are posting screenshots of clients or former clients that received this notification.” The volume of warnings suggests Google is casting a wide net before enforcement begins.

Sites that rely on aggressive interstitials, ad-driven redirects, or certain pop-up implementations should pay close attention. Some implementations may hijack the back button unintentionally, particularly those using pushState for modal windows or overlay ad units.

What to do

Check your Search Console email for the warning. If you received one, Google has already flagged specific URLs. Start with those.

Search your codebase and third-party scripts for these patterns:

• history.pushState() calls that fire on page load without corresponding user-initiated navigation. These inject fake history entries that trap users.
• popstate event listeners that redirect users or load new content instead of allowing normal back-button behavior.
• beforeunload or unload handlers combined with history manipulation. Some implementations use these to intercept navigation attempts.
• Third-party ad scripts or analytics tags that modify the history stack. Audit tag manager containers for scripts you didn’t write.

Test affected pages manually. Navigate to the page from a search result, then press the back button. If you don’t return to the search results page immediately, something is hijacking the back button.

If you use pushState legitimately for single-page app routing, confirm that each pushed state corresponds to real content the user intentionally navigated to. The violation targets deceptive history manipulation, not standard SPA behavior.

Fix issues before June 15, 2026. Google’s email confirms it will re-verify before taking action, so you have time. But the April 17 cutoff for detection means recent fixes won’t appear in the current warning.

Watch out for

Third-party scripts you forgot about. Ad networks, affiliate tools, and pop-up plugins are common sources of back button hijacking. The code may not be in your repository at all. Audit every external script loaded on flagged URLs.

SPAs with aggressive preloading. Some single-page application frameworks push history entries for prefetched routes. If a user hasn’t actually navigated to a route, that pushed state can look like hijacking to Google’s detection system. Review your router configuration.