Klient wchodzi na kartę produktu, wybiera kolor, rozmiar albo wzór, a potem dorzuca konkretną wersję do koszyka. Dla człowieka sprawa jest oczywista. Dla Google już niekoniecznie. Wyszukiwarka musi dostać jasny sygnał, że te różne opcje należą do jednego produktu, ale mogą mieć własną nazwę, cenę, dostępność czy identyfikator.
Właśnie tutaj pojawiają się dane uporządkowane produktów. To nie jest dodatkowy opis pisany dla klienta ani magiczny przycisk „wyżej w Google”. To uporządkowany, zrozumiały maszynowo zapis informacji o stronie. Pomaga wyszukiwarce lepiej odczytać ofertę i może zwiększyć szanse na bogatszą prezentację wyniku, ale nie gwarantuje ani konkretnej pozycji, ani konkretnego wyglądu wyniku.
Jeśli sklep ma warianty, temat robi się ciekawszy. Sprawdźmy więc, co powinno być wspólne, co przypisać do konkretnej wersji i jak skontrolować, czy wszystko faktycznie mówi to samo co karta produktu.
Dane uporządkowane produktu — o co tu w ogóle chodzi?
Dane uporządkowane to ustandaryzowany sposób przekazywania wyszukiwarce informacji o stronie. Zamiast liczyć na to, że Google samo odczyta z karty produktu nazwę, cenę i stan magazynowy, można te informacje opisać w formacie, który jest dla niego łatwiejszy do interpretacji.
W e-commerce szczególne znaczenie mają typy Product i ProductGroup. Pierwszy służy do opisania produktu, a drugi pomaga zebrać warianty należące do jednej grupy. Dzięki temu wyszukiwarka może lepiej zrozumieć, co sprzedajesz i czym różnią się poszczególne wersje.
To jednak nie jest obietnica, że przy wyniku pojawi się cena, dostępność albo dodatkowe informacje. Dane uporządkowane mogą zwiększyć kwalifikację strony do bogatszej prezentacji, ale Google nie gwarantuje konkretnego wyglądu wyniku ani jego pozycji. Innymi słowy: warto uporządkować dane, ale nie warto traktować ich jak kuponu na pierwsze miejsce.
Product, ProductGroup i warianty — kto tu jest kim?
Jeżeli sprzedajesz produkt bez wariantów, opis przez Product może być wystarczającym punktem wyjścia. Przy produkcie występującym w kilku wersjach potrzebujesz jednak pokazać relację między produktem nadrzędnym a konkretnymi opcjami.
Do tego służy ProductGroup. Można potraktować go jak wspólny „parasol” dla wariantów. Właściwość variesBy wskazuje, czym te warianty się różnią, na przykład rozmiarem, kolorem, materiałem albo wzorem. hasVariant łączy grupę z konkretnymi produktami, a productGroupID identyfikuje grupę produktu nadrzędnego.
Nie chodzi o wrzucenie wszystkich informacji do jednego worka. Wspólne elementy, takie jak marka albo część opisu, mogą być przypisane do grupy. Natomiast dane dotyczące konkretnej wersji powinny trafić do właściwego Product.
Co wspólne, a co przypisane do wariantu?
Najprostsza zasada brzmi: jeśli coś dotyczy całej rodziny produktów, może znaleźć się na poziomie ProductGroup. Jeśli dotyczy jednej, konkretnej wersji, powinno być przypisane do jej własnego Product.
Na poziomie wariantu mogą znaleźć się między innymi:
- nazwa konkretnej wersji;
- cechy wariantu, takie jak kolor czy rozmiar;
- zdjęcie właściwe dla danej wersji;
- SKU albo odpowiedni identyfikator;
- oferta z ceną i dostępnością.
To ważne, bo wariant nie jest tylko ozdobnym wyborem w rozwijanym polu. Może mieć inną cenę, inne zdjęcie, osobny identyfikator i inny stan magazynowy. Jeśli opiszesz go wyłącznie jako część ogólnego produktu, wyszukiwarka dostaje mniej precyzyjny obraz oferty.
Co oznaczyć przy produkcie: nazwa, cena, dostępność i identyfikator
Przy sprawdzaniu danych produktu warto przejść przez kilka podstawowych elementów. Najpierw nazwa i cechy wariantu. Potem oferta, czyli przede wszystkim cena, waluta oraz dostępność. Na końcu identyfikator. Każdy z tych elementów powinien odpowiadać temu, co rzeczywiście widzi klient.
Cena w ofercie może być przekazana przez price, a waluta przez priceCurrency. Jeżeli wariant kosztuje inaczej niż pozostałe wersje, jego oferta powinna pokazywać właściwą wartość. Szczególnej ostrożności wymagają promocje, cena przekreślona i cena członkowska. Nie warto mieszać właściwości cenowych tylko dlatego, że brzmią podobnie.
Za dostępność odpowiada właściwość availability. Można użyć między innymi wartości InStock, OutOfStock, PreOrder, BackOrder albo LimitedAvailability. Dla tej samej oferty nie należy podawać więcej niż jednej wartości dostępności.
Cena i dostępność muszą mówić to samo co karta produktu
Jeśli klient widzi przy wybranym rozmiarze cenę 120, a dane uporządkowane przekazują inną kwotę, pojawia się zwyczajna niespójność. Tak samo, gdy strona pokazuje „brak w magazynie”, a oznaczenie mówi InStock. Dane uporządkowane nie powinny opowiadać alternatywnej wersji historii.
Identyfikatorem wariantu może być SKU. Jeśli produkt ma globalny identyfikator, można wykorzystać właściwą właściwość GTIN, na przykład gtin8, gtin12, gtin13 albo gtin14, gdy ma zastosowanie. GTIN powinien być prawdziwą wartością liczbową przypisaną do danego produktu lub wariantu, a nie zapisem w formie URL. Nie każdy produkt musi mieć każdy rodzaj identyfikatora. Najgorszym pomysłem jest tworzenie numeru na chybił-trafił, żeby tylko „jakieś pole się zgadzało”.
Warianty z różnymi cenami i stanami magazynowymi
Typowy problem wygląda tak: sklep ma jedną kartę produktu z kilkoma wariantami, ale dane uporządkowane pokazują jedną cenę i jedną dostępność dla całej grupy. Na stronie klient może wybrać trzy rozmiary, z których jeden jest droższy, a drugi chwilowo niedostępny. Jeśli schema opisuje wszystkie wersje jednym zestawem informacji, robi się bałagan.
Każdy wariant powinien mieć dane odpowiadające jego realnej ofercie. Nie kopiuj jednej ceny na wszystkie wersje, jeśli ceny się różnią. Nie oznaczaj wszystkich jako dostępnych, kiedy część ma inny stan. Nie zakładaj też, że skoro jeden wariant jest poprawny, to cała grupa działa bez zarzutu.
Przy kontroli wybierz kilka konkretnych przypadków: wariant z inną ceną, wariant z inną dostępnością i wariant z innym identyfikatorem. Sprawdź, czy po wyborze opcji na stronie nadal opisujesz tę samą wersję w danych uporządkowanych.
Jedna karta produktu czy osobne adresy wariantów?
Warianty mogą być wybierane na jednej stronie produktu albo prezentowane pod osobnymi adresami. Żaden z tych modeli nie jest automatycznie właściwy dla każdego sklepu. Wybór zależy od architektury sklepu i sposobu, w jaki pokazujesz ofertę.
Przy jednej karcie trzeba jasno powiązać produkt nadrzędny z konkretnymi wariantami. Przy osobnych adresach również trzeba zadbać o czytelne opisanie wersji i ich relacji z grupą. Sam fakt, że wariant ma własny adres, nie rozwiązuje problemu danych.
Nie ma jednej uniwersalnej metody obsługi wariantów dla wszystkich instalacji WordPressa, WooCommerce, motywów i narzędzi. Konkretne wdrożenie trzeba sprawdzić w rzeczywistym sklepie, a nie oceniać po nazwie platformy. Dokumentacja opisuje zasady, ale nie generuje identycznego kodu w każdej konfiguracji.
Jak sprawdzić wdrożenie bez wróżenia z fusów?
Najpierw uruchom adres produktu w Rich Results Test. Narzędzie pozwala sprawdzić, jakie wyniki rozszerzone może obsługiwać strona i czy dane zawierają wykrywalne błędy. Jeśli pojawiają się błędy krytyczne, popraw je przed przejściem dalej.
Następnie użyj URL Inspection w Search Console, aby sprawdzić, jak Google widzi stronę. Warto też upewnić się, że adres nie jest blokowany przez robots.txt, dyrektywę noindex ani logowanie. Jeśli wyszukiwarka nie może pobrać strony, nawet starannie przygotowane dane niewiele pomogą.
Krótka checklista kontroli
- Uruchom adres produktu w Rich Results Test.
- Popraw wykryte błędy krytyczne.
- Sprawdź stronę przez URL Inspection w Search Console.
- Zweryfikuj, czy adres nie jest blokowany przez
robots.txt,noindexani logowanie. - Porównaj dane z kartą produktu: nazwę, cechy, cenę, dostępność i identyfikator.
- Sprawdź kilka realnych wariantów, a nie tylko pierwszy z brzegu.
- Po wdrożeniu monitoruj dane w Search Console i uwzględnij czas potrzebny na ponowne pobranie oraz zindeksowanie strony.
Ważne: pozytywny wynik Rich Results Test nie gwarantuje, że Google pokaże rozszerzony wynik. Test mówi, czy dane przechodzą określoną walidację, ale nie obiecuje konkretnej prezentacji w wyszukiwarce.
Najczęstsze błędy i rozsądny następny krok
Najczęściej problemem nie jest brak skomplikowanego kodu, tylko brak zgodności. Cena w danych różni się od ceny na karcie. Wszystkie warianty mają tę samą dostępność, choć magazyn mówi co innego. Produkt nadrzędny nie jest jasno połączony z konkretnymi wersjami. Albo kilka wtyczek i systemów generuje równolegle sprzeczne oznaczenia.
Dlatego zacznij od prostego porównania: co widzi klient i co przekazują dane uporządkowane. Przy wariantach sprawdź osobno nazwę, cechy, identyfikator, cenę oraz dostępność. Dopiero potem oceniaj wynik testu. Walidator jest pomocny, ale nie zastąpi sprawdzenia całej ścieżki produktu.
Najważniejszy wniosek? Przy produkcie z wariantami nie wystarczy opisać jednej karty ogólnym schematem. Trzeba połączyć grupę produktu z konkretnymi wariantami i pilnować, żeby dane zgadzały się z realną ofertą. To właśnie od tej spójności warto zacząć, zamiast zgadywać na podstawie samego wyglądu strony.
Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.
