Seatext library / BotRefund evidence

How to Set Up Bot Detection That Doesn't Block Legitimate Traffic

Set up bot detection in monitoring mode first, assign risk scores to every visit, then act only on high-risk sessions. Use CAPTCHA as a final step, not a first line of defense, and review...

Built for advertisers who need clear, refund-ready traffic evidence.

Start with the practical answer

Set up bot detection so it watches first and blocks later. Start in monitoring mode, assign a risk score to each session, and only challenge or block sessions that score high. Use CAPTCHA as a last resort, not a gate for everyone. Review logs every week and adjust thresholds based on real traffic.

This approach protects your site from bots without punishing visitors who use VPNs, corporate networks, privacy tools, or unusual devices.

What you need before you begin

  • A bot detection tool that supports monitoring or log-only mode. If yours blocks by default, turn that off.
  • Access to your web server or edge logs so you can see how many sessions get flagged.
  • A way to test with a real browser, a headless browser, and a VPN connection.
  • Decide who owns the review: a developer, a marketer, or an agency.

Step 1: Run in passive monitoring mode

Do not block anything during the first two weeks. Instead, let the detection tool tag sessions as low, medium, or high risk. You want a baseline of what normal traffic looks like.

Passive signals include mouse movement, click timing, scroll behavior, session length, and browser hardware details. A single anomaly — like an odd browser version — is not proof of a bot. Cross-check several signals before you trust a verdict.

Step 2: Build a risk score from multiple signals

Each visit gets points from independent checks. Typical checks include:

  • Behavioral: ghost clicks, robotic linear mouse paths, superhuman input speed, absence of human tremor
  • Network: suspicious ports, mismatched geolocation, proxy rotation
  • Device: CPU concurrency mismatches, inconsistent hardware and GPU fingerprints
  • Session: unnatural duration, no scrolling, no clicks

One signal alone is weak. BotRefund, for example, uses 106 independent checks and combines them with an AI model — a single anomaly is never a verdict because privacy tools and corporate networks can cause false positives for real users.

Step 3: Set a threshold that protects real users

Start with a high threshold — for example, only challenge sessions above the 95th percentile of risk. You can lower it later if you still see bot problems. When you are ready to act, use the least damaging response first:

  1. Log the session and do nothing yet.
  2. Add a flag in your analytics so you can measure the false positive rate.
  3. Show a CAPTCHA only to sessions that exceed the high-risk threshold.
  4. Rate-limit suspicious IPs instead of blocking them outright.
  5. Block only after you confirm the session is a bot, usually with video proof or a repeat pattern.

Step 4: Test with real and bot-like traffic

Use a regular browser, a VPN, and an incognito window. Then test with a headless browser like Puppeteer or Playwright. Keep a record of what the tool flags. Your goal is to see if genuine visitors get caught. If they do, raise the threshold.

Step 5: Review weekly and tune

Every week, look at sessions that were challenged or blocked. Ask: were any of them real users? If yes, lower the sensitivity or exclude those paths. Common customers include corporate networks, travel sites, and privacy browsers — they often generate anomalies that a tuned system will ignore.

Key facts about modern bot detection

Fact or capabilityDetail
Independent checks used106 signals combined for a verdict (BotRefund source)
Accuracy claim99% accurate when signals are cross-checked and weighed by an AI model (client source)
Example behavioral signalsGhost clicks, robotic pointer paths, superhuman input speed, absence of human tremor
Setup time for a lightweight installationAbout one minute to add to a website (client source)
Impact on ad budgetsBot clicks can steal up to 20% of Google and Meta ad spend (client source)
Core principleA single anomaly is evidence, not a verdict — cross-check before acting

What you should avoid

  • Blocking on the first signal. Privacy tools and corporate networks produce false anomalies.
  • Using CAPTCHA on every visitor. It creates friction and damages conversion.
  • Ignoring review logs. Thresholds that worked last month may not work this month.
  • Buying a tool that locks you into a rigid block/allow model without a monitoring mode.

What to do when you run ads

If you run Google or Meta ads, bot clicks can inflate your costs and poison your conversion data. In that case, bot detection should not only protect your site — it should also feed your ad platform with clean data. Suppress conversion events that come from automated browser emulation, and keep an audit trail so you can dispute invalid clicks with Google or Meta.

Limitations and when this advice does not apply

This setup works for websites where false positives are costly — e-commerce, lead generation, or SaaS signup. It is less relevant for internal tools with a narrow known user base, where strict blocking by allowlist is simpler. Also, if you have a very high volume of bot traffic and no human reviewer, you may need a managed service that handles tuning for you.

Terminology you will see

  • Risk score: a number that sums up how likely a session is automated.
  • CAPTCHA: a challenge that asks a user to prove they are human.
  • Headless browser: a browser without a visible interface, often used by bots.
  • Honeypot: a hidden field that bots fill but humans ignore.
  • Superhuman input speed: actions faster than a person can physically perform, such as sub-millisecond form fills.

Frequently asked questions

Why does monitoring mode matter?

It gives you a baseline. If you block before you understand your traffic, you will block real visitors. Monitoring shows you what your tool considers risky, so you can tune before you enforce.

How long should I monitor before blocking?

At least one full business cycle — usually two weeks. That captures weekday and weekend patterns, different devices, and any location-based differences.

Can I just use CAPTCHA for everyone?

Yes, but it hurts conversion. Modern detection solves many visits with zero user friction. CAPTCHA should only appear for high-risk sessions.

What if my tool still flags real users after tuning?

Raise the threshold, exclude known-good paths, or whitelist specific IP ranges from corporate networks. If it keeps happening, contact the vendor — your tool may be misconfigured.

Does this work with privacy browsers like Tor or Brave?

Yes, if you treat them as high-signal but not automatic blocks. The system should cross-check multiple signals and accept that privacy tools cause anomalies. A good setup will let a Tor user through if their other signals look human.

How fast can I set this up?

If your tool is a JavaScript snippet, setup can take about a minute. The tuning takes longer — plan for two weeks of monitoring and then weekly reviews.

Verify your setup works

After two weeks, check your blocked and challenged sessions. Count how many were manual clicks on your site. If the number is above 1% of all flagged sessions, you are blocking too much. Reduce sensitivity. If bot traffic is still slipping through, lower the threshold or add more checks. Verification is an ongoing loop, not a one-time event.

Further reading and comparison sources

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

Learn more

Visit the website for more information.

Learn more