Dokumentation: Bot-Schutz

Bot-Schutz: Maschinen, Keine Menschen

Ein "Bot" ist ein Programm, das automatisch, ohne menschliches Zutun, auf Ihre Website zugreift. Manche Bots sind gut (Google), andere sind bösartig (Spam, Scraping, Angriffe).

Der Bot-Schutz von SeenSecure erkennt, ob es sich beim Zugriff wirklich um einen Menschen oder eine Maschine handelt. Handelt es sich um einen bösartigen Bot, wird er blockiert. Handelt es sich um einen guten Bot (Googlebot), wird er durchgelassen.

Hinweis: Nicht alle Bots sind schlecht. Google benötigt Zugriff, um zu indexieren. SeenSecure unterscheidet zwischen guten und schlechten Bots.

Bot-Typen

Legitime Bots (Erlaubt)

Bot	Zweck	Vorteil
Googlebot	Indexiert für die Google-Suche	Ihre Website erscheint bei Google
Bingbot	Indexiert für die Bing-Suche	Ihre Website erscheint bei Bing
Facebook Crawler	Ruft Metadaten zum Teilen ab	Links auf Facebook zeigen eine Vorschau
Slack Bot	Ruft Metadaten für Slack ab	Links in Slack zeigen Infos

Bösartige Bots (Blockiert)

Scraper: Kopieren Ihre Inhalte
Brute-Force-Bots: Probieren automatisch Passwörter aus
Spam-Bots: Veröffentlichen Spam in Kommentaren
DDoS-Bots: Senden Tausende von Anfragen, um die Website lahmzulegen
Malware-Bots: Suchen nach Schwachstellen
Proxy-Rotations-Bots: Verbergen ihre Identität, um Sperren zu umgehen

Zweideutige Bots (Kontextabhängig)

Manche Bots sind nicht eindeutig gut oder schlecht. Beispiel:

Pingdom: Legitime Uptime-Überwachung
Generische Crawler: Könnten Forschungszwecken dienen oder bösartig sein
SEO-Tools: Analysewerkzeuge (legal, aber aggressiv)

Schicht 1: Identitätsfilterung

Die erste Schicht analysiert kein Verhalten und wartet nicht ab, was der Besucher tut — sie urteilt anhand dessen, was die Anfrage selbst über sich aussagt, noch bevor WordPress überhaupt lädt. Sie ist am günstigsten auszuführen (keine Datenbankabfragen, keine Berechnungen), weshalb sie zuerst kommt: Sie verwirft offensichtlich automatisierten Datenverkehr in Mikrosekunden und überlässt den teureren Schichten nur das, was diesen ersten Filter bereits passiert hat.

User-Agent-Blockliste

Jeder Besucher (Mensch oder Maschine) sendet einen User-Agent-Header, der angibt, welche Software verwendet wird. Ein echter Browser sendet etwas wie Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36. Viele automatisierte Scraping- und Angriffswerkzeuge verwenden dagegen ihren echten Namen ohne Verschleierung — entweder weil der Programmierer nie daran gedacht hat, ihn zu verbergen, oder weil das Ändern des User-Agents bei manchen Tools zusätzliche Konfiguration erfordert, die fast niemand vornimmt.

Echter Browser:   Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Legitimer Bot:    Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Tool:             python-requests/2.25.1
Tool:             curl/7.68.0
Tool:             Scrapy/2.5.0 (+https://scrapy.org)
Leer:             (kein User-Agent-Header vorhanden)

SeenSecure führt eine Liste von 21 bekannten Signaturen für Scan- und Pentest-Tools (sqlmap, Nikto, Nmap, masscan, Metasploit, Hydra usw.) und blockiert die Anfrage, sobald der User-Agent übereinstimmt — bevor weitere Ressourcen für die Analyse aufgewendet werden.

HTTP/1.0-Blockierung

HTTP hat mehrere Protokollversionen. HTTP/1.0 aus dem Jahr 1996 ist die älteste und wird von praktisch keinem modernen Browser mehr verwendet — Chrome, Firefox, Safari und Edge handeln automatisch HTTP/1.1, HTTP/2 oder HTTP/3 mit dem Server aus. Meldet sich eine echte Anfrage als HTTP/1.0, stammt sie fast sicher nicht von einem echten Browser, sondern von einem einfachen Skript mit einer minimalen Bibliothek, die ihre Standard-Protokollversion nie aktualisiert hat.

Fehlender oder inkonsistenter Sprach-Header

Ein echter Browser sendet immer den Header Accept-Language, der angibt, in welcher Sprache er Inhalte bevorzugt (festgelegt vom Betriebssystem oder Browser selbst). Ein handgeschriebenes Skript fügt ihn fast nie hinzu — wem es nur darum geht, Daten zu extrahieren oder auf Schwachstellen zu testen, ist egal, in welcher Sprache der Server antwortet. Sein vollständiges Fehlen ist daher ein starkes Signal für nicht-menschlichen Datenverkehr.

Und nicht nur das Fehlen zählt: Die angegebene Sprache wird auch mit dem Herkunftsland der IP verglichen (per Geolokalisierung). Ein Besucher, der "zh-CN" (Chinesisch) angibt, aber von einer privaten IP in einem Land verbindet, in dem diese Sprache selten ist, folgt einem typischen Muster von Datenverkehr, der über einen schlecht konfigurierten Proxy oder VPN geleitet wird — das beweist für sich genommen nichts, erhöht aber zusammen mit den übrigen Signalen dieser Schicht den Verdachtswert.

Kein einzelnes Signal entscheidet allein. Keiner dieser vier Schicht-1-Checks blockiert für sich allein, außer der User-Agent-Blockliste (Übereinstimmung = sofortige Blockierung, da es sich um eine bekannte Signatur handelt). Die übrigen erhöhen einen Verdachtswert, der mit Schicht 2 und 3 kombiniert wird, bevor irgendetwas entschieden wird — so wird vermieden, z. B. einen echten Nutzer zu blockieren, der seinen Browser nur ungewöhnlich konfiguriert hat.

Anti-Bot-URL-Ausschlüsse (Externe Crons und Skripte)

Wofür? Einige automatisierte Aufgaben rufen nicht über einen echten Browser Ihre Website auf, sondern eine konkrete URL von einem anderen Server aus: ein Cron, der jede Nacht /planung/script_general_diario.php aufruft, ein Webhook eines Zahlungsanbieters, ein Synchronisationsskript usw. Diese Anfragen senden den Header Accept-Language nicht, daher hält Schicht 1 sie fälschlich für Bots und blockiert sie. Dieses Feld erlaubt es Ihnen, der Firewall zu sagen: «wende Anti-Bot auf diese konkreten Pfade nicht an, sie sind legitim».

Empfohlen (sicherer): Bevor Sie eine URL ausschließen, ziehen Sie in Betracht, die IP des Servers, der den Cron ausführt, zur Whitelist hinzuzufügen (Firewall › IP-Verwaltung › Whitelist). Diese IP wird als «vertrauenswürdig» markiert und umgeht die gesamte Firewall, ohne den Pfad für andere zu öffnen. Ein Angreifer kann diese vertrauenswürdige IP niemals nutzen, um Anti-Bot zu umgehen. Wenn die IP des aufrufenden Servers fest ist, verwenden Sie immer diese Option.

Nur wenn Sie die IP nicht festlegen können: Das Feld für URL-Ausschlüsse ist die Alternative für Fälle, in denen der aufrufende Server keine feste IP hat. Der Ausschluss eines Pfads öffnet eine Tür: Ein Angreifer könnte Traffic an diesen Pfad senden, und Schicht 1 würde ihn nicht stoppen. Die anderen WAF-Schichten gelten weiterhin. Deshalb: Schließen Sie nur das Notwendigste aus, niemals /.

So Finden Sie den Genauen Pfad zum Ausschließen

Öffnen Sie Firewall › Protokolle › Traffic Log und suchen Sie die blockierte Zeile.
Kopieren Sie den Pfadteil aus der Spalte Request, z. B. /planung/script_general_diario.php.
Fügen Sie ihn ins Feld «Anti-Bot-URL-Ausschlüsse» ein, einen Pfad pro Zeile, und speichern Sie Schicht 1.

Der Platzhalter * wird unterstützt (z. B. schließt /cron/* alles unter /cron/ aus) sowie Präfix-Treffer. /wp-cron.php ist bereits standardmäßig ausgeschlossen.

Wie die Sicherheit Bleibt

WAF, Rate-Limiting, IP-Listen, DNS-Crawler-Verifizierung und Login-Validierung schützen diese URL weiterhin. Nur die automatisierte Schicht-1-Prüfung wird gelockert.

Keine Verlangsamung

Ausschlüsse werden in Millisekunden gegen eine Liste im Speicher geprüft. Keine Auswirkung auf die Leistung.

Schicht 2: Browser-Fingerabdruck

Ein raffinierterer Angreifer verwendet kein einfaches curl-Skript — er nutzt einen Headless-Browser (echtes Chrome oder Firefox, aber per Code statt von einem Menschen gesteuert, ohne sichtbare Oberfläche), genau um Schicht 1 problemlos zu passieren: Der User-Agent ist identisch mit dem eines normalen Chrome, die HTTP-Version stimmt, und er kann sogar Accept-Language senden. Schicht 2 existiert, um genau diesen Fall zu erkennen, indem sie Browser-Eigenschaften betrachtet, die Automatisierungssoftware offenlegt, selbst wenn sie versucht, als normaler Browser durchzugehen.

Was der Angreifer erreichen will: massenhaftes Scraping von Inhalten, das Testen gestohlener Zugangsdaten gegen das Login-Formular oder automatisiertes Ausfüllen von Formularen (Spam, Betrug) — und das alles unter Ausführung von echtem JavaScript wie ein echter Nutzer, was ein einfaches Skript ohne Browser nicht kann, ein Headless-Browser aber schon.

Wie es funktioniert: Wenn ein Besucher eine geschützte Seite lädt, sammelt ein kleines Skript im Browser eine Handvoll technischer Merkmale — ob er auf Canvas- und WebGL-Anfragen (Grafik) reagiert, welche Plugins installiert sind, die tatsächliche Bildschirmauflösung, die Reihenfolge, in der HTTP-Header eintreffen, und wie schnell er reagiert. Jedes trägt zu einem Wert von 0 bis 100 bei: Ein normaler Mensch mit echtem Browser erzielt einen hohen Wert; ein Headless-Browser ohne grafische Oberfläche scheitert an mehreren dieser Prüfungen gleichzeitig und erzielt einen niedrigen Wert.

Reales Beispiel: ein menschlicher Besucher mit normalem Chrome, installierten Plugins und einem 1920×1080-Bildschirm reagiert auf eine Herausforderung in etwa 2 Sekunden — hoher Wert, passiert reibungslos. Ein Bot mit Headless-Chrome, ohne Plugins, ohne WebGL-Unterstützung, reagiert in 0,1 Sekunden — niedriger Wert, die konfigurierte Aktion wird angewendet (protokollieren, CAPTCHA oder blockieren).

Wie Man Sie Aktiviert und Konfiguriert

SeenSecure > Firewall > Anti-Bot > Schicht 2: Bot Fingerprint Analyzer > Aktiviert

Feld	Was es tut
Aktion bei Bot-Erkennung	Nur protokollieren, CAPTCHA erzwingen oder Zugriff direkt blockieren
Mindestpunktzahl	Schieberegler von 0 bis 100: Besucher unterhalb dieses Schwellenwerts gelten als verdächtig
Prüfen bei	Login-Seite und/oder Frontend (Kommentare, öffentliche Formulare)
Erkennungsmodule	5 unabhängige Schalter: Headless-Erkennung, Canvas-Fingerprint, WebGL-Renderer, Timing-Analyse, Feature-Erkennung

Empfehlung: Beginnen Sie einige Tage lang mit der Aktion «Nur protokollieren» und prüfen Sie das Log — so sehen Sie, welche Werte Ihre echten Besucher erzielen, bevor Sie auf Blockieren oder CAPTCHA-Pflicht umstellen. Bemerken Sie legitime Besucher mit niedrigem Wert (sehr minimalistische Browser, aggressive Datenschutz-Erweiterungen, manche Barrierefreiheits-Browser), erhöhen Sie den Schwellenwert vorsichtig oder wechseln Sie zu «CAPTCHA erzwingen» statt direkter Blockierung.

Schicht 2+: Erweiterte Erkennung Menschlichen Verhaltens (PRO)

Warum zusätzlich zum Fingerprint eine weitere Schicht nötig ist: heutige Angriffswerkzeuge können bereits ein visuelles CAPTCHA "lesen" und lösen, auch solche mit verzerrten Buchstaben oder Emojis. Wenn ein Bot bereits weiß, wie er diese Art von Herausforderung löst, wird ein weiteres Signal benötigt, das nicht von der korrekten Lösung einer Aufgabe abhängt. Diese Schicht prüft nicht, ob das CAPTCHA korrekt gelöst wurde, sondern wie sich der Besucher beim Ausfüllen des Formulars verhalten hat. Es ist ein zusätzlicher Schutz, kein Ersatz für Schicht 2 (Fingerprint) — sie ergänzt sie.

Wie es funktioniert: die Maus einer echten Person bewegt sich unregelmäßig, mit kleinen Korrekturen und Pausen — nie in einer perfekt geraden Linie. Beim Tippen gibt es natürliche Rhythmen zwischen den Tastenanschlägen, die nie perfekt gleichmäßig sind. Ein automatisiertes Skript hingegen bewegt die Maus meist in einer geraden Linie zum Feld (oder gar nicht) und tippt mit einem fast immer identischen Abstand zwischen den Anschlägen. Diese Signale fließen in denselben Wert ein, den Schicht 2 bereits berechnet — es ist kein unabhängiger Wert oder eine unabhängige Aktion.

In der Praxis bewiesen: in Tests mit einem echten KI-Assistenten, der einen automatisierten Login versuchte, wurde das visuelle CAPTCHA beim ersten Versuch korrekt gelöst — der Zugriff wurde trotzdem wegen "Sicherheitswert zu niedrig" verweigert, genau das Signal, das diese Schicht erkennen soll.

Wo wird sie angewendet? Standardmäßig nur bei Anmelde- und Registrierungsformularen. Optional kann sie auf jedes Formular der Website ausgeweitet werden (Kontakt, Kommentare und Formulare anderer Plugins wie Contact Form 7 oder WPForms). Ein legitimer Bot wie Googlebot füllt keine Formulare aus: Er durchsucht die Website und indexiert Seiten ganz normal, sodass er diese Prüfung nie durchläuft und nicht betroffen ist, unabhängig davon, welche Option gewählt wird.

Wie Man Sie Aktiviert

SeenSecure > Firewall > Anti-Bot > Schicht 2+: Erweiterte Erkennung Menschlichen Verhaltens > Aktiviert

Nach der Aktivierung fließt sie in den Wert von Schicht 2 ein: Wirkt das Verhalten verdächtig, sinkt der Wert und dieselbe bereits in Schicht 2 konfigurierte Aktion (protokollieren, CAPTCHA oder blockieren) wird angewendet — es gibt keine separate Einstellung zu konfigurieren.

PRO: diese Schicht ist ausschließlich PRO-Plänen vorbehalten. Bei FREE-Websites erscheint der Schalter deaktiviert und gesperrt — der Rest von Schicht 2 (Fingerprint) funktioniert weiterhin normal.

Schicht 3: Crawler-Verifikation

Jeder kann "Googlebot" in seinen User-Agent schreiben — das ist nur Text, es gibt keine automatische Prüfung, die dies auf Protokollebene verhindert. Viele bösartige Bots tun genau das und geben sich als Googlebot oder Bingbot aus, um die Firewall dazu zu bringen, sie ohne weitere Fragen durchzulassen — in der Hoffnung, dass viele Websites diesem Namen blind vertrauen.

SeenSecure verifiziert die echte Identität mit einer branchenüblichen Technik: Reverse-DNS. Behauptet eine Anfrage, Googlebot zu sein, löst das System den tatsächlichen Domainnamen zu dieser IP-Adresse auf (Google zum Beispiel löst immer zu einer Domain auf, die auf .googlebot.com oder .google.com endet) und führt bei Übereinstimmung eine zweite Prüfung in umgekehrter Richtung durch (Forward-DNS von dieser Domain zurück zur IP), um sicherzustellen, dass sie nicht gefälscht wurde. Nur wenn beide Prüfungen übereinstimmen, wird der Anfrage vertraut, wirklich von Google zu stammen.

Warum diese doppelte Prüfung wichtig ist: Ein Angreifer könnte einen Server kontrollieren, dessen Reverse-DNS zu einem selbst gewählten Namen auflöst — er kann diese Domain jedoch nicht wiederum zu seiner eigenen IP zurücklösen lassen, es sei denn, er besitzt diese Domain wirklich. Die doppelte Prüfung (Reverse + Forward) macht es praktisch unmöglich, die Identität eines bekannten Crawlers zu fälschen.

Kombination der Schichten: Keine dieser drei Schichten entscheidet bei den zweideutigeren Fällen allein — SeenSecure kombiniert die Signale aus Schicht 1, 2 und 3, bevor die konfigurierte Aktion (blockieren, CAPTCHA-Herausforderung oder nur protokollieren) angewendet wird. So sinkt das Risiko, legitimen Datenverkehr aufgrund eines einzelnen, isolierten und unzuverlässigen Signals zu blockieren.

Wie Man Den Bot-Schutz Konfiguriert

Schritt 1: Schutz Aktivieren

SeenSecure > Firewall > Bot Protection > Aktivieren

Schritt 2: Schutzstufe Wählen

Permissiv: Blockiert nur eindeutig bösartige Bots. Googlebot passiert ohne CAPTCHA
Moderat (Empfohlen): Erkennt verdächtige Bots, kann bei manchen ein CAPTCHA verlangen
Aggressiv: Jeder nicht erkannte Bot = CAPTCHA. Auch Google muss sich beweisen

Schritt 3: Verhalten Bei Erkennung Festlegen

Blockieren: Weist sofort ab (Fehler 403)
Herausforderung: Verlangt das Lösen eines CAPTCHA
Protokollieren: Speichert nur im Protokoll, erlaubt Zugriff (Debug)

Schritt 4: Bestimmte Bots Zulassen (Whitelist)

Falls es legitime Crawler gibt, die Sie ohne CAPTCHA zulassen möchten:

Whitelist:
- Googlebot
- Bingbot
- facebookexternalhit
- Slurp (Yahoo)

Schritt 5: Bestimmte Bots Blockieren (Blacklist)

Falls Sie bestimmte, eindeutig bösartige Bots kennen:

Blacklist:
- MJ12Bot (bösartiger SEO-Bot)
- DotBot (Scraper)
- AhrefsBot (aggressiv)

Empfehlung: Beginnen Sie mit "Moderat". Überprüfen Sie eine Woche lang die Protokolle. Wenn alles in Ordnung ist, wechseln Sie bei Bedarf an mehr Sicherheit zu "Aggressiv".

Schicht 4: robots.txt-Steuerung und XML-Sitemap

Diese Schicht blockiert von sich aus nichts — sie ist eine Anleitung, die Suchmaschinen (Google, Bing) mitteilt, welche Teile deiner Website sie crawlen dürfen. Sie ergänzt die anderen Schichten: Während Schicht 1-3 bösartige Bots erkennen, die die Regeln ignorieren, ordnet Schicht 4 das Verhalten legitimer Bots, die sich tatsächlich daran halten.

Was ist robots.txt? Eine Textdatei im Stammverzeichnis deiner Website (deineseite.de/robots.txt), die als "Eingangsschild" für Crawler dient: Sie zeigt ihnen, wo sie hin dürfen und welche Bereiche gesperrt sind. Es ist eine Richtlinie, kein Befehl — legitime Crawler halten sich daran, bösartige können sie ignorieren. Verwende sie niemals, um sensible Informationen zu "verstecken": Jeder kann sie direkt lesen.

robots.txt-Editor

Aktiviere unter Firewall > Anti-Bot > Schicht 4 die Option "robots.txt anpassen" und wähle zwischen:

Vordefinierte Vorlagen: fertige Konfigurationen für häufige Fälle (/wp-admin/ blockieren, alles erlauben, alles blockieren usw.), einsatzbereit ohne eine einzige Zeile zu schreiben
Benutzerdefinierte Direktiven: du wählst selbst, Kästchen für Kästchen, welche Teile von WordPress vor Suchmaschinen gesperrt werden (Administrationsbereich /wp-admin/, interne Dateien /wp-includes/, REST-API /wp-json/ und /?rest_route=, oder /xmlrpc.php)

XML-Sitemap-Generator

Aktiviere auf demselben Bildschirm "Von SeenSecure generierte sitemap.xml bereitstellen", um eine vollständige Karte deiner Website unter deineseite.de/sitemap.xml zu veröffentlichen — die Datei, mit der Suchmaschinen alle deine Seiten auf einmal entdecken, statt sie Link für Link finden zu müssen.

Option	Was es bewirkt
Gesperrte Pfade ausschließen	Die Sitemap enthält keine Seiten, die du oben bereits in den robots.txt-Direktiven als gesperrt markiert hast
Cache (Sekunden)	Wie lange die generierte Sitemap gespeichert wird, bevor sie neu berechnet wird. Kein Warten nötig: Sie erzeugt sich automatisch neu, sobald du Inhalte veröffentlichst oder aktualisierst
Zusätzliche Pfade	URLs, die keine WordPress-Seiten/-Beiträge sind, aber trotzdem enthalten sein sollen (eine pro Zeile; auch vollständige externe URLs werden akzeptiert)

Wirklich automatisch: du musst nicht jedes Mal auf "generieren" klicken, wenn du etwas Neues schreibst. Die Sitemap aktualisiert sich im Hintergrund selbst, sobald du Inhalte veröffentlichst oder bearbeitest — die Schaltfläche "Sitemap jetzt generieren" dient nur dazu, eine sofortige Aktualisierung zu erzwingen, falls du nicht warten möchtest.

Schicht 5: Strenge IP-Validierung (Anti-Spoofing)

Diese Schicht ist keine neue Begrenzung — sie schützt alle anderen. Rate Limiting, Login-Sperren, Geo-Blocking, IP-Listen... all diese Schutzmaßnahmen entscheiden anhand der IP-Adresse des Besuchers, was zu tun ist. Das Problem: Es gibt HTTP-Header (X-Forwarded-For, X-Real-IP, CF-Connecting-IP), die ein Besucher von Hand fälschen kann, um sich als eine andere IP als die tatsächliche seiner Verbindung auszugeben — und wenn die Firewall diesen Headern blind vertraut, lassen sich alle deine IP-basierten Zähler und Sperren einfach umgehen, indem man über die eigene IP lügt.

PRO-Funktion. Im PRO-Plan verfügbar. Aktivierung unter Firewall > Anti-Bot > Schicht 5, mit zwei unabhängigen Schaltern: "Strenge IP-Validierung aktivieren" (verwendet ab sofort immer die echte TCP-Verbindungs-IP statt den Headern zu vertrauen) und, erst wenn dieser aktiv ist, "IP bei Spoofing-Versuch blockieren" (weist zusätzlich jeden direkt ab, der versucht seine IP zu fälschen).

Schicht 6: Massen-404-Scan-Schutz

Wofür: Wenn derselbe Besucher innerhalb weniger Minuten nacheinander viele nicht existierende Seiten deiner Website anfordert, ist das ein sehr zuverlässiges Zeichen dafür, dass er nach Schwachstellen sucht — kein Mensch surft so, und kein legitimer Suchmaschinen-Bot (Google, Bing) erzeugt dieses Muster. Diese Schicht zählt diese 404-Fehler pro IP und stoppt den Scan, bevor er abgeschlossen ist.

Warum ein Angreifer es versucht: Automatisierte Scan-Tools (wie Nuclei oder Nikto) probieren in Sekunden Dutzende oder Hunderte bekannter Pfade aus — /wp-config.php.bak, /.env, /database.sql, /admin.php — auf der Suche nach einer versehentlich zugänglichen sensiblen Datei. Es ist ein Aufklärungsschritt vor einem echten Angriff: Je mehr Pfade er ausprobiert, desto höher die Chance, etwas Ausnutzbares zu finden.

Reales Beispiel: Ein Scanner fordert in wenigen Sekunden 50+ nicht existierende Pfade an. Mit der Standardkonfiguration (12 404-Fehler in einem 5-Minuten-Fenster) wird die IP beim 12. Versuch automatisch für die konfigurierte Dauer (standardmäßig 10 Minuten) blockiert — der Scanner erhält mitten in seiner Liste keine Antworten mehr und bricht ab.

Wie es funktioniert: Für jede IP zählt das Plugin, wie viele 404-Seiten sie innerhalb des konfigurierten Zeitfensters anfordert. Wird der Schwellenwert überschritten, wird diese IP für die konfigurierte Dauer blockiert (oder nur protokolliert, je nach gewählter Aktion). Wie der Rest der Firewall respektiert diese Schicht den globalen Modus: im Überwachungsmodus wird nur protokolliert, nie blockiert; im Schutz-/Strikt-Modus wird die konfigurierte Aktion angewendet. Sie können Pfade ausschließen, die legitime 404-Fehler erzeugen (favicon.ico, robots.txt usw.), damit sie nicht zum Schwellenwert zählen.

Konfiguration

Feld	Was es tut	Standard
404-Schwellenwert	Anzahl nicht gefundener Seiten, die die Blockierung auslösen	12
Zeitfenster	Zeitraum, in dem 404er gezählt werden	5 min
Blockierungsdauer	Zeit, die die IP blockiert bleibt	10 min
Aktion	IP blockieren (403) oder nur protokollieren	Blockieren

Falsch-positive: Hat deine Website defekte interne Links, könnte ein echter Besucher mehrere legitime 404er ansammeln. Werden echte Besucher blockiert, erhöhe den Schwellenwert oder das Zeitfenster und füge wiederkehrende falsche 404-Pfade zur Ausschlussliste hinzu. Diese Schicht blockiert nie echtes Google oder Bing — siehst du deren IPs blockiert, handelt es sich wahrscheinlich um gefälschte IPs, die Schicht 5 (Strenge IP-Validierung, PRO) erkennen würde.

Privater Modus

Ein Schalter für Websites, die in keiner Suchmaschine erscheinen sollen: Intranets, Staging-Umgebungen, Websites im Aufbau oder private Projekte. Die Aktivierung unter Firewall > Anti-Bot bewirkt drei Dinge gleichzeitig:

robots.txt blockiert ab sofort alles (Disallow: /), unabhängig von der Konfiguration in Schicht 4
Jede Seite sendet den Header X-Robots-Tag: noindex, nofollow, das direkte Signal an eine Suchmaschine: "speichere mich nicht in deinem Index und folge meinen Links nicht"
Die Firewall blockiert jeden erkannten Bot, einschließlich legitimer Suchmaschinen wie Google oder Bing — keine Ausnahmen

Nur verwenden, wenn du wirklich keine Indexierung möchtest. Das ist eine drastische Maßnahme: Ist deine Website bereits öffentlich und du willst Sichtbarkeit, entfernt dich der Private Modus aus Google. Er ist für Websites gedacht, die NOCH NICHT öffentlich sein sollen, nicht zum "Härten" einer bereits veröffentlichten Website.

Bewährte Praktiken

Für Öffentliche Websites (Blog, Shop)

Verwenden Sie die Stufe "Permissiv"
Lassen Sie Googlebot und Bingbot ohne CAPTCHA (Sie benötigen Indexierung)
Blockieren Sie bekannte Scraper-Bots

Für Private Websites (Admin, Community)

Verwenden Sie die Stufe "Aggressiv"
Verlangen Sie ein CAPTCHA für jeden ersten Zugriff
Setzen Sie nur Mitarbeiter-IPs auf die Whitelist (keine Bots)

Für E-Commerce (Online-Shop)

Stufe "Moderat"
Schützen Sie den Checkout aggressiv (Aggressiv bei /checkout)
Besucher können ohne CAPTCHA navigieren

Protokolle Interpretieren

Bot = Googlebot, verlangt CAPTCHA: Das ist nicht der echte Googlebot, sondern ein Fälschung. Blockieren Sie ihn.
Leerer User-Agent + verdächtige Header: Eindeutig bösartig.
Legitimer Bot blockiert: Prüfen Sie, ob es sich um einen Fehlalarm handelt, und setzen Sie ihn auf die Whitelist, falls legitim.

Wichtig: Wenn Sie den echten Googlebot blockieren, verschwindet Ihre Website aus der Google-Suche. Seien Sie vorsichtig mit übertriebener Aggressivität.

🔧 Problembehandlung

Ein legitimer Besucher wurde blockiert oder erhält ständig ein CAPTCHA

Das ist das häufigste Symptom eines Fehlalarms. Bevor Sie etwas ändern, bestätigen Sie die tatsächliche Ursache unter Firewall → Traffic Log: suchen Sie die IP oder den ungefähren Zeitpunkt und prüfen Sie die Spalte "PROTECCIÓN" — sie zeigt genau, welche Schicht aktiv wurde; gehen Sie nicht ungeprüft davon aus, dass es der Bot-Schutz war.

War es Schicht 2 (Fingerprint) oder Schicht 3 (Crawler-Verifikation): Jede hat auf ihrer eigenen Karte unter Firewall → Anti-Bot ein Aktions-Dropdown mit der Option 📝 "Nur protokollieren" — stellen Sie das dort vorübergehend um, statt die ganze Schicht zu deaktivieren: Sie sehen weiterhin im Traffic Log, was blockiert worden wäre, ohne während der Feinabstimmung jemanden auszusperren.
War es Schicht 5 (Strikte IP-Validierung): Die Karte dieser Schicht warnt bereits vor der typischsten Ursache: manche Unternehmens- oder Mobilfunk-Proxys schreiben den X-Forwarded-For-Header bei legitimen Verbindungen um. Falls Sie dort den zusätzlichen Schalter "🚫 IP bei Spoofing-Versuch blockieren" aktiviert haben, schalten Sie ihn zuerst aus — die Validierung selbst kann aktiv bleiben (sie korrigiert weiterhin die IP Ihrer Zähler), nur ohne die harte Blockierung.

Ich muss jemanden sofort entsperren

Fügen Sie die Person direkt unter Firewall → IP-Listen hinzu (Whitelist): Das hat absoluten Vorrang vor jeder Anti-Bot-Schicht, auch Schicht 2+. Sie müssen weder auf den Ablauf der Blockierung warten noch die Konfiguration dieser Schicht ändern.

Häufig Gestellte Fragen

Verlangsamt es meine Website durch CAPTCHA? Nur wenn ein Besucher als Bot erkannt wird. Menschen kommen normalerweise ohne CAPTCHA durch.

Kann ich Googlebot zulassen, aber andere Bots blockieren? Ja, das ist ideal. Googlebot/Bing auf die Whitelist setzen, den Rest auf die Blacklist.

Was passiert, wenn legitime Benutzer als Bots markiert werden? Sie werden gebeten, ein CAPTCHA zu lösen. Wenn dies häufig vorkommt, reduzieren Sie die Aggressivität.

Sind RSS-Feeds betroffen? Nein, RSS ist anders. Aber manche Reader können als Bots erkannt werden (normal).

Was ist die im Rate-Limiting-Panel erwähnte "Erste Linie"? Es handelt sich um eine eigenständige Schutzschicht, die nicht bot-spezifisch ist: Sie wird aktiv, bevor WordPress überhaupt geladen wird, um Traffic-Spitzen oder Angriffe zu stoppen, die zu groß oder zu schnell sind, als dass der Rest des Plugins reagieren könnte. Sie wird unter Firewall → Rate Limiting → "🚀 Erste Linie" aktiviert und konfiguriert. Als Teil dieses Schutzes und um Ihr Suchranking nicht zu beeinträchtigen, prüft sie zudem, ob ein Besuch, der vorgibt, eine legitime Suchmaschine oder ein KI-Assistent zu sein, dies auch wirklich ist, bevor ein Limit angewendet wird — es reicht nicht, dass die Anfrage dies einfach behauptet: Sie wird mit den offiziellen Daten des jeweiligen Unternehmens abgeglichen, sodass niemand allein durch das Ändern eines Headers durchkommt.

Funktioniert Schicht 2+ (Menschliches Verhalten) nur bei Login und Registrierung? Standardmäßig ja, weil es dort am wichtigsten ist (ein echter Suchbot durchsucht und liest, versucht sich aber nie anzumelden). Sie können sie über ihre eigene Karte unter Firewall → Anti-Bot auf "jedes Formular der Website" erweitern, wenn Sie z. B. auch ein Kontaktformular schützen möchten.

Was ist der Unterschied zwischen Blockieren und "Nur protokollieren" bei jeder Schicht? "Nur protokollieren" zeigt Ihnen im Traffic Log, was diese Schicht blockiert hätte, ohne einen echten Besucher zu beeinträchtigen — nützlich, um eine neue Schicht zu testen, bevor Sie sie scharf schalten.

Kann ich eine einzelne Schicht deaktivieren und den Rest aktiv lassen? Ja, jede der 6 Schichten (und Schicht 2+) wird unabhängig aktiviert/deaktiviert; keine hängt von den anderen ab, um zu funktionieren.

Schadet eine höhere Aggressivität meinem Google-Ranking? Sollte es nicht: Googlebot und andere legitime Suchmaschinen/KI-Assistenten werden per Reverse-DNS (Schicht 3) und offiziellen Listen verifiziert, nicht anhand ihrer Header-Angaben — sie kommen weiterhin durch, auch wenn der restliche Traffic strenger behandelt wird.

Fazit: Der Bot-Schutz ist die letzte Verteidigungslinie gegen bösartigen automatisierten Zugriff. Kombinieren Sie ihn mit anderen Schutzmaßnahmen für vollständige Abdeckung.