Bounce Rate Improved Because the Visitors Were Bots
Bounce rate improved while engagement time collapsed. Two dated traffic floods, the checks that told bots from people, and the tell.
By David Jubé · Aug 25, 2026 · 9 min read
I advise a small ecommerce property on organic search. In August 2026 its analytics started printing the best engagement numbers I had ever seen on it, and the note I filed that month told the owner to disregard every one of them.
The same shape had already run through a property I own, five months earlier.
Both times, the metric that is supposed to flag a problem reported an improvement instead. This note is the pattern behind that, and the checks that catch it.
Key takeaways
- Bounce rate and engagement rate are session-duration proxies. A script that clears GA4’s engagement threshold and stops there reports as an improvement.
- Dimensional collapse is the fingerprint. One country, one browser, one OS, one device, one channel, all in the same window.
- Organic search is the control. If it stays flat while direct explodes, the anomaly is not a growth event.
- Both floods here are dated, measured in GA4, and compared against baseline windows of equal length.
- Edge filtering and reporting filtering are different decisions with different failure modes.
Two Floods, Five Months Apart, With One Fingerprint
Every figure in both tables is GA4 session data for the property named, measured, not modeled. Each surge window is compared against a baseline window of equal length ending the day before it started: 23 days against 23 days for the client property (Jul. 12 to Aug. 3, 2026 as baseline, Aug. 4 to Aug. 26, 2026 as surge), and 3 days against 3 days for The Gourmet Host (Nov. 28 to Nov. 30, 2025 as baseline, Dec. 1 to Dec. 3, 2025 as surge).
Table 1: what each flood was made of
Seven dimensions, two properties, five months apart, and every one of them lands on a single value.
Table 2: the numbers behind the metric that improved
Session duration collapsed on both properties. Bounce rate improved on both anyway, and on the client property engagement rate rose with it, to 93.0% from a 90.6% baseline.
How I Separated the Script From the Audience
GA4 marks a session engaged once it clears roughly ten seconds, fires a second pageview, or logs a conversion event. A visitor who lands, waits eleven seconds, and leaves counts as engaged. A visitor who reads for eight seconds and leaves counts as bounced.
The metric cannot tell attention from a timer.
So I stopped reading the aggregate and broke each surge down by country, browser, operating system, device category, session source and medium, and new versus returning, comparing each dimension’s surge-window share against its own baseline share.
Real traffic is a mix. One script running from one kind of machine collapses every dimension onto one value at once.
I then summed the top-15 rows of each surge’s country breakdown and checked that sum against the reported session total. In ordinary traffic the two sit close, since a session belongs to one country. Here the breakdown sum ran well above the total, 1.44x on the client property and 1.69x on The Gourmet Host, against baseline ratios near 1.0 on both.
That mismatch is what sessions whose apparent geography shifts mid-session look like, the signature of IP or proxy rotation.
Last, I checked organic search on its own, the channel least likely to be moved by a script that arrives with no referrer.
Direct and unassigned already carries a blind spot before any flood reaches it, since it is also where AI-driven referral traffic lands when the referring app strips its header. A flood makes that blind spot loud enough to notice.
The Tell Was a Ten-Second Session
Inside the client property’s surge, the Singapore cohort ran an average session duration of 10.0 seconds, sitting almost exactly on GA4’s engaged-session cutoff.
Real behaviour does not pile up on a threshold like that. A script built to clear it does.
The Gourmet Host shows the same thing from the other direction: 97% of its flood landed directly on /cart rather than the homepage, at 1.00 pages per session. That is one transactional URL being hit, not a visitor browsing.
What rules out the flattering explanation is the channel split. If either site had simply become more popular, organic search would have moved with it, and it did not: 0.98x on the client property, 1.22x on The Gourmet Host, both inside ordinary day-to-day variance.
The whole distortion sat inside direct and unassigned traffic. A real growth event does not skip the one channel search engines drive.
It is the same failure as a plugin setting that reports as enabled while never firing at checkout: the dashboard states one thing, the live behaviour another, and only checking the behaviour settles it.
Five Lessons a Traffic Flood Leaves Behind
A single-metric read of engagement is not a safety check. Bounce rate and engagement rate are session-duration proxies with a fixed threshold, so a script tuned to clear that threshold reports as an improvement rather than a warning. Read session duration alongside them or the flood arrives disguised as a good week.
Dimensional collapse beats any one number. Country, browser, OS, device, and channel all landing on a single value in the same window is what one automated source looks like. Build the breakdown before you build the theory, because real traffic, including a real viral spike, stays a mix on nearly every dimension.
Landing page concentration tells you what the traffic wants. A flood aimed at one transactional page reads as a scripted target, not as interest. On The Gourmet Host that pointed straight at /cart and told me to look at checkout abuse rather than at content performance.
Organic search is the control group. Before reacting to any traffic anomaly, check whether search-driven sessions moved with it. If organic stayed flat while direct or unassigned exploded, the anomaly is not a growth event and should not be reported or acted on as one.
Edge filtering and reporting filtering are two different decisions. A WAF rate-limiting rule or a one-click AI-bot block stops a session before it loads a page, while GA4’s bot filtering only hides it from the dashboard afterwards. Naming the crawlers you want ahead of time, the way an llms.txt file or a documented crawl-budget policy does, beats writing one blanket rule after a flood.
What This Does Not Claim
Organic search sessions held flat through both windows and for weeks after, which argues against major crawler damage on either property. That is a GA4-side proxy for crawl health, not Search Console coverage data, and I did not run the Search Console check for either property. “Organic held flat” is not the same evidence as “Googlebot kept full access.”
The country-sum mismatch corroborates the rotation reading rather than establishing it on its own.
Neither flood was traced to a named actor, and no rule change is on record behind The Gourmet Host’s recovery on Dec. 4, 2025, so nothing here credits an intervention for that.
Rate-based rules react to the shape of traffic, and Googlebot, OpenAI’s GPTBot, and Anthropic’s ClaudeBot can produce that same shape after a large publish. Verify by reverse DNS rather than trusting a user-agent string.
The takeaway in one line: bounce rate got better on both properties because the traffic clearing the threshold was never trying to read the page.
Wondering whether a recent traffic jump on your own site is a growth event or a flood? Sorting that out is part of a free diagnosis.
Frequently Asked Questions
What Is a Bot Traffic Surge, and How Does It Differ From a Real Spike?
A bot traffic surge is a sudden run of automated, scripted sessions rather than human visits. It shows up as a large jump in sessions concentrated in one country, browser, operating system, and channel at once. A real spike, from a viral post or a press mention, stays spread across a normal mix of geographies and devices.
Why Did Bounce Rate Improve During a Bot Flood Instead of Getting Worse?
Bounce rate depends on GA4’s engagement threshold, roughly ten seconds or a second pageview. A script that holds a session open past that mark registers as engaged with no real reading happening. On both properties here, average session duration collapsed while bounce rate improved, because the traffic was clearing the timer rather than the page.
How Do You Verify a Crawler Claiming to Be Googlebot Is Genuine?
Check the requesting IP with a reverse DNS lookup, then confirm the forward lookup resolves back to the same address, using Google’s documented method. A user-agent string alone proves nothing, because any script can claim to be Googlebot or another named crawler. Only the IP-level check settles it.
Does GA4 Bot Filtering Catch Traffic Like This Automatically?
GA4 applies known-bot filtering against a published list of user-agent patterns, which stops obvious bots. It will not catch a script using a real browser user-agent and rotating IPs, which is what both floods in this note look like. That gap is why the dimensional-collapse check matters more than the default filter.
Can Blocking Bad Bot Traffic Also Block Real Search or AI Crawlers?
It can. Rate-based rules react to the shape of traffic, meaning burst volume from a narrow IP range or user-agent pattern, and legitimate crawlers produce that same shape after a large publish or a fresh sitemap submission. Naming the crawlers you want, and verifying them by reverse DNS, keeps a blanket rule from catching the crawl you depend on.
How Long Does a Bot Traffic Surge Usually Last?
There is no fixed duration. The Gourmet Host’s flood ran three days and stopped on its own, with no documented rule change behind the stop. The client property’s flood was still running 23 days in, at roughly 13,595 sessions a day against a 61.7-session baseline, with no sign of tapering.
Continue Reading
More from TDM Insights
- How to Measure AI Traffic With No Referrer
- Technical SEO for Founders: What to Fix First
- SEO and AI Visibility Tracking Tools Compared
- Crawl Budget and Indexation for Small Sites
- Structured Data for SEO: The Founder’s 80/20
Explore TDM Insights Topics