Antibot Setup for Cloaking
The antibot layer sits in front of the cloak and decides who actually gets to see the white page versus the offer: a real visitor, a bot, an automated platform check, or a human reviewer. A weak antibot lets too much through and leads to bans; an overly aggressive one cuts real audience along with the junk. Here's what layers a solid antibot is built from and how APEX handles it.
Why antibot filtering is separate from geo cloaking
A geo filter only answers which country the visitor is from, but a bot, a scanning service, or a human reviewer often connects from the exact target geo on an ordinary-looking IP. Antibot filtering adds a second, behavioral and technical layer on top of geo, and that's where most automated platform checks actually get caught.
Filtering by user-agent
The first layer cross-checks the user-agent against known lists of ad-platform bots, crawlers, and headless browsers such as Puppeteer, Selenium, PhantomJS, and their derivatives. It also flags suspiciously old or unusual browser versions that real users rarely run but automated checks often do.
Datacenters, proxies, and VPNs
The second layer is IP intelligence: detecting whether an IP belongs to a datacenter, cloud host, public proxy, or VPN service rather than a residential or mobile carrier network. This is the single most effective filter against reviewers and platform scan services, which overwhelmingly connect from server-side IPs rather than ordinary consumer ones.
Fingerprinting and behavioral signals
The third layer is device fingerprinting (screen resolution, fonts, timezone, system language) plus on-page behavior: how fast the visit follows the click, whether there's any scroll or touch/mouse movement, and time to first action. Automated checks typically land instantly after launch with zero movement — real visitors almost never behave that way.
Combining layers without cutting real traffic
A common beginner mistake is maxing out every filter at once and losing part of the real audience — corporate VPN users or mobile carrier visitors, for instance, whose IPs sometimes get misclassified as datacenter ranges. Layers work better combined under a rule like several matching signals in a row equals a ban, rather than banning on one triggered flag, with regular log checks on exactly who's landing in the ban list.
APEX's built-in antibot in practice
In APEX, all these layers — user-agent, IP intelligence for datacenters, proxies, and VPNs, geo, and baseline behavioral signals — work together out of the box, with no manual regex rules or third-party IP databases to maintain. Rules get updated on the platform side as new bot and crawler patterns emerge, and role-based access lets a team lead see filtering logs and stats across the whole buyer team.
FAQ
- How is antibot filtering different from plain geo cloaking?
- Geo cloaking only checks which country the IP is from; antibot adds user-agent checks, IP reputation (datacenter/proxy/VPN), and behavior — a reviewer often connects from the target geo, and without these extra layers they'd slip through.
- Which filtering layer matters most?
- There's no single winner, but IP intelligence for datacenters and proxies/VPNs usually catches the most reviewers and scan bots, since the overwhelming majority connect from server-side IPs.
- Can antibot filtering accidentally ban a real user?
- Yes, if filters are tuned too bluntly and ban on a single signal — some corporate VPNs and mobile carriers can get misclassified into datacenter ranges.
- Do bot and datacenter lists need manual upkeep?
- Not with APEX's built-in antibot — the databases and rules are maintained on the platform side.
- How do you verify the antibot is configured correctly?
- Check the filtering logs after a small test run: who got routed to the white page, who reached the offer, and whether an unusual share of real target-geo traffic ended up in the ban list.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free