Digital Ocean Bots in WordPress blockieren

Wenn Ihre GA4-Berichte plötzliche Spitzen aus unbekannten Regionen, identische Sitzungsdauern oder Landingpages zeigen, die niemand teilt, sehen Sie oft Bots, die trotzdem den Analytics-Tag auslösen. Ziel ist nicht, jeden Crawler zu sperren. Ziel ist, den Müll zu entfernen, der Entscheidungen verfälscht, und Googlebot, Bingbot und echte Besucher in Ruhe zu lassen.

Diese Anleitung gilt für WordPress auf einem DigitalOcean-Droplet (oder einem ähnlichen VPS) mit nginx, optional fail2ban, und GA4. Sie behandelt robots.txt, Server-Firewalls, WordPress-Plugins und CDN-Bot-Werkzeuge als getrennte Schichten mit getrennten Aufgaben. Wenn Sie Arbeit an Crawling und Zitierungen über die reine Traffic-Hygiene hinaus brauchen, finden Sie mehr zu den SEO- und GEO-Optimierungsdiensten bei WPPoland.

#Warum schlechte Bots Google Analytics aufblähen

GA4 zählt einen Treffer, wenn ein Browser (oder ein Headless-Browser, der sich wie einer verhält) Ihren Tag ausführt und Ereignisse sendet. Deshalb tauchen drei verschiedene Gruppen an verschiedenen Stellen auf:

• Scraper mit JavaScript und Klickbetrugs-Tools können in GA4 als Sitzungen, Seitenaufrufe und sogar Conversions erscheinen, wenn sie die passenden URLs treffen.
• Einfache HTTP-Scraper führen oft gar kein JavaScript aus, verfehlen GA4 also komplett und laden trotzdem PHP, MySQL und jedes ungecachte Template auf dem Server.
• Benannte Such-Crawler sollten in Server-Logs und in der Search Console auftauchen, nicht als großer Anteil der “Nutzer” in GA4.

Wächst die Gruppe mit JavaScript, driften Akquisitions- und Engagement-Berichte ab. Absprungrate und durchschnittliche Interaktionszeit sehen seltsam aus. Bezahlte und organische Berichte werden verrauscht. Teams fangen an, auf Traffic zu optimieren, der nie etwas kauft.

Typische Formen von schlechtem Traffic (ohne konkrete IPs zu erfinden):

• Hohes Anfragevolumen aus wenigen Cloud-ASNs, ohne Referrer und mit seltsamen User-Agents
• Wiederholte Zugriffe auf /wp-login.php, xmlrpc.php, Abfragen zur Autoren-Auflistung oder alte Plugin-Pfade
• Sitzungen, die nur auf dünnen URLs landen und in unter einer Sekunde abspringen, aber trotzdem page_view-Ereignisse in GA4 erzeugen
• “Organischer” Traffic, der im selben Zeitraum nie zu den Suchanfragen in der Search Console passt

Cloud-Anbieter wie DigitalOcean und AWS hosten viele legitime Seiten. Sie hosten auch Scraper. Diese Überschneidung ist der Grund, warum pauschale Regeln wie “sperre das ganze /16” riskant sind. Setzen Sie auf Quellen, die Sie in Ihren eigenen Logs bestätigt haben, statt auf Listen aus alten Blogartikeln.

#Bot-Traffic in GA4 und Server-Logs erkennen

Eine Änderung ohne Ausgangswert ist Erzählkunst. Erfassen Sie möglichst mindestens sieben Tage als Basis, bei saisonalem Traffic eine volle Geschäftswoche.

#Bot-Traffic in GA4-Berichten erkennen

Bevor Sie nginx oder fail2ban anfassen, bauen Sie eine einfache Vergleichsansicht:

