> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Your own visits show up as blocked

> You are testing on your live site, but your data does not appear in the results. The most likely cause: you or your office is on the site's blocked-IP list.

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](/settings/blocked-ips).

## Check

**Site → Settings → Blocked IPs.** Look at the rules. Any of them
match your current public IP?

Your current public IP:

```
https://www.google.com/search?q=what+is+my+ip
```

If yes: you added yourself. Remove yourself from the list, or use
the [visitor opt-out URL](/install/opt-out) instead, which is
per-browser rather than per-IP.

## The debugger sanity check

Open DevTools on your site and run:

```js theme={null}
window.__abtestly.debug()
```

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](/install/opt-out) 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.