Google Storebot robi zakupy w Twoim sklepie PrestaShop: co merchant musi wiedzieć w 2026

Otwórz siatkę Klienci → Koszyki w back office PrestaShop, a możesz zobaczyć coś, co wygląda alarmująco: setki koszyków bez nazwy klienta, bez adresu, bez przewoźnika — tylko produkt, znacznik czasu i nic więcej. Dzień po dniu, równym strumieniem, bez konwersji. Pierwszy odruch podpowiada, że coś jest zepsute albo że sklep jest atakowany. Zwykle nie jest prawdą ani jedno, ani drugie. W większości przypadków winny jest crawler Google o nazwie Storebot, który robi dokładnie to, do czego Google go zaprojektował: dosłownie robi zakupy w Twoim sklepie, żeby sprawdzić, czy listingi Google Shopping mówią prawdę.

Ten wpis dotyczy właśnie tego zjawiska w PrestaShop — czym jest Storebot, jak potwierdzić, że to on wypełnia tabelę ps_cart (a nie bot, którego naprawdę należy zablokować), dlaczego blokowanie go jest kosztownym błędem i co zrobić zamiast tego. Sprawdzaliśmy to bezpośrednio na kilku działających sklepach PrestaShop w 2026 roku, więc ścieżki w back office, kształt danych w bazie i kroki weryfikacji poniżej są realne, nie teoretyczne.

Czym naprawdę jest Storebot-Google

Storebot to dedykowany crawler Google, oddzielny od Googlebota indeksującego strony dla wyników organicznych. Jego zadaniem jest weryfikacja ecommerce: ładuje stronę produktu, odczytuje cenę i dostępność, a potem testuje, czy prawdziwy klient mógłby faktycznie kupić produkt, dodając go do koszyka i przechodząc w stronę checkout. Renderuje JavaScript jak prawdziwa przeglądarka, co w PrestaShop ma znaczenie, bo domyślny theme dodaje produkt do koszyka przez AJAX.

Rozpoznasz go po user agencie, który zawiera dosłowny token Storebot-Google:

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

Podczas typowej wizyty ładuje stronę produktu, wysyła request dodania do koszyka (POST obsługiwany przez CartController PrestaShop — controller_class to cart, niezależnie od tego, czy zlokalizowany URL mówi /cart, /panier czy /warenkorb), sprawdza, czy suma koszyka zgadza się z ceną na stronie produktu, zagląda w stronę kroków adresu i dostawy, żeby odczytać wysyłkę oraz podatek, a potem wychodzi bez zamówienia. Ten ostatni krok sprawia, że zostaje stos jednoproduktowych porzuconych koszyków. To weryfikacja, nie porzucenie w sensownym znaczeniu tego słowa.

Dlaczego te koszyki wyglądają w PrestaShop właśnie tak

Kształt takiego phantom cart jest konkretny i rozpoznawalny. Gdy analizowaliśmy je na sklepach produkcyjnych, każdy koszyk Storebota miał ten sam odcisk w ps_cart:

• id_customer = 0 — brak zalogowanego klienta
• id_guest = 0 — brak powiązanego rekordu sesji gościa
• id_carrier = 0 oraz id_address_delivery = 0 — nigdy nie dotarł do wyboru dostawy
• secure_key = '' — pusty

Jest konkretny, prestashopowy powód, dla którego te koszyki w ogóle powstają. CartController::updateCart od dawna sprawdzał $this->context->cookie->exists() przed pozwoleniem na zmianę koszyka — zabezpieczenie mające ograniczać właśnie takie ghost carts (nowsze gałęzie mocniej opierają się na sprawdzeniu Connection::isBot()). W sklepach, które oglądaliśmy, bot mimo to przechodził, bo warstwa full-page cache (dynamiczny AJAX add-to-cart, którego używa) podaje botowi cookie bez id_guest. Sam rekord gościa zwykle tworzy hook statystyk w nagłówku strony; przy full-page cache ten hook często się nie wykonuje, więc front controller buduje koszyk z id_guest = 0 i pustym secure key.

Co to oznacza dla Ciebie? Dwie rzeczy. Po pierwsze, kształt pustego gościa jest efektem ubocznym cache, a nie dowodem na bota — i to prowadzi bezpośrednio do następnej sekcji. Po drugie, ponieważ nie ma powiązanej sesji gościa, własne mechanizmy PrestaShop do odzyskiwania koszyków i atrybucji odwiedzających po cichu psują się dla tych rekordów: nie ma komu wysłać e-maila, nie ma czego powiązać z sesją, a mimo to rekordy nadal leżą w tabelach i zawyżają każdą liczbę.

Najpierw potwierdź, że to naprawdę Storebot — nie zgaduj

To krok pomijany przez większość porad typu „po prostu usuń koszyki”, a właśnie on chroni Cię przed usuwaniem realnych klientów. Kształt koszyka z pustym gościem nie jest sam w sobie wiarygodnym markerem bota. W sklepie PrestaShop działającym z full-page cache i pustą tabelą ps_connections prawdziwy klient bez cookie — na przykład ruch z reklamy płatnej z gclid i bez wcześniejszego cookie — tworzy identyczny osierocony koszyk. Jeśli czyścisz wyłącznie po kształcie, możesz usunąć realne porzucone koszyki i zepsuć własny lejek odzyskiwania.

Weryfikuj w access logu, nie w tabeli koszyków. Dwa sprawdzenia, w tej kolejności:

• User agent + źródło IP. Znajdź requesty, które utworzyły koszyki, w prawdziwym access logu serwera WWW (na nginx zwykle /var/log/nginx/access.log; pamiętaj, że domlogi Apache często wykluczają ruch proxy, więc sprawdź właściwy plik). Prawdziwe requesty Storebota pochodzą z zakresów Google — potwierdzaliśmy trafienia z 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x i 192.178.11.x.
• Forward-confirmed reverse DNS. Nie ufaj samemu IP ani samemu stringowi UA — oba da się podrobić. Uruchom reverse DNS lookup dla IP (prawdziwe trafienia Google rozwiązują się do *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), potem rozwiąż ten hostname z powrotem i potwierdź, że zwraca to samo IP. Storebot-Google respektuje robots.txt (patrz ostatnia sekcja), a Google publikuje zakresy IP crawlerów w oficjalnej dokumentacji IP crawlerów — sprawdź plik dla właściwej kategorii crawlera, żeby potwierdzić zweryfikowane IP Storebota, zamiast zakładać, że jedna lista pokrywa wszystko.

Jeśli UA twierdzi, że jest Storebotem, ale forward-confirmed reverse DNS nie przechodzi, patrzysz na spoofera udającego Google — i ten ruch możesz potraktować inaczej. Zweryfikowane requesty muszą zostać.

Dlaczego blokowanie Storebota to drogi błąd

Kuszący ruch — reguła firewalla, Disallow w robots.txt, 403 na trasie koszyka dla tego UA — obraca się przeciwko sklepowi, i to przez system, którego nie kontrolujesz: Google Merchant Center.

• Zablokuj UA, a produkty mogą zostać odrzucone. Dokumentacja Google jasno mówi, że dopuszczenie crawlera do stron jest „highly encouraged”. Jeśli Storebot nie może zweryfikować checkout, produkty ryzykują odrzucenia za landing page i rozbieżność cen, a potem wypadają z Shopping ads i free listings.
• Nie blokuj też samego POST do koszyka. Pozwolenie na odczyt stron produktów, ale blokowanie dodania do koszyka psuje dokładnie to, co Storebot ma weryfikować — zgodność ceny w koszyku — co samo w sobie może uruchomić odrzucenie.
• Nigdy nie blokuj zakresów IP na firewallu. Zakresy 66.249.* i 66.102.* są współdzielone ze zwykłym Googlebotem. Zablokuj je, a wyindeksujesz sklep także z wyników organicznych — to znacznie większa strata niż kilka dodatkowych rekordów koszyka.

Uczciwe ujęcie jest takie: wizyta Storebota to darmowy audyt potwierdzający, że listingi są dokładne, a dokładne listingi są częściej wyświetlane. Chcesz, żeby crawlowal sklep. Problemem do rozwiązania nie jest crawler — tylko śmieci, które zostawia.

Realny koszt: bot carts okłamują analitykę

Phantom carts to nie tylko bałagan. Po cichu zatruwają liczby, na których opierasz decyzje:

• Współczynnik porzuceń jest fikcją. Jeśli Storebot tworzy siedem koszyków na godzinę i prawie żaden nie konwertuje, wskaźnik koszyk-zamówienie w back office wygląda dużo gorzej niż w rzeczywistości. Widzieliśmy okresy, w których bot carts przewyższały realne koszyki kilka do jednego w ciągu kilku dni.
• Tabele ps_cart i ps_cart_product rosną bez końca, a na hostingach ze skromnymi zasobami bazy ten ciężar objawia się wolnymi zapytaniami koszyka i admina.
• Automatyzacje odzyskiwania marnują pracę. Ponieważ te rekordy nie mają realnego klienta ani użytecznej sesji, proces odzyskiwania koszyków albo je pomija (najlepszy przypadek), albo spala zasoby, próbując działać na kontakcie, który nie istnieje.

Decydowanie, które koszyki są botami, a które realne, zanim zaufasz jakiejkolwiek liczbie konwersji, to ta sama dyscyplina, na której opiera się całe mierzenie sklepu — wiedza, co liczyć, a co ignorować. Ten sposób myślenia omawiamy w analytics for online stores: what to track and what to ignore, a wersję filtrowania tego szumu dla GA4 w the GA4 metrics that actually matter.

Co zrobić zamiast tego: zostaw crawlera, sprzątaj pozostałości

1. Upewnij się, że Storebot znajduje dokładnie to, co obiecał feed

Najskuteczniejszy ruch to dać crawlerowi czystą weryfikację, żeby wizyta przeszła i niczego nie uruchomiła. Feed, dane strukturalne, strona produktu, koszyk i checkout muszą zgadzać się co do ceny (w tym podatku i waluty) oraz dostępności. W PrestaShop oznacza to, że moduł feedu czyta aktualne ceny i stany, a strony produktów mają poprawny markup schema.org/Product z price, priceCurrency, availability i brand. Jeśli wysyłasz listingi przez Merchant API, potwierdź, że moduł feedu obsługuje v1 — stary Content API for Shopping jest wycofywany w 2026 roku, więc przestarzały moduł feedu to tykające źródło rozbieżności.

2. Dobrze obsłuż strony produktów niedostępnych

Google oczekuje, że strona produktu bez stanów jasno pokazuje niedostępność, uniemożliwia zakup i że dostępność dokładnie zgadza się z feedem oraz danymi strukturalnymi. Widocznie wyłączony przycisk kupna (wyszarzony, z atrybutem HTML disabled) jest akceptowalnym wdrożeniem, o ile pozostaje spójny z feedem i availability w schema. Wiele theme PrestaShop zamiast tego całkowicie ukrywa przycisk add-to-cart, gdy stan spada do zera — sprawdź product.tpl / szablon produktu swojego theme. Storebot testuje to bezpośrednio: nie powinien móc dodać produktu niedostępnego i musi móc dodać produkt dostępny.

3. Czyść bot carts według harmonogramu — ale zabezpiecz delete

Okresowe czyszczenie to praktyczna naprawa rozrostu bazy, a koszyki da się zidentyfikować: id_customer = 0, id_guest = 0 (albo rekord gościa z UA Storebota), id_carrier = 0, id_address_delivery = 0, utworzone ze zweryfikowanego IP Google. Część z zabezpieczeniem jest tak samo ważna jak dopasowanie: przed usunięciem potwierdź, że koszyk nie ma powiązanego zamówienia, klienta, adresów i (zgodnie z sekcją wyżej) został utworzony przez forward-confirmed IP Storebota — nigdy wyłącznie po kształcie.

Jedna ostra pułapka specyficzna dla PrestaShop, jeśli piszesz własny cleanup SQL albo cron: PrestaShop zapisuje wartości date_add używając zegara PHP, nie MySQL. Na hoście, gdzie timezone bazy różni się od timezone PHP, filtr wieku oparty o NOW() / DATE_SUB(NOW(), ...) może uznać każdy koszyk za świeżo aktywny i po cichu nie usunąć niczego (albo usunąć złe rekordy). Wylicz cutoff z zegara aplikacji i zawsze usuwaj pasujące rekordy ps_cart_product razem z rekordami ps_cart, żeby nie zostawiać osieroconych pozycji.

4. Trzymaj bot carts poza raportowaniem i odzyskiwaniem

Prawdziwa liczba porzuceń to ta liczona wyłącznie z koszyków z realnym klientem albo zidentyfikowaną sesją gościa. Wyklucz anonimowe, zweryfikowane koszyki botów z lejka konwersji i upewnij się, że każda automatyzacja odzyskiwania koszyków je filtruje, żeby nie działała na rekordach, które nigdy nie były osobą. Ten sam rozdział pozwala w końcu raportować realny wskaźnik koszyk-zamówienie zamiast wartości zawyżonej przez Storebota — czystą, właścicielską liczbę, która pasuje do zaawansowanego raportowania sklepu.

5. Ogranicz crawl niekomercyjny przez robots.txt (nie dotykaj produktu ani koszyka)

Możesz ograniczyć zmarnowany crawl bez ryzykowania weryfikacji, kierując Storebota z dala od URL-i bez wartości komercyjnej — nigdy od stron produktów ani samej trasy koszyka:

User-agent: Storebot-Google — potem Disallow: /*?order=, Disallow: /*?utm_, a na końcu Allow: /, żeby cała reszta, w tym strony produktów i trasa koszyka, pozostała crawlable.

Jak zrobić to bez developera: Spam Cart Blocker

Workflow „zweryfikuj, potem bezpiecznie usuń” powyżej jest poprawny, ale ręczne utrzymanie go — parsowanie logów, forward-confirmation reverse DNS, cron odporny na timezone, zabezpieczone delete, które nigdy nie dotykają realnego zamówienia — to dużo pracy. Zbudowaliśmy Spam Cart Blocker dla własnych sklepów właśnie dlatego, że dostępne alternatywy robiły to niebezpiecznie źle: nieliczne moduły w tej przestrzeni albo blokują koszyki botów (co, jak wyżej, może zawiesić produkty w Merchant Center), albo wykonują tępe usuwanie po wieku bez wiedzy, czy koszyk był botem, czy realnym klientem bez cookie.

Co to robi dla Ciebie? Klasyfikuje koszyki, sprawdzając tożsamość crawlera przez forward-confirmed reverse DNS — więc zweryfikowany Storebot jest rozpoznany, a impostor spoofujący UA nie — potem taguje i TTL-purge'uje prawdziwe bot carts, zostawiając nietknięte wszystko, co ma zamówienie, klienta, adres albo realną sesję. Nigdy nie blokuje Google, więc listingi pozostają bezpieczne. Naprawia zepsute tworzenie gościa pod full-page cache, dzięki czemu realna atrybucja koszyków zaczyna znowu działać. I pokazuje prawdę w back office: podział koszyków bot-vs-human oraz realny współczynnik porzuconych koszyków, plus inteligencję koszyka per visitor — wszystko konfigurowane z admina, bez core overrides, więc przetrwa aktualizacje. Krótko mówiąc, zamienia ręczne dochodzenie z tego artykułu w ustawienie, które zaznaczasz raz.

Co dalej: Storebot to początek, nie koniec

Crawlowanie Storebota rośnie, a nie zanika, bo Google zmierza w stronę agentów zakupowych AI działających w imieniu klienta — weryfikujących ceny, sprawdzających stany i potencjalnie finalizujących zakupy przez checkout. Niezależnie od tego, co sądzisz o tym kierunku, praktyczna konsekwencja dla merchantów PrestaShop jest taka sama, jak argumentowaliśmy przez cały artykuł: sklepy, których feed, dane strukturalne, strony produktów i koszyk opowiadają jedną spójną historię, są tymi, którym crawler — prowadzony przez człowieka albo agenta — może zaufać. Te z rozbieżnościami cen, ukrytymi przyciskami produktów niedostępnych i tabelą ps_cart pełną niesprawdzonego śmiecia zostają odfiltrowane, zanim kupujący w ogóle je zobaczy.

Wniosek nie brzmi więc „usuń dziwne koszyki”. Brzmi: potwierdź, czym są, przyjmij weryfikację, która utrzymuje listingi online, i posprzątaj po niej na zasadach PrestaShop — zabezpieczone delete, cron zgodny z timezone i analityka, która liczy ludzi zamiast crawlerów. Gdy to zrobisz, Storebot przestaje być zagadką w bazie danych i staje się tym, czym miał być od początku: darmowym, ciągłym audytem potwierdzającym, że sklep jest gotowy sprzedawać.