1. Notieren Sie Nutzer, Sitzungen, Sitzungen mit Interaktionen und Aufrufe für die letzten 7 und 28 Tage.
2. Öffnen Sie Traffic-Akquisition und suchen Sie Quellen mit absurdem Engagement (Interaktionszeit nahe null, Absprünge nahe 100 % auf jeder Landingpage).
3. Prüfen Sie Technologie > Browser und Gerät auf leere, unbekannte oder offensichtlich skriptgesteuerte Clients.
4. Sehen Sie unter Landingpage nach Pfaden, die nur Bots mögen (/?author=1, alter Spam in Parametern, nicht existierende Produkt-IDs).
5. Exportieren Sie den Zeitraum oder machen Sie einen Screenshot, damit Sie später Gleiches mit Gleichem vergleichen (gleiche Länge, gleiche Wochentagsmischung).

GA4 entfernt bekannte Bots bereits selbst (dazu der nächste Abschnitt), aber diese Liste erwischt nicht jeden lästigen Client, der JavaScript ausführt. Behandeln Sie GA4 als ein Signal, nicht als das einzige.

#Bot-IPs in nginx-Access-Logs finden

Auf DigitalOcean haben Sie in der Regel nginx-Access-Logs und, falls aktiviert, fail2ban-Jails. Nützliche Prüfungen:

# Häufigste Adressen im letzten Access-Log (Pfad anpassen)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# Pfade, die nach Sondierung aussehen
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -40

# Dominierende User-Agents
awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Gleichen Sie GA4-Spitzen mit den Zeitstempeln in diesen Logs ab. Wenn GA4 um 03:00 UTC springt und das Access-Log dieselben IPs zeigt, die auf xmlrpc.php einhämmern, haben Sie ein Serverproblem, das Analytics-Filter allein nicht lösen.

Notieren Sie während der Spitze auch die CPU-Last und die Länge der PHP-FPM-Warteschlange. Bot-Rauschen, das nie in GA4 ankommt, kann ein kleines Droplet trotzdem erschöpfen.

#Filtert GA4 Bot-Traffic automatisch

Zum Teil. Der Google-Hilfeartikel zu bekanntem Bot-Traffic sagt, dass GA4 Traffic von bekannten Bots und Spidern automatisch ausschließt. Die zugrunde liegende Liste kombiniert Googles eigene Forschung mit der International Spiders and Bots List des Interactive Advertising Bureau (IAB).

Zwei Details dieser Seite sind hier wichtig. Der Ausschluss lässt sich nicht abschalten, und Sie können nicht sehen, wie viel Traffic er entfernt hat. Zeigt GA4 also weiterhin Müll-Sitzungen, standen diese Clients nicht auf der Liste: meist Headless-Browser auf gemieteten Servern, die Ihren Tag wie ein normaler Besucher ausführen. Für Anfragen ohne JavaScript bewirkt der automatische Ausschluss ebenfalls nichts, weil GA4 sie nie erhält.

Diese Lücke behandelt der Rest der Anleitung. GA4 kümmert sich um Crawler, die sich ausweisen; um Clients, die verbergen, was sie sind, müssen sich Ihr Server und Ihr Edge kümmern.

#Bot-IP-Bereiche mit GA4-Datenfiltern ausschließen

Datenfilter in GA4 gibt es in drei Typen: Entwickler-Traffic (Debug-Modus), interner Traffic (nach IP-Adresse oder Bereich) und unerwünschte Hostnamen. Einen Bot-Typ gibt es nicht, also ist der Filter für internen Traffic das einzige IP-basierte Werkzeug.

Er arbeitet in zwei Schritten, die Googles Anleitung zur Definition von internem Traffic beschreibt. Zuerst öffnen Sie unter Admin im Bereich Data collection and modification die Data streams, wählen den Web-Stream, gehen zu Configure tag settings, dann zu Define internal traffic und legen eine Regel an. Passende Ereignisse erhalten einen Parameter traffic_type. Sein Standardwert ist internal, Sie können aber einen eigenen setzen, etwa bot_do, damit sich eine Bot-Regel nie mit Ihrer Büro-Regel vermischt. IP-Bedingungen erlauben exakte Übereinstimmung, beginnt mit, endet mit, enthält, einen CIDR-Bereich oder einen regulären Ausdruck. Im zweiten Schritt legen Sie unter Data filters einen Filter vom Typ Internal Traffic an, der diesen traffic_type-Wert ausschließt.

Grenzen, die Sie kennen sollten, bevor Sie sich darauf verlassen:

