Traffic from aocr.org is a bot: how to spot it and filter it out

TL;DR: visits from aocr.org in your analytics aren't real users. They come from a bot that poses as a regular Chrome browser and sends a fake referrer. It has already left 388 sessions across eight of our sites, and on one of the smaller ones it accounted for every sixth session. You can filter it out in your analytics dashboard or on the server, by the Referer header. Don't block IPs, don't rely on robots.txt and don't contact aocr.org.

What it is and how to spot it

The most thorough analysis is tin.computer's write-up from 29 October 2026. It marks three findings as confirmed: the bot's network fingerprint (TLS, HTTP/2, Accept header) matches Bytespider, ByteDance's declared crawler; its session recordings contain timing fields named after Forest, ByteDance's internal resource loader; and a WebRTC leak placed the real machines in China Mobile's data center network in Shanxi. Who runs it is not established: a ByteDance team or a customer of a ByteDance cloud service such as Volcano Engine. The aocr.org site belongs to the American Osteopathic College of Radiology and has nothing to do with any of this. We covered the news side in our nowosci.ai story on the aocr.org bot (in Polish).

Our own analytics tell the same story. As of 7 November, our self-hosted Umami holds 388 sessions with an aocr.org referrer across eight sites, 321 of them on the largest one. According to tin.computer, other site owners have been reporting the bot since about 24 September; in our data the first visits date from 18 September 2026. There were a few dozen sessions until the end of October, then the bot sped up sharply in November, with 206 sessions on 6 November alone. Every visit gives itself away with the same set of traits:

• An aocr.org referrer. The header reads https://www.aocr.org/ and Umami stores it as aocr.org. The requests also carry Sec-Fetch-Site: none, the value a browser sends when an address is typed in or opened by a program; a real click from aocr.org would send cross-site (tin.computer).
• An 800x600 screen, Windows 10, Chrome 146, en-US. In our data almost every session is 800x600 (two were 600x800), and OS, browser and language match in 100% of them. The user agent alone proves nothing, because the bot imitates a regular Chrome.
• One page, about 25 seconds. In 96% of visits the bot sees a single page, the median visit in our Umami lasts 23.6 s, and tin.computer measured about 28 s of waiting and scrolling.
• A new IP on almost every visit, mostly from hosting and proxy networks: Datacamp/CDN77, Web2Objects, M247, Ace Data Centers, NET3. These are the same networks tin.computer listed independently. That's why the US dominates the country report (75% of our sessions), even though it only reflects where the proxies sit.
• The Asia/Shanghai time zone next to a US IP and English language (tin.computer). In PostHog you'll find it in the $timezone property.
• A curiosity from our logs: the fake Referer is attached to every request: CSS and JS files, images, even the analytics call. A normal browser would send your page's address there, so the header comes from the automation, not the browser. That's exactly why filtering on it works.

How to filter it out

• Umami: in your views, add a Referrer filter “is not” aocr.org, without www, because that's how Umami stores the domain. Old visits stay in the database but stop skewing your charts.
• Plausible and Fathom: exclude the referrer www.aocr.org in your filters (tin.computer's advice). Check your sources report to see whether the tool stores the domain with or without www.
• GA4: create a segment that excludes sessions with the source aocr.org (tin.computer's advice).
• PostHog: exclude events where $referring_domain is www.aocr.org. If the bot changes its referrer, tin.computer suggests filtering on $timezone = Asia/Shanghai together with $screen_width = 800.

If you host your analytics yourself, you can stop counting the bot altogether. Since 7 November we've been doing this in nginx in front of Umami: every tracker call (/api/send) whose Referer header points to aocr.org gets an empty 204 response and never reaches the database. Pages stay available; only the counting is blocked. And because a real browser sends your page's address to the tracker, a genuine visitor from aocr.org (should one ever turn up) still gets counted. Here's the minimal version of the rule, with the map block in the http context:

map $http_referer $aocr_referrer {
    default 0;
    "~*^https?://([^/]+\.)?aocr\.org(/|$)" 1;
}

server {
    # ... the server block of your analytics host
    location = /api/send {
        if ($aocr_referrer) { return 204; }
        proxy_pass http://127.0.0.1:3000;  # your Umami upstream
    }
}

Want to stop the bot rather than just not count it? For Cloudflare, tin.computer suggests a WAF custom rule with a Managed Challenge action: the Accept header contains image/heif,image/avif and there is no sec-ch-ua header. A second, simpler rule checks whether the http.referer field contains aocr.org. Before you switch the challenge on, look at what the rule catches: tin.computer recommends starting in log mode, if your plan includes it. The author also notes that the fingerprint rule hits the declared Bytespider along the way.

What not to do

• Don't block IP addresses. In our server logs, 5,365 bot requests came from 1,020 different addresses, and only 7 of them showed up on more than one day. A blocklist like that is stale before you deploy it. The tin.computer write-up says the same.
• Don't rely on robots.txt. The bot doesn't identify itself as Bytespider, so a Bytespider rule doesn't apply to it. If you want to block it, do it at the CDN or firewall.
• Don't contact aocr.org. It's the website of the American Osteopathic College of Radiology, nothing suggests it was hacked, and tin.computer explicitly asks people not to contact them about this traffic.
• Don't rush to delete history. We kept the old visits in the database and hide them with a filter. If the bot changes its referrer, the raw data will help you track it down by its other traits.

Why it matters for small projects

We measure the bot's share from its first visit on each site. On our largest site that's 0.18% of sessions, because heavy traffic dilutes it. On raba.pl it's already 8.45% (18 of 213), and on openclaw.com.pl 16.3% (7 of 43). If you vibecode side projects and use analytics to decide which one is catching on, this bot adds users who don't exist. The same goes for an agent you give access to your stats. It skews other numbers too: on our largest site it racked up 924 partner banner “views”, and it sent 321 event requests to PostHog. Analytics filters and the nginx rule block no content, only the counting of visits, so this is a few minutes of work that doesn't change who can read your site.

Sources: tin.computer: Getting traffic from aocr.org? That's ByteDance crawling your website.