Dane strukturalne dla produktów: jak dostać cenę i dostępność w wynikach Google

W wynikach Google część sklepów ma pod linkiem cenę, dostępność i gwiazdki, a część tylko tytuł i opis. Różnica to dane strukturalne: fragment kodu na karcie produktu, który mówi Google wprost, co jest produktem, ile kosztuje i czy jest na stanie. Wdrożenie nie jest trudne, ale ma kilka pułapek, przez które Search Console zgłasza błędy, a rozszerzone wyniki nie pojawiają się miesiącami.

W skrócie

Dane strukturalne to kod JSON-LD w sekcji head karty produktu z typami Product, Offer i opcjonalnie AggregateRating.
Google wymaga, żeby dane w kodzie zgadzały się z tym, co widzi użytkownik: ta sama cena, ta sama dostępność, te same opinie.
Najczęstsze błędy w Search Console to brak ceny przy wariantach, zła waluta, dostępność w nieznanym formacie i oceny bez widocznych opinii.
Test robisz w narzędziu do testowania wyników z elementami rozszerzonymi od Google, a efekt widzisz w Search Console w raporcie Fragmenty produktów.

Co dają dane strukturalne w sklepie

Google czyta Twoją kartę produktu jak każdą stronę i próbuje zgadnąć, co na niej jest. Dane strukturalne usuwają zgadywanie. Dostajesz za to szansę na wynik rozszerzony: cena, dostępność, ocena i liczba opinii pod linkiem w wynikach wyszukiwania. Taki wynik zajmuje więcej miejsca i przyciąga wzrok, więc przy tej samej pozycji dostaje więcej kliknięć. Dodatkowo dane te zasilają zakładkę Zakupy w Google i bezpłatne listy produktów, jeśli masz połączone Merchant Center.

Nie ma gwarancji, że Google wyświetli rozszerzony wynik. Poprawne dane to warunek konieczny, nie wystarczający. Ale bez nich nie ma na to szans wcale.

Trzy typy, które musisz znać

Product: co to jest

Typ Product opisuje sam produkt: nazwę, obrazek, opis, markę, identyfikatory (GTIN czy EAN, MPN, SKU). Nazwa powinna być taka sama jak widoczna na stronie. Obrazek to adres głównego zdjęcia w pełnym rozmiarze, nie miniatura. Identyfikatory są ważne dla dopasowania Twojego produktu do tego samego produktu u konkurencji w Zakupach Google.

Offer: za ile i czy dostępne

Typ Offer zagnieżdżony w Product opisuje ofertę: cenę jako liczbę bez symbolu waluty, walutę w kodzie ISO (PLN), dostępność jako jedną z wartości ze słownika schema.org (InStock, OutOfStock, PreOrder, BackOrder), adres strony oferty i opcjonalnie datę ważności ceny. Jeśli produkt ma warianty w różnych cenach, używasz AggregateOffer z ceną najniższą i najwyższą albo osobnych Offer dla każdego wariantu. Cena musi być tą, którą widzi klient, czyli brutto dla sklepu konsumenckiego.

AggregateRating: co mówią klienci

Typ AggregateRating podaje średnią ocenę, liczbę opinii i skalę. Google wymaga, żeby opinie były widoczne na stronie dla użytkownika i żeby liczby się zgadzały. Jeśli masz moduł opinii, który pokazuje 12 opinii ze średnią 4,5, dokładnie to ma być w kodzie. Produkty bez opinii nie dostają AggregateRating w ogóle, zamiast zera opinii.

Pole	Typ	Wymagane	Typowy błąd
name	Product	tak	inna nazwa niż na stronie, np. z dopiskiem SEO
image	Product	tak	miniatura zamiast pełnego zdjęcia, adres względny
gtin, mpn, sku	Product	zalecane	EAN z błędną sumą kontrolną, brak przy wariantach
price	Offer	tak	cena z przecinkiem, z symbolem zł, cena netto
priceCurrency	Offer	tak	brak albo „zł” zamiast PLN
availability	Offer	tak	własny tekst zamiast wartości schema.org
ratingValue, reviewCount	AggregateRating	jeśli są opinie	oceny w kodzie, brak opinii na stronie

Jak to wdrożyć w PrestaShop

PrestaShop 8 i 9 w domyślnym motywie i w motywie Hummingbird generują podstawowe dane Product i Offer z szablonu karty produktu. Problem w tym, że motywy z marketplace’u często to nadpisują albo usuwają, a moduły SEO dokładają własny zestaw, przez co na jednej stronie są dwa komplety danych, czasem sprzeczne. Pierwszy krok to sprawdzenie, co obecnie wysyła Twoja karta produktu.

Krok po kroku

Sprawdź obecny stan. Otwórz kartę produktu w narzędziu do testowania wyników z elementami rozszerzonymi. Zobaczysz, które typy Google wykrył i jakie zgłasza błędy albo ostrzeżenia. Zrób to dla produktu prostego, produktu z wariantami i produktu niedostępnego.
Zdecyduj o jednym źródle. Albo motyw, albo moduł, nie oba. Jeśli masz moduł SEO generujący dane, wyłącz generowanie w motywie, i odwrotnie. Dwa komplety to najczęstsza przyczyna błędów.
Uzupełnij dane produktów. EAN, numer producenta, marka w polach PrestaShop. Dane strukturalne są tak dobre, jak dane w katalogu. Przy imporcie z ERP te pola często są puste.
Obsłuż warianty. Dla produktu z kombinacjami cena w kodzie musi odpowiadać wybranemu wariantowi albo używać AggregateOffer z zakresem. Przy zmianie wariantu bez przeładowania strony dane w kodzie trzeba aktualizować skryptem albo zostać przy zakresie.
Podłącz opinie. Jeśli moduł opinii nie dodaje AggregateRating, trzeba to dopisać w szablonie z danych modułu. Tylko dla produktów z co najmniej jedną opinią.
Przetestuj i wyślij do indeksowania. Ponowny test w narzędziu Google, potem w Search Console poproś o indeksowanie kilku kart. Po kilku dniach sprawdź raport Fragmenty produktów.

Ważne

Cena w danych strukturalnych musi być taka sama jak cena widoczna na stronie w momencie odwiedzin robota Google. Jeśli sklep pokazuje ceny różne dla grup klientów, w kodzie podaj cenę dla gościa niezalogowanego, bo tak Google widzi stronę. Przy promocjach zgodnych z Omnibusem w kodzie idzie cena aktualna, nie najniższa z 30 dni.

Jak czytać błędy w Search Console

W Search Console, w sekcji Zakupy albo Ulepszenia, znajdziesz raport Fragmenty produktów. Pokazuje liczbę stron poprawnych, z ostrzeżeniami i z błędami. Błędy blokują wynik rozszerzony dla danej strony. Ostrzeżenia nie blokują, ale ograniczają, które elementy Google pokaże.

„Brak pola price” albo „Nieprawidłowa wartość w polu price”: najczęściej cena z przecinkiem jako separatorem, z symbolem waluty albo pusta przy produkcie z wariantami. Cena to liczba z kropką.
„Nieprawidłowa wartość w polu availability”: szablon wstawia własny tekst, np. „Dostępny”, zamiast adresu schema.org z wartością InStock.
„Brak pola image”: adres obrazka względny albo wskazujący na miniaturę, której nie ma. Potrzebny pełny adres z protokołem.
„Opinie bez widocznych treści” albo problemy z AggregateRating: oceny w kodzie są, ale na stronie użytkownik ich nie widzi, albo liczby się różnią. Google traktuje to jako manipulację.
„Brak pola gtin, mpn lub sku”: to ostrzeżenie, nie błąd, ale bez identyfikatorów Twój produkt nie dopasuje się do innych ofert w Zakupach.

Przy każdym błędzie Search Console pokazuje przykładowe adresy. Napraw w szablonie, sprawdź jeden adres w narzędziu testowym, a potem kliknij „Sprawdź poprawkę” w raporcie. Google ponownie przejrzy strony z problemem i po kilku dniach do kilku tygodni zaktualizuje raport.

Z naszej praktyki

Sklep z częściami rowerowymi miał w Search Console ponad 4 tysiące stron z błędem ceny. Przyczyna: motyw generował Offer z ceną w formacie „129,00 zł”, bo szablon używał tej samej funkcji formatującej co do wyświetlania. Do tego moduł SEO dodawał drugi blok Product bez ceny. Wyłączyliśmy generowanie w module, poprawiliśmy szablon tak, żeby cena szła jako liczba z kropką i walutą PLN, i dodaliśmy AggregateOffer dla produktów z wariantami. Po trzech tygodniach raport pokazał prawie wszystkie strony jako poprawne, a przy produktach pojawiły się cena i dostępność w wynikach.

Jak testować przed wdrożeniem i po

Google udostępnia narzędzie do testowania wyników z elementami rozszerzonymi. Wklejasz adres albo kod HTML i dostajesz listę wykrytych typów, błędów i ostrzeżeń oraz podgląd, jak wynik mógłby wyglądać. Testuj zawsze trzy przypadki: produkt prosty dostępny, produkt z wariantami, produkt niedostępny. Dodatkowo sprawdź produkt w promocji, bo tam szablon czasem wstawia cenę przekreśloną zamiast aktualnej.

Po wdrożeniu obserwuj dwa miejsca: raport Fragmenty produktów w Search Console (liczba poprawnych stron powinna rosnąć) oraz raport Skuteczność z filtrem na wygląd w wynikach, gdzie zobaczysz kliknięcia i wyświetlenia osobno dla wyników z fragmentami produktów. To jedyny sposób, żeby ocenić, czy wdrożenie przyniosło ruch.

Dane strukturalne nie są trikiem SEO. To po prostu powiedzenie Google wprost tego, co i tak piszesz klientowi.

Czego nie robić

Nie wstawiaj AggregateRating z ocenami zbieranymi gdzie indziej albo wymyślonymi. To najszybsza droga do ręcznej kary i utraty wszystkich wyników rozszerzonych.
Nie oznaczaj strony kategorii jako jednego Product. Kategoria to lista, nie produkt. Dla list istnieje ItemList, ale Google rzadko ją wykorzystuje w sklepach.
Nie podawaj dostępności InStock dla produktu na zamówienie z terminem kilku tygodni. Użyj PreOrder albo BackOrder, inaczej klient przyjdzie z Google po produkt „na stanie” i wyjdzie zły.
Nie zostawiaj danych strukturalnych bez nadzoru po zmianie motywu albo aktualizacji modułu. To miejsce psuje się po cichu.

Pytania, które słyszymy najczęściej

Czy dane strukturalne poprawiają pozycję w Google?

Nie bezpośrednio. Poprawiają wygląd wyniku, przez co dostaje więcej kliknięć przy tej samej pozycji. Pośrednio lepsza klikalność może pomóc, ale nie licz na skok w rankingu.

Czy potrzebuję osobnego modułu do danych strukturalnych?

Nie zawsze. Domyślne motywy PrestaShop generują podstawy. Moduł albo poprawka w szablonie są potrzebne przy wariantach, opiniach i identyfikatorach. Ważniejsze od narzędzia jest, żeby robiło to tylko jedno.

Dlaczego Google pokazuje cenę konkurencji, a mojej nie, choć kod jest poprawny?

Google wyświetla rozszerzone wyniki według własnego uznania, biorąc pod uwagę zaufanie do strony, zgodność danych i historię. Poprawny kod to warunek wejścia. Daj mu kilka tygodni i sprawdzaj raport.

W audycie SEO technicznego sprawdzamy dane strukturalne na kartach produktów, kategorii i stronach informacyjnych, wskazujemy źródło błędów z Search Console i dajemy gotową poprawkę do szablonu. Zobacz, co zawiera audyt.

Zamów audyt SEO technicznego