• Eine Property kann höchstens 10 Datenfilter haben.
• Jeder Filter ist Testing, Active oder Inactive. Im Teststatus werden passende Ereignisse mit der Dimension Test data filter name markiert, die Sie in Explore prüfen können, bevor etwas entfernt wird.
• Ein aktiver Filter verändert eingehende Daten dauerhaft und wirkt nicht auf historische Daten. Laut Google kann es 24 bis 36 Stunden dauern, bis ein Filter greift.
• Für eine vorübergehende Ansicht ohne Datenverlust verweist Google auf Berichtsfilter.

Eine sicherere Reihenfolge: Lassen Sie eine Bot-IP-Regel eine volle Woche im Teststatus, vergleichen Sie die markierten Sitzungen mit dem, was das nginx-Log für dieselben Adressen zeigt, und schalten Sie erst auf aktiv, wenn der markierte Traffic eindeutig Müll ist. Halten Sie die Regelliste kurz und notieren Sie, wann jeder Bereich hinzukam. Und behalten Sie im Kopf, was dieser Filter ist: eine Korrektur der Berichte. Die Anfragen treffen weiterhin nginx, PHP und MySQL; GA4 zählt sie nur nicht mehr.

#Prüfen, wem eine IP gehört, bevor Sie sie sperren

Eine einzelne Adresse im Log sagt wenig, solange Sie nicht wissen, wer sie ankündigt. whois liefert den Registereintrag. Die Daten-API von RIPEstat zeigt die Routing-Sicht, also das Präfix und das autonome System (AS), das es gerade ankündigt:

whois 5.101.96.1 | grep -iE "orgname|org-name|netname"
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=5.101.96.1"
curl -s "https://stat.ripe.net/data/as-overview/data.json?resource=AS14061"

Als wir die beiden API-Abfragen am 14. Oktober 2026 ausgeführt haben, lieferte RIPEstat das Präfix 5.101.96.0/21, angekündigt von AS14061, und nannte als Inhaber von AS14061 DIGITALOCEAN-ASN, DigitalOcean, LLC. Der Endpunkt network-info ist kostenlos und antwortet für Adressen aus allen regionalen Registern, nicht nur aus RIPE.

Lesen Sie das CIDR-Suffix, bevor Sie einen Bereich irgendwo einfügen. Die Zahl nach dem Schrägstrich zählt die festen Präfix-Bits: Ein /24 umfasst 256 Adressen, ein /16 umfasst 65.536 und ein /14 umfasst 262.144. Eine einzige alte Zeile wie deny from 104.236.0.0/16 sperrt 65.536 Adressen aus, die fast alle nichts mit dem Client zu tun haben, der Sie gestört hat.

#Aktuelle IP-Bereiche von DigitalOcean finden

DigitalOcean veröffentlicht seinen Adressraum als CSV-Datei, verlinkt als DigitalOcean IP Ranges in der Plattform-Dokumentation, und gibt an, dass die Datei automatisch aktualisiert wird. Jede Zeile enthält das Präfix, den Ländercode, die Region, die Stadt und die Postleitzahl.

Am 14. Oktober 2026 enthielt die Datei 1.234 Präfixe, davon 148 IPv6. Nach Ländern entfielen 654 Zeilen auf die USA, 224 auf die Niederlande, 111 auf Deutschland, 90 auf Singapur und 67 auf das Vereinigte Königreich. Diese Streuung ist das praktische Argument gegen pauschales Sperren: In denselben Präfixen laufen Droplets von Agenturen, SaaS-Tools, Uptime-Monitoren, CI-Runnern und gewöhnlichen Unternehmen, neben den Scrapern.

Nutzen Sie die Datei zum Nachschlagen, nicht als Sperrliste. Wenn eine Adresse Ihr Access-Log dominiert, prüfen Sie, ob sie im Adressraum von DigitalOcean liegt:

curl -s -o do-ranges.csv https://www.digitalocean.com/geo/google.csv
python3 -c 'import csv,ipaddress,sys; nets=[ipaddress.ip_network(r[0]) for r in csv.reader(open("do-ranges.csv")) if r]; ip=ipaddress.ip_address(sys.argv[1]); print(any(ip in n for n in nets))' 5.101.96.1

