How to Audit a SaaS Site for Back Button Hijacking After Google's Spam Policy
Google has enforced its back button hijacking policy since June 15, 2026. Most of the risk on B2B SaaS sites sits in third-party scripts, not in your own code.
- Desk
- Technical SEO
- Format
- How-to
- Reading time
- 7 min
- Published
- Oct 21, 2026
Back button hijacking means a site interferes with browser navigation so a visitor cannot return to the previous page. Google made it a spam policy violation in April 2026 and began enforcing it on June 15, 2026. On B2B SaaS sites, the usual culprits are third-party scripts, so an audit should start with your tag manager and widgets.
This guide is for SaaS marketers and engineers who own a marketing site, docs or a web app. It covers what the policy says, where the problem usually hides and a step-by-step audit with fixes. Cekpr covers technical SEO for B2B software, and this is one of the few spam rules that a single injected script can trigger without anyone on the team noticing.
What Does Google's Back Button Hijacking Policy Say?
Google's Search Central blog introduced a new spam policy for back button hijacking in April 2026. It treats the behavior as part of the malicious practices category in Google's spam policies. Search Engine Journal's coverage says the policy was announced on April 13, with enforcement beginning June 15.
The behavior includes sending users to pages they never visited, showing unsolicited ads or recommendations and blocking back navigation. Google said users report feeling manipulated and become less willing to visit unfamiliar sites. It also said some cases may come from a site's included libraries or advertising platform.
Violating sites risk manual spam actions or automated demotions. Both can lower visibility in Search. The policy has been in force for four months, so any site still doing this is already exposed.
Why Is This a Risk for B2B SaaS Sites?
SaaS sites run more scripts than most. A typical marketing site loads an analytics tag, a chat widget, a demo scheduler, an exit-intent popup, a heatmap tool, retargeting pixels and a consent banner. Each can touch the browser history.
Single-page apps add another layer. Frameworks use the history API to change URLs without a reload, which is legitimate. The problem starts when code adds extra history entries, so the back button lands on the same page again, or redirects users somewhere new.
Warning notices went out before the deadline. According to PPC Land's report, Google began sending Search Console messages on April 27, 2026. Each said no manual action had been taken yet and listed sample URLs. The same report points to tag manager injection as a main vector.
How Do You Audit Your Site Step by Step?
Treat this as a repeatable check, not a one-time fire drill. Run the steps below on a representative sample of page types:
- List your page templates: home, pricing, product pages, blog posts, docs, landing pages and signup flows.
- Open each template in a clean browser session, click through from a search result and press back once.
- Note any case where back does nothing, loops to the same page or lands on a page you never visited.
- Search your code and tag containers for history.pushState, history.replaceState and popstate listeners.
- Disable third-party scripts one by one, then retest to find the source.
- Fix or remove the cause, and retest across templates, devices and consent states.
Test from a search result, not from a typed URL. Many scripts act only when a visit arrives from an external referrer, such as Google, because that is when an exit offer makes sense to the vendor.
Where Does the Code Usually Hide?
The table below lists the common sources and what to check in each. Start with the ones you did not write yourself.
| Source | What to check | Typical fix |
|---|---|---|
| Tag manager container | Custom HTML tags, old triggers, vendor templates | Remove unused tags, restrict publish access |
| Chat or popup widget | Exit-intent and navigation hooks | Turn off redirect or history features |
| Ad or recommendation widget | Added history entries on load | Remove or replace the vendor |
| Own SPA router | Duplicate pushState calls | Use replaceState or fix the routing logic |
| A/B testing tool | Redirect tests that alter history | Use server-side or client-side swaps without redirects |
The Mozilla Developer Network documents the History API if your engineers need a reference for how pushState and replaceState behave. Legitimate routing adds one entry per real navigation. Anything beyond that deserves a second look.
How Do You Audit the Tag Manager Specifically?
Tag managers deserve their own pass, because marketers can publish tags without an engineering review. Export the container and read every custom HTML tag. Look for scripts from vendors you no longer use.
Check who can publish. If five people have publish rights, five people can ship a policy violation. Limit it to a few named owners and require review for custom code.
Add a standing rule: any new vendor script gets a back-button test before it goes live. It takes two minutes and prevents a manual action. Our backlink audit for the September 2026 spam update follows the same idea of checking what others added to your site's footprint.
How Do Single-Page Apps Avoid False Positives?
Most single-page apps behave well. The router adds a history entry when the user moves to a new view, and the back button returns to the previous view. That is normal and expected.
Trouble starts with patterns like these. A redirect inserts an extra entry, so pressing back immediately forwards the user again. A modal adds history entries that never get cleaned up. A guard on the back event prompts users to stay on the page, or sends them to an offer.
Use replaceState when a redirect should not leave a trail, and make sure route guards never block navigation to the previous page. Test deep links from search results, since those arrive with no prior in-app history. A user who lands on a docs page from Google should go back to Google with one press.
Be careful with authentication flows. Login redirects often bounce through several URLs. If back leads to a redirect that forwards the user back to the same page, it feels like a trap even if nobody intended one.
What Does Enforcement Mean for Search Performance?
Google has not published a count of affected sites, and neither the policy nor its coverage says how many have been demoted. The practical risk is a manual action that lowers visibility, or an automated demotion that appears as a gradual traffic loss. Manual actions show up in the Manual actions report in Search Console.
A manual action can also reach beyond organic search. PPC Land notes that a manual action may affect Google Ads eligibility under a framework introduced in December 2024. For a SaaS company that buys search ads, that doubles the stakes.
Keep your expectations measured. A clean site has nothing to fear from this policy, and most fixes are small. The audit costs a few hours, and the downside of skipping it is a loss of the traffic that feeds your pipeline. Cekpr editors treat it as basic hygiene, the same as a broken link check.
What If You Get a Warning or a Manual Action?
Read the message closely. It lists sample URLs, which are representative, not complete. Fix the pattern across the site, not just the listed pages.
Remove the code that manipulates history, whatever its source. Verify the fix on each template. If you got a manual action, submit a reconsideration request in Search Console describing what you found and what you changed. If it was an automated demotion, there is no request to file, so fix the issue and monitor performance.
Recovery is not instant. Our guide to measuring AI search visibility in Search Console shows how to track impressions and clicks week by week, which helps you tell whether a fix is working.
How Do You Keep It From Coming Back?
Add a back-button check to your release checklist. Run it after each major deploy, after adding a vendor and after any change to the tag manager. Automated tests can click through key templates and confirm the previous page loads.
Document the owner of each third-party script, why it exists and when it was last reviewed. Remove scripts nobody can explain. Fewer scripts means fewer risks and faster pages, which helps in other ways.
Also keep an eye on how your site behaves with different consent settings. Some scripts load only after a user accepts cookies, so test with consent granted and denied.
Conclusion
Back button hijacking is now an explicit spam violation with active enforcement. For a B2B SaaS site, the risk sits mostly in scripts you did not write. Test the back button on every template, audit your tag manager and widgets, and add a check to your release process. Then confirm your content story holds up, as we covered in our look at what schema markup does and does not do for AI citations.
What is back button hijacking?
When did Google start enforcing the back button hijacking policy?
Can third-party scripts cause back button hijacking?
How do I fix a back button hijacking manual action?
Up next · Content Strategy Where AI Answers Get Their Sources for B2B Software, and Why Only 10% Point to Your Site join the club.
The week's best SEO and AI search posts, plus one thing to check in your own Search Console, every Thursday morning. Unsubscribe whenever.