aocr.org als Referrer in Matomo? Das steckt hinter dem Fake-Traffic

Wer in Matomo, Google Analytics oder anderen Webanalytics-Tools seit einigen Wochen plötzlich Zugriffe mit dem Referrer "www.aocr.org" sieht, stellt sich zu Recht die Frage: Was hat ein amerikanisches Radiologie-Kolleg mit meinem Blog zu tun? Die Antwort: eigentlich nichts. Die Besuche stammen nämlich nicht von echten Menschen und die Website hat auch keinen Link auf dich gesetzt. Es handelt sich um eine Crawler-Kampagne mit gefälschtem Referrer-Header, die seit etwa dem 24. September 2026 weltweit tausende Websites trifft.

Was ist aocr.org überhaupt?

Die Domain gehört zum American Osteopathic College of Radiology, einer echten medizinischen Fachorganisation in Missouri, USA. Sie hat mit dem Traffic auf deinen Seiten nichts zu tun: Auf aocr.org existiert kein Link zu den betroffenen Seiten, und es gibt keine Hinweise auf einen Hack der Organisation. Wer den Crawler betreibt, hat sich schlicht einen seriös klingenden Domainnamen ausgeliehen – vermutlich, weil eine bekannte Institution in einem Referrer-Bericht glaubwürdiger wirkt als eine frisch registrierte Spam-Domain.

Wie der Fake funktioniert

Technisch ist das Prinzip simpel: Der Referer-Header einer HTTP-Anfrage ist ein clientseitig gesetztes Feld, das jeder Bot beliebig fälschen kann. Der Crawler sendet bei jedem Aufruf https://www.aocr.org/ als Referrer mit – ohne dass je ein echter Klick stattgefunden hat.

Beweisen lässt sich das an den Request-Headern: Die Anfragen enthalten Sec-Fetch-Site: none. Ein Browser sendet diesen Wert, wenn jemand eine Adresse direkt eintippt – bei einem echten Klick von einer anderen Website müsste dort cross-site stehen. Da der Crawler zudem JavaScript ausführt, indem er einen Headless-Browser wie Playwright oder Puppeteer nutzt, landen die Besuche auch in Matomo – und nicht nur in den Serverlogs. Analysen in Apache-Access-Logs bestätigten die Requests tatsächlich auf dem Webserver: Ein Betreiber zählte über 46.000 HTTP-Anfragen mit dem gefälschten Referrer.

Wer dahintersteckt: Spuren führen zu ByteDance

Die detaillierteste Analyse stammt von Tin Analytics, die den Crawler auf mehreren Websites untersucht haben. Ihre Befunde:

• Der Crawler hat dasselbe Netzwerk-Fingerprint wie Bytespider, der deklarierte Crawler von ByteDance. Nur 0,08 Prozent des übrigen Traffics teilt dieses Muster.
• Der verwendete Browser enthält interne Timing-Felder mit dem Namen von „Forest", BytDances internem Resource-Loader – ein normales Chrome besitzt diese Felder nicht.
• Die echten Server stehen in einem China-Mobile-Rechenzentrum in der Provinz Shanxi, China – getarnt als Windows-Rechner mit Mac-Grafikkarte.

Wer den Crawler exakt betreibt, ist allerdings nicht bewiesen – es könnte ein ByteDance-Team oder auch ein Kunde der ByteDance-Technologie (etwa über Volcano Engine) sein. Japanische und internationale Analysen vermuten dahinter vor allem das Sammeln von Trainingsdaten für KI-Modelle oder auch für einen Suchindex.

Woran du die Besuche erkennst

Die typische Signatur der Kampagne ist auffällig einheitlich:

• Ein einziger Seitenaufruf pro Sitzung, danach Schluss – Bounce-Rate nahe 100 Prozent
• User-Agent: Chrome 146 auf Windows 10, Desktop
• Bildschirmauflösung 800 × 600, Zeitzone Asia/Shanghai
• Überwiegend US-IP-Adressen aus gemieteten Proxy-Netzwerken (Datacamp, M247, EGIHosting und andere) – pro Besuch oft eine neue Adresse
• Zugriffe verteilen sich gleichmäßig über viele Artikel statt auf eine einzelne Seite

Genau das erklären auch andere betroffene Betreiber: 43 angebliche "Besucher" mit aocr.org-Referrer erzeugten 46 Seitenaufrufe, alle aus den USA, alle Windows, alle Chrome.

Was du jetzt tun solltest

Zunächst die Beruhigung: Der Traffic ist natürlich kein Sicherheitsproblem. Es gab von diesem Traffic keine Login-Versuche, keine Uploads und keine ungewöhnlichen Request-Methoden. Auch die Serverlast ist bei gecachten Seiten vernachlässigbar. Deine konkreten Optionen:

In Matomo filtern (empfohlen): Lege ein Segment für die Referrer-Quelle aocr.org an, um die Besuche in deinen Berichten auszublenden – so vergleichst du saubere Daten, ohne die Rohdaten zu löschen. Prüfe im Besucherprotokoll die aufgezeichneten Aktionen und Zeitpunkte, um das Muster zu bestätigen.

Serverseitig blocken (optional): Wenn dich die Requests stören, kannst du sie auf Webserver-Ebene selbstverständlich auch per Rewrite-Regel mit HTTP 403 abweisen:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^https?://(www.)?aocr.org(/|$) [NC]
RewriteRule ^ - [F,L]

Bei Cloudflare funktioniert hingegen alternativ eine WAF-Regel mit http.referer contains "aocr.org" oder – dauerhafter – ein Fingerprint-Filter, der auf die ungewöhnliche Accept-Header-Kombination und fehlende Client Hints zielt.

Was hingegen nicht funktioniert sind IP-Blocklisten. Der Crawler nutzt für jeden Besuch in der Regel eine neue Proxy-Adresse, blockierst du einzelne IPs, rennst du einem rotierenden Pool hinterher. Auch robots.txt hilft nicht, weil sich der Crawler nicht als Bytespider identifiziert. Und ein Disavow ist sinnlos, da gar kein echter Link existiert – ein Referrer ist nur ein Header, kein Hyperlink.

Fazit

Die "Besucher" mit aocr.org-Referrer sind üblicher Bot-Traffic und kein Angriff: Ein verkappter Crawler, der vermutlich Trainingsdaten sammelt, mit einem fremden seriösen Domainnamen als Tarnung durch US-Proxys auf deine Seite kommt. Die sauberste Lösung ist ein Filter in Matomo; blocken auf Server- oder CDN-Ebene ist optional. Wenn das Muster eines Tages verschwindet, hilft das Wissen um den Fingerprint weiter – der bleibt auch erhalten, wenn der Betreiber den Referrer wechselt.