Ein True sagt Ihnen, dass der Client auf einem DigitalOcean-Server läuft. Es sagt nicht, dass er bösartig ist; darüber entscheidet sein Verhalten im Log.

#Kann robots.txt schlechte Bots blockieren

robots.txt ist ein freiwilliges Protokoll. Kooperative Crawler lesen es und lassen gesperrte Pfade aus. Missbräuchliche Clients ignorieren es.

Nutzen Sie robots.txt, um gute Bots zu lenken:

• Schließen Sie Staging-Pfade, Suchergebnis-URLs und Admin-Endpunkte aus, die nicht in den Index sollen
• Gehen Sie sparsam mit crawl-delay und breiten Disallow-Regeln um; zu viel Sperren kann Seiten verstecken, die Sie weiterhin in der Suche wollen
• Legen Sie sensible Bereiche hinter eine Authentifizierung, nicht nur hinter eine Disallow-Zeile

Erwarten Sie nicht, dass eine Disallow-Regel Credential Stuffing auf /wp-login.php stoppt. Eine solche Anfrage schaut praktisch nie in robots.txt nach. Firewall, Ratenbegrenzung und Authentifizierung gehören auf den Server oder an den Edge.

Eine praktische Aufteilung:

#Googlebot prüfen, bevor Sie eine IP sperren

Googlebot über den User-Agent-String zu sperren ist ein klassisches Eigentor. Gefälschte Googlebot-Strings sind verbreitet; der echte Googlebot lässt sich über Reverse-DNS und eine Vorwärtsbestätigung verifizieren. Google beschreibt das Verfahren unter Googlebot überprüfen.

Bevor Sie eine IP sperren, die sich als Googlebot ausgibt:

1. Führen Sie eine Reverse-DNS-Abfrage für die IP aus.
2. Prüfen Sie, ob der Hostname auf eine von Google dokumentierte Domain endet.
3. Lösen Sie den Hostnamen vorwärts auf und bestätigen Sie, dass er die ursprüngliche IP ergibt.
4. Erst dann behandeln Sie den Client als Googlebot (oder eben nicht).

Fügen Sie nie eine Regel wie “sperren, wenn der User-Agent Googlebot enthält” als Sicherheitsmaßnahme hinzu. Sie blockiert den echten Crawler, wenn jemand anderswo den String fälscht, und hält Fälscher mit einem anderen String nicht auf.

Dieselbe Vorsicht gilt für Bingbot und andere benannte Crawler, die Ihnen wichtig sind. Allowlists für verifizierte Crawler-Bereiche nur dann, wenn Sie sie sorgfältig pflegen; für alles andere sind verhaltensbasierte Ratenbegrenzungen besser.

#Bots auf DigitalOcean mit nginx und fail2ban begrenzen

Auf einem typischen LEMP-Droplet ist nginx der günstigste Ort, um Missbrauch abzuwerfen, bevor PHP-FPM und der WordPress-Autoload anlaufen.

#nginx limit_req für wp-login.php und xmlrpc.php

Das Modul ngx_http_limit_req_module begrenzt die Anfragerate pro Schlüssel (meist IP). Ein vorsichtiges Muster für Login und XML-RPC sieht so aus:

# http-Kontext
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=wp_xmlrpc:10m rate=1r/s;

# Beispiele für server / location
location = /wp-login.php {
    limit_req zone=wp_login burst=5 nodelay;
    include fastcgi_params;
    # ... bestehender PHP-Handler ...
}

location = /xmlrpc.php {
    limit_req zone=wp_xmlrpc burst=2 nodelay;
    # Viele Seiten liefern hier 403, wenn sie XML-RPC gar nicht brauchen
}

Stimmen Sie die Raten auf Ihre Basiswerte ab. Eine Redaktion mit vielen Autoren hinter einem gemeinsamen NAT braucht einen höheren Burst als eine Visitenkarten-Website. Protokollieren Sie limit_req-Ablehnungen und achten Sie auf Fehlalarme von den Ausgangs-IPs des Büros.

Weitere nginx-Gewohnheiten, die auf DO-Droplets helfen:

• xmlrpc.php deaktivieren oder stark einschränken, wenn Sie es nicht nutzen
• POST-Anfragen anonymer Clients an admin-ajax.php begrenzen, wenn Plugins das zulassen
• TLS an nginx (oder bei Cloudflare) terminieren und in der DigitalOcean-Cloud-Firewall nur die nötigen Ports offen lassen

#fail2ban-Jails für WordPress-Login und Sondierungspfade

fail2ban beobachtet Logs und setzt vorübergehende Firewall-Sperren, wenn ein Filter anschlägt. Typische WordPress-Jails beobachten nginx-Logs auf wiederholte 401/403/404 bei Login- und Sondierungspfaden. Halten Sie Jails eng:

• Sperren Sie für Minuten oder Stunden, nicht für immer, bis Sie dem Filter vertrauen
• Nehmen Sie Ihr Büro-VPN und Monitoring-Dienste aus
• Prüfen Sie erneut nach WordPress- oder Plugin-Updates, die Log-Formate ändern

fail2ban ist hervorragend gegen laute Scanner. Es ist ein schwacher Ersatz dafür, einen offenen Plugin-Endpunkt zu reparieren, der auf jede Sondierung 200 antwortet.

#Welche Ports in der DigitalOcean-Cloud-Firewall öffnen

Nutzen Sie die DO-Firewall (oder ein Gegenstück), um 22/80/443 nur dann weltweit zu öffnen, wenn es sein muss, und bevorzugen Sie schlüsselbasiertes SSH von bekannten IPs. Netzwerksperren stoppen Pakete vor nginx. Sie sollten trotzdem nicht “sperre jedes DigitalOcean-/16 der Welt” lauten, denn das trifft Kunden, Agenturen und CI-Runner beim selben Anbieter.

#Stoppen WordPress-Firewall-Plugins Bot-Traffic

Plugins wie Wordfence, Sucuri und solide Sicherheitspakete bringen Login-Schutz, Malware-Scans und Anwendungsregeln. Sie helfen. Sie laufen aber erst, nachdem nginx die Verbindung angenommen hat und PHP gestartet ist.

Einschränkungen, die für die Analytics-Bereinigung zählen:

• CPU-Kosten: Jede blockierte Anfrage hat trotzdem einen PHP-Start bezahlt, sofern nichts sie früher abgewiesen hat.
• Fehlalarme: Aggressive Regeln wie “unbekannte Länder sperren” oder “alle Cloud-ASNs sperren” können Freelancer, Agenturen und Zahlungsanbieter aussperren.
• Überschneidung mit der Edge-WAF: Doppelte Regeln bei Cloudflare und im Plugin erschweren die Fehlersuche, wenn ein legitimer Nutzer zweimal geprüft wird.
• Log-Rauschen: Plugin-Logs und GA4 stimmen nicht überein, weil sie verschiedene Schichten sehen.

Die Hinweise aus dem WordPress-Härtungshandbuch gelten weiter: Core und Plugins aktuell halten, Datenbanknutzern nur minimale Rechte geben und Dateiberechtigungen einschränken. Ein Firewall-Plugin ersetzt diese Grundlagen nicht.

Praktische Reihenfolge:

1. Offene Endpunkte und schwache Zugangsdaten beheben.
2. nginx-Ratenbegrenzung und fail2ban für laute Pfade einrichten.
3. Eine WordPress-Firewall für anwendungsbezogene Regeln und Warnungen ergänzen.
4. Cloudflare-Bot-Werkzeuge hinzunehmen, wenn Sie das CDN bereits nutzen.

#Bots mit Cloudflare blockieren, bevor sie WordPress erreichen

Liegt die Seite hinter Cloudflare, nutzen Sie deren Bot-Dokumentation, statt auf dem Server eigene User-Agent-Sperrlisten zu erfinden. Edge-Regeln können:

• Offensichtlich automatisierten Traffic prüfen oder blockieren, bevor er DigitalOcean erreicht
• Bestimmte Pfade begrenzen (/wp-login.php, /xmlrpc.php)
• Verifizierte Suchmaschinen-Bots durchlassen, wenn Sie das sorgfältig konfigurieren

