How to Implement Detection for Selenium Bots on Your Website

Selenium-driven bots leave consistent fingerprints: they expose Chrome DevTools Protocol endpoints, mismatch JavaScript engine internals, and fail to replicate human-like mouse tremor or scroll behavior. The most reliable way to catch them is a client-side script that collects 100+ signals — WebRTC network paths, timezone consistency, automation properties, CDP leaks, and pointer dynamics — then sends the full pattern to a classification engine that decides human versus bot in milliseconds.

What Selenium Bot Detection Actually Means

Selenium bot detection is the practice of identifying visits driven by the Selenium WebDriver framework (or its derivatives like undetected-chromedriver, Selenium Stealth, or Rebrowser) rather than by a real person using a standard browser. These automation tools control a real browser binary, so they pass basic user-agent and IP checks. Detection therefore shifts from "is this a known bot IP?" to "does this browser behave like a human-operated instance?"

The core challenge: Selenium bots run inside genuine Chrome or Firefox processes. They execute JavaScript, render CSS, and load images. Traditional server-side filters — IP reputation, request rate limits, header inspection — miss them because the network layer looks legitimate. You need client-side telemetry that observes the browser's internal state and interaction patterns.

Why Server-Side Checks Alone Miss Selenium Bots

Server logs show a valid Chrome user-agent, a residential IP, normal TLS handshake, and correct Accept-Language headers. The request timing falls within human ranges. All of this is reproducible by Selenium when configured with residential proxies and realistic headers. What the server cannot see: whether the browser has a CDP websocket open, whether navigator.webdriver is true, whether the JS engine's internal performance.memory object matches a real Chrome build, or whether mouse moves exhibit micro-jitter.

BotRefund's detection model evaluates 106 browser, network, hardware, and behavior signals together before classifying a visit. One signal can be misleading; the prediction AI sees how they fit together. This multi-signal approach is what separates automation from human traffic.

Core Detection Vectors for Selenium Automation

The following vectors are specific to browser automation frameworks like Selenium. Each is a client-side check that runs in the visitor's browser and reports a boolean or numeric result.

• CDP Debugger Leak — Checks for traces left by browser automation or masking tools. Selenium enables the Chrome DevTools Protocol by default; even stealth builds often leave a websocket endpoint or __cdp__ object detectable via timing attacks.
• Native Patching — Checks whether the browser profile behaves like a real device. Selenium injects polyfills or patches native functions (e.g., window.chrome.runtime) that alter prototype chains in detectable ways.
• Engine Mismatch — Checks whether the browser profile behaves like a real device. The V8 version, navigator.userAgentData brands, and performance.memory layout must align with the claimed Chrome build.
• Rebrowser Leaks — Checks for traces left by browser automation or masking tools. Tools like Rebrowser or undetected-chromedriver modify browser internals but often leave timing side-channels or inconsistent chrome.app objects.
• JS Engine Mismatch — Checks whether the browser profile behaves like a real device. Selenium's JavaScript execution context can differ in stack trace format, Error object properties, or eval behavior.
• Automation Properties — Checks for traces left by browser automation or masking tools. The classic navigator.webdriver === true flag, plus newer properties like window.__selenium__ or document.__webdriver_evaluate__.

These six vectors belong to a larger set that also covers network evasion (WebRTC leak, DNS tunnel, timezone mismatch, latency mismatch) and behavioral traps (pointer tremor, scroll dynamics, click speed, session duration patterns). No single vector decides the outcome; the classification engine weighs the full pattern.

Step-by-Step Implementation Process

1. Add a lightweight client-side collector — Embed a < 50 KB async script that runs on every page load. It gathers the 106 signals: WebRTC ICE candidates, Intl.DateTimeFormat().resolvedOptions().timeZone, navigator.webdriver, CDP websocket probe, mouse move listeners (capturing x/y/timestamp at 60 Hz), scroll depth and velocity, click timestamps, and canvas/WebGL fingerprints.
2. Send the signal bundle to a classification endpoint — POST the JSON payload to your detection API within 200 ms of page load. Include the Google Click ID (GCLID) or Facebook Click ID (FBCLID) if present, so later refund claims can tie a specific paid click to the behavioral evidence.
3. Receive a real-time verdict — The API returns { "classification": "human" | "bot", "confidence": 0.0-1.0, "signals": { ... } }. Use this to conditionally fire conversion pixels, suppress bid signals, or flag the session in your analytics.
4. Store the evidence for refund disputes — Persist the full signal bundle, verdict, timestamp, click ID, and page URL. BotRefund's platform auto-captures GCLIDs/FBCLIDs with behavioral proof and generates compliance-ready refund reports for Google and Meta.
5. Integrate with ad platform APIs — For Google Ads, use the Offline Conversion Import API to send "invalid click" conversions tied to GCLIDs. For Meta, use the Conversions API with a custom event parameter marking the click as disputed. This feeds the platforms' learning systems and supports manual refund requests.
6. Monitor false-positive rate weekly — Sample 100 human-classified and 100 bot-classified sessions manually. Check for real users on corporate VPNs, unusual hardware, or accessibility tools that might trigger automation flags. Adjust signal weights or add allowlist rules as needed.

