WordPress-Websites ohne Analyse-Tools erkennen: So stoppen Sie unsichtbare Bots

Ein Kunde beschwert sich seit Wochen über langsame Ladezeiten seiner WordPress-Website – doch alle gängigen Analysetools wie Google Analytics oder PageSpeed Insights zeigen keine Auffälligkeiten. Serverauslastung? Normal. Traffic? Stabil. Plugins? Up-to-date. Was also verursacht die Performance-Probleme?

Die Lösung lag in einer Kategorie von Traffic, die Standard-Analysewerkzeuge grundsätzlich übersehen: unsichtbare Bots und automatisierte Skripte, die ohne Browser auf die Seite zugreifen. Nach einer detaillierten serverseitigen Analyse zeigte sich ein alarmierendes Bild – und eine einfache Lösung, um die Website wieder zuverlässig zu betreiben.

Die versteckte Bedrohung: Bots ohne JavaScript-Engine

Moderne Analysetools wie Google Analytics oder Plausible funktionieren nach demselben Prinzip: Sie laden eine JavaScript-Datei in den Browser des Besuchers und sammeln Daten, während die Seite geladen wird. Doch was passiert, wenn ein Besucher gar keinen Browser verwendet?

Genau das war der Fall bei der betroffenen WordPress-Website. Der Kunde berichtete von gelegentlichen, aber schwer reproduzierbaren Ladeverzögerungen. Die Analyse mit dem Tool SysWP Radar – das alle Serveranfragen erfasst, bevor JavaScript überhaupt zum Einsatz kommt – enthüllte eine völlig neue Perspektive: Rund 68.000 Anfragen in einem bestimmten Zeitraum stammten von Quellen, die in den gängigen Analysetools unsichtbar blieben.

Der Hauptverdächtige: Go-http-client/1.1 – ein stiller Ressourcenfresser

Innerhalb dieses „unsichtbaren“ Traffics entpuppte sich ein einzelner Akteur als Hauptproblem: Go-http-client/1.1. Dieser HTTP-Client aus der Programmiersprache Go war für 99 % aller unbekannten Anfragen verantwortlich – insgesamt 67.323 Hits. Das ist kein Zufall, sondern das Ergebnis eines systematischen Web-Scrapings.

Was bedeutet das für die Performance? Jede dieser Anfragen:

• Verbrauchte einen PHP-Worker auf dem Server
• Durchsuchte die Datenbank
• Generierte eine vollständige WordPress-Seitenausgabe

Bei einem typischen Hosting-Plan mit nur vier parallelen PHP-Workern (wie bei vielen Einstiegsangeboten von WP Engine, Kinsta oder Cloudways üblich) führte dies zu einem direkten Wettstreit um Ressourcen. Während der Scraper Anfragen im Sekundentakt stellte, mussten sich echte Besucher die verbleibenden Worker teilen – mit der Folge von verzögerten Antworten oder sogar 503-Fehlern.

Die Konsequenzen gehen über reine Performance-Probleme hinaus:

• Erhöhte Hosting-Kosten, falls der Tarif nach Ressourcenverbrauch abrechnet
• Gefahr von Content-Diebstahl für KI-Training, Wettbewerbsanalysen oder illegale Wiederveröffentlichungen
• Verschlechterung der Core Web Vitals, da die Scraper-Anfragen die Messwerte verzerren

Weitere Angreifer: Spoofed User Agents und Fingerprinting-Tools

Doch das Go-Scraping war nicht das einzige Problem. Im selben Analysezeitraum wurden weitere verdächtige Aktivitäten entdeckt:

• `axios/1.15.0` (308 Hits): Ein HTTP-Client aus dem Node.js-Ökosystem, der ebenfalls für automatisierte Anfragen genutzt wurde.
• Spoofed User Agents (370 Hits): Mehrere Anfragen nutzten scheinbar echte Browser-User-Agents, wiesen aber konsistente Unstimmigkeiten auf:
• Mozilla/5.0 (Mac/Win) ... AppleWebKit/605 ... Safari traf gezielt auf /wp-json/wp/v2/ – ein Muster, das auf Enumeration von WordPress-Rest-API-Endpunkten hindeutet, um Benutzernamen für Brute-Force-Angriffe zu sammeln.
• Mozilla/5.0 AppleWebKit/537.36 ohne Plattformangabe – ein offensichtlicher Versuch, sich als Chrome auszugeben, aber mit inkonsistenter WebKit-Version.
• Mozilla/5.0 (Windows NT 10) AppleWebKit/605 Chrome/X – hier wurde die User-Agent-Zeichenkette falsch kombiniert, was auf ein automatisiertes Tool hindeutet.
• `getwp/1.0 (WP tespit)` (2 Hits): Ein türkisches Tool zur WordPress-Erkennung („tespit“ = „Erkennung“), das gezielt nach WordPress-Installationen und deren Konfigurationen sucht – ein klassisches Reconnaissance-Tool.
• Weitere HTTP-Bibliotheken: curl, wget, python-requests, Apache-HttpClient, Java – alle in unterschiedlichen Kombinationen genutzt, um die Website zu durchsuchen.