nginx-Regeln auf dem Server bleiben als zweite Verteidigungslinie wichtig, falls jemand den Proxy umgeht (graue Wolke im DNS, direkte Server-IP). Im vollen Proxy-Modus sperren Sie die Droplet-Firewall so, dass nur die IP-Bereiche von Cloudflare (oder Ihre Admin-IPs) Port 80/443 erreichen.

Cloudflare macht GA4 nicht von selbst genau. Es reduziert missbräuchliche Zugriffe, die Tags ausgeführt oder PHP erschöpft hätten. Messen Sie nach Änderungen an Bot Fight Mode oder WAF-Regeln sowohl die Edge-Analyse als auch GA4, denn Prüfungen können auch verändern, wie echte Nutzer eine Sitzung abschließen.

#DigitalOcean-Traffic mit Cloudflare-WAF-Custom-Rules prüfen

WAF-Custom-Rules von Cloudflare können das Netz abgleichen, aus dem eine Anfrage kommt. Das Feld heißt ip.src.asnum und enthält die AS-Nummer der Client-IP; das Netz von DigitalOcean ist AS14061. Eine Regel auf das AS ersetzt die Pflege von 1.234 Präfixen von Hand.

Halten Sie den Geltungsbereich eng. Eine Regel, die DigitalOcean-Traffic nur auf den von Bots missbrauchten Pfaden erfasst, sieht so aus:

(ip.src.asnum eq 14061 and http.request.uri.path in {"/wp-login.php" "/xmlrpc.php"})

Wählen Sie als Aktion Managed Challenge, nicht Block. Ein Mensch, der über ein VPN auf einem Droplet arbeitet, besteht die Prüfung; ein einfaches Skript meist nicht. Block beendet die Anfrage, und weil Cloudflare Custom Rules der Reihe nach auswertet, stoppt es für diese Anfrage auch alle späteren Custom Rules.

Wie viele solcher Regeln Sie sich leisten können, hängt vom Tarif ab. Cloudflare nennt 5 Custom Rules im Free-Tarif, 20 in Pro, 100 in Business und 1.000 in Enterprise, den Regex-Operator nur in Business und Enterprise. In einer kostenlosen Zone lässt eine Regel für die ASN-Prüfung auf Login-Pfaden vier Regeln für Probleme übrig, die Sie auf dem Server nicht lösen können.

#IP-Bereiche von DigitalOcean und AWS sperren oder nicht

Ältere Ratschläge kopierten lange deny from-Listen für ganze DigitalOcean- oder AWS-Bereiche in die .htaccess. Dieser Ansatz altert schlecht:

• Die Bereiche der Anbieter ändern sich
• Legitimer Traffic teilt sich diese Bereiche
• Die Apache-Syntax deny bewirkt nichts, wenn Sie WordPress über nginx ohne Apache ausliefern

Wenn Sie weiterhin Apache nutzen, bevorzugen Sie bestätigte Einzeladressen oder kleine CIDR-Blöcke aus Ihren Logs statt einer kopierten Riesenliste:

# Nur ein Formbeispiel - durch IPs ersetzen, die Sie in eigenen Logs bestätigt haben
# RequireAll / Require hängen von der Apache-2.4-Autorisierungssyntax ab
<RequireAll>
    Require all granted
    # Require not ip 203.0.113.10
</RequireAll>

Unter nginx nutzen Sie deny in einem geo/map-Block oder fail2ban und hinterlassen einen kurzen Kommentar mit Datum und Grund der Sperre. Prüfen Sie Sperren vierteljährlich.

Veröffentlichen oder verwenden Sie nie Tabellen mit “bekannten Bot-IPs” aus zufälligen Beiträgen ohne Prüfung. Sie veralten und verursachen Kollateralschäden.

