Possible back-button hijacking (indicator)
back_button_hijack_suspectedShort answer
When Glimana opened this page in a real browser, the page — before any click or key press — added its own address to the browser history and registered a listener for the back button. That is the pattern of back-button hijacking: pressing Back keeps the visitor on the site or sends them elsewhere. Google’s spam policies list it under malicious practices.
Why it matters
Google defines back-button hijacking as a site interfering with user browser navigation, so that users cannot easily return to the previous page. It can lead to a manual action, and visitors who cannot leave a page tend not to come back. The script responsible is often not your own code: ad networks, “exit intent” pop-ups and push-notification widgets are common sources.
How Glimana detects it
This is an indicator, not proof of intent. Glimana renders a sample of your pages (the home page and the most-clicked pages) in Chromium and counts, before any user interaction, calls to history.pushState that add the page’s own URL again, and whether the page listens for popstate (the back button). The rule fires when both happen. Single-page apps that navigate to a different URL, and replaceState calls, are not counted.
How to fix it
- Find the affected pages in Glimana. Open Issues › Possible back-button hijacking (indicator). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Open the page in Chrome with DevTools, set a breakpoint on
history.pushState(Sources › Event listener breakpoints, or rundebug(history.pushState)in the console), reload, and see which script calls it. Remove or replace that script; if it comes from an ad or widget provider, turn off the “back button”, “exit” or “interstitial” feature in its settings.Deactivate plugins one at a time (push notifications, pop-ups, ad managers) and re-test. Also check the header and footer script fields of the theme or a “custom code” plugin for third-party snippets.
Check apps that add pop-ups, upsells or push notifications, and custom scripts in
theme.liquid. Remove the app or turn off its exit-intent feature.Search your bundle and any tag manager containers for
pushState. Only call it in response to a real navigation; never on load to duplicate the current entry. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Verification is manual: after removing the script, mark the task done. The render sample is refreshed weekly; the issue closes when the page no longer shows the pattern.
How the fix is verified
The weekly render sample re-checks the page; the issue closes when the pattern is gone.