Common Implementation Mistakes

• Relying on navigator.webdriver alone — Modern stealth builds set this to undefined. It catches only naive scripts.
• Blocking on the first suspicious signal — A single WebRTC leak can happen on a legitimate corporate network. Wait for the full pattern.
• Skipping click ID capture — Without GCLID/FBCLID, you cannot file a refund claim even with perfect detection.
• Running detection only on landing pages — Bots often land on a benign page first, then navigate to the conversion page. Deploy the collector site-wide.
• Using server-side UA parsing as a gate — Selenium rotates user-agents trivially. Treat UA as one weak signal among many.

How to Verify Your Detection Is Working

Run a controlled test: spin up a Selenium instance (standard, undetected-chromedriver, and a stealth build) pointed at a test page with your collector. Confirm the API returns "bot" with high confidence for all three. Then visit the same page yourself — from a residential IP, a corporate VPN, and a mobile hotspot — and confirm "human" classifications. Log the signal bundles for each run; compare the automation property flags, CDP probe results, and pointer tremor distributions. This before/after comparison is your verification step.

Limitations and When This Approach Falls Short

• Human click farms — Real people on real devices clicking ads for pay. Behavioral signals look human because they are human. Detection requires pattern analysis across sessions (e.g., same device clicking multiple advertisers in sequence).
• Residential proxy botnets — Malware on consumer devices routes bot traffic through genuine home IPs. Network signals (IP reputation, latency) appear clean; only client-side automation vectors catch the underlying script.
• Advanced stealth frameworks — Tools that patch V8 internals, spoof CDP, and simulate human mouse curves via Bezier curves with injected jitter. These raise the bar; detection becomes an arms race requiring continuous signal updates.
• Privacy regulations — GDPR, CCPA, and ePrivacy require consent for fingerprinting-level data. Your collector must respect consent mode and offer opt-out.

Key Facts

Fact	Detail	Source
Signal count evaluated	106 browser, network, hardware, and behavior signals	S1
Classification accuracy claim	99% accurate at detecting bots	S1
Automation-specific vectors	CDP Debugger Leak, Native Patching, Engine Mismatch, Rebrowser Leaks, JS Engine Mismatch, Automation Properties	S1
Network evasion vectors	WebRTC Leak, DNS Tunnel, DNS Challenge Blocked, Timezone Evasion, Latency Mismatch, Suspicious Ports, UTC Timezone Bias, Languages Mismatch, Netprobe Telemetry Missing, IP Address Inconsistency, OS/TCP TTL Mismatch, HTTP User-Agent Mismatch, Accept-Language Mismatch, HTTP Protocol Mismatch, DNS Routing Mismatch	S1
Behavioral traps	Robotic linear mouse movements, absence of humanlike mouse tremor, superhuman input speed (<1ms), grid-aligned movement patterns, absence of clicks or scrolling, unnatural session durations	S2
Refund success rate	83% for high-volume advertisers	S2
Ad spend drain estimate	Up to 20% of Google and Meta ad budget	S2
Installation time	About one minute, no credit card required	S2
Historical refund window	Google Ads spend dating back to 2017	S2

FAQ

Can I build this detection myself without a third-party service?

Yes, but you'll need to maintain 100+ signal collectors, a classification model that updates as stealth tools evolve, and the refund evidence pipeline for Google and Meta. Most teams find the maintenance burden exceeds the cost of a specialized service.

Does Selenium detection also catch Puppeteer, Playwright, or headless Chrome?

The same signal categories apply: CDP leaks, automation properties, engine mismatches, and behavioral gaps. Puppeteer and Playwright have their own fingerprint patterns (e.g., navigator.webdriver defaults, specific chrome.runtime shapes). A multi-signal engine trained on all major frameworks catches them.

Will this block legitimate users on corporate VPNs or unusual devices?

False positives happen when a single signal is treated as decisive. The multi-pattern approach (106 signals weighed together) reduces this. Still, monitor weekly and allowlist known corporate IP ranges or device profiles if needed.

How long does it take to see refund results after implementing detection?

Google's invalid activity credits can appear automatically within weeks. Manual disputes with evidence packages (GCLIDs + behavioral logs) typically resolve in 30-60 days. Meta's process is similar. BotRefund reports an 83% success rate for high-volume advertisers.

What's the difference between this and a traditional click-fraud blocker like CHEQ?

Tools such as CHEQ focus on filtering suspicious traffic. BotRefund emphasizes proving invalid clicks, preparing evidence, and negotiating directly with Google and Meta to recover wasted ad spend. The detection signals overlap, but the refund workflow is the differentiator.

Can I run detection only on paid landing pages to save resources?

Not recommended. Bots often enter through organic or direct pages, then navigate to conversion pages. Site-wide deployment ensures you capture the full session and the originating click ID.

Does the collector script slow down page load?

The script is under 50 KB, loads asynchronously, and collects signals in the background. It does not block rendering. Most sites see no measurable impact on Core Web Vitals.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

• How to Avoid Bot Detection With Selenium · Zenrows
• Python Selenium - How To Make Selenium Undetectable | ScrapeOps
• Python Selenium: Bot Detection Prevention Techniques | by Abdul ...

Learn more

Visit the website for more information.