Skip to main content
You loaded your live site, walked through the funnel, checked the results page, nothing happened. Zero new exposures on your test. Nine times out of ten: you (or your office) are on the site’s blocked-IP list.

​
Check

Site → Settings → Blocked IPs. Look at the rules. Any of them match your current public IP? Your current public IP:
If yes: you added yourself. Remove yourself from the list, or use the visitor opt-out URL instead, which is per-browser rather than per-IP.

​
The debugger sanity check

Open DevTools on your site and run:
The events buffer will show a beacon entry with the exposure event being sent, the snippet has no way to know your IP is blocked, so it will fire the beacon regardless. The rejection happens server-side. That means:
  • You see a beacon event in the debugger, snippet is working.
  • Results page shows no new exposure, server dropped it.
If those two together, blocked IP is the almost-certain cause.

​
The Activity column

The Blocked IPs panel shows a “last observed” column. If a rule matches your current IP, “last observed” will be very recent (minutes or seconds after your visit). If your IP is not on any rule, all Activity cells are old, some minutes or hours ago, from prior traffic.

​
Removing yourself

Delete the row. Save. Your next visit is counted. If the rule is deliberately blocking a range that includes your IP (say, your office is on a corporate NAT and you cannot separate yourself from the office), use the visitor opt-out URL as your personal QA workflow instead. ?abtestly_optout=0 opts your browser back in.

​
Why the snippet still runs on a blocked IP

Because the block is server-side, on ingest. The snippet on the visitor’s browser fetches config, decides a variant, applies it, sends the beacon. Only the beacon is dropped. This is deliberate. The visitor still sees the correct variant so that click-through testing works, they just do not appear in the data. Blocking at the snippet level would produce a different visual experience on blocked IPs, which is not what a QA workflow wants.

​
The two-second detail

If you added yourself to the block list just now and your visit still counts, wait a few seconds. The block-list check reads a cached copy of the site’s settings; a fresh rule takes a moment to propagate.

​
Bots

If you are seeing traffic from an IP range that is clearly a bot. recurring spikes, no engagement, a blocked-IP rule is the right tool. The panel accepts CIDR ranges, so you can block a whole /24 at once. If you want to avoid manually maintaining bot lists, use Cloudflare Bot Management on your zone. That is upstream of ABTestly and drops bots before they ever hit us.