How to Diagnose If Your Site Is Being Targeted by Headless Browsers

Headless browsers leave a combined trail of technical fingerprints and behavioral gaps that normal users do not produce. The fastest way to confirm targeting is to correlate server-side logs (IP reputation, request headers, TLS fingerprints) with client-side telemetry (navigator properties, pointer dynamics, timing) and look for the pattern mismatches that automation tools struggle to hide.

What headless browser targeting looks like

Headless browsers — Chrome, Firefox, or WebKit running without a visible UI — are legitimate tools for testing and scraping. Attackers repurpose them to click ads, fill forms, and poison conversion pixels at scale. Because they execute real JavaScript, they bypass simple user-agent filters. What they cannot easily fake is the full constellation of browser, hardware, and network signals that a genuine device emits.

BotRefund’s detection engine evaluates 106 signals across browser, network, hardware, and behavior categories before classifying a visit. Signals become a decision only when they are seen together. A single odd header is noise; a cluster of mismatched timezone, WebRTC leak, and linear mouse path is evidence.

Technical signals to monitor

Start with the browser surface that automation frameworks expose. The most reliable indicators come from the Evasion, Debugger, & Anti-Stealth Traps group:

• CDP Debugger Leak — traces left by Chrome DevTools Protocol connections used by Puppeteer and Playwright.
• Automation Properties — flags such as navigator.webdriver or vendor-specific properties that automation injects.
• Native Patching — checks whether built-in APIs behave like a real device or have been overwritten by stealth plugins.
• Engine Mismatch and JS Engine Mismatch — inconsistencies between the reported user-agent and the actual JavaScript engine behavior.
• Rebrowser Leaks — artifacts from tools that wrap headless browsers to mimic real sessions.

These signals are captured client-side and sent to your logging endpoint. Do not rely on server headers alone; headless browsers can forward perfect headers while the client environment betrays them.

Behavioral patterns that reveal automation

Even when technical fingerprints are masked, behavior rarely matches human variance. BotRefund tracks several behavioral dimensions:

• Pointer behavior — robotic linear mouse movements, absence of humanlike mouse tremor, and grid-aligned movement patterns that snap to precise lines instead of natural curves.
• Speed behavior — superhuman input speed under 1 millisecond for clicks or keystrokes.
• Path behavior — navigation sequences that skip expected pages or follow identical step orders across sessions.
• Engagement behavior — absence of clicks, scrolling, or field corrections; forms submitted immediately after landing.
• Session behavior — unnatural session durations that are too short, too long, or too uniform to be human.

Collect these via a lightweight script that records pointer coordinates, scroll events, focus changes, and timestamps. Aggregate per session and flag statistical outliers.

Network and geolocation inconsistencies

Automation often runs on cloud or proxy infrastructure that leaks location mismatches. The Network, VPN, & Geolocation Evading Vectors surface these:

• WebRTC Network Leak — browser network paths revealing conflicting locations.
• DNS Tunnel Leak and DNS Challenge Blocked — DNS and web traffic following different routes.
• Timezone Evasion and UTC Timezone Bias — location and language settings that disagree.
• Languages Mismatch and Accept-Language Mismatch — browser language headers that do not match the IP geography.
• IP Address Inconsistency, OS / TCP TTL Mismatch, Suspicious Ports, Netprobe Telemetry Missing — network identity coherence checks.
• HTTP User-Agent Mismatch and HTTP Protocol Mismatch — connection and browser request details that stay inconsistent.
• DNS Routing Mismatch — DNS and web traffic route divergence.

Log the client’s reported timezone, language, WebRTC ICE candidates, and TCP fingerprint alongside the server-seen IP. Automated correlation rules can flag sessions where three or more vectors disagree.

Step-by-step diagnostic process

1. Enable client-side telemetry. Deploy a script that captures the 106-signal set (or a practical subset: navigator properties, WebRTC, canvas hash, pointer dynamics, scroll depth, timing).
2. Centralize logs. Join server access logs (IP, headers, TLS JA3) with client telemetry by session ID.
3. Build baseline profiles. For each traffic source (campaign, referrer, device type), compute normal ranges for each signal.
4. Score sessions. Apply a rule set: any session with ≥3 technical mismatches OR ≥2 behavioral anomalies gets a "suspect" tag.
5. Review suspect clusters. Group by IP subnet, user-agent family, campaign, and time window. Look for burst patterns — many suspect sessions arriving in minutes.
6. Validate with honeypots. Add hidden links or form fields that only bots interact with. Confirmation rate on honeypots calibrates your false-positive threshold.
7. Export evidence. For ad-platform refunds, package session timelines, pointer heatmaps, and signal mismatch tables into the format Google and Meta accept.

