Are Old Browser Versions a Useful Bot Signal?

Executive Summary

We analyzed 49 months of US browser market share data to answer one question: Can you detect bots by looking at browser version age? Short answer: yes, for some browsers and version patterns — but with important caveats.

Understanding "Version Lag"

Modern browsers like Chrome, Edge, and Firefox release a new major version roughly every 4 weeks. That means:

We define "version lag" as: current version − this user's version. For example, if Chrome 141 is the current stable and a visitor uses Chrome 109, their lag is 32 — meaning they're running a version approximately 2.5 years old.

Chrome Version Cadence (2025)

To make this concrete, here's what the "current" Chrome version looked like each month in 2025. "Current Chrome" here means the single version with the highest share that month (the statistical mode) — a slightly different measure from the 99.5th-percentile reference used in the lag charts, but useful for building intuition about the version timeline.

The takeaway: "lag 12" means roughly "version released more than a year ago." But the right threshold depends on how aggressively the browser auto-updates — and whether legitimate enterprise users might be pinned to older versions. Read on for browser-by-browser guidance.

Why Not Just Block Anything Old?

The risk is blocking real people. Some legitimate reasons a user might be on an older browser version:

• Enterprise IT policy — companies sometimes freeze browser versions for compatibility with internal tools. Chrome and Edge support an "Extended Stable" channel that lags 8 weeks behind regular stable.
• Legacy hardware/OS — Chrome 109 is the last version that runs on Windows 7 and 8.1, which some machines still run.
• Firefox ESR — Firefox's "Extended Support Release" gives enterprises a supported older version. Firefox 128 ESR (released July 2024) is currently supported and would appear as "old" under a strict lag rule.
• Slow auto-update — some users disable automatic updates. Being 2–3 versions behind is not unusual.

Browser Market Share Overview

Our data covers 49 months across four periods. Chrome dominates US traffic, followed by Safari, Edge, and Firefox. A few notable shifts from 2022 to 2025-26:

Key notes: IE fell from 1.28% to 0.21% — IE 11 officially ended support in June 2022, so most remaining IE traffic is non-human. Brave grew from near-zero to 2.73%, and Chrome for Android doubled its share (likely reflecting more mobile measurement).

Figure 1 — Browser family share, January–December 2022. Y-axis: share of all measured US web traffic (%). X-axis: month. Each line is one browser family (desktop and mobile combined for Chrome). Chrome led at ~58%, Safari at ~16%, Edge at ~13%. Within Chrome and Edge, the rapid succession of individual version releases appears as closely spaced peaks at the ~4-week release cadence.

Figure 2 — Browser family share, January 2025–January 2026. Y-axis: share of all measured US web traffic (%). X-axis: month. Chrome holds steady at ~59%. Safari fell to ~11% (down approximately 5 percentage points from 2022). Brave emerged at ~2.7%. Chrome for Android approximately doubled its reported share. Edge and Firefox remained approximately flat.

Bot Signals in the Data

Three patterns in the data are strongly indicative of bot activity rather than human browser use. They share a common signature: specific old versions appearing in bulk, often with sudden activation and cessation behavior inconsistent with normal software update patterns.

Signal 1: The Edge 87 Anomaly (November 2023 – February 2024)

This is the clearest automated-traffic signal in the dataset. By late 2023, the dominant Edge version was ~119 — putting Edge 87 approximately 32 versions behind current (about 2.5 years' worth of releases at Edge's ~4-week cadence). Edge 87 traffic was otherwise under 0.1% — consistent with deeply outdated usage gradually fading away.

Here's what happened to Edge 87's traffic share:

Recommendation: Hard-block Edge 87 outright. Also block the legacy "EdgeHTML" versions (Edge 15, 18, 19) — these pre-date the 2020 redesign and have been end-of-life since 2021.

Signal 2: Firefox 11 — The Growing Bot Fleet

Firefox 11 was released in 2012. Current Firefox in 2026 is version 140+. That's a lag of approximately 129 versions — approximately 10+ years behind current. There is no realistic scenario in which a human user has been running Firefox 11 uninterrupted since 2012.

What makes this more alarming is that Firefox 11 traffic is growing:

Signal 3: Firefox 118 — The Hidden Campaign That Just Ended

This is a more subtle signal we discovered when looking at which specific old Firefox versions dominate traffic. Firefox 118 was released in September 2023 — a perfectly normal browser version at the time. But something unusual happened: it maintained roughly 1% of all US web traffic for over two years, then dropped to exactly 0% in January 2026 — the last month in our dataset.

