Google Shopping w 2026 roku: najgorzej wykorzystywana warstwa pozyskania w sklepach PrestaShop
W audytowanych przez nas sklepach PrestaShop ze średniej półki Google Shopping odpowiada średnio za 18 % pozyskanego obrotu. Gdy feed jest dobrze zrobiony. Gdy nie jest, a to sytuacja domyślna, spada do 3 % albo mniej, z rosnącym kosztem pozyskania i produktami odrzucanymi przez Merchant Center bez wiedzy sprzedawcy.
Różnica rozgrywa się na trzech poziomach: jakości feedu (wymagane atrybuty, GTIN, unikalne identyfikatory), strategii kampanii (Performance Max kontra Standard Shopping) i zgodności z zasadami Merchant Center (Omnibus, zwroty, dostawa). To trzy odrębne i techniczne tematy. Ten artykuł omawia je w kolejności, w jakiej pojawiają się u sprzedawcy uruchamiającego albo przebudowującego kanał Shopping w 2026 roku.
Co zmieniło się w Merchant Center w latach 2024 do 2026
Merchant Center Next zastępuje dawny interfejs
Od 2024 roku Google przeniósł wszystkie konta do Merchant Center Next, czyli przebudowy, która spłaszcza hierarchię, upraszcza tworzenie feedów i ściślej egzekwuje zasady. Konsekwencja praktyczna: feedy, które przechodziły po cichu jeszcze osiemnaście miesięcy temu, dziś bywają odrzucane hurtowo, zwłaszcza przy braku atrybutów dostawy i podatku.
Usługi porównywania cen w Unii
Po decyzji europejskiej i jej korektach sprzedawcy z Unii mogą działać bezpośrednio przez Google albo przez partnerską usługę porównywania cen (CSS), uzyskując efektywny rabat na koszcie kliknięcia. Przy budżetach Shopping powyżej kilkudziesięciu tysięcy złotych miesięcznie przejście przez partnera CSS jest opłacalne. To optymalizacja, która nic nie kosztuje we wdrożeniu, a której nie aktywuje większość sprzedawców.
Atrybuty zwrotów i dostawy stały się praktycznie obowiązkowe
Od końca 2024 roku Google wymaga jawnych informacji o dostawie i polityce zwrotów na większości kart Shopping. Bez nich reklamy działają, ale z pogorszoną widocznością i spadającą oceną jakości. Jest to spójne z właściwościami Schema.org Product, których Google wymaga już w wynikach wzbogaconych.
Anatomia zgodnego feedu produktowego w 2026 roku
Feed Google Shopping to plik (XML, CSV albo przez Content API) opisujący każdy produkt dla Google. Możliwych jest dwadzieścia kilka atrybutów, dziesięć jest obowiązkowych, a ich poprawna obsługa decyduje o różnicy między zdrowym kontem Merchant Center a kontem w stałym ostrzeżeniu.
Dziesięć obowiązkowych atrybutów i pułapki w PrestaShop
| Atrybut | Źródło w PrestaShop | Klasyczna pułapka |
|---|---|---|
id |
id_product plus odmiany |
Ponowne użycie identyfikatora po usunięciu, bo Google blokuje za duplikację |
title |
name plus atrybuty |
Limit 150 znaków, ale optimum to 70 do 90; format marka, nazwa, wariant, rozmiar |
description |
description_short albo description |
HTML tolerowany, ale czyszczony; maksymalnie 5 000 znaków; bez emoji i wersalików |
link |
Adres kanoniczny karty | Musi wskazywać dokładną odmianę, a nie produkt nadrzędny |
image_link |
Zdjęcie główne | Minimum 800 na 800 pikseli, zalecane jednolite tło, bez znaku wodnego |
availability |
Stan magazynowy | Wyłącznie wartości słownikowe, bez własnych |
price |
Cena brutto | Musi dokładnie odpowiadać cenie na karcie, z walutą (na przykład 199.00 PLN) |
brand |
Marka | Obowiązkowa, jeśli marka istnieje |
gtin |
EAN, UPC albo ISBN | Walidacja cyfrą kontrolną; 8, 12, 13 albo 14 cyfr; ISBN-10 nieakceptowany |
mpn |
Numer katalogowy producenta | Obowiązkowy przy braku GTIN, inaczej opcjonalny, ale poprawia dopasowanie |
Atrybuty opcjonalne, ale krytyczne
Cztery atrybuty nie są oznaczone jako obowiązkowe, ale ich brak mocno pogarsza skuteczność:
shipping: tabela kosztów dostawy per kraj i region. Bez niej Google stosuje reguły domyślne, często błędne. Do uzupełnienia szczegółowo, zwłaszcza przy sprzedaży wielokrajowej.tax: podatek. Obowiązkowy dla sprzedawców amerykańskich, w Unii cena brutto jest już w poluprice.google_product_category: kategoria Google od 3 do 5 poziomów. Bez niej Google zgaduje, często źle. Do zmapowania z oficjalnej taksonomii.product_type: własna taksonomia, przydatna przy segmentacji kampanii.
Odmiany: złożoność po stronie PrestaShop
W PrestaShop karta z odmianami (rozmiar razy kolor) to produkt z wieloma wpisami id_product_attribute. W Google Shopping każda odmiana musi być osobnym wierszem feedu, z unikalnym id per odmiana, wspólnym item_group_id dla wszystkich odmian tego samego rodzica, atrybutami wariacji (kolor, rozmiar, materiał, wzór, płeć, grupa wiekowa), własnym GTIN i własnym stanem magazynowym.
Najczęstszy błąd: wysłanie jednego wiersza na produkt nadrzędny ze średnią ceną i zagregowanym stanem. Google blokuje to natychmiast. Moduł Google Shopping dla PrestaShop obsługuje ten rozkład na odmiany natywnie, wraz z mapowaniem atrybutów PrestaShop na atrybuty Google.
GTIN: tarcie numer jeden i jego rozwiązanie
GTIN to uniwersalny identyfikator produktu: EAN-13 w Europie, UPC-A w Stanach, ISBN przy książkach. Google wymaga GTIN dla wszystkich produktów, które mają go natywnie. Przy produktach bez GTIN (rękodzieło, marka własna, usługi) trzeba jawnie ustawić identifier_exists na fałsz.
1. Nieprawidłowe kody EAN-13
Trzynasta cyfra jest cyfrą kontrolną wyliczaną z dwunastu poprzednich algorytmem modulo 10. Wiele sklepów importuje referencje producenta z kodami obciętymi albo wymyślonymi. Google odrzuca je masowo. Walidację należy robić w momencie importu, a nie odkrywać trzy tygodnie później, gdy Merchant Center odrzuci 800 kart.
2. GTIN współdzielony między odmianami
Klasyczny błąd w PrestaShop: kod EAN zapisany na produkcie nadrzędnym (ps_product.ean13) zamiast na odmianie (ps_product_attribute.ean13). Efekt: wszystkie warianty mają ten sam GTIN, Google wykrywa duplikację i odrzuca.
Właściwy wzorzec: zapisywać EAN na poziomie odmiany, gdy ma ona własną referencję, a na poziomie produktu nadrzędnego wyłącznie przy kartach bez odmian.
Performance Max kontra Standard Shopping w 2026 roku
Od 2022 roku Google promuje Performance Max jako kampanię domyślną. To kampania zautomatyzowana, łącząca Shopping, Display, YouTube, Discover i wyszukiwarkę w jednej logice optymalizacji. Algorytm decyduje, gdzie i komu wyświetlać reklamy, a reklamodawca dostarcza grupy zasobów i budżet.
Kiedy Performance Max się opłaca
- Szeroki katalog (ponad 1 000 referencji) o zróżnicowanym pokryciu kategorii.
- Solidne dane konwersyjne, co najmniej 50 konwersji na 30 dni na kampanię, najlepiej ponad 100.
- Marże znoszące koszt pozyskania optymalizowany przez algorytm, wyższy o 15 do 30 %, ale przy wolumenie razy 2 do 5.
- Zdolność do analizy segmentów przez raporty grup zasobów i sygnałów odbiorców.
Kiedy Standard Shopping pozostaje lepszy
- Katalog wyspecjalizowany (poniżej 200 referencji), gdzie krytyczna jest granularna kontrola per grupa produktów.
- Wąskie marże wymagające ścisłego kosztu pozyskania i stabilnego ROAS.
- Kategorie regulowane, gdzie Performance Max może rozszerzyć targetowanie w sposób niezgodny z zasadami.
- Faza uczenia: lepiej ustrukturyzować kampanie w Standard Shopping przez 3 miesiące, zmierzyć skuteczność per segment, a potem przejść na Performance Max z tą wiedzą.
Układ hybrydowy na 2026 rok
Wzorzec, który dziś działa: Standard Shopping na 20 % katalogu odpowiadających za 80 % obrotu i Performance Max na długim ogonie. Łączy kontrolę nad produktami strategicznymi z automatyzacją tam, gdzie ręczna optymalizacja się nie opłaca.
Eksport feedu z PrestaShop: trzy architektury
Architektura 1: statyczny plik XML albo CSV regenerowany
Cron PHP (co godzinę albo co noc, zależnie od rytmu katalogu) regeneruje plik wystawiony pod stałym adresem. Merchant Center go pobiera z ustaloną częstotliwością. Proste i solidne, ale z kilkugodzinnym opóźnieniem między zmianą a jej odbiciem w Shopping.
Architektura 2: wypychanie przez Content API
Moduł wypycha zmiany w czasie rzeczywistym przez Content API. Idealne przy często zmieniających się cenach albo ograniczonych stanach. Trudniejsze we wdrożeniu, wymaga limitu API i starannej obsługi błędów.
Architektura 3: aktualizacje w czasie rzeczywistym w Merchant Center Next
Od 2024 roku Merchant Center Next obsługuje aktualizacje w czasie rzeczywistym dla atrybutów krytycznych: ceny, stanu i dostępności. To osobny punkt końcowy, niezależny od feedu głównego. Zalecany wzorzec na 2026 rok łączy feed statyczny dla danych stabilnych z wypychaniem ceny i stanu w czasie rzeczywistym.
Zgodność z Merchant Center: zasady, przez które odrzucane są produkty
1. Cena odniesienia i dyrektywa Omnibus
Jeśli wyświetlasz cenę przekreśloną, cena odniesienia musi być zgodna z dyrektywą Omnibus, czyli być najniższą ceną z 30 dni przed obniżką. Google zrównał swoją politykę z tym wymogiem: niezgodna cena odniesienia oznacza odrzucenie, a fakt ten jest odnotowywany na całym koncie.
2. Produkty ograniczone i zakazane
Tytoń, broń, treści dla dorosłych i leki na receptę są zakazane. Suplementy diety i wyroby konopne są ograniczone, z regułami per kraj. Odrzucenie jednego produktu ograniczonego może przy powtórzeniu doprowadzić do zawieszenia konta, więc zawsze filtruj te kategorie po stronie eksportu z PrestaShop. Pamiętaj też, że w Polsce część kategorii w ogóle nie może być sprzedawana na odległość, co opisujemy w artykule o weryfikacji wieku.
3. Niespójna dostępność
Feed mówi „dostępny”, a karta pokazuje brak towaru albo wyłączony przycisk. Google porównuje i odrzuca. Rozwiązanie: zsynchronizować feed z realnym stanem per odmiana, z odpowiednim progiem.
4. Niezadeklarowana polityka zwrotów i dostawy
Od 2025 roku Google jawnie wymaga informacji o zwrotach i dostawie, przez ustawienia konta albo przez atrybuty w feedzie. Bez nich pojawia się stałe ostrzeżenie i spada ocena jakości.
Mierzenie skuteczności poza samym ROAS
ROAS pokazywany w Google Ads to metryka powierzchniowa. Do właściwego sterowania potrzebne są trzy dodatkowe odczyty:
- ROAS netto, czyli obrót brutto razy wskaźnik marży, podzielony przez koszt reklamy. ROAS Google nie uwzględnia marży produktowej, więc ROAS 8 przy marży 15 % jest mniej opłacalny niż ROAS 4 przy marży 45 %.
- Przyrostowość: ile z tych sprzedaży nastąpiłoby i bez Shopping, przez ruch organiczny albo inny kanał. Test polega na wstrzymaniu kampanii na 14 dni w jednym segmencie i zmierzeniu różnicy w obrocie.
- Koszt pozyskania nowego kontra powracającego klienta. Shopping konwertuje głównie na nowych. Aby zmierzyć wartość życiową klienta, trzeba skrzyżować dane z zapleczem PrestaShop w horyzoncie 6 do 12 miesięcy.
Powiązanie z pozostałymi sygnałami SEO i AEO
Google Shopping nie żyje w izolacji. Agenci AI czytają jednocześnie feed Shopping, dane strukturalne Schema.org karty i treść semantyczną witryny. Trzy optymalizacje wzajemnie się wzmacniają: plik llms.txt jako indeks dla modeli językowych, kompletne oznaczenie Schema.org Product oraz zgodny feed Shopping z bogatymi atrybutami.
Realistyczny budżet na start w 2026 roku
Dla sklepu PrestaShop ze średniej półki uruchamiającego Google Shopping:
- Moduł feedu: licencja wieczysta albo rozwiązanie w abonamencie.
- Wdrożenie początkowe: od 1 do 3 dni pracy (mapowanie taksonomii Google, walidacja GTIN, ustawienia dostawy i podatku). Moduł automatyzuje około 80 % tego wdrożenia.
- Budżet reklamowy: start od 130 do 220 zł dziennie, ze wzrostem do 850 do 2 200 zł dziennie w miarę stabilizacji ROAS. Optimum uczenia Performance Max to około 50 konwersji na 30 dni.
- Partner CSS: rabat na koszcie kliknięcia, aktywacja bezpłatna po otwarciu konta.
Przy takim ustawieniu docelowy ROAS po 12 miesiącach mieści się w przedziale od 4 do 8 przy marżach 30 do 40 %, a zwrot z wdrożenia następuje w ciągu dwóch pierwszych miesięcy.
FAQ
Czy do korzystania z Merchant Center potrzebne jest konto Google Ads?
Do płatnych reklam Shopping tak. Ale samo Merchant Center umożliwia też bezpłatne wyniki w zakładce Shopping i w wyszukiwarce. Nie konwertują tak jak płatne, ale to darmowy ruch, którego żaden sklep nie powinien zostawiać.
Czy da się prowadzić Shopping w B2B?
Oficjalnie Shopping jest przeznaczony dla B2C. Sklepy B2B wystawiają jednak publiczny katalog, aby generować leady, i działa to, dopóki karta pozwala na zakup bezpośredni. Ceny muszą być wyświetlane brutto, a sklepy wyłącznie netto z walidacją firmową nie kwalifikują się.
Co powoduje zawieszenie konta Merchant Center?
Trzy główne przyczyny: mnożenie odrzuceń bez poprawek, wielokrotne zakładanie kont w celu obejścia wcześniejszego zawieszenia oraz obecność produktu zakazanego. Przy zawieszeniu procedura odwoławcza wymaga udokumentowanej poprawki, a nie wyjaśnień.
Jak obsługiwać promocje i wyprzedaże w Shopping?
Merchant Promotions pozwala dołączyć kody promocyjne do reklam. Kod musi być ważny, powiązany z minimalnym koszykiem i zgodny z dyrektywą Omnibus w zakresie ceny przekreślonej. Przy wyprzedażach kalendarzowych reklamy przygotowuje się z 7 do 14 dni wyprzedzeniem, a budżet planuje na dwu- albo trzykrotność. Zobacz także listę kontrolną Black Friday.
Czy feed musi być wielojęzyczny i wielokrajowy?
Tak, ale z odrębnym feedem per kraj i język. Ten sam produkt w Polsce i w Czechach deklaruje się dwoma wpisami: jednym z językiem polskim, krajem PL, ceną w złotych i dostawą krajową, drugim z językiem czeskim, krajem CZ, właściwą ceną i dostawą. Nigdy nie deklaruj jednego produktu na kilka krajów w tym samym feedzie, bo psuje to dopasowanie i prowadzi do odrzuceń.
W syntezie
Google Shopping w 2026 roku nie jest kanałem, który uruchamia się w pół godziny. To infrastruktura danych produktowych wymagająca rygoru przy GTIN, czystości w mapowaniu taksonomii, zgodności regulacyjnej i spójności z sygnałami SEO oraz AEO reszty witryny. Sklepy PrestaShop, które podejmują tę inwestycję, uzyskują typowo od 15 do 25 % pozyskanego obrotu przy ROAS od 4 do 8 i zwrocie z wdrożenia w 60 dni.
Moduł Google Shopping dla PrestaShop automatyzuje najbardziej czasochłonne elementy: rozbicie na odmiany, walidację GTIN, mapowanie taksonomii Google, eksport XML i CSV oraz integrację z Content API.
Przeczytaj także: oznaczenie Schema.org Product oraz agenci zakupowi AI.
Aby przejść do działania: nasz wybór modułów do audytu i sterowania SEO.