Common mistakes and limitations

• Relying on one signal. navigator.webdriver alone produces false positives (some privacy tools set it) and false negatives (stealth plugins hide it).
• Blocking instead of logging. Aggressive blocking destroys the evidence trail you need for refund claims.
• Ignoring residential proxies. Click farms on real phones with residential IPs pass IP reputation checks but fail behavioral and client-side fingerprint checks.
• Sampling too little traffic. Sophisticated bots rotate slowly; you need 100% coverage or statistically sound sampling to catch low-volume campaigns.
• No feedback loop. Without refund outcomes or CRM qualification data feeding back into thresholds, the model drifts.

BotRefund’s approach is to prove bot clicks and negotiate directly with Google and Meta to recover wasted ad spend, not just block traffic. The diagnostic data serves both protection and recovery.

Key facts

Category	Signal examples	What it checks
Evasion, Debugger, & Anti-Stealth Traps	CDP Debugger Leak, Automation Properties, Native Patching, Engine Mismatch, Rebrowser Leaks, JS Engine Mismatch	Traces left by browser automation or masking tools; whether the browser profile behaves like a real device
Network, VPN, & Geolocation Evading Vectors	WebRTC Network Leak, DNS Tunnel Leak, Timezone Evasion, Latency Mismatch, IP Address Inconsistency, OS/TCP TTL Mismatch, HTTP User-Agent Mismatch, Languages Mismatch, Accept-Language Mismatch, DNS Routing Mismatch	Whether network identity, location, language, and connection details stay coherent
Pointer behavior	Robotic linear mouse movements, absence of humanlike mouse tremor, grid-aligned movement patterns	Unnaturally straight pointer paths; missing micro-jitter; movement snapping to precise lines
Speed behavior	Superhuman input speed (<1ms)	Interactions faster than a person could realistically perform
Engagement behavior	Absence of clicks or scrolling	Sessions that stay too static to match a real browsing journey
Session behavior	Unnatural session durations	Visit lengths too short, too long, or too uniform to be human

FAQ

Can I detect headless browsers with server logs alone?

No. Server logs see headers, IPs, and TLS fingerprints. Headless browsers running on residential proxies with stealth plugins mimic those perfectly. Client-side JavaScript is required to surface navigator properties, WebRTC leaks, and pointer dynamics.

What is the minimum telemetry I should deploy today?

At minimum: navigator.webdriver, navigator.plugins.length, WebRTC ICE candidate IPs, canvas fingerprint, pointer move/click timestamps, scroll depth, and session duration. This covers the highest-signal vectors with ~2 KB of script.

How do I distinguish a privacy-conscious user from a bot?

Privacy tools (Tor, hardened Firefox) may set navigator.webdriver or block canvas. They rarely also exhibit superhuman click speed, zero scroll, linear mouse paths, and timezone/language mismatches simultaneously. Require multiple concurrent anomalies before flagging.

Do I need to block traffic to stop budget waste?

Blocking helps but is not required for refunds. Platforms accept behavioral evidence from client-side logs linked to click IDs (GCLID, FBCLID). BotRefund captures those IDs and generates compliance-ready reports for Google and Meta disputes.

How far back can I claim refunds?

BotRefund recovers Google Ads spend dating back to 2017. Meta’s window varies; preserve attribution data before changing campaigns.

What if my traffic volume is under $10,000/month?

The free bot audit works at any spend level. Install the script, let it collect a week of data, and review the suspect-session report. No credit card required.

Verification step

After deploying telemetry, pick one high-spend campaign. Filter sessions to those with click IDs. Count how many show ≥3 technical mismatches or ≥2 behavioral anomalies. If the rate exceeds 5%, you have a measurable invalid-traffic problem worth a formal audit.

Further reading and comparison sources

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

• How to Detect Headless Browsers and Protect Your Website from Bots ...
• Headless Browser Detection: 6 Signals Sites Use (+ Fixes) | AlterLab
• selenium - Headless browser detection - Stack Overflow

Learn more

Visit the website for more information.