Bounce rate
The share of sessions that failed an engagement test — a definition that changed materially between Universal Analytics and GA4, and that measures less every year as answers move off your page.
Karl-Gustav Kallasmaa, Founder & CEOLast updated Bounce rate is the share of sessions that failed an engagement test defined by your analytics tool. Which test, and therefore what the number means, depends entirely on which tool and which version produced it.
The two definitions, and why they do not compare
Universal Analytics measured "the percentage of single page sessions in which there was no interaction with the page". One page view, no tracked event, session over. Time spent was irrelevant, because with nothing after the first hit there was no second timestamp to subtract from.
Google Analytics 4 measures "the percentage of sessions that were not engaged sessions", and defines an engaged session as one that meets any of three conditions: it lasts longer than 10 seconds, it has a key event, or it has 2 or more screen or page views.
The consequence is a single-page visit lasting fifteen seconds with no clicks: a bounce in Universal Analytics, engaged in GA4. Google says as much in its migration guidance, noting that bounce rate as calculated in Universal Analytics "has become less useful as websites and apps have changed". A reported drop across the migration is a definition change, not an improvement, and any target carried across from the old tool is meaningless.
Note also that GA4's bounce rate is defined as the exact inverse of its engagement rate. Reporting both is reporting one number twice.
What it is a proxy for, and what it is not
Bounce rate has always been a proxy for "did this visit go anywhere". It was never a satisfaction measure, and it is a bad one on two page types in particular.
- A reference page that answers the question. The reader arrives, gets the fact, leaves satisfied. That is the page working.
- A page whose next step is off-site. A documentation page that sends the reader to a repository, or a comparison that sends them to a vendor, cannot record the outcome it caused.
It is also not a ranking signal you transmit. The number is computed inside your own analytics property from your own tag. Search engines and AI assistants do not receive it. Where dwell-time-shaped signals exist at all, they are inferred from behaviour in the results interface, not read out of your GA4 property — so "improve bounce rate to rank better" is optimising a number nobody else can see.
Why the metric is quietly degrading
Two things have changed what a session even is.
The answer increasingly arrives before the click. When a result page or an assistant states the fact, the visitor who wanted only the fact never becomes a session at all. Your remaining visitors are pre-filtered for depth of intent. Bounce rate can therefore improve while total demand captured falls — the metric moves in the opposite direction to the business. Zero-click search and AI Overviews are the mechanisms.
Consent and blocking remove sessions unevenly. Sessions that are never measured are not distributed randomly across pages or regions, so the denominator itself is biased in ways the metric cannot show.
Failure modes
- Comparing across the definition change. A GA4 figure against a Universal Analytics target is two different questions with one label.
- Comparing across page types. A glossary entry and a pricing page have no shared expectation; a site-wide average of the two describes neither.
- Firing an event to fix it. A scroll or timer event added on every page converts every session into an engaged one. The number improves and nothing else does.
- Reading it as satisfaction. A short visit that answered the question and a short visit that failed to load look identical here. Diagnose that with page performance instead — see Core Web Vitals.
- Ignoring the crawl side. Some of what analytics records as odd sessions is automated traffic your filters missed; how agents fetch pages is covered under crawling and indexing.
How to use it honestly
- Segment before averaging. By page template, by source, by device. The site-wide number is the least informative version of this metric that exists.
- Pair it with an outcome. Bounce rate alongside a defined key event for that page type turns a proxy into a diagnosis.
- State which definition you are using whenever the number appears in a report, because a reader who assumes the other one will be wrong by a wide margin.
- Set expectations per template. A reference page is supposed to end the visit. A checkout step is not.
- Watch the direction of travel, not the level. Level comparisons across tools, time zones and consent regimes are noise; a sustained change within one segment and one definition is a signal.
Frequently asked questions
What does GA4 count as a bounce?
Any session that is not engaged: under 10 seconds, no key event, and a single page view.
Why did the number change after migrating?
The definition changed. Universal Analytics ignored duration; GA4 does not.
Is a high bounce rate a problem?
Only relative to what the page was for. Reference pages are expected to end visits.
Do search engines or assistants see it?
No. It is computed in your analytics property from your own tag.
Terms related to Bounce rate
A search that ends without the reader visiting any website, and the measured gap between sessions that show an AI summary and those that do not.
Google's three published field metrics for loading, responsiveness and visual stability, with the exact thresholds and the percentile they are judged at.
The two separate stages that decide whether a page can be retrieved at all, and the reason a serving rule on a blocked page is never read.
Google's AI-generated summary at the top of a results page, and the snippet controls that decide whether your page can appear inside one.