A customer opens your service page from Google, decides it is not quite right and presses Back. Instead of returning to the results, they stay on your site, reach an unexpected offer or have to press again and again.
That deserves investigation. First establish whether the website is manipulating browser navigation, failing to restore the previous page or simply responding slowly. Those problems need different repairs.
For a UK business buying traffic or investing in SEO, the practical objective is straightforward: customers should be able to browse, compare and leave using the controls they expect. Keeping someone on a page by frustrating their attempt to leave is no substitute for a useful offer.
What counts as back button hijacking?
Google’s current spam policies explicitly list back button hijacking under malicious practices. It describes interference with browser navigation that prevents people using Back to return immediately to the page they came from.
Google’s April 2026 announcement set an enforcement date of 15 June 2026 and explained that affected pages may face manual spam actions or automated demotions. This is now an existing policy issue, rather than a future deadline to prepare for.
Warning signs include an unrequested sales page appearing when someone tries to leave, an advert replacing their previous destination, or repeated Back presses that keep returning them to the same landing page. Do not assume every navigation fault is deliberate hijacking, or that one observed fault proves Google has penalised your website.
Legitimate browser history is different
A booking tool or product catalogue may change what appears on screen without loading a completely new page. It still needs sensible Back and Forward behaviour.
As MDN’s History API guide explains, pushState() adds a browser history entry, while replaceState() updates the current entry. These methods support legitimate web applications. Finding them in your website’s code does not, by itself, establish a problem.
The question is whether the history reflects meaningful steps the visitor actually took. Returning from a product to the category they browsed is useful. Adding artificial steps solely to stop them leaving is a different behaviour.
Reproduce the exact customer journey
Start with a journey someone has reported, rather than randomly pressing buttons on the homepage. Write down the starting page, the link they followed, what they did after arrival and the destination they expected when they pressed Back.
For example, test a search result leading directly to a service page separately from a category-to-product journey. In the first case, Back should normally return to the search results. In the second, it should follow the real browsing history, which may include meaningful filter or navigation steps.
- Use the same tab. Opening a fresh tab and pasting the destination URL does not recreate the history of clicking a link from another page.
- Try leaving immediately, then after interaction. Repeat after scrolling, opening a gallery, using a filter or dismissing a promotional overlay.
- Test the browser’s own control. Compare its Back button with the phone’s back gesture and any Back link drawn inside the website.
- Compare environments. Check a normal browsing session and a clean private session, then another browser or device. Record the differences.
- Capture the failure. A short screen recording showing the starting page, interaction and unexpected destination is more useful than “the back button is broken”. Avoid recording customer information.
For paid landing pages, use a preview or an existing destination link where possible. There is no reason to repeatedly click your own live adverts just to create a navigation test.
Separate a history trap from a restoration fault
Use the observed behaviour to decide what your developer should investigate first.
- Back reveals a page the visitor never chose. Investigate unsolicited redirection, injected history entries and scripts that react when someone attempts to leave.
- The URL changes backwards but the visible content stays the same. Investigate whether the application restores the correct view when browser history changes.
- The correct category returns, but filters or position are lost. Treat this as a state-restoration problem. It can still make shopping frustrating, but it does not establish hijacking.
- The previous page eventually appears after a delay. Investigate loading and restoration performance before assuming an artificial navigation loop.
- Only the website’s own Back link fails. Compare that link’s intended destination and implementation with the browser control.
These are starting points for diagnosis, not automatic verdicts. More than one fault can exist in the same journey.
Check how the application handles a return
For a developer, MDN’s popstate documentation explains how applications can respond when the active history entry changes. Calling pushState() or replaceState() does not itself fire that event.
Ask the developer to trace the interaction that creates an entry and the code that restores its view. Does returning select the right product, category or booking step? Does a handler immediately send the visitor forward again? The repair should preserve real navigation while removing the unwanted behaviour.
A blanket instruction to delete every history handler risks breaking the application. Request evidence identifying the responsible handler or component instead.
Check cached-page restoration separately
Browsers can restore an entire page from memory using the back/forward cache, or bfcache. Google’s current bfcache guidance, updated in October 2026, explains that this differs from ordinary HTTP caching and can make return navigation almost instant.
The same guidance describes using the pageshow event and its persisted property to recognise a restored page. Where a returned page shows outdated basket or account information, ask the developer whether the relevant state is refreshed correctly after restoration.
Disabling caching across the website is not a diagnosis. Establish whether the wrong destination, missing application state or stale content is actually responsible before choosing a fix.
Trace third-party code as well as your theme
The fault may not come from code your business commissioned directly. Google’s announcement specifically warns that included libraries or advertising platforms can introduce back button hijacking.
Build a shortlist from recent changes: promotional overlays, advertising scripts, landing-page additions, theme updates, tag-manager changes and application-routing changes. Their presence is not proof; test the suspected component.
Ask your developer to compare a reproducible failing journey with a controlled version where one suspected component is disabled. Use staging where practical, while checking whether its different scripts or configuration affect the result. Record which change removes the fault and whether restoring that component brings it back.
If the evidence points to an external script, give its supplier the reproduction steps and request a supported correction. Removing a visible pop-up is insufficient if the script continues altering history in the background.
Agree a focused production change and a rollback route. Avoid switching off unrelated tracking, payment or booking components together: that makes the cause harder to identify and can interrupt working customer journeys.
Verify the repair from arrival to completion
Repeat the original failing journey on the live site after deployment. Then check adjacent routes rather than stopping after one successful Back press.
- Enter from an external page, interact with the landing page and return to the genuine previous destination.
- Browse from a category to a product, return and check the expected filters and position.
- Use Forward after going Back and confirm that the correct view appears.
- Check mobile gestures and desktop browser controls.
- Repeat with the consent choices and promotional interactions involved in the original failure.
- Complete a test enquiry or supported test booking to confirm the repair has not broken the main conversion journey.
Keep a before-and-after recording and a brief description of the component changed. Include the failure in future checks whenever that component is updated. A passing homepage test cannot establish that every landing page or embedded booking route works.
Check Search Console if you suspect a search impact
Open the Manual actions report for the correct website property. Google’s Manual actions guidance explains that reported actions come from human review and provides the reconsideration process.
If an action is present, follow its stated scope, fix all affected pages and submit a review request explaining the issue, repair and verification. Do not submit a request simply because rankings changed. An empty report does not certify the navigation as sound or rule out automated effects.
Judge the functional repair by repeatable customer journeys. Treat later search performance as a separate outcome: removing a navigation problem does not guarantee a particular ranking or an immediate traffic recovery.
Give customers control of their next step
A useful diagnosis should name the journey, show the failure, identify the responsible component and demonstrate the repaired behaviour. That gives your business something concrete to approve and maintain.
If customers cannot navigate away from your pages normally, BuzzBoost’s web development and integration work can help investigate the underlying journey. Tell us which page they enter and what happens when they press Back, and we can discuss the next practical step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
