- Edge bot detection classifies a request on a CDN or reverse-proxy node near the visitor, before your origin server responds. It is fast and covers every request, including clients that never execute JavaScript — but it only sees the network and protocol layer.
- The edge can read IP reputation and network type, TLS and HTTP fingerprints, header ordering and completeness, request rate and path shape. It cannot read rendering behaviour, pointer and scroll events, or real dwell time — those need in-page JavaScript.
- Providers differ less in whether they use machine learning than in when the verdict is produced and how much evidence it rests on: pure edge rules are fastest and coarsest, edge-plus-in-page hybrids are the most accurate but must wait for execution, and managed services bundle both and add cross-site intelligence.
- False positives are a real cost. Corporate VPNs, carrier NAT, privacy relays, older browsers, accessibility tools and aggressive script blockers all make real people look automated. Measure the flagged rate per country, network type and device — a single site-wide number hides the damage.
- Do not use edge logs to audit a platform's invalid-click filtering. The two count different populations at different moments and will never reconcile. Use the edge verdict as an independent second view that helps explain a gap between clicks and sessions.
What "edge" actually refers to
When a visitor opens your landing page, the request passes through several layers: first a CDN node close to them, then your origin server, and only after the response arrives does the browser start executing JavaScript. Edge bot detection is the first of those layers — classification happens on the CDN or reverse-proxy node before anything is forwarded to your origin, producing one of three verdicts: allow, challenge, or block.
That position buys two structural advantages. Cost: requests judged automated never consume origin compute or bandwidth, which matters at volume. Coverage: clients that never run JavaScript — scripted scrapers, command-line tools, some security scanners — are invisible to in-page detection but leave a complete connection trace at the edge. For a side-by-side view of the layers, see our comparison of bot detection systems.
The edge asks whether the connection looks automated. In-page JavaScript asks whether the session behaves like a person using it. The first is early, complete and coarse; the second is late, partial and detailed. Mature setups run both and merge the two scores into one verdict.
What the edge layer can read — and what it cannot
Verdict quality is a function of available evidence. The table separates the signals present at the moment a request arrives from the ones the edge has to give up:
| Signal | Available at the edge? | What it tells you, and its limits |
|---|---|---|
| IP reputation and network type | Yes | Datacentre ranges, known proxy pools and cloud egress are strong signals — but residential proxies and carrier NAT blunt them |
| TLS and HTTP fingerprint | Yes | Handshake parameter order, supported extensions and HTTP/2 frame characteristics expose client libraries — though mainstream automation frameworks increasingly resemble real browsers |
| Header ordering and completeness | Yes | A missing Accept-Language, a user agent inconsistent with the other headers, or an ordering matching no known browser are cheap and effective checks |
| Request rate and path shape | Yes | Fixed intervals, directory enumeration and deep URLs hit with no entry page point to scripts — but a single-click visitor offers almost no rate to measure |
| Rendering and interaction behaviour | No | Pointer paths, scroll rhythm and focus changes only exist after execution and must be collected in-page |
| Dwell time and conversion behaviour | No | The edge sees one request; it cannot know whether the visitor stayed three seconds or three minutes, or whether they converted |
The table explains a common puzzle: why the edge reliably stops crude scraping scripts yet has almost nothing to say about automation that drives a real browser engine through a residential exit and clicks once. At the connection layer that traffic is indistinguishable from a person; separating it requires the page to run and behaviour to be observed. Industry reporting usually files it under sophisticated invalid traffic (SIVT), which follows a different remediation path from general invalid traffic.
How the main approaches differ
Vendor messaging converges on the same vocabulary, so compare on three axes instead: when the verdict is produced, how much evidence it rests on, and whether cross-site intelligence feeds into it. On those axes the market splits into three groups:
| Approach | Verdict timing | Fits / does not fit |
|---|---|---|
| Pure edge rules — WAF rulesets, rate limits, IP lists | First request, no added latency | Good against bulk scraping and credential stuffing; poor at separating low-frequency, human-like visits |
| Edge plus in-page scoring | Provisional at the first request, revised after execution | Highest accuracy; requires a script on the page, and falls back to the edge-only verdict for non-JavaScript clients |
| Managed detection services, of which DataDome is one example | Edge-terminated, with the score accumulating across the session | Cross-site intelligence is the main added value; you accept a score you cannot fully explain and depend on the vendor console to debug it |
If you are evaluating or already running a managed service, start by understanding how the score is composed and which action each band triggers — we cover that separately in what DataDome is and how to read a bot score. Teams building their own edge logic may find the runtime section of request routing on Cloudflare Workers useful.
Why legitimate visitors get flagged
The edge judges on network and protocol characteristics, and some real people share those characteristics. The recurring cases:
- Corporate networks and VPNs. An entire company exits through a handful of IPs, which reads as scripted rate; remote-work VPNs additionally desynchronise geography from language settings.
- Carrier NAT and privacy relays. On mobile networks thousands of users share one egress address, leaving IP reputation with almost no discriminating power, while privacy relays deliberately obscure the originating network.
- Older browsers and minority clients. A TLS stack or header order matching no known-good template lands in the suspicious band — most visibly on low-end Android devices and regionally customised browsers.
- Accessibility tools and script blockers. Screen readers and aggressive ad or script blocking alter request characteristics or prevent the detection script from running, forcing hybrid setups back onto the coarse edge-only verdict.
A site-wide false-positive rate is a useless number. Break the challenged and blocked rates down by country, network type — residential, mobile, datacentre — device tier and browser version, then compare each group against its conversion rate. The damage usually concentrates in one or two segments, such as mobile traffic in a single market being broadly challenged while the site-wide figure moves by a fraction of a percent.
Reading an edge verdict alongside ad data
The first thing most advertisers do with edge logs is check them against the invalid-click figures in their ad reports — then, finding the two irreconcilable, conclude the platform is under-reporting. The reconciliation itself is the mistake.
The reason is direct: the two count different populations at different moments. Platform filtering happens before billing, using cross-account data you cannot see, and a filtered click never delivers a visitor to your site at all. Your edge logs count every request that reached your domain, including traffic from non-ad sources and excluding whatever the platform already discarded. We unpack the platform-side definitions in invalid clicks in Google Ads.
The useful application is to treat the edge verdict as an independent view that explains a gap between clicks and sessions. If a channel's clicks rise while sessions do not, and that channel's suspicious share at the edge is visibly higher than its peers, you at least know where to look. If the edge distribution looks normal, the gap more likely sits in redirects, load time or measurement definitions. For keeping invalid traffic out of conversion data systematically, see bot traffic detection and what invalid traffic is.
One principle to close on: an edge verdict exists to protect your resources and inform your measurement, not to justify serving different content to different visitors. Search engine crawlers should be explicitly allowed through, and the landing page URL and its content should be the same for everyone — a line drawn clearly in the landing-page red lines set by ad platforms.
Frequently asked questions
What is edge bot detection?
It is a traffic classification step that runs on a CDN or reverse-proxy node close to the visitor, before the request reaches your origin. The node inspects what exists at connection time — IP reputation and network type, TLS and HTTP fingerprints, header ordering, request rate and path patterns — and returns allow, challenge or block. Because it precedes your application, it protects origin capacity and produces a verdict even for requests that never execute page code.
How does it differ from JavaScript-based detection in the page?
They observe different things. The edge sees the network and protocol layer and can decide on the first request, but nothing that requires the page to run. In-page JavaScript sees browser APIs, rendering behaviour, pointer and scroll events and timing, which a simple script struggles to imitate — but it only produces a verdict after load, and never for clients that do not execute JavaScript. Most mature setups run both and combine the signals.
Why do real users sometimes get flagged?
Because the edge judges on characteristics legitimate users sometimes share with automation. Corporate VPNs, carrier NAT ranges, privacy relays, older browsers with unusual TLS stacks, accessibility tools and aggressive ad or script blockers can each produce an automated-looking profile. Absolute rates are usually low but concentrate in specific segments, which is why false positives must be measured per country, network type and device rather than site-wide.
Can I use edge logs to check the invalid clicks in my ad reports?
Only partly, and the two numbers will never match. Platforms filter before billing using data you cannot see, and a filtered click never reaches your site. Your edge logs cover every request that arrives at your domain, including non-ad sources and excluding what the platform already discarded. Treat the edge verdict as a second, independent view of traffic quality that helps explain a gap between clicks and sessions — not as an audit of the platform's filtering.
Want visibility into what each visit was served?
Every visitor hits the same landing-page URL — invalid-traffic filtering, in-page A/B testing and audience-aware content, with every served result inspectable in the dashboard. No hidden content, no sneaky redirects.