Visitor Control: Schlechte Bots und unerwünschten Besucherverkehr blockieren

Öffnen Sie Ihr PrestaShop-Backoffice, gehen Sie an einem ruhigen Nachmittag zu Statistiken → Besucher online, und möglicherweise sehen Sie mehr „Besucher“, als Sie echte Kunden haben. Ein großer Teil des Traffics in jedem Shop ist automatisiert, Crawler, Scraper, Skripte und Sonden, die nie die Absicht haben, etwas zu kaufen. Ein Teil dieser Automatisierung ist für Ihr Geschäft unverzichtbar: Googlebot muss Ihre Seiten crawlen, damit Sie ranken können. Der Rest kostet Sie Geld. Er verbraucht CPU und Bandbreite auf Ihrem Hosting, füllt Ihre Warenkorbdatenbanken mit Müll, verfälscht jede gemeldete Conversion-Zahl und ist, im Fall von Bots, die gestohlene Zugangsdaten durchprobieren, und Schwachstellenscannern, der erste Schritt eines echten Angriffs. In diesem Leitfaden geht es darum, diese beiden Gruppen in einem PrestaShop-Shop auseinanderzuhalten, die schädliche Gruppe in Ihren eigenen Logs und Ihrer Datenbank zu erkennen und sie auszusperren, ohne versehentlich Google oder echte Kunden zu blockieren.

Dies ist das Kapitel zu Bots und Automatisierung in unserem Sicherheitscluster. Es bleibt bewusst bei seinem Thema: Einzelne problematische menschliche Besucher per IP zu blockieren, behandeln wir in Customer Extra Info and IP Bans; Formular-Spam mit einer Challenge zu stoppen, steht in reCAPTCHA for PrestaShop; die spezifische, crawlergetriebene Überlastung durch Facettensuche hat eine eigene ausführliche Analyse in surviving the ?q= flood; und die Webserver-Regeln finden Sie in PrestaShop .htaccess security rules. Wo Bot-Filterung im Gesamtbild sitzt, zeigt die vollständige Checkliste zur Sicherheitshärtung.

Geprüft im Juni 2026 anhand des aktuellen Verhaltens von PrestaShop-Statistiken und SQL-Manager sowie der weiterhin gültigen Empfehlung, Googlebot per Reverse-DNS zu verifizieren.

Nicht alle Bots sind der Feind, und die falschen zu blockieren schadet

Der teuerste Fehler, den Händler beim Blockieren von Bots machen, ist zu viel zu blockieren. Sperren Sie Googlebot in einem Anfall von „stoppt die Bots“-Eifer, bekommen Sie keinen sichereren Shop, Sie bekommen einen Shop, der aus der Suche verschwindet. Die erste Aufgabe ist daher eine klare Einordnung, denn Ihre Blockierregeln müssen diese beiden Gruppen genau gegensätzlich behandeln.

Beachten Sie die Konsequenz: Ein grobes Werkzeug, das „Bots“ allein nach Reputation blockiert, ist gefährlich, weil gute und schlechte Bots dieselben Techniken nutzen können. Wirksame Filterung richtet sich nach Identität und Verhalten, nicht nach einem einzigen Ein-/Aus-Schalter.

Schlechten Bot-Traffic gezielt in PrestaShop erkennen

Sie brauchen kein Drittanbieter-Dashboard, um das Problem zu sehen, PrestaShop zeichnet den größten Teil bereits auf, und Ihr Hosting protokolliert den Rest. Drei Stellen sollten Sie prüfen, in dieser Reihenfolge nach Aufwand.

1. Die Backoffice-Statistiken (der Zwei-Minuten-Check)

Unter Statistiken sind die Panels Herkunft der Besucher, Seiten nicht gefunden und Am häufigsten aufgerufene Seiten leise Warnsignale. Eine Flut von 404-Fehlern auf Pfaden, die Ihr Shop nie hatte (/wp-login.php, /.env, /administrator/), ist ein Schwachstellenscanner, der eine generische Exploit-Liste abarbeitet. Das sind nicht einmal PrestaShop-Pfade, und genau daran erkennen Sie den wahllosen Bot. Wenn eine „am häufigsten aufgerufene Seite“ plötzlich Ihre Login- oder Passwort-wiederherstellen-Seite ist statt eines Produkts, ist das ein typisches Muster für Passwortlisten-Angriffe.

2. Die Datenbank (die ehrlichen Zahlen)

PrestaShop protokolliert Sitzungen in ps_connections und ps_guest. Beachten Sie, dass ps_guest geparste Browser- und Betriebssystemattribute speichert (Browser, Version, Betriebssystem, Bildschirmauflösung), nicht aber den rohen User-Agent-String. In Standard-PrestaShop gibt es keine Spalte http_user_agent, erwarten Sie also nicht, den wörtlichen Agent direkt aus der Datenbank auszulesen. Was die Tabellen Ihnen geben, ist das Anfragevolumen pro IP, und das reicht, um eine Quelle sichtbar zu machen, die den Shop hämmert. Eine Abfrage wie die folgende (ausführen unter Erweiterte Einstellungen → SQL-Manager, Präfix anpassen) sortiert aktuelle Besucher nach Trefferzahl:

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

Eine einzelne IP mit Hunderten Treffern an einem Tag ist kein Kunde. Ein echter Käufer lädt eine Handvoll Seiten; ein Scraper läuft Ihren gesamten Katalog der Reihe nach ab. Um den tatsächlichen User-Agent zu sehen, den jede IP gesendet hat, dort verraten sich Scraper mit leeren, generischen oder geskripteten Agents, lesen Sie das rohe Server-Access-Log (unten behandelt) oder ein Modul, das den rohen User-Agent speichert, denn die PrestaShop-eigenen Tabellen behalten ihn nicht wortgetreu.

3. Die Warenkorbdatenbanken (das PrestaShop-Warnsignal)

Hier ist ein Symptom, das fast einzigartig für PrestaShop ist und Tausende Händler verwirrt: Dutzende abgebrochene Warenkörbe ohne Kunde und ohne Produkte, die unter Bestellungen → Warenkörbe erscheinen. PrestaShop legt über seine Warenkorb- und Sitzungsabläufe eine Warenkorbzeile an, sobald ein In-den-Warenkorb-Endpunkt berührt wird. Leere Gastwarenkörbe können durch mehrere Dinge entstehen, Bots und Crawler, Module, die Warenkörbe vorab anlegen, oder normales Sitzungsverhalten, nehmen Sie also nicht vorschnell an, dass ein bestimmter Crawler verantwortlich ist. Prüfen Sie in Ihren Logs, welche Quelle den Endpunkt tatsächlich aufgerufen hat, bevor Sie einen Crawler beschuldigen, blockieren oder auf die Whitelist setzen. Die Warenkörbe sind echte Datenbankzeilen, aber in diesen Fällen sind sie Artefakte, keine verlorenen Verkäufe; die Lösung ist, sie zu erkennen und zu bereinigen, statt einen Crawler zu blockieren, dessen Urheberschaft Sie nicht bestätigt haben. Wir haben das in unserem Hinweis zu bot-erstellten Warenkörben auseinandergezogen; die praktische Erkenntnis lautet: Leere Gastwarenkörbe sind meist eine Protokollierungs-Eigenheit, kein Notfall.

4. Das Server-Access-Log (die belastbare Wahrheit)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Ihr rohes Access-Log zeigt jede Anfrage mit IP, User-Agent und Zeitpunkt. Die belastbare Wahrheit, die Ihre Analysen nicht vortäuschen können, weil JavaScript-basierte Analytics bei den meisten Bots gar nicht erst ausgelöst wird. Achten Sie auf eine IP, die Produktseiten in perfekter Reihenfolge anfordert, auf Anfragen ohne User-Agent und auf Trefferwellen gegen /login, /password-recovery und create-account. In diesem Log bestätigen Sie auch, ob ein „Googlebot“ echt ist, ein echter Googlebot löst bei einem Reverse-DNS-Lookup auf einen googlebot.com- / google.com-Host auf; ein gefälschter behauptet nur den Namen, zeigt aber auf eine beliebige Rechenzentrums-IP.

Die Abwehrleiter: zuerst günstig und breit wirksam

Bot-Filterung funktioniert in Schichten, und die kluge Reihenfolge ist, mit den Maßnahmen zu beginnen, die den meisten Traffic mit dem geringsten Aufwand und dem niedrigsten False-Positive-Risiko stoppen. Sie steigen die Leiter nur so weit hinauf, wie Ihr Problem es verlangt.

robots.txt, Erwartungen setzen, keine Barriere bauen

PrestaShop kann unter Shop-Einstellungen → Traffic & SEO → SEO & URLs → robots.txt generieren eine sinnvolle robots.txt für Sie erzeugen. Sie weist gut erzogene Crawler an, Warenkorb, Kasse, Suchergebnisse und Kontoseiten zu überspringen, dadurch reduzieren Sie Crawl-Verschwendung bei den Bots, die Sie behalten wollen. Ihre Grenze muss klar sein: Sie wird von guten Bots beachtet und von schlechten ignoriert, also ist sie ein Crawl-Budget-Werkzeug, niemals eine Sicherheitsmaßnahme. Listen Sie dort keinen Pfad in der Hoffnung auf, ihn zu verstecken; Sie veröffentlichen damit eine Karte dessen, was andere lieber nicht sehen sollen.

Die Edge WAF, der Schritt mit der größten Hebelwirkung

Wenn Sie Cloudflare (oder eine vergleichbare WAF) vor den Shop setzen, verlagern Sie den Kampf vollständig weg von Ihrem Hosting: bekannte schlechte IPs, Anfragen, die nicht wie ein echter Browser aussehen, und volumetrische Floods werden an der Edge gefiltert, bevor sie PHP überhaupt erreichen. Im kostenlosen Tarif erhalten Sie Bot-Fight-Modus, eine IP-Reputationsdatenbank, Browser-Integritätsprüfungen und einfache Rate-Limiting-Regeln, genug, um den Großteil der Müllautomatisierung von Ihrem Server fernzuhalten. Für die meisten kleinen und mittelgroßen PrestaShop-Shops bewirkt dieser eine Schritt mehr als alles andere zusammen, und es ist dieselbe Edge-Schicht, auf die Sie stärker setzen würden, wenn Crawler-Traffic zur Facettensuche-?q=-Flut wird, die einen Shop umwerfen kann.

Rate Limiting, Menschen und Skripte anhand der Geschwindigkeit trennen

Ein echter Kunde lädt beim Stöbern vielleicht fünf bis zehn Seiten pro Minute; ein Scraper, der Ihren Katalog abläuft, lädt hundert. Ein Rate Limit pro IP (mit HTTP 429, sobald eine Schwelle überschritten wird) erkennt diese Lücke automatisch. Am zuverlässigsten ist es an der Edge (Cloudflare) oder auf Webserver-Ebene. Stimmen Sie es großzügig ab, setzen Sie die Obergrenze deutlich oberhalb menschlichen Surfverhaltens, damit eine geteilte Büro- oder Mobilfunkanbieter-IP, hinter der viele echte Kunden sitzen, nicht für hohe Aktivität bestraft wird.

Formular-Challenges und Honeypots, für die gezielten Formulare

Scraper wollen Ihre Seiten; Spam-Bots wollen Ihre Formulare. Registrierungs-, Login-, Kontakt- und Newsletter-Formulare sind die Stellen, an denen sich automatisierte Übermittlungen konzentrieren, und eine unsichtbare Challenge stoppt sie, ohne echte Käufer zu belästigen. Das ist ein eigenes Thema in reCAPTCHA for PrestaShop. Ein Honeypot ergänzt das: ein verborgenes Feld, das ein Mensch nie sieht, das ein einfacher Formular-Bot aber brav ausfüllt und sich damit ohne Kosten für Ihre Kunden selbst als Bot markiert.

Nach Identität blockieren, direkt aus dem PrestaShop-Backoffice

Die Schichten oben sind Infrastruktur. Sie brauchen aber auch eine Steuerung, die Sie ohne SSH oder Entwickler erreichen, einen Ort, an dem Sie direkt aus der Administration sagen können: „Dieses Land schickt mir nur Betrug und Scraper, fordere eine Challenge an“ oder „Dieser User-Agent aus einem Hosting-Bereich hämmert meinen Login, blockiere ihn“. Das ist die Anwendungsebene, und hier zahlt es sich aus, nativ in PrestaShop zu arbeiten: Die Sperre erfolgt mit vollem Sitzungskontext (sie kennt Kundengruppe, Land und Agent), und sie übersteht Theme- und Core-Upgrades, weil sie nicht in Server-Konfigurationsdateien festgeschraubt ist, die Sie später vergessen.

Ein Hinweis, bevor Sie zu einer IP-Sperre greifen: gehen Sie bei IP-Bans chirurgisch vor. Private und mobile IPs werden wiederverwendet. Die Scraper-IP von heute kann morgen ein zahlender Kunde beim selben Anbieter sein. Blockieren Sie einzelne private IPs nur als kurze, überprüfte Maßnahme; dauerhafte Sperren ganzer IP-Bereiche sollten Rechenzentrums- und VPN-Bereichen vorbehalten bleiben, in denen keine echten Kunden sitzen. (Eine konkrete missbräuchliche Person per IP zu sperren, ist eine andere Aufgabe, die in Customer Extra Info and IP Bans behandelt wird.) Für grobe Linien sind Länder- und User-Agent-Regeln meist sicherer und wartungsärmer, als einzelnen Adressen hinterherzujagen.

Wo Visitor Control hineinpasst

Visitor Control speichert shopspezifische Blockierentscheidungen im Backoffice.

Whitelisting vertrauenswürdiger Netzwerke verhindert, dass breite Blockierregeln Ihr eigenes Team treffen.

Die gesammelte Besuchertabelle ist ps_mprvc_info. Diese schnelle Prüfung zeigt, ob ein Land oder Gerätetyp den aktuellen Traffic dominiert:

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

Genau diese Lücke schließt unser Modul Visitor Control. Es erledigt zwei Aufgaben direkt im Backoffice, ohne Serverkonfiguration und ohne externen Dienst, den Sie anbinden müssen. Erstens blockiert es unerwünschte Besucher nach IP, Land oder User-Agent. So können Sie einen bekannten Scraper-Agent oder ein Land, aus dem nur Kartentest-Traffic kommt, unauffällig abweisen, und zwar über PrestaShops eigene Anfrageverarbeitung statt über manuell bearbeitete .htaccess-Zeilen. Zweitens macht es sichtbar, wer Ihre Besucher tatsächlich sind: Gerät, IP und Land werden direkt im Kundenprofil angezeigt, sodass Sie bei der Entscheidung, ob ein Muster Bot oder echter Käufer ist, mit Belegen arbeiten statt mit Bauchgefühl. Was bringt Ihnen das konkret? Die Entscheidung, zu blockieren oder zu erlauben, ist keine Server-Admin-Aufgabe mehr, die man aufschiebt, sondern eine Zwei-Minuten-Entscheidung auf demselben Bildschirm, auf dem Sie den Shop führen, und weil es ein Modul ist, bleiben die Regeln beim nächsten PrestaShop-Upgrade intakt.

Für das zuvor beschriebene PrestaShop-spezifische Bot-Warenkorb-Rauschen, die leeren Gastwarenkörbe, die Ihre Backoffice-Zähler verzerren, liegen die passenden Werkzeuge auf der Warenkorbseite: Sie markieren und bereinigen Bot-Warenkörbe, ohne Crawler zu blockieren, die sie legitimerweise erzeugen. Der Sinn dieser Trennung ist Präzision: Sie filtern den Traffic, den Sie nicht wollen, und behalten gleichzeitig die Bots, die Rankings bringen, sowie die Indexierung, die Verkäufe bringt.

Ein praktisches Schichtmodell für einen normalen Shop

Sie brauchen keinen Enterprise-Vertrag für Bot-Management, um die alltägliche Flut zu bewältigen. Für einen typischen PrestaShop-Shop stoppt dieser Stack den Großteil schlechter Automatisierung mit wenig Einrichtung und praktisch ohne Risiko für echte Kunden:

• Setzen Sie den kostenlosen Cloudflare-Tarif vor den Shop, die größte einzelne Reduzierung von Mülltraffic, an der Edge, bevor er Sie einen CPU-Zyklus kostet.
• Generieren Sie eine saubere robots.txt über Traffic & SEO, damit gute Crawler Warenkorb-, Such- und Kontoseiten überspringen und ihr Budget auf Produkte verwenden.
• Fügen Sie eine unsichtbare Challenge hinzu für Registrierungs-, Login-, Kontakt- und Newsletter-Formulare.
• Blockieren Sie nach Land und User-Agent für Muster, die Sie als Bots bestätigt haben, direkt aus dem Backoffice, und halten Sie IP-Sperren kurz und gezielt.
• Überfliegen Sie monatlich Ihre Logs und die SQL-Manager-Abfrage, blockieren Sie bestätigte Wiederholungstäter und prüfen Sie jeden verdächtigen „Googlebot“ per Reverse-DNS, bevor Sie ihm vertrauen.

Häufig gestellte Fragen

Schadet das Blockieren von Bots meinem Google-Ranking?

Nur wenn Sie die falschen blockieren. Such-Crawler (Googlebot, Bingbot) und Vorschau-Bots sozialer Netzwerke müssen Sie erreichen können, blockieren Sie sie, verschwinden Ihre Seiten in den folgenden Wochen aus der Suche, oder geteilte Links erscheinen ohne Vorschau. Die ganze Aufgabe besteht darin, diese von Scrapern, Bots für Passwortlisten-Angriffe und Schwachstellenscannern zu unterscheiden. Blockieren Sie nach bestätigter Identität und bestätigtem Verhalten, prüfen Sie jeden „Googlebot“ per Reverse-DNS, bevor Sie ihm vertrauen, und Sie reduzieren unerwünschten Traffic, ohne die Bots anzutasten, die Kunden bringen.

Warum hat mein Shop so viele leere abgebrochene Warenkörbe ohne Kunde?

PrestaShop legt eine Warenkorbzeile an, sobald ein In-den-Warenkorb-Endpunkt berührt wird. Leere Gastwarenkörbe können daher von Bots, Crawlern, Modulen, die Warenkörbe vorab anlegen, oder normalem Sitzungsverhalten stammen. Es sind echte Zeilen, aber meist Artefakte, keine verlorenen Verkäufe. Gehen Sie nicht davon aus, dass ein bestimmter Crawler verantwortlich ist, bestätigen Sie in Ihrem Access-Log, welche Quelle den Endpunkt tatsächlich getroffen hat, und bereinigen Sie dann das Rauschen, statt blind einen Crawler zu blockieren, dessen Beteiligung Sie nicht bestätigt haben.

Reicht robots.txt aus, um schlechte Bots fernzuhalten?

Nein. robots.txt wird von guten Crawlern beachtet und von schlechten ignoriert, daher ist sie ein Crawl-Budget-Werkzeug, niemals eine Sicherheitsmaßnahme. Es lohnt sich, sie zu generieren (Traffic & SEO → robots.txt generieren), damit höfliche Crawler kein Budget auf Warenkorb-, Such- und Konto-URLs verschwenden, aber listen Sie dort niemals einen Pfad in der Hoffnung auf, ihn zu verstecken, denn Sie veröffentlichen damit eine Karte dessen, was andere lieber nicht sehen sollen. Für Bots, die sie ignorieren, brauchen Sie Edge WAF, Rate Limiting und identitätsbasiertes Blockieren.

Was ist die einzelne Maßnahme mit der größten Wirkung?

Für die meisten kleinen und mittelgroßen Shops: Setzen Sie den kostenlosen Cloudflare-Tarif (oder eine vergleichbare WAF) vor den Shop. Er filtert bekannte schlechte IPs, offensichtliche Nicht-Browser und volumetrische Floods an der Edge, bevor sie PHP überhaupt erreichen, und selbst im kostenlosen Tarif erhalten Sie Bot-Fight-Modus, IP-Reputation, Browser-Integritätsprüfungen und einfaches Rate Limiting. Dieser eine Schritt bewirkt typischerweise mehr als alles andere zusammen.

Sollte ich Scraper-IP-Adressen dauerhaft sperren?

Gehen Sie gezielt vor. Private und mobile IPs werden wiederverwendet. Die Scraper-IP von heute kann morgen ein zahlender Kunde beim selben Anbieter sein, blockieren Sie einzelne private IPs daher nur als kurze, überprüfte Maßnahme. Dauerhafte Bereichssperren sollten Rechenzentrums- und VPN-Bereichen vorbehalten bleiben, in denen keine echten Kunden sitzen; für grobe Maßnahmen sind Länder- und User-Agent-Regeln vorzuziehen, weil sie sicherer und wartungsärmer sind, als einzelnen Adressen hinterherzujagen.

Die Denkweise, die das sicher hält, ist dieselbe wie am Anfang: Das Ziel lautet nie „Bots blockieren“, sondern „die Bots blockieren, die Ihnen schaden, während die willkommen bleiben, die Kunden bringen“. Ordnen Sie die Bot-Typen sauber ein, lesen Sie die Belege aus Ihrem eigenen Shop, bevor Sie den Hammer schwingen, und ergänzen Sie Schichten nur so weit, wie Ihr Traffic es verlangt. So umgesetzt ist Bot-Filterung einer der stilleren Gewinne in der Shopsicherheit, unsichtbar für die Kunden, auf die es ankommt, und ein dauerhaftes Leck bei Ressourcen, Analysen und Angriffsfläche wird geschlossen, das Sie sonst Skripten überlassen würden. Wenn Sie das in Ihre übrige Verteidigung einbauen möchten, verbinden die Checkliste zur Sicherheitshärtung und der leicht verständliche Sicherheitsleitfaden für Shopbetreiber das ganze Themenfeld.