Wo IP-Sperren an ihre Grenzen stoßen, zeigte der Angriff auf Read the Docs im Juni 2026, den David Fischer am 8. September 2026 beschrieben hat. In der Spitze kamen über 5,5 Millionen Requests pro Minute an, etwa das 100-Fache des normalen Traffics, fast zehn Tage lang, von Millionen eindeutiger IP-Adressen aus Hunderten von Netzen (ASNs). Die Angreifer zielten auf ungecachte 404-Pfade und 302-Weiterleitungen; das Team verlegte die Weiterleitungen in etwa einer halben Stunde an den Cloudflare-Edge, und den größten Unterschied machte laut Fischer wahrscheinlich eine “Penalty Box”-Regel, die Clients mit vielen 404- oder Redirect-Antworten drosselt. Sein erstes Fazit lautet: “IP-Sperren sind bei verteilten Angriffen überholt” (eigene Übersetzung), und die härteste Reaktion von Read the Docs ist eine JavaScript-Challenge. Für WordPress gilt dieselbe Logik: Cachen Sie 404-Antworten und Weiterleitungen am Edge und drosseln Sie verdächtige Clients, statt ganze Cloud-Bereiche zu sperren.

#In GA4 prüfen, ob der Bot-Traffic gesunken ist

Warten Sie nach dem Einführen von Begrenzungen oder Sperren ebenso lange wie der Basiszeitraum (7 oder 28 Tage). Vergleichen Sie dann:

1. Nutzer / Sitzungen / Sitzungen mit Interaktionen: Achten Sie darauf, dass das Müllvolumen sinkt, während Sitzungen mit Interaktionen gleich bleiben oder steigen.
2. Landingpages: Sondierungs-URLs sollten in GA4 schrumpfen, wenn diese Clients JS ausgeführt haben; in den nginx-Logs sollten sie in jedem Fall schrumpfen.
3. Traffic-Akquisition: Rätselhafte Quellen ohne Engagement sollten zurückgehen.
4. Server-Metriken: Belegte PHP-FPM-Worker und 5xx-Raten außerhalb der Geschäftszeiten sollten sich entspannen, wenn der Missbrauch am Server real war.
5. Search Console: Crawling-Statistiken und Abdeckung sollten nicht einbrechen. Tun sie es doch, haben Sie wahrscheinlich einen echten Crawler gesperrt; machen Sie die Änderung rückgängig und verifizieren Sie Googlebot korrekt.

Vermerken Sie das Änderungsdatum in GA4 (Admin > Anmerkungen oder im Änderungsprotokoll Ihres Teams), damit Sie später wissen, was die Kurve bewegt hat.

Wenn sich GA4 kaum bewegt, aber die nginx-Ablehnungen steigen, haben die Bots Ihren Tag nie ausgeführt. Für die Servergesundheit ist das trotzdem ein Gewinn, auch wenn die Analytics-Kurve ruhig aussieht.

Fällt GA4 stark und steigen die Crawling-Fehler in der Search Console, nehmen Sie zuerst die letzte Deny-Regel zurück. Saubere Analytics sind wertlos, wenn die Indexierung kaputtgeht.

#Checkliste gegen Bot-Traffic in WordPress

Gehen Sie sie der Reihe nach durch:

1. GA4-Basis (7/28 Tage) erfassen und eine Stichprobe der nginx-Access-Logs ziehen.
2. Klären, ob das Rauschen JS ausführt (GA4) oder nur den Server trifft (Logs).
3. Ratenbegrenzung für xmlrpc.php und Login in nginx verschärfen.
4. fail2ban-Jails für wiederholte Sondierungen einrichten; eigene IPs ausnehmen.
5. robots.txt auf Crawler-Hinweise beschränken, nicht auf Sicherheitstheater.
6. Eine WordPress-Firewall hinzufügen oder abstimmen, ohne ganze Cloud-Anbieter zu sperren.
7. Optional Cloudflare-Bot- und WAF-Kontrollen aktivieren, wenn die Seite Cloudflare bereits nutzt.
8. GA4 und Logs über einen vergleichbaren Zeitraum neu messen; Search Console im Blick behalten.

Wenn Sie Crawler-Rauschen, Serverregeln und Analytics-Hygiene gemeinsam mit breiterer SEO- und GEO-Arbeit prüfen lassen wollen, ist das sinnvoller, als ewige Sperrlisten ins WordPress-Stammverzeichnis zu kopieren. Entdecken Sie auch unsere WordPress-Entwicklungsdienste, um Ihr Projekt voranzubringen.