Signal 4: Chrome October 2025 Anomaly

In October 2025, nearly 30% of all US web traffic came from Chrome versions 12+ versions behind current (compared to the annual average of ~16%). This is the largest single-month spike in the dataset.

Figure 3 — Chrome old-version traffic over time (lag ≥ 12, 99.5th-percentile reference). Y-axis: share of all US web traffic (%) from Chrome versions more than approximately one year behind current stable. X-axis: month within each year. Each colored line is one calendar year. The October 2025 spike (~29.6%) was approximately 3× the 2025-26 annual average (~9.7%).

The main contributors in October 2025:

Chrome 125 (12.8%) is particularly notable: it was released in May 2024 — 17 months before October 2025, placing it 16 versions behind current. It had also spiked anomalously in December 2024 before fading out, then resurged in October 2025. Chrome's Extended Stable channel only extends support by ~8 weeks (2 versions), not 16. This level of persistence for a ~17-month-old version suggests large pinned or legacy fleets, measurement artifacts, or automation using Chrome 125 user-agent strings — not a plausible Extended Stable explanation. Chrome 130 (~5 months old, lag 11) is a more defensible enterprise candidate.

How Concentrated Is the Old-Version Traffic?

Throughout this section, "old-version traffic" means traffic from browsers with a version lag of 12 or more — approximately one year or more behind the current stable release (99.5th-percentile reference). This is the lag ≥ 12 tail visible in the bucket charts above.

One way to distinguish bot traffic from slow-updating humans: bots tend to use one specific version, while humans spread out across multiple adjacent versions. We measure this with the Herfindahl-Hirschman Index (HHI), a standard concentration metric — a higher score means traffic is more concentrated on fewer specific versions.

Figure 4 — Version concentration (HHI) of old-version traffic, Chrome / Edge / Firefox, all years. Y-axis: Herfindahl-Hirschman Index (HHI, 0–10,000) applied to the lag ≥ 12 tail of each browser. A higher HHI means old-version traffic is more concentrated on fewer specific versions — a pattern more consistent with automated fleets using hard-coded user-agent strings than with organic slow-updating users. X-axis: month. Each colored line is one calendar year. The red dashed line marks HHI = 2,500, the conventional "concentrated" threshold. Edge's 2024 spike corresponds to the Edge 87 campaign; Firefox's upward trend reflects the growing Firefox 11 and Firefox 118 fleets.

What Version Lags Should We Actually Block?

Here's the practical guide, browser by browser. The key insight is that the right lag threshold is different for each browser, and for some browsers (Firefox especially) there are specific version numbers that are better hard-block candidates than a blanket lag rule.

All lag values in this section use the 99.5th-percentile reference version — the version at or below which 99.5% of a browser family's traffic falls in a given month. This approach handles small fractions of pre-release (Beta/Canary) traffic more robustly than using the single highest-share version.

Figure 5 — Version lag bucket distribution by browser, 2022 vs 2025-26. Y-axis: share of each browser's own traffic (%) in each lag bucket. Bars within a browser sum to 100%. X-axis: lag bucket. Two bars per cluster: 2022 (blue) and 2025-26 (orange). Note: these are percentages within each browser's traffic, not of all US traffic. Edge remains concentrated in the 0–2 lag bucket. Chrome and Firefox have shifted toward older buckets between 2022 and 2025-26.

Policy Tiers

Here are three readymade policy options depending on your risk tolerance. "False positive rate" (FP rate) refers to the percentage of browser traffic in a given category that would be blocked or challenged — lower is better for user experience.

The Safari Problem

Safari is fundamentally different from Chrome, Edge, and Firefox when it comes to version-based anti-bot rules. Here's why:

Safari's major version is tied to the operating system. When Apple releases a new version of iOS or macOS, Safari gets a new major version number. You can't upgrade Safari independently — you upgrade your entire phone or computer. This creates a very different traffic pattern:

Note: Shares below are aggregated across all sub-versions (e.g., Safari 18.0 + 18.1 + 18.2 … = "Safari 18"). The lag column uses the 99.5th-percentile reference, which shifts mid-period (see note below table).

There's a secondary complication: some very old Safari user-agent strings (like "Safari 604.1" or "Safari 537.36") are actually Blink/WebKit engine version numbers that appear in old or spoofed user-agent strings, not real Safari versions. These are worth blocking separately as they represent either ancient browsers or deliberate spoofing.

