„Brak ceny” i „brak dostępności” brzmią jak puste pola w danych produktu, ale błędy siedziały w tym, co szablon mówi robotowi Google o dostępności. Rozbicie produktu na kilkanaście bloków to pierwsze, co widać w kodzie strony, ale test Google wyklucza je jako przyczynę, więc diagnozę trzeba prowadzić dalej.
Produkty z własnego pliku produktów przechodzą, a te same produkty w źródle „Znalezione przez Google” są odrzucane za brak ceny i brak dostępności. W badanym sklepie odrzucone było około 6 na 10 produktów z tego źródła.
Test wyników z elementami rozszerzonymi dla jednej odrzuconej karty. Liczy się to, co Google z tej strony wykrywa: ile produktów, czy każdy ma ofertę z ceną, walutą i dostępnością. Sama liczba bloków JSON-LD w kodzie niczego jeszcze nie przesądza.
Skąd Merchant Center bierze te produkty
Merchant Center ma dwie drogi do produktów: plik produktów, który dostarczasz sam albo przez integrację, oraz produkty, które Google znajduje samodzielnie, czytając strony sklepu. W panelu to drugie źródło nazywa się „Znalezione przez Google”. Dla niego podstawowym materiałem są dane strukturalne karty produktu, czyli bloki JSON-LD w kodzie strony.
Pomoc Merchant Center o danych strukturalnych przy automatycznych aktualizacjach produktów wymienia jako wymagane cenę, walutę, dostępność i stan produktu. Dokumentacja Google dla informacji o sprzedawcy wymaga produktu z nazwą, zdjęciem i ofertą z ceną większą od zera oraz walutą, a dostępność wymienia jako pole zalecane. W badanym sklepie Merchant Center odrzucał produkty bez dostępności, więc dla tego źródła cena i dostępność trzeba traktować jako minimum.
Ważne rozróżnienie: prawidłowy wynik w Teście wyników z elementami rozszerzonymi oznacza poprawne dane strukturalne, a nie zatwierdzenie produktu w Merchant Center. To dwa osobne sprawdzenia i drugie ma własne wymagania, np. zgodność ceny z plikiem i ze stroną.
Jak Google składa dane produktu rozdzielone na wiele bloków JSON-LD
Rdzeń szablonu Shoper Storefront (stan z października 2026) nie wypisuje produktu jako jednego obiektu. Każdy moduł karty dokłada własny fragment, a fragmenty łączy tylko wspólny identyfikator @id, podany jako adres względny. Na badanej karcie było 14 bloków JSON-LD.
| Blok | Co zawiera | Typ obiektu |
|---|---|---|
| zdjęcia | lista adresów zdjęć | brak |
| marka | nazwa producenta | brak |
| nazwa | sama nazwa produktu | brak |
| identyfikatory | SKU oraz puste gtin, gtin13 i mpn | brak |
| produkt | adres karty i oferta z samym adresem | Product |
| cena | oferta z ceną i walutą | brak na poziomie produktu |
| dostępność | oferta z samą dostępnością | brak na poziomie produktu |
| zakup | akcja zakupu i sprzedawca | Product |
Tak wyglądają trzy z tych bloków (adres zanonimizowany, pozostałe pola bez zmian):
{ "@context": ["http://schema.org/", { "@base": "https://sklep.example/" }],
"@id": "/pl/p/produkt/123",
"@type": "http://schema.org/Product",
"offers": { "@id": "/pl/p/produkt/123", "@type": "Offer",
"url": "https://sklep.example/pl/p/produkt/123" } }
{ "@context": ["http://schema.org/", { "@base": "https://sklep.example/" }],
"@id": "/pl/p/produkt/123",
"offers": { "@id": "/pl/p/produkt/123", "@type": "Offer",
"price": 130.99, "priceCurrency": "PLN" } }
{ "@context": ["http://schema.org/", { "@base": "https://sklep.example/" }],
"@id": "/pl/p/produkt/123",
"offers": { "@id": "/pl/p/produkt/123", "@type": "Offer",
"availability": "https://schema.org/InStock" } }Test wyników z elementami rozszerzonymi na żywej karcie (20 października 2026) pokazuje, że Google łączy te fragmenty po @id w jeden produkt z nazwą, zdjęciami, marką, SKU, ceną 130,99 PLN i dostępnością, oznaczony jako prawidłowy. To wyklucza samo rozbicie na bloki jako przyczynę braku ceny, przynajmniej w tym, jak dane czyta wyszukiwarka.
Test pokazał za to wadę modelu danych. Oferta dostaje ten sam @id co produkt, więc po złożeniu powstaje jeden węzeł, który ma naraz typ Product i Offer. Google dziś to przyjmuje, ale to opis produktu jako własnej oferty, a nie produktu z ofertą. Czy Merchant Center czyta taki węzeł tak samo jak test, nie sprawdziliśmy.
gtin13 to osobny problem z tej samej tabeli. Gdy kody EAN siedzą w rozmiarach, a produkt główny ich nie ma, karta wysyła pusty ciąg zamiast pominąć pole. Ten wątek opisuje poradnik o pliku produktów Google z Shopera.Przyczyna potwierdzona: dostępność z wariantu, którego nikt nie kupuje
Blok dostępności rdzeń liczy z jednego miejsca: z dostępności produktu, a ta pochodzi z wariantu domyślnego. W sklepie, w którym stan siedzi w rozmiarach, wariant domyślny ma zero sztuk. Efekt: karta z pełną rozmiarówką mówi Google OutOfStock, a klient na tej samej stronie normalnie kupuje.
Skąd zero na wariancie domyślnym, opisuje poradnik o wariancie domyślnym w Shoperze po imporcie z BaseLinkera. Ten sam mechanizm daje złą cenę na listingu i „0 szt.” w panelu; tutaj daje fałszywy brak towaru w danych dla Google.
Wcześniej w tym samym sklepie dostępność nie była wysyłana wcale. Rdzeń dokłada ją do danych strukturalnych tylko z modułu „Ilość i dostępność”, a układ karty produktu tego modułu nie miał. Dane w panelu były poprawne, a w kodzie strony słowo availability nie występowało ani razu. Dodanie modułu do układu karty w edytorze wyglądu przywróciło pole.
Zastrzeżenie o wariantach: karta w Shoper Storefront to jeden adres dla wszystkich rozmiarów i jedna oferta na poziomie produktu. Dla takiej oferty InStock, gdy dostępny jest choć jeden rozmiar, odpowiada temu, co klient może kupić. Nie przenosi się to na oferty poszczególnych wariantów: wyprzedany rozmiar M nie staje się dostępny, bo jest L. Jeśli sklep opisuje warianty osobno, każdy ma własną ofertę i dostępność, zgodnie z dokumentacją Google o wariantach produktu (ProductGroup, hasVariant). W pliku produktów wysyłamy osobną pozycję dla każdego dostępnego rozmiaru, co opisuje poradnik o pliku produktów Google z Shopera.
Jak sprawdzić, która przyczyna dotyczy Twojego sklepu
| Sprawdź | Wynik | Co z tego wynika |
|---|---|---|
| w którym źródle Merchant Center są odrzucenia | tylko w „Znalezione przez Google” | zacznij od tego, jak Google czyta stronę: dane strukturalne, dostępność, moduły karty |
| to samo | także we własnym pliku produktów | sprawdź plik i zgodność pliku ze stroną; dane strukturalne to wtedy tylko jedna z możliwych przyczyn |
| produkty wykryte w Teście wyników z elementami rozszerzonymi | OK, gdy jeden produkt z ofertą z ceną, walutą i dostępnością | brak ceny albo dostępności w wykrytym produkcie wskazuje miejsce błędu; dwa produkty oznaczają dwa opisy tej samej rzeczy |
@id produktu i oferty | OK, gdy są różne albo oferta nie ma własnego @id | przy tym samym @id produkt i oferta zlewają się w jeden węzeł |
availability na karcie z dostępnymi rozmiarami | OK, gdy InStock | przy OutOfStock sprawdź, czy szablon nie bierze dostępności z wariantu domyślnego |
pole availability w kodzie strony | OK, gdy występuje | gdy go nie ma, jedną z przyczyn może być brak modułu dostępności w układzie karty |
| cena w danych strukturalnych a cena na karcie | OK, gdy identyczne, z kropką dziesiętną | przy różnicy Merchant Center zgłosi niezgodną cenę; sprawdź wariant domyślny |
Do sprawdzenia wystarczą trzy karty: produkt z kilkoma rozmiarami, produkt bez wariantów i produkt bez żadnego dostępnego rozmiaru. Ten trzeci jest kontrolą: po poprawce ma nadal mówić OutOfStock.
Co zmieniliśmy w szablonie
Rdzenia Storefrontu nie da się przepisać, ale makro dostępności karty jest częścią szablonu i można je rozszerzyć. Zmiany były dwie, w dwóch kolejnych dniach, każda z kopią poprzedniej wersji makra.
- Dostępność z rozmiarów (15 października). Produkt jest dostępny, jeśli dostępna jest którakolwiek wartość opcji magazynowej, a nie gdy stan ma wariant domyślny. Produkt bez wariantów zostaje przy dotychczasowej logice. Ta zmiana poprawia też fragment dostępności rdzenia.
- Pełny blok produktu (16 października). Obok fragmentów rdzenia makro wypisuje kompletny
Productz własnym@id: nazwa, opis, zdjęcia, marka, SKU i oferta z ceną, walutą, dostępnością, stanem produktu, warunkami dostawy i zwrotów.
Test z 20 października wykrywa po tej zmianie na karcie dwa prawidłowe produkty: złożony z fragmentów rdzenia i dodany blok. Mają tę samą nazwę, cenę i dostępność, więc dziś się nie gryzą, ale to dwa opisy jednej rzeczy na stronie, która powinna opisywać jeden produkt. Gdyby kiedyś się rozjechały, np. cena promocyjna w jednym i regularna w drugim, Google musiałby wybierać.
Dlatego ten blok jest do decyzji, nie do zostawienia na zawsze. Skoro po zmianie z 15 października produkt złożony z rdzenia ma poprawną dostępność, są dwie rozsądne drogi: dołożyć brakujące pola (dostawa, zwroty) do węzła rdzenia przez jego @id zamiast budować drugi produkt albo usunąć nasz blok i zostać przy rdzeniu. W obu przypadkach na karcie zostaje jeden opis produktu.
Warunki dostawy i zwrotów w danych strukturalnych muszą zgadzać się z ustawieniami Merchant Center i regulaminem sklepu, więc przy każdej ich zmianie trzeba je poprawić w dwóch miejscach: w Merchant Center i w szablonie.
Efekt wdrożonych poprawek
Po wdrożeniu sprawdziliśmy dane strukturalne na żywej karcie produktu w Teście wyników z elementami rozszerzonymi (20 października 2026).
- Dostępność jest w danych strukturalnych na każdej karcie, bo układ karty ma moduł dostępności.
- Dostępność liczy się z rozmiarów, a nie z wariantu domyślnego: karta z dostępnymi rozmiarami mówi
InStock, karta bez żadnego dostępnego rozmiaru nadalOutOfStock. - Google odczytuje cenę i dostępność: test wykrywa produkt z ceną 130,99 PLN, walutą i dostępnością, oznaczony jako prawidłowy w „Informacjach o sprzedawcy”.
- Znaleźliśmy i nazwaliśmy dwa problemy struktury: kolizję
@idproduktu i oferty w rdzeniu szablonu oraz drugi opis produktu po dodaniu pełnego bloku. Oba są opisane wyżej razem ze sposobem uporządkowania.
Poprawki usunęły błędy w tym, jak szablon przekazuje Google dostępność produktu. Końcowego wpływu na liczbę odrzuceń w Merchant Center nie mierzyliśmy, bo źródło „Znalezione przez Google” przetwarza się niezależnie od testu danych strukturalnych. Przyczyny samego komunikatu „Brak ceny produktu” nie potwierdziliśmy: test wykrywa cenę poprawnie.
Jeśli sklep ma własny plik produktów obejmujący cały asortyment, warto też rozważyć wyłączenie źródła „Znalezione przez Google”. W badanym koncie miało ono kilka razy więcej pozycji niż plik, z innymi danymi i innymi problemami, co utrudniało ocenę katalogu. Przed decyzją sprawdź, które produkty są tylko w nim.
Co poprawisz w panelu, a co wymaga zmiany szablonu
Diagnoza z tabeli w sekcji 04, Test wyników z elementami rozszerzonymi dla kilku kart, filtr źródła w Merchant Center, dodanie modułu dostępności do układu karty w edytorze wyglądu i decyzja o wyłączeniu źródła „Znalezione przez Google”, jeśli masz pełny plik produktów.
Zmiana makra w szablonie: dostępność z rozmiarów, uzupełnienie danych strukturalnych bez tworzenia drugiego opisu tego samego produktu, spójność z ustawieniami dostawy i zwrotów, test na trzech typach kart, wgranie szablonu z kopią poprzedniej wersji i kontrola na żywej stronie po publikacji.
Kolejne wpisy tej serii: wbudowany plik produktów Google w Shoperze, który przy produktach z rozmiarami potrafi wysłać prawie cały katalog jako niedostępny, oraz ustawienie usługi porównywania cen, przez które bezpłatne wyniki produktowe potrafią nie wyświetlać się wcale. Ogólny przegląd błędów integracji z API Shopera jest w poradniku Najczęstsze błędy Shoper API.
Jeśli Merchant Center jest tylko jednym z objawów, a problemy dotyczą też indeksacji kart, danych strukturalnych albo jakości katalogu, szerszym punktem wyjścia jest audyt sklepu internetowego.