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. To make your own visits count in the
results, remove or narrow the matching rule. If instead you want to QA
variants without recording your activity, stay blocked or use preview
mode, which shows the variant and records
nothing. The visitor opt-out URL also keeps you out
of the data, but it shows the original rather than the variant, so it
will not make your visits appear either.
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 preview mode
as your personal QA workflow: it shows the variant and never writes
data. Visitor opt-out also keeps you out of the data, but it shows the
original experience rather than the variant. ?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. Last modified on August 25, 2026