Bottom line for Safari: Stick to hard-blocking specific very old versions (Safari 12 and below, released before 2019) and fake WebKit UA strings. Do not apply a "lag ≥ N" rule to Safari based on major version numbers.

What StatCounter Actually Measures — And Why It Matters for Your Access Logs

This is one of the most important things to understand before acting on this data. StatCounter and your web server's access logs are measuring completely different things, and mixing them up can lead to bad decisions.

StatCounter measures JavaScript page views, not HTTP requests

StatCounter works by embedding a small JavaScript tag on participating websites. Every time a page fully loads and that JavaScript executes, StatCounter records one data point — one "page view." This means:

The Pagination / Faceted Search Trap Problem

This is particularly relevant if your website has:

• Paginated listings — e.g., /products?page=1 through /products?page=9999
• Faceted search — where every combination of filters generates a unique URL (e.g., color × size × brand × sort-order × page = potentially millions of unique URLs)
• Auto-generated tag or category pages that link to each other endlessly
• Calendar or date-range archives that can be combined indefinitely

A bot following links through faceted search can visit an effectively unlimited number of unique URLs on your site. Each page it loads (if it executes JavaScript) becomes one StatCounter data point — but generates dozens of HTTP requests in your access log for the page itself, plus all its assets.

What This Means for Old Browser Version Analysis

There are two opposing distortions to be aware of:

1. StatCounter may overstate old-browser version share relative to unique visitors. If bot crawlers using old browser UA strings visit many pages per session (especially in a faceted-search trap), their version's "share" in StatCounter will be inflated relative to the number of actual bot instances. The 0.8% "Firefox 11 share" could represent a handful of bot processes visiting millions of pages, not millions of unique Firefox 11 browser installations.

2. StatCounter may understate the impact on your server load. Each of those many page views triggers dozens of HTTP requests. So if StatCounter shows Firefox 11 at 0.8% of page views, the actual percentage of HTTP requests hitting your server could be much higher — especially if those bots are crawling deep into your pagination or faceted search.

3. Bots that don't execute JavaScript are completely invisible to StatCounter. Many scrapers and crawlers fetch raw HTML without executing JavaScript at all. These would appear in your access logs but not in any StatCounter data. This means StatCounter's numbers are a lower bound on bot activity — the real bot traffic hitting your server is likely higher than what StatCounter can see.

A Note on StatCounter's Own Bot Filtering

StatCounter states that it filters known bots and crawlers. However: its filtering is based on known bot signatures (user-agent strings, IP ranges), not on behavioral analysis. Novel or disguised bots using legitimate browser UA strings (like the Firefox 11 and Edge 87 campaigns in this dataset) may pass through StatCounter's filters and be counted as real traffic. This means some of what appears to be "human market share" in this dataset is almost certainly bot traffic that StatCounter could not identify.

Important Limitations

Methodology (Brief)

Data Source

All data in this report is sourced from Statcounter Global Stats (© Statcounter 1999–2026), licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Use of this data is credited to Statcounter as required by their terms.

StatCounter measures page views — not unique visitors or raw HTTP requests — collected from a network of over 1.5 million websites representing approximately 5 billion page views per month. The data reflects JavaScript-rendered page views only; traffic from automated clients that do not execute JavaScript is not captured. Statistics are subject to quality assurance revision for 45 days from initial publication.

Four monthly CSV exports covering January 2022 through January 2026 were downloaded from the StatCounter "US browser version" report and loaded into the analysis pipeline. Files were converted from wide format (one column per browser version) to long format with one row per month per browser version. Special cases were handled as follows:

• Safari 604.1, 537.36, 605.1 — Reclassified as "Safari (WebKit UA)"; these are engine build numbers, not real Safari versions.
• Chrome for Android — Kept as separate family (no version number available).
• Mozilla 0, 360 Safe Browser 0 — Treated as "unversioned" special families.
• IE, Edge (all versions), Opera, Brave, SeaMonkey — Parsed normally.

The "current" version reference for each browser was computed two ways: (A) the 99.5th-percentile major version by traffic share that month (handles beta/canary noise), and (B) the single highest-traffic version (mode). Results are reported using Method A.

Outlier months were flagged if lag≥12 traffic exceeded the period's median + 3× the median absolute deviation. Concentration was measured using the Herfindahl-Hirschman Index (HHI) — a standard measure of market concentration — applied to version shares within the old-version tail.

All analysis code is in statcounter_browser_version_analysis.py. Raw data tables are in the output/ directory.