Diese Aktivitäten sind kein Einzelfall. Sie zeigen ein ganzes Ökosystem automatisierter Angriffe, das gezielt nach Schwachstellen in WordPress-Websites sucht.

Die konkreten Auswirkungen auf die Performance

Um die Tragweite zu verdeutlichen: Stellen Sie sich einen Einstiegs-Hosting-Plan mit vier parallelen PHP-Workern vor. Während der Scraper aktiv war:

1. Sendete er Anfragen schneller, als WordPress antworten konnte.
2. Jede Anfrage besetzte einen PHP-Worker für die Dauer der Seitenausgabe.
3. Mit vier Workern belegt, hatten echte Besucher keine Chance, ihre Anfragen zu verarbeiten.
4. Die Folge: Verzögerte Ladezeiten, Timeouts oder 503-Fehler – während Google Analytics nichts davon mitbekam.

Der Grund? Die Scraper nutzten kein JavaScript, sodass die Standard-Analysetools keinerlei Daten aufzeichneten. Die Ladeprobleme erschienen als „intermittierende Performance-Probleme“ – ein klassisches Symptom für unsichtbare Bots.

Warum herkömmliche Analysetools blind für diese Angriffe sind

Der Kern des Problems liegt in der Architektur moderner Webanalyse. Tools wie Google Analytics, Fathom oder Plausible basieren auf clientseitigem JavaScript. Das bedeutet:

• Bots ohne JavaScript-Engine bleiben vollständig unsichtbar.
• Anfragen an API-Endpunkte (z. B. /wp-json/wp/v2/) oder direkte Zugriffe auf /xmlrpc.php erzeugen keine Tracking-Daten, da die Seite nie vollständig geladen wird.
• Geblockte oder vorzeitig abgebrochene Anfragen werden nicht erfasst.

In diesem konkreten Fall war der Go-Scraper für 67.000 unsichtbare Anfragen verantwortlich – während die Analyse-Tools nur die „normalen“ Besucher erfassten. Die Diskrepanz zwischen den gemeldeten Problemen und den Analyseergebnissen war damit erklärt.

Wie Sie unsichtbare Bots erkennen und blockieren können

Die Lösung ist einfach, aber erfordert einen Paradigmenwechsel: Verlassen Sie sich nicht ausschließlich auf clientseitige Analyse-Tools. Stattdessen sollten Sie serverseitige Logging-Systeme nutzen, um ein vollständiges Bild des Traffics zu erhalten. Hier sind die wichtigsten Schritte:

1. Server-Log-Analyse: Nutzen Sie Tools wie SysWP Radar, AWStats oder GoAccess, um alle eingehenden Anfragen zu prüfen – bevor JavaScript oder PHP zum Einsatz kommen.

1. User-Agent-Filterung: Identifizieren Sie verdächtige User Agents wie Go-http-client/1.1, axios oder spoofed Browser-Signaturen. Diese können Sie gezielt blockieren.

1. Rate-Limiting und Firewall-Regeln: Richten Sie automatische Sperren für IP-Adressen ein, die zu viele Anfragen in kurzer Zeit stellen.

1. WordPress-spezifische Schutzmaßnahmen:

• Deaktivieren Sie XML-RPC, falls nicht benötigt.
• Schützen Sie die REST-API mit Plugins wie „Disable REST API“ oder „WP Cerber Security“.
• Nutzen Sie Sicherheits-Plugins wie Wordfence oder Sucuri, um bösartige Aktivitäten zu erkennen.

1. Hosting-Optionen prüfen: Falls Ihr Hosting-Anbieter serverseitige Analyse-Tools anbietet (z. B. Kinsta’s „Activity Log“ oder WP Engine’s „Global Edge Security“), nutzen Sie diese, um verdächtigen Traffic frühzeitig zu erkennen.

Ein proaktiver Ansatz hilft nicht nur, Performance-Probleme zu lösen, sondern schützt auch vor Content-Diebstahl, Brute-Force-Angriffen und anderen Bedrohungen.

Fazit: Sichtbarkeit schafft Kontrolle

Langsame WordPress-Websites sind oft das Ergebnis unsichtbarer Angriffe, die herkömmliche Analyse-Tools einfach ignorieren. Die Lösung liegt nicht in teureren Hosting-Plänen oder zusätzlichen Plugins, sondern in einem bewussten Blick auf die Server-Logs.

Indem Sie serverseitige Analysen mit gezielten Schutzmaßnahmen kombinieren, können Sie nicht nur die Performance Ihrer Website verbessern, sondern auch Sicherheitslücken schließen, bevor sie zu ernsthaften Problemen führen. Der erste Schritt? Hören Sie auf Ihren Server – nicht nur auf Ihre Analytics.