Google Storebot kauft in Ihrem PrestaShop-Shop ein: Was Händler 2026 wissen müssen

Öffnen Sie im PrestaShop-Backoffice die Übersicht Kunden → Warenkörbe, sehen Sie dort möglicherweise etwas Beunruhigendes: hunderte Warenkörbe ohne Kundennamen, ohne Adresse, ohne Versanddienstleister, nur ein Produkt, ein Zeitstempel und sonst nichts. Tag für Tag, in einem stetigen Strom, ohne je zu konvertieren. Der erste Gedanke ist oft: Etwas ist kaputt, oder der Shop wird angegriffen. Bestätigen Sie die Quelle, bevor Sie einen Fehler oder unerwünschten Bot-Traffic ausschließen. In den meisten Fällen ist ein Google-Crawler namens Storebot der Auslöser, und er tut genau das, wofür Google ihn entwickelt hat: Er testet den Kaufablauf in Ihrem Shop, ohne zu bestellen, um zu prüfen, ob Ihre Google-Shopping-Einträge der Wahrheit entsprechen.

Dieser Beitrag behandelt genau dieses Phänomen in PrestaShop. Was Storebot ist, wie Sie bestätigen, dass tatsächlich er Ihre ps_cart-Tabelle füllt (und nicht ein Bot, den Sie wirklich blockieren sollten), warum eine Blockierung ein teurer Fehler ist und was Sie stattdessen tun sollten. Wir haben das 2026 selbst in mehreren aktiven PrestaShop-Shops untersucht; die Backoffice-Pfade, Datenbankstrukturen und Prüfschritte unten sind also echte Praxiswerte, keine vagen Empfehlungen.

Was Storebot-Google eigentlich ist

Storebot ist ein dedizierter Google-Crawler, getrennt vom Googlebot, der Seiten für die organische Suche indexiert. Seine Aufgabe ist die Prüfung von E-Commerce-Daten: Er lädt eine Produktseite, liest Preis und Verfügbarkeit aus und testet anschließend, ob ein echter Kunde den Artikel tatsächlich kaufen könnte, indem er ihn in den Warenkorb legt und sich in Richtung Kasse bewegt. Er rendert JavaScript wie ein echter Browser; das ist bei PrestaShop wichtig, weil das Standard-Theme Produkte per AJAX in den Warenkorb legt.

Sie erkennen ihn an seinem User-Agent, der das wörtliche Token Storebot-Google enthält:

Mozilla/5.0 (X11; Linux x86_64; Storebot-Google/1.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

Bei einem typischen Besuch lädt er die Produktseite, löst die Anfrage zum Hinzufügen in den Warenkorb aus (ein POST, den PrestaShops CartController verarbeitet. Die controller_class ist cart, unabhängig davon, ob Ihre lokalisierte URL /cart, /panier oder /warenkorb lautet), prüft, ob die Warenkorbsumme mit dem Preis auf der Produktseite übereinstimmt, tastet sich zu den Adress- und Lieferschritten vor, um Versandkosten und Steuern auszulesen, und verschwindet dann, ohne zu bestellen. Genau deshalb bleibt am Ende ein Stapel einzeiliger abgebrochener Warenkörbe zurück. Das ist Prüfung, keine Warenkorbabbrüche im eigentlichen Sinn.

Warum diese Warenkörbe in PrestaShop so aussehen

Die Form dieser Phantom-Warenkörbe ist spezifisch und gut erkennbar. Als wir sie in produktiven Shops untersucht haben, hatten alle Storebot-Warenkörbe denselben Fingerabdruck in ps_cart:

• id_customer = 0, kein angemeldeter Kunde
• id_guest = 0, keine verknüpfte Gast-Sitzung
• id_carrier = 0 und id_address_delivery = 0, nie bis zur Lieferauswahl gelangt
• secure_key = '', leer

Dass diese Warenkörbe überhaupt entstehen, hat einen PrestaShop-spezifischen Grund. CartController::updateCart prüft seit Langem $this->context->cookie->exists(), bevor eine Warenkorbänderung durch eine In-den-Warenkorb-Aktion zugelassen wird. Eine Schutzmaßnahme, die genau solche Geister-Warenkörbe eindämmen soll (neuere Branches stützen sich stärker auf eine Prüfung mit Connection::isBot()). In den von uns untersuchten Shops kam der Bot trotzdem durch, weil eine Full-Page-Cache-Schicht (genauer: die dynamische AJAX-Anfrage zum Hinzufügen in den Warenkorb, die er nutzt) dem Bot ein Cookie gibt, in dem keine id_guest enthalten ist. Der Gastdatensatz selbst wird normalerweise erst durch einen Statistik-Hook im Seitenkopf angelegt; unter Full-Page-Caching wird dieser Hook häufig nicht ausgeführt, sodass der Front Controller einen Warenkorb mit id_guest = 0 und leerem Secure Key erstellt.

Was bedeutet das für Sie? Zwei Dinge. Erstens ist die leere Gaststruktur eine Nebenwirkung des Cachings, kein Beweis für einen Bot, und genau das führt direkt zum nächsten Abschnitt. Zweitens brechen PrestaShops eigene Warenkorbwiederherstellung und Besucherzuordnung für diese Zeilen stillschweigend weg, weil keine Gast-Sitzung verknüpft ist: Es gibt nichts, dem man eine E-Mail senden könnte, nichts, was sich einer Sitzung zuordnen ließe, und trotzdem liegen diese Zeilen in Ihren Tabellen und blähen jede Auswertung auf.

Zuerst bestätigen: Ist es wirklich Storebot, nicht raten

Diesen Schritt überspringen die meisten Ratschläge nach dem Muster „löschen Sie die Warenkörbe einfach“, und genau er schützt Sie davor, echte Kunden zu löschen. Die leere Gaststruktur ist für sich allein kein verlässlicher Bot-Marker. In einem PrestaShop-Shop mit Full-Page-Cache und leerer ps_connections-Tabelle erzeugt ein echter Käufer ohne Cookie, zum Beispiel bezahlte Anzeigenzugriffe, die mit einem gclid und ohne vorheriges Cookie ankommen, einen identischen verwaisten Warenkorb. Wenn Sie nur nach dieser Struktur bereinigen, können Sie echte abgebrochene Warenkörbe löschen und Ihren eigenen Prozess zur Warenkorbwiederherstellung verfälschen.

Prüfen Sie gegen das Zugriffsprotokoll, nicht gegen die Warenkorb-Tabelle. Zwei Kontrollen, in dieser Reihenfolge:

• User-Agent + IP-Quelle. Suchen Sie die Anfragen, die die Warenkörbe erstellt haben, im echten Zugriffsprotokoll Ihres Webservers (bei nginx ist das typischerweise /var/log/nginx/access.log; beachten Sie, dass Apache-Domlogs über Proxy geleitete Zugriffe oft ausschließen, prüfen Sie also die richtige Datei). Echte Storebot-Anfragen kommen aus Googles Bereichen. Wir haben Treffer von 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x und 192.178.11.x bestätigt.
• Vorwärts bestätigtes Reverse DNS. Vertrauen Sie weder der IP noch dem UA-String allein, beides lässt sich fälschen. Führen Sie eine Reverse-DNS-Abfrage für die IP aus (echte Google-Zugriffe lösen zu *.google.com / google-proxy-* / rate-limited-proxy-*.google.com auf), lösen Sie diesen Hostnamen anschließend wieder vorwärts auf und bestätigen Sie, dass dieselbe IP zurückkommt. Storebot-Google beachtet robots.txt (siehe letzter Abschnitt), und Google veröffentlicht Crawler-IP-Bereiche in seiner offiziellen Dokumentation zu Crawler-IPs, prüfen Sie die Datei für die relevante Crawler-Kategorie, um eine verifizierte Storebot-IP zu bestätigen, statt anzunehmen, dass eine einzelne Liste alles abdeckt.

Wenn der UA Storebot behauptet, die vorwärts bestätigte Reverse-DNS-Prüfung aber fehlschlägt, sehen Sie einen Nachahmer, der sich als Google ausgibt, und diese Zugriffe können Sie anders behandeln. Die verifizierten Zugriffe müssen Sie zulassen.

Warum Storebot zu blockieren der teure Fehler ist

Die naheliegende Maßnahme, eine Firewall-Regel, ein robots.txt-Disallow, ein 403 auf der Warenkorb-Route für diesen UA, schlägt zurück, und zwar über ein System, das Sie nicht kontrollieren: das Google Merchant Center.

• Wenn Sie den UA blockieren, riskieren Sie die Ablehnung Ihrer Produkte. Googles Dokumentation sagt ausdrücklich, dass es dringend empfohlen ist, dem Crawler Zugriff auf Ihre Seiten zu geben. Wenn Storebot Ihre Kasse nicht prüfen kann, riskieren Ihre Artikel Ablehnungen wegen Zielseiten- und Preisabweichungen und verschwinden aus Shopping-Anzeigen und kostenlosen Einträgen.
• Sperren Sie auch nicht gezielt den Warenkorb-POST. Produktseiten lesen zu lassen, aber das Hinzufügen in den Warenkorb zu blockieren, zerstört genau das, wofür Storebot existiert: die Prüfung der Preisübereinstimmung im Warenkorb. Auch das kann eine Ablehnung auslösen.
• Blockieren Sie die IP-Bereiche niemals in der Firewall. Die Bereiche 66.249.* und 66.102.* werden mit dem regulären Googlebot geteilt. Wenn Sie sie blockieren, kann Ihr Shop auch an Sichtbarkeit in der organischen Suche verlieren, ein deutlich größerer Verlust als ein paar zusätzliche Warenkorbzeilen.

Die ehrliche Einordnung: Ein Storebot-Besuch ist eine kostenlose Prüfung, die bestätigt, dass Ihre Einträge korrekt sind, und korrekte Einträge werden häufiger ausgespielt. Sie wollen, dass er crawlt. Das Problem ist nicht der Crawler, sondern die Spuren, die er hinterlässt.

Die echten Kosten: Bot-Warenkörbe verfälschen Ihre Auswertungen

Die Phantom-Warenkörbe sind nicht nur Unordnung. Sie vergiften still die Kennzahlen, auf deren Basis Sie Entscheidungen treffen:

• Ihre Abbruchrate ist Fiktion. Wenn Storebot sieben Warenkörbe pro Stunde erzeugt und fast keiner davon konvertiert, sieht Ihre Warenkorb-zu-Bestellung-Rate im Backoffice viel schlechter aus als in Wirklichkeit. Wir haben Zeiträume gesehen, in denen Bot-Warenkörbe echte Warenkörbe über einige Tage hinweg mehrfach übertrafen.
• Die Tabellen ps_cart und ps_cart_product wachsen endlos, und auf Hosts mit knappen Datenbankressourcen zeigt sich diese Last in langsamen Warenkorb- und Admin-Abfragen.
• Automatisierungen zur Warenkorbwiederherstellung verschwenden Aufwand. Weil diese Zeilen keinen echten Kunden und keine nutzbare Sitzung haben, überspringt jeder Warenkorbwiederherstellungsprozess sie entweder (bestenfalls) oder verbrennt Ressourcen beim Versuch, einen Kontakt anzusprechen, der nicht existiert.

Zu entscheiden, welche Warenkörbe Bots sind und welche echt, bevor Sie irgendeiner Konversionszahl vertrauen, ist dieselbe Disziplin, die jeder Shop-Auswertung zugrunde liegt: wissen, was gezählt werden muss und was ignoriert werden sollte. Diese Denkweise behandeln wir in Webanalyse für Onlineshops: was Sie messen sollten und was nicht, und die GA4-spezifische Variante dieser Filterung in den GA4-Kennzahlen, die wirklich zählen.

Was Sie stattdessen tun sollten: Crawler zulassen, Spuren bereinigen

1. Sorgen Sie dafür, dass Storebot genau das findet, was Ihre Produktdaten versprochen haben

Der wirksamste Schritt ist eine saubere Prüfung für den Crawler, damit sein Besuch erfolgreich ist und nichts auslöst. Produktdaten, strukturierte Daten, Produktseite, Warenkorb und Kasse müssen bei Preis (inklusive Steuern und Währung) und Verfügbarkeit übereinstimmen. In PrestaShop heißt das: Ihr Modul für Produktdatenexport liest Live-Preise und Lagerbestand aus, und Ihre Produktseiten enthalten korrektes schema.org/Product-Markup mit price, priceCurrency, availability und brand. Wenn Sie Einträge über die Merchant API ausspielen, prüfen Sie, ob Ihr Modul für Produktdatenexport v1 unterstützt. Die alte Content API for Shopping wird 2026 eingestellt, und ein veraltetes Produktdatenmodul wird damit zur tickenden Quelle für Abweichungen.

2. Produktseiten für nicht vorrätige Artikel korrekt behandeln

Google erwartet, dass eine Produktseite für einen nicht vorrätigen Artikel den Nichtverfügbarkeitsstatus klar anzeigt, den Kauf verhindert und die Verfügbarkeit exakt zu Produktdaten und strukturierten Daten passt. Ein sichtbar deaktivierter Kaufen-Button (ausgegraut, mit dem HTML-Attribut disabled) ist eine zulässige Umsetzung, solange sie konsistent mit Produktdaten und Schema-Verfügbarkeit bleibt. Viele PrestaShop-Themes verstecken den In-den-Warenkorb-Button dagegen vollständig, sobald der Lagerbestand null erreicht, prüfen Sie das product.tpl / Produkt-Template Ihres Themes. Storebot testet genau das: Er darf keinen nicht vorrätigen Artikel in den Warenkorb legen können, muss aber einen vorrätigen Artikel hinzufügen können.

3. Bot-Warenkörbe regelmäßig bereinigen, aber den Löschvorgang absichern

Regelmäßige Bereinigung ist die praktische Lösung für das Datenbankwachstum, und die Warenkörbe sind identifizierbar: id_customer = 0, id_guest = 0 (oder ein Gastdatensatz mit Storebot-UA), id_carrier = 0, id_address_delivery = 0, erstellt von einer verifizierten Google-IP. Der abgesicherte Teil ist genauso wichtig wie der Treffer selbst: Bestätigen Sie vor dem Löschen, dass der Warenkorb keine verknüpfte Bestellung, keinen Kunden, keine Adressen hat und (wie oben beschrieben) von einer forward-confirmed Storebot-IP erstellt wurde, niemals nur anhand der Tabellenstruktur.

Eine scharfe PrestaShop-spezifische Falle, falls Sie Ihr eigenes Cleanup-SQL oder einen eigenen Cron schreiben: PrestaShop schreibt seine date_add-Werte mit der PHP-Uhr, nicht mit der MySQL-Uhr. Auf einem Host, auf dem sich die Datenbank-Zeitzone von der PHP-Zeitzone unterscheidet, kann ein Altersfilter auf Basis von NOW() / DATE_SUB(NOW(), ...) jeden Warenkorb fälschlich als frisch aktiv einstufen und stillschweigend nichts löschen (oder die falschen Zeilen). Berechnen Sie den Cutoff mit der Anwendungsuhr, und löschen Sie die passenden ps_cart_product-Zeilen immer zusammen mit den ps_cart-Zeilen, damit keine Positionsdaten verwaisen.

4. Bot-Warenkörbe aus Auswertungen und Wiederherstellung heraushalten

Berechnen Sie die Abbruchrate nach dem Ausschluss verifizierter Bot-Warenkörbe und berücksichtigen Sie weiterhin nicht verifizierte Warenkörbe, die von echten Käufern ohne Cookies stammen könnten. Schließen Sie die anonymen, verifizierten Bot-Warenkörbe aus Ihrem Konversionstrichter aus, und stellen Sie sicher, dass jede Warenkorbwiederherstellung sie herausfiltert, damit sie nicht auf Zeilen reagiert, die nie ein Mensch waren. Dieselbe Trennung ermöglicht endlich eine reale Warenkorb-zu-Bestellung-Rate statt einer von Storebot aufgeblähten Zahl, genau die Art von sauberer, inhaberfreundlicher Kennzahl, die in Ihre erweiterten Shop-Auswertungen gehört.

5. Nicht kommerzielles Crawling mit robots.txt begrenzen (Produkt und Warenkorb nicht anfassen)

Sie können unnötiges Crawling reduzieren, ohne die Prüfung zu gefährden, indem Sie Storebot von URLs fernhalten, die keinen kommerziellen Wert haben, niemals jedoch von Produktseiten oder der Warenkorb-Route selbst:

User-agent: Storebot-Google, dann Disallow: /*?order=, Disallow: /*?utm_ und zuletzt Allow: /, damit alles andere, einschließlich Produktseiten und Warenkorb-Route, crawlbar bleibt.

All das ohne Entwickler erledigen: Spam Cart Blocker

Der oben beschriebene Ablauf „erst verifizieren, dann sicher bereinigen“ ist korrekt, aber manuell schwer dauerhaft zu pflegen, Protokollauswertung, vorwärts bestätigtes Reverse DNS, zeitzonensicherer Cron, abgesicherte Löschvorgänge, die nie eine echte Bestellung berühren. Wir haben Spam Cart Blocker für unsere eigenen Shops gebaut, weil die verfügbaren Alternativen es gefährlich falsch gelöst haben: Die wenigen Module in diesem Bereich blockieren Bot-Warenkörbe entweder (was, wie oben beschrieben, zur Sperrung Ihrer Produkte im Merchant Center führen kann) oder löschen stumpf nach Alter, ohne zu wissen, ob ein Warenkorb von einem Bot oder von einem echten Käufer ohne Cookie stammt.

Was macht es also für Sie? Es klassifiziert Warenkörbe, indem es die Identität des Crawlers per vorwärts bestätigtem Reverse DNS prüft. Ein verifizierter Storebot wird erkannt, ein UA-fälschender Nachahmer nicht, und markiert sowie bereinigt anschließend echte Bot-Warenkörbe nach TTL, während alles mit Bestellung, Kunde, Adresse oder echter Sitzung unangetastet bleibt. Es blockiert Google nie, sodass Ihre Einträge sicher bleiben. Es repariert die unter Full-Page-Cache gestörte Gast-Erstellung, damit Ihre echte Warenkorbzuordnung wieder funktioniert. Und es zeigt die Wahrheit im Backoffice: eine Bot-gegen-Mensch-Aufschlüsselung Ihrer Warenkörbe und Ihre echte Abbruchrate, plus Warenkorb-Intelligenz pro Besucher, alles aus der Administration konfigurierbar, ohne Core-Overrides, also upgradefest. Kurz gesagt: Es verwandelt die manuelle Untersuchung aus diesem Artikel in eine Einstellung, die Sie einmal aktivieren.

Häufig gestellte Fragen

Warum füllt sich meine PrestaShop-Warenkorb-Tabelle mit leeren Warenkörben, die nie konvertieren?

In den meisten Fällen ist es Storebot-Google, ein dedizierter Google-Crawler, getrennt vom seitenindexierenden Googlebot, der überprüft, ob Ihre Google-Shopping-Einträge der Wahrheit entsprechen. Er lädt eine Produktseite, legt den Artikel in den Warenkorb, um den Preisabgleich zu prüfen, tastet sich in Richtung Lieferung vor, um Versandkosten und Steuern auszulesen, und geht dann, ohne zu bestellen. Jeder Besuch hinterlässt einen einzeiligen Warenkorb mit id_customer = 0, id_guest = 0, id_carrier = 0 und leerem Secure Key. Das ist Prüfung, kein Warenkorbabbruch.

Sollte ich Storebot blockieren, um die Phantom-Warenkörbe zu stoppen?

Nein. Das ist der teure Fehler. Googles Dokumentation sagt ausdrücklich, dass es dringend empfohlen ist, dem Crawler Zugriff auf Ihre Seiten zu geben. Blockieren Sie den User-Agent, den Warenkorb-POST oder (am schlimmsten) die IP-Bereiche, riskieren Ihre Produkte Ablehnungen wegen Zielseiten- und Preisabweichungen im Merchant Center und verschwinden aus Shopping-Anzeigen und kostenlosen Einträgen. Die Bereiche 66.249.* und 66.102.* werden mit dem regulären Googlebot geteilt; eine Firewall-Sperre kann also auch Ihre Sichtbarkeit in der organischen Suche gefährden. Lassen Sie den Crawler zu, bereinigen Sie die Spuren.

Wie bestätige ich, dass ein Warenkorb vom echten Storebot und nicht von einem echten Käufer erstellt wurde?

Prüfen Sie gegen das Zugriffsprotokoll, nicht gegen die Warenkorb-Tabelle. Die leere Gaststruktur allein ist kein verlässlicher Bot-Marker, weil ein echter Käufer ohne Cookie, der unter Full-Page-Cache mit einem gclid ankommt, einen identischen verwaisten Warenkorb erzeugt. Prüfen Sie User-Agent und Quell-IP im Zugriffsprotokoll Ihres Webservers, und führen Sie dann eine vorwärts bestätigte Reverse-DNS-Prüfung aus: Die IP sollte zu einem *.google.com / google-proxy-*-Hostnamen auflösen, der vorwärts wieder auf dieselbe IP zeigt. Wenn das fehlschlägt, ist es ein Nachahmer, der sich als Google ausgibt.

Welche PrestaShop-spezifische Falle gibt es beim Schreiben von Cleanup-SQL für Bot-Warenkörbe?

Die Zeitzone. PrestaShop schreibt date_add mit der PHP-Uhr, nicht mit der MySQL-Uhr. Auf einem Host, auf dem sich die Datenbank-Zeitzone von der PHP-Zeitzone unterscheidet, kann ein Altersfilter auf Basis von DATE_SUB(NOW(), ...) jeden Warenkorb falsch beurteilen und stillschweigend nichts oder die falschen Zeilen löschen. Berechnen Sie Ihren Cutoff mit der Anwendungsuhr, löschen Sie die passenden ps_cart_product-Zeilen immer zusammen mit den ps_cart-Zeilen, und sichern Sie den Löschvorgang so ab, dass er nie einen Warenkorb mit Bestellung, Kunde oder Adresse berührt.

Kann ich Storebots Crawling begrenzen, ohne die Prüfung zu gefährden?

Ja, lenken Sie ihn nur von nicht kommerziellen URLs weg, niemals von Produktseiten oder der Warenkorb-Route. Ein sicherer robots.txt-Block zielt auf Parameter-URLs ohne kommerziellen Wert:

User-agent: Storebot-Google
Disallow: /*?order=
Disallow: /*?utm_
Allow: /

Denken Sie daran: Disallow verhindert das Crawling dieser URLs, nicht die Indexierung von Seiten, die anderswo verlinkt sind. Es ist ein Werkzeug für das Crawl-Budget, keine Indexsteuerung. Halten Sie Produktseiten und die Warenkorb-Route vollständig crawlbar, damit die Prüfung weiterhin gelingt.

Sicher erledigen ohne Entwickler

Der oben beschriebene Ablauf „erst verifizieren, dann bereinigen“, Protokollauswertung, vorwärts bestätigtes Reverse DNS, zeitzonensicherer Cron, abgesicherte Löschvorgänge, ist manuell aufwendig zu pflegen. Spam Cart Blocker klassifiziert Warenkörbe, indem es die Identität des Crawlers prüft (ein verifizierter Storebot wird erkannt, ein UA-fälschender Nachahmer nicht), bereinigt echte Bot-Warenkörbe nach TTL, während alles mit Bestellung, Kunde oder echter Sitzung unangetastet bleibt, blockiert Google nie und zeigt Ihre echte Abbruchrate im Backoffice. Wenn Ihr Shop bereits unter Bot-Warenkörben begraben ist, übernimmt unser Cleanup Revolution die geplante Datenbankbereinigung, und Google Analytics GA4 hält die Konversionszahlen sauber, sobald das Crawler-Rauschen herausgefiltert ist.

Ausblick: Storebot ist der Anfang, nicht das Ende

Storebots Crawling nimmt zu, nicht ab, weil Google auf KI-Shopping-Agenten hinarbeitet, die im Auftrag eines Kunden handeln, Preise prüfen, Lagerbestand kontrollieren und möglicherweise Käufe über Ihre Kasse abschließen. Wie auch immer Sie diese Richtung bewerten: Die praktische Konsequenz für einen PrestaShop-Händler ist dieselbe, die dieser Artikel durchgehend betont hat. Die Shops, deren Produktdaten, strukturierte Daten, Produktseiten und Warenkorb eine konsistente Geschichte erzählen, sind die Shops, denen ein Crawler. Ob menschlich angestoßen oder agentengesteuert, vertrauen kann. Shops mit Preisabweichungen, versteckten Nicht-vorrätig-Buttons und einer ps_cart-Tabelle voller ungeprüfter Altlasten werden herausgefiltert, bevor ein Käufer sie überhaupt sieht.

Die Quintessenz lautet also nicht: „Löschen Sie die merkwürdigen Warenkörbe.“ Sondern: Bestätigen Sie, was sie sind, begrüßen Sie die Prüfung, die Ihre Einträge live hält, und räumen Sie danach nach PrestaShop-Regeln auf, mit abgesicherten Löschvorgängen, zeitzonenkorrektem Cron und Analysen, die Menschen statt Crawler zählen. Wenn Sie das richtig umsetzen, ist Storebot kein Rätsel in Ihrer Datenbank mehr, sondern das, was er immer sein sollte: eine kostenlose, kontinuierliche Prüfung, die bestätigt, dass Ihr Shop verkaufsbereit ist.