A monthly report lands with bounce rate in the third column. It reads 64%. Somebody asks whether that is good. Nobody in the room can answer, because the number has meant three different things over the last few years and the report does not say which one it is using.
That is the actual problem with bounce rate. Not that it is a bad metric — that it is an ambiguous one, and an ambiguous number on a dashboard costs more attention than it returns.
What does bounce rate measure now?
In Google Analytics 4 it is the exact inverse of engagement rate: the percentage of sessions that were not engaged. A 64% bounce rate means 36% of sessions met the engagement definition, and nothing more than that.
A session counts as engaged if it lasted longer than ten seconds, fired a conversion event, or included at least two pageviews. So a visitor who reads one page for fifteen seconds and leaves is engaged. The same visitor leaving after eight seconds is not. The threshold is configurable, which means two properties can report different bounce rates for identical behavior.
Why did the old definition mislead so often?
Because it ignored time entirely. Universal Analytics called a session a bounce when it produced a single interaction hit — one page, nothing else. Duration did not enter into it, since with no second hit there was nothing to measure the first one against.
That put two opposite outcomes in the same bucket. A reader who spent six minutes on a guide, got the answer, and closed the tab was a bounce. So was somebody who hit the page, saw the wrong thing, and pressed back within a second. One of those is a success and one is a failure, and the metric scored them identically.
Bounce rate has never measured satisfaction. It measures whether a session cleared a technical threshold, and the threshold has changed. Any trend line that crosses a platform migration is comparing two different metrics drawn as one.
When is a high bounce rate genuinely fine?
Whenever the page is designed to answer the question and stop. Plenty of pages do their whole job in one visit, and a second pageview would mean the first one failed.
| Page type | Expect high bounce? | What it means |
|---|---|---|
| Opening hours, address, phone | Yes | Visitor got what they came for |
| Glossary or definition page | Yes | Question answered in one screen |
| Blog post answering one query | Often | Depends on whether a next step exists |
| Service or pricing page | No | Visitor should be moving toward contact |
| Category or listing page | No | Its job is to send visitors deeper |
| Checkout or form step | No | A bounce here is lost revenue |
Read down that table and the pattern is that bounce rate is only interpretable against the page's intended next action. A page with no intended next action cannot fail at producing one.
When is it a real warning?
When it moves on a page whose job is to move people onward, and the movement is not explained by a traffic mix change. That is a narrow but genuinely useful signal.
The sequence worth running is short. Isolate organic search sessions for the page, compare the period to the one before it, and check whether the queries bringing people there changed. A service page whose engagement fell while its query set stayed constant has a page problem. One whose query set widened has a mix problem, and the same dilution arithmetic applies as with conversion rate: newer, broader queries bring visitors who are further from a decision.
Does Google use bounce rate as a ranking factor?
No. Google has said repeatedly that it does not use Google Analytics data in ranking, and the mechanical reason is simpler than the debate around it: your Analytics property is your data, not Google's search index.
What Google does have is its own click behavior on its own results pages, which is a different dataset with different boundaries. Confusing the two leads teams to optimize a number in their own dashboard in the belief that it feeds a ranking system that never sees it.
Chasing the bounce rate down by adding interstitials, auto-playing video, or forced pagination. Every one of those creates the extra interaction the metric counts. The number improves, the experience degrades, and nothing about the business changes.
What should sit on the report instead?
Metrics tied to an action the page was built to produce. For most sites that is a short list, and it survives the next analytics platform change because it is defined by the business rather than by the tool.
- Conversions per page, counted rather than rated, so small samples cannot masquerade as trends.
- Next-page rate for pages whose job is routing — category pages, hubs, service overviews.
- Scroll or interaction depth for long-form pages, which tells you whether the page was read or abandoned in the first screen.
- Click-through rate from search, which measures the promise the title and description made, separately from what the page did after the click.
Bounce rate can stay as a diagnostic that one analyst checks while investigating something specific. What it should not be is a headline number that a client reads without context, because the first question it prompts is one nobody can answer in a meeting.
How do you retire a metric a client has watched for years?
By replacing it in the same slot rather than deleting it. A column that disappears looks like something being hidden, and the conversation you get is worse than the one you were trying to avoid.
Put the replacement metric where bounce rate sat, add one line stating what it counts, and keep both columns for a single reporting cycle so the client can see how they relate. After that, drop the old one. The point of a report is to prompt a decision, and a number that produces the same unanswerable question every month is doing the opposite.
Open last month's report and check every metric on it against one test: if this number moved five points, what would we do? Anything that has no answer is taking up a row that a metric with an answer could use.
Reporting numbers nobody can act on?
We will rebuild your organic reporting around metrics that answer a question, and retire the ones that only start arguments.
Get in Touch →Does this apply to your site?
Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.
Free and unlimited. No account, no card, and you get every finding rather than a teaser.