Google Storebot robi zakupy w Twoim sklepie PrestaShop: co sprzedawcy powinni wiedzieć w 2026 roku

Otwórz w panelu administracyjnym PrestaShop siatkę Klienci → Koszyki, a możesz zobaczyć coś, co wygląda niepokojąco: setki koszyków bez nazwy klienta, bez adresu, bez przewoźnika, tylko produkt, znacznik czasu i nic więcej. Dzień po dniu, regularnie, bez żadnej konwersji. Pierwszy odruch podpowiada, że coś się zepsuło albo że sklep jest atakowany. Ani jedno, ani drugie zwykle nie jest prawdą. W większości przypadków winowajcą jest robot Google o nazwie Storebot, który robi dokładnie to, do czego Google go zaprojektowało: dosłownie robi zakupy w Twoim sklepie, aby sprawdzić, czy oferty w Google Shopping pokazują prawdę.

Ten artykuł dotyczy właśnie tego zjawiska w PrestaShop. Czym jest Storebot, jak potwierdzić, że to on zapełnia tabelę ps_cart (a nie robot, którego faktycznie należałoby zablokować), dlaczego blokowanie go jest kosztownym błędem i co zrobić zamiast tego. W 2026 roku sprawdziliśmy to bezpośrednio w kilku działających sklepach PrestaShop, więc ścieżki w panelu administracyjnym, układ danych w bazie i kroki weryfikacji opisane poniżej są konkretne, a nie teoretyczne.

Ostatnia aktualizacja: czerwiec 2026.

Czym naprawdę jest Storebot-Google

Storebot to wyspecjalizowany robot Google, oddzielny od Googlebota indeksującego strony na potrzeby wyników organicznych. Jego zadaniem jest weryfikacja e-commerce: ładuje stronę produktu, odczytuje cenę i dostępność, a następnie sprawdza, czy prawdziwy klient mógłby faktycznie kupić dany produkt, dodając go do koszyka i przechodząc w stronę finalizacji zakupu. Renderuje JavaScript jak prawdziwa przeglądarka, co w PrestaShop ma znaczenie, bo domyślny motyw dodaje produkty 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 żądanie dodania do koszyka (POST obsługiwany przez CartController w PrestaShop, controller_class to cart, niezależnie od tego, czy Twój lokalizowany URL zawiera /cart, /panier czy /warenkorb), sprawdza, czy suma w koszyku zgadza się z ceną na stronie produktu, przechodzi kontrolnie w stronę kroków adresu i dostawy, aby odczytać koszt wysyłki oraz podatki, po czym wychodzi bez złożenia zamówienia. Ten ostatni krok sprawia, że zostaje po nim stos jednopozycyjnych porzuconych koszyków. To weryfikacja, a nie porzucenie koszyka w sensie biznesowym.

Dlaczego te koszyki tak wyglądają w PrestaShop

Kształt fikcyjnego koszyka jest charakterystyczny i łatwy do rozpoznania. Gdy analizowaliśmy je w sklepach produkcyjnych, każdy koszyk Storebota miał ten sam odcisk palca w ps_cart:

• id_customer = 0, brak zalogowanego klienta
• id_guest = 0, brak powiązanego rekordu sesji gościa
• id_carrier = 0 i id_address_delivery = 0, koszyk nigdy nie doszedł do wyboru dostawy
• secure_key = '', pusta wartość

Jest konkretny, prestashopowy powód, dla którego te koszyki w ogóle powstają. CartController::updateCart od dawna sprawdza $this->context->cookie->exists(), zanim pozwoli operacji dodania produktu zmienić koszyk, to zabezpieczenie miało ograniczać dokładnie takie koszyki-widma (nowsze gałęzie mocniej opierają się na sprawdzeniu Connection::isBot()). W sklepach, które analizowaliśmy, robot mimo to przechodził dalej, ponieważ warstwa full-page cache (dynamiczne dodawanie do koszyka przez AJAX, z którego korzysta) przekazuje mu ciasteczko bez id_guest. Sam rekord gościa zwykle tworzy dopiero hook statystyk w nagłówku strony; przy pełnym cache'u stron ten hook często się nie uruchamia, więc front controller buduje koszyk z id_guest = 0 i pustym kluczem bezpieczeństwa.

Co to oznacza dla Ciebie? Dwie rzeczy. Po pierwsze, koszyk bez gościa to skutek uboczny cache'owania, a nie dowód na obecność robota, i to prowadzi bezpośrednio do następnej sekcji. Po drugie, ponieważ nie ma powiązanej sesji gościa, wbudowane w PrestaShop odzyskiwanie koszyków i atrybucja odwiedzających po cichu przestają działać dla tych rekordów: nie ma do kogo wysłać wiadomości, nie ma czego powiązać z sesją, a mimo to rekordy nadal leżą w tabelach i zawyżają wszystkie liczniki.

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

To krok pomijany przez większość porad w stylu „po prostu usuń koszyki”, a właśnie on chroni Cię przed skasowaniem prawdziwych klientów. Sam kształt koszyka bez gościa nie jest wiarygodnym znacznikiem robota. W sklepie PrestaShop działającym z full-page cache i pustą tabelą ps_connections prawdziwy kupujący bez ciasteczek, na przykład ruch z płatnej reklamy przychodzący z parametrem gclid i bez wcześniejszego cookie, tworzy identyczny osierocony koszyk. Jeśli czyścisz tylko po kształcie danych, możesz usunąć prawdziwe porzucone koszyki i uszkodzić własny lejek odzyskiwania.

Weryfikuj log dostępu, nie tabelę koszyków. Dwa sprawdzenia, w tej kolejności:

• User agent + źródło IP. Znajdź żądania, które utworzyły koszyki, w rzeczywistym logu dostępu serwera WWW (w nginx zwykle jest to /var/log/nginx/access.log; pamiętaj, że domlogi Apache często nie obejmują ruchu proxy, więc sprawdź właściwy plik). Prawdziwe żądania Storebota pochodzą z zakresów Google, potwierdziliśmy wejścia z 64.233.172.x, 66.102.8.x, 66.249.92.x, 72.14.199.x i 192.178.11.x.
• Odwrotny DNS potwierdzony ponownym rozwiązaniem nazwy. Nie ufaj samemu adresowi IP ani samemu ciągowi UA. Jedno i drugie można podrobić. Wykonaj odwrotne zapytanie DNS dla IP (prawdziwe wejścia Google rozwiązują się do *.google.com / google-proxy-* / rate-limited-proxy-*.google.com), a następnie rozwiąż tę nazwę hosta z powrotem i potwierdź, że zwraca ten sam adres IP. Storebot-Google respektuje robots.txt (patrz ostatnia sekcja), a Google publikuje zakresy IP robotów w oficjalnej dokumentacji adresów IP robotów, sprawdź plik dla odpowiedniej kategorii robota, aby potwierdzić zweryfikowany adres IP Storebota, zamiast zakładać, że jedna lista obejmuje wszystko.

Jeśli UA podaje Storebota, ale kontrola odwrotnego DNS i ponownego rozwiązania nazwy się nie zgadza, patrzysz na podszywającego się bota udającego Google, i ten ruch możesz traktować inaczej. Zweryfikowane wejścia muszą zostać wpuszczone.

Dlaczego blokowanie Storebota to kosztowny błąd

Kuszący ruch, reguła firewalla, Disallow w robots.txt, kod 403 na ścieżce koszyka dla tego UA, obraca się przeciwko Tobie, i to przez system, nad którym nie masz kontroli: Google Merchant Center.

• Zablokujesz UA, a Twoje produkty mogą zostać odrzucone. Dokumentacja Google jasno mówi, że umożliwienie robotowi dostępu do stron jest zdecydowanie zalecane. Jeśli Storebot nie może zweryfikować finalizacji zakupu, produkty ryzykują odrzucenie z powodu strony docelowej lub niezgodności ceny, a następnie znikają z reklam Shopping i bezpłatnych informacji o produktach.
• Nie wycinaj też samego POST-a koszyka. Zezwolenie na odczyt stron produktów przy jednoczesnym blokowaniu dodania do koszyka psuje dokładnie to, co Storebot ma sprawdzać, zgodność ceny w koszyku, a to samo w sobie jest powodem odrzucenia.
• Nigdy nie blokuj zakresów IP na firewallu. Zakresy 66.249.* i 66.102.* są współdzielone ze zwykłym Googlebotem. Zablokujesz je, a przy okazji usuniesz sklep z indeksu wyszukiwania organicznego, to znacznie większa strata niż kilka dodatkowych rekordów koszyka.

Uczciwie rzecz ujmując: wizyta Storebota to darmowy audyt potwierdzający, że Twoje oferty są dokładne, a dokładne oferty częściej się wyświetlają. Chcesz, żeby robot odwiedzał sklep. Problemem do rozwiązania nie jest robot, tylko ślady, które po sobie zostawia.

Prawdziwy koszt: koszyki botów zakłamują analitykę

Fikcyjne koszyki to nie tylko bałagan. Po cichu psują liczby, na których opierasz decyzje:

• Wskaźnik porzuceń koszyka staje się fikcją. Jeśli Storebot tworzy siedem koszyków na godzinę i prawie żaden nie kończy się zamówieniem, współczynnik koszyk-zamówienie w panelu administracyjnym wygląda znacznie gorzej niż w rzeczywistości. Widzieliśmy okresy, w których koszyki botów kilkukrotnie przewyższały liczbę prawdziwych koszyków w ciągu zaledwie kilku dni.
• Tabele ps_cart i ps_cart_product rosną bez końca, a na hostingach ze skromniejszymi zasobami bazy danych odbija się to wolnymi zapytaniami koszyka i panelu administracyjnego.
• Automatyzacje odzyskiwania marnują zasoby. Ponieważ te rekordy nie mają prawdziwego klienta ani użytecznej sesji, każdy proces odzyskiwania koszyków albo je pomija (najlepszy przypadek), albo traci cykle na próbę działania na kontakcie, który nie istnieje.

Ustalenie, które koszyki są botami, a które prawdziwe, zanim zaufasz jakiejkolwiek liczbie konwersji, to ta sama dyscyplina, na której opiera się całe mierzenie sklepu, wiedzieć, co liczyć, a co ignorować. Omawiamy to podejście w artykule analityka dla sklepów internetowych: co mierzyć, a co ignorować, a wersję filtrowania tego szumu specyficzną dla GA4 w tekście o metrykach GA4, które naprawdę mają znaczenie.

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

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

Najskuteczniejszy krok to zapewnić robotowi czystą weryfikację, aby jego wizyta przeszła bez wywoływania problemów. Plik produktowy, dane strukturalne, strona produktu, koszyk i finalizacja zakupu muszą zgadzać się co do ceny (w tym podatku i waluty) oraz dostępności. W PrestaShop oznacza to, że moduł pliku produktowego odczytuje aktualne ceny i stany magazynowe, a strony produktów zawierają poprawne znaczniki schema.org/Product z price, priceCurrency, availability i brand. Jeśli wysyłasz oferty przez Merchant API, potwierdź, że moduł pliku produktowego obsługuje v1. Stare Content API for Shopping jest wycofywane w 2026 roku, więc przestarzały moduł pliku produktowego to tykające źródło niezgodności.

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

Google oczekuje, że strona produktu niedostępnego w magazynie jasno pokazuje brak dostępności, uniemożliwia zakup, a dostępność dokładnie zgadza się z plikiem produktowym i danymi strukturalnymi. Widocznie wyłączony przycisk zakupu (wyszarzony, z atrybutem HTML disabled) jest jedną z akceptowalnych implementacji, o ile pozostaje spójny z dostępnością w pliku produktowym i schemacie. Wiele motywów PrestaShop zamiast tego całkowicie ukrywa przycisk dodania do koszyka, gdy stan magazynowy spada do zera, sprawdź product.tpl / szablon produktu w swoim motywie. Storebot testuje to bezpośrednio: nie powinien móc dodać produktu niedostępnego w magazynie i musi móc dodać produkt dostępny.

3. Czyść koszyki botów według harmonogramu, ale zabezpiecz usuwanie

Okresowe czyszczenie to praktyczne rozwiązanie problemu puchnącej bazy danych, 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 adresu IP Google. Część zabezpieczająca jest równie ważna jak samo dopasowanie: przed usunięciem potwierdź, że koszyk nie ma powiązanego zamówienia, klienta ani adresów oraz że (zgodnie z sekcją powyżej) został utworzony przez adres IP Storebota potwierdzony odwrotnym DNS i ponownym rozwiązaniem nazwy, nigdy wyłącznie po kształcie danych.

Jedna ostra pułapka specyficzna dla PrestaShop, jeśli piszesz własny SQL lub cron do sprzątania: PrestaShop zapisuje wartości date_add według zegara PHP, a nie MySQL. Na hostingu, gdzie strefa czasowa bazy danych różni się od strefy PHP, filtr wieku oparty na NOW() / DATE_SUB(NOW(), ...) może błędnie uznać każdy koszyk za świeżo aktywny i po cichu nie usunąć niczego (albo usunąć złe rekordy). Wyliczaj punkt odcięcia z zegara aplikacji i zawsze usuwaj pasujące rekordy ps_cart_product razem z rekordami ps_cart, aby nie zostawiać osieroconych pozycji.

4. Nie wpuszczaj koszyków botów do raportów i odzyskiwania

Prawdziwy wskaźnik porzuceń to ten liczony wyłącznie z koszyków mających prawdziwego klienta 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, aby nie działała na rekordach, które nigdy nie należały do osoby. To samo rozdzielenie pozwala wreszcie raportować prawdziwy współczynnik koszyk-zamówienie zamiast wyniku zawyżonego przez Storebota, czyli czystą, zrozumiałą dla właściciela liczbę, która powinna znaleźć się w zaawansowanym raportowaniu sklepu.

5. Ogranicz niekomercyjne indeksowanie w robots.txt (nie ruszaj produktów ani koszyka)

Możesz zmniejszyć marnowany budżet indeksowania bez narażania weryfikacji, kierując Storebota z dala od adresów URL, które nie mają wartości handlowej, nigdy od stron produktów ani samej ścieżki koszyka:

User-agent: Storebot-Google, następnie Disallow: /*?order=, Disallow: /*?utm_, a na końcu Allow: /, aby wszystko inne, w tym strony produktów i ścieżka koszyka, pozostało dostępne dla robota.

Jak zrobić to wszystko bez programisty: Spam Cart Blocker

Opisany wyżej schemat „zweryfikuj, a potem bezpiecznie usuń” jest poprawny, ale ręczne utrzymywanie go, parsowanie logów, potwierdzanie odwrotnego DNS przez ponowne rozwiązanie nazwy, cron odporny na strefy czasowe, zabezpieczone usuwanie, które nigdy nie dotyka prawdziwego zamówienia, to sporo pracy. Zbudowaliśmy Spam Cart Blocker dla własnych sklepów właśnie dlatego, że dostępne alternatywy myliły się w niebezpieczny sposób: nieliczne moduły z tej kategorii albo blokują koszyki botów (co, jak wyjaśniliśmy wyżej, może doprowadzić do zawieszenia produktów w Merchant Center), albo wykonują tępe usuwanie po wieku, nie wiedząc, czy koszyk należał do bota, czy do prawdziwego kupującego bez ciasteczek.

Co więc robi dla Ciebie? Klasyfikuje koszyki, sprawdzając tożsamość robota przez odwrotny DNS i ponowne rozwiązanie nazwy, dzięki temu zweryfikowany Storebot zostaje rozpoznany, a podszywający się oszust z podrobionym UA nie. Następnie oznacza i usuwa po TTL prawdziwe koszyki botów, zostawiając nietknięte wszystko, co ma zamówienie, klienta, adres albo prawdziwą sesję. Nigdy nie blokuje Google, więc Twoje oferty pozostają bezpieczne. Naprawia zaburzone tworzenie gościa przy full-page cache, dzięki czemu atrybucja prawdziwych koszyków zaczyna znowu działać. I pokazuje prawdę w panelu administracyjnym: podział koszyków na boty i ludzi, rzeczywisty wskaźnik porzuconych koszyków oraz inteligencję koszyków per odwiedzający: wszystko konfigurowane z panelu, bez nadpisywania core, więc przetrwa aktualizacje. Krótko mówiąc, zamienia ręczne dochodzenie z tego artykułu w ustawienie, które zaznaczasz raz.

Najczęściej zadawane pytania

Dlaczego tabela koszyków w moim PrestaShop zapełnia się pustymi koszykami, które nigdy nie konwertują?

W większości przypadków to Storebot-Google, wyspecjalizowany robot Google, oddzielny od indeksującego strony Googlebota, sprawdzający, czy oferty w Google Shopping mówią prawdę. Ładuje stronę produktu, dodaje produkt do koszyka, aby sprawdzić zgodność ceny, przechodzi kontrolnie w stronę dostawy, żeby odczytać koszt wysyłki i podatek, a potem wychodzi bez złożenia zamówienia. Każda wizyta zostawia jednopozycyjny koszyk z id_customer = 0, id_guest = 0, id_carrier = 0 i pustym kluczem bezpieczeństwa. To weryfikacja, nie porzucenie koszyka.

Czy powinienem zablokować Storebota, żeby zatrzymać fikcyjne koszyki?

Nie, to kosztowny błąd. Dokumentacja Google jasno mówi, że umożliwienie robotowi dostępu do stron jest zdecydowanie zalecane. Zablokuj user agenta, POST koszyka albo, najgorzej, zakresy IP, a Twoje produkty ryzykują odrzucenia w Merchant Center z powodu strony docelowej i niezgodności ceny, przez co wypadną z reklam Shopping i bezpłatnych informacji o produktach. Zakresy 66.249.* i 66.102.* są współdzielone ze zwykłym Googlebotem, więc blokada na firewallu usuwa Cię też z indeksu wyszukiwania organicznego. Zostaw robota, sprzątaj pozostałości.

Jak potwierdzić, że koszyk utworzył prawdziwy Storebot, a nie prawdziwy kupujący?

Weryfikuj log dostępu, nie tabelę koszyków. Sam kształt koszyka bez gościa nie jest wiarygodnym znacznikiem robota, ponieważ prawdziwy kupujący bez ciasteczek, przychodzący z gclid przy full-page cache, tworzy identyczny osierocony koszyk. Sprawdź user agenta i źródłowy adres IP w logu dostępu serwera WWW, a potem wykonaj kontrolę odwrotnego DNS potwierdzoną ponownym rozwiązaniem nazwy: IP powinno rozwiązać się do nazwy hosta *.google.com / google-proxy-*, która po ponownym rozwiązaniu wskazuje ten sam adres IP. Jeśli to się nie zgadza, masz do czynienia z podszywającym się botem udającym Google.

Jaka jest pułapka specyficzna dla PrestaShop przy pisaniu SQL-a do czyszczenia koszyków botów?

Strefa czasowa. PrestaShop zapisuje date_add według zegara PHP, a nie MySQL. Na hostingu, gdzie strefa czasowa bazy danych różni się od strefy PHP, filtr wieku oparty na DATE_SUB(NOW(), ...) może błędnie ocenić każdy koszyk i po cichu nie usunąć niczego albo usunąć niewłaściwe rekordy. Wyliczaj punkt odcięcia z zegara aplikacji, zawsze usuwaj pasujące rekordy ps_cart_product razem z rekordami ps_cart i zabezpiecz usuwanie tak, aby nigdy nie dotknęło koszyka z zamówieniem, klientem ani adresem.

Czy mogę ograniczyć pobieranie stron przez Storebota bez narażania weryfikacji?

Tak, kieruj go tylko z dala od niekomercyjnych adresów URL, nigdy od stron produktów ani ścieżki koszyka. Bezpieczny blok robots.txt celuje w adresy URL z parametrami bez wartości handlowej:

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

Pamiętaj, że Disallow zatrzymuje pobieranie tych adresów URL przez robota, a nie indeksowanie stron podlinkowanych gdzie indziej, to narzędzie do zarządzania budżetem indeksowania, nie kontrola indeksu. Zostaw strony produktów i ścieżkę koszyka w pełni dostępne dla robota, aby weryfikacja nadal przechodziła.

Jak zrobić to bezpiecznie bez programisty

Opisany wyżej proces „zweryfikuj, a potem usuń”, parsowanie logów, odwrotny DNS potwierdzony ponownym rozwiązaniem nazwy, cron odporny na strefy czasowe, zabezpieczone usuwanie. Jest trudny do ręcznego utrzymywania. Spam Cart Blocker klasyfikuje koszyki, sprawdzając tożsamość robota (więc zweryfikowany Storebot zostaje rozpoznany, a podszywający się oszust z podrobionym UA nie), usuwa po TTL prawdziwe koszyki botów, zostawiając nietknięte wszystko, co ma zamówienie, klienta albo prawdziwą sesję, nigdy nie blokuje Google i pokazuje w panelu administracyjnym rzeczywisty wskaźnik porzuconych koszyków. Jeśli Twój sklep jest już zasypany koszykami botów, nasz Cleanup Revolution obsługuje zaplanowane przycinanie bazy danych, a Google Analytics GA4 utrzymuje liczby konwersji w ryzach po odfiltrowaniu szumu od robotów.

Co dalej: Storebot to początek, nie koniec

Crawl Storebota rośnie, a nie wygasa, ponieważ Google zmierza w stronę agentów zakupowych AI działających w imieniu klienta, weryfikujących ceny, sprawdzających stany magazynowe i potencjalnie finalizujących zakupy przez Twój proces zakupowy. Niezależnie od tego, co sądzisz o tym kierunku, praktyczna konsekwencja dla sprzedawcy PrestaShop jest taka sama, jak w całym tym artykule: sklepy, w których plik produktowy, dane strukturalne, strony produktów i koszyk opowiadają jedną spójną historię, są tymi, którym robot. Prowadzony przez człowieka albo przez agenta, może zaufać. Te z rozbieżnościami cen, ukrytymi przyciskami dla produktów niedostępnych w magazynie i tabelą ps_cart pełną niesprawdzonego śmiecia są odfiltrowywane, 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 Twoje oferty aktywne, i sprzątaj po niej na warunkach PrestaShop, zabezpieczonym usuwaniem, cronem poprawnym względem stref czasowych i analityką, która liczy ludzi zamiast robotów. Zrób to dobrze, a Storebot przestanie być zagadką w bazie danych i stanie się tym, czym od początku miał być: darmowym, ciągłym audytem potwierdzającym, że Twój sklep jest gotowy do sprzedaży.