Produkt w sklepie ma nazwę, zdjęcie, cenę, dostępność, a czasem jeszcze kilka kolorów, rozmiarów i innych wariantów. Dla klienta to zwykła karta produktu. Dla Google — zestaw informacji, który trzeba poprawnie odczytać i zrozumieć. Tu właśnie wchodzą dane uporządkowane produktu, czyli sposób na przekazanie wyszukiwarce, co właściwie sprzedajesz.
Nie chodzi o dorabianie ofercie magicznego przycisku „pokaż mnie wyżej”. Chodzi o porządek, zgodność i sensowne opisanie tego, co już znajduje się na stronie. W tym artykule przejdziemy przez najważniejsze dane produktów w Google, różnicę między Product snippets i Merchant listings, warianty, ceny oraz dostępność. Na końcu będzie też krótka kontrola wdrożenia — bez obietnic cudów, bo Google lubi mieć w tej sprawie własne zdanie.
Najpierw: co Google właściwie chce wiedzieć o produkcie?
Dane produktu to nie magia, tylko porządek w informacji
Dane uporządkowane nie tworzą nowej oferty i nie zastępują treści widocznej dla klienta. Porządkują informacje, które sklep już posiada, aby wyszukiwarka mogła łatwiej zrozumieć konkretny produkt. W grę wchodzą między innymi nazwa, zdjęcia, marka, opis, identyfikatory, cena, waluta i dostępność.
W zależności od produktu i oferty można uwzględnić także stan produktu, opinie, informacje o dostawie oraz zasady zwrotów. Najważniejsza zasada jest prosta: oznaczone dane muszą odpowiadać temu, co naprawdę widać na stronie i co faktycznie obowiązuje w sklepie. Jeśli karta pokazuje jedną cenę, a dane produktowe drugą, wyszukiwarka dostaje sprzeczny komunikat. A sprzeczny komunikat to raczej bałagan niż pomoc.
Dla stron sprzedażowych podstawą są właściwości Product, zdjęcie oraz oferta typu Offer. To punkt wyjścia do kontroli, ale nie obietnica konkretnego wyglądu wyniku. Samo uporządkowanie informacji nie gwarantuje wyższej pozycji, większego ruchu ani sprzedaży.
Product snippets a Merchant listings — nie wrzucaj wszystkiego do jednego worka
Strona o produkcie kontra strona, na której produkt kupujesz
Google rozróżnia dwa główne zastosowania danych produktowych. Product snippets dotyczą stron, na których użytkownik poznaje produkt, czyta opis albo recenzję, ale nie kupuje go bezpośrednio od danego sprzedawcy. Taki kontekst pasuje do strony informacyjnej, opinii czy materiału opisującego produkt.
Merchant listings dotyczą z kolei stron sprzedażowych. To karty produktów w sklepie, gdzie użytkownik może kupić produkt od konkretnego sprzedawcy. Dlatego w tym przypadku znaczenie mają nie tylko nazwa i zdjęcie, ale również informacje handlowe: oferta, cena, waluta, dostępność, dostawa czy zasady zwrotów, jeśli są prezentowane i rzeczywiście obowiązują.
Te dwa zastosowania mogą częściowo się pokrywać, ale nie warto wrzucać ich do jednego worka. Najpierw trzeba odpowiedzieć na proste pytanie: czy użytkownik może kupić produkt na tej stronie? Jeśli tak, punkt wyjścia stanowią dane związane z Merchant listings. Jeśli strona tylko opisuje produkt, sytuacja jest inna. Wybór kontekstu powinien wynikać z funkcji strony, a nie z chęci zaznaczenia wszystkiego, co brzmi technicznie.
Checklista danych produktu w sklepie
Minimum i dane dodatkowe
Przy audycie karty produktu warto rozdzielić podstawy od informacji dodatkowych. Dla Merchant listings Google wskazuje jako podstawowe właściwości produktu name, image oraz offers. W przypadku oferty sprzedawanej przez właściciela oznaczanej strony oferta powinna być typu Offer.
Potem przychodzi pora na szczegóły. Warto sprawdzić, czy dane obejmują:
- nazwę produktu odpowiadającą karcie produktu;
- zdjęcie właściwe dla produktu lub konkretnego wariantu;
- cenę i walutę zgodne z aktualną ofertą;
- dostępność pokazującą rzeczywisty stan oferty;
- markę, opis oraz SKU lub GTIN, jeśli takie dane rzeczywiście istnieją;
- stan produktu, gdy jest używany w opisie oferty;
- opinie, dostawę i zasady zwrotów, ale tylko wtedy, gdy są zgodne z informacjami widocznymi dla klienta.
To nie jest lista do bezmyślnego odhaczania. Jeżeli sklep nie ma konkretnego identyfikatora albo nie pokazuje informacji o dostawie w danym miejscu, nie należy dopisywać jej na siłę. Nie kopiuj też przykładowej ceny, waluty, kraju dostawy czy identyfikatora z dokumentacji Google. Przykład techniczny nie jest gotową wartością dla twojego sklepu.
Dobrze zacząć od porównania trzech miejsc: karty produktu oglądanej przez klienta, danych widocznych w kodzie oraz informacji generowanych dla Google. Jeśli te trzy obrazy się rozjeżdżają, sama poprawna składnia nie rozwiąże problemu.
Warianty produktów: rozmiar, kolor i cała reszta zamieszania
Jeden produkt nadrzędny, wiele realnych ofert
Warianty potrafią szybko zrobić w sklepie mały bałagan. Jeden produkt ma kilka rozmiarów, kolorów, materiałów albo wzorów, ale każdy wariant może mieć inną cenę, dostępność, zdjęcie czy adres. Oznaczenie wyłącznie produktu nadrzędnego często nie pokazuje, co naprawdę dzieje się z konkretną wersją.
Google wspiera model ProductGroup, który pozwala powiązać warianty z produktem nadrzędnym. W tym modelu wykorzystywane są między innymi właściwości variesBy, hasVariant oraz productGroupID. Dzięki temu można opisać, według czego produkt się różni, jakie warianty do niego należą i jak je powiązać.
Każdy wariant powinien mieć informacje odpowiadające właśnie jemu. Dotyczy to szczególnie nazwy lub cechy wariantu, zdjęcia, adresu URL, ceny, waluty i dostępności. Cena czerwonej wersji nie powinna udawać ceny niebieskiej, a stan magazynowy rozmiaru M nie powinien opisywać rozmiaru XL. Brzmi oczywiście? A jednak właśnie takie rozjazdy potrafią zostać po wdrożeniu.
Jedna strona czy osobne adresy wariantów?
Google opisuje dwa podejścia. W pierwszym wszystkie warianty działają na jednej stronie, a użytkownik wybiera odpowiednią wersję. W drugim warianty mają osobne strony i adresy. Nie ma jednego uniwersalnego schematu pasującego do każdego sklepu, także do każdego wdrożenia WooCommerce.
Dane powinny odzwierciedlać faktyczną konstrukcję sklepu. Jeśli wariant ma własny adres, jego dane powinny wskazywać właściwy URL. Jeśli wybór odbywa się na jednej stronie, trzeba sprawdzić, jak sklep identyfikuje wariant i jak generuje informacje o jego cenie oraz dostępności. Najgorszy wariant to taki, w którym dane opisują produkt nadrzędny, a klient ogląda zupełnie inną wersję.
Cena i dostępność muszą mówić prawdę
Rozjazd między kartą produktu a danymi
Cena, waluta i dostępność należą do informacji, które szybko się zmieniają. Promocja się kończy, produkt znika ze stanu, wariant zostaje wyłączony albo cena zależy od wybranej wersji. W danych produktowych powinien znaleźć się stan faktyczny, a nie informacja sprzed kilku dni.
Przy kontroli sprawdź konkretny produkt i konkretny wariant. Czy cena w danych jest taka sama jak cena widoczna dla klienta? Czy waluta się zgadza? Czy dostępność dotyczy wybranej wersji, a nie całej grupy produktów? Czy zdjęcie i adres prowadzą do tej samej oferty?
Wdrożenia generowane przez JavaScript warto sprawdzić w gotowym kodzie oraz w sposobie odczytu strony przez Google. Jest to szczególnie ważne przy szybko zmieniających się cenach i stanach magazynowych. Poprawny zapis techniczny nie pomoże, jeśli wyszukiwarka odczyta starą albo niepełną informację.
Jak sprawdzić wdrożenie i nie obiecywać sobie cudów?
Krótka procedura kontroli
Kontrola nie musi zaczynać się od grzebania w całym sklepie. Można przejść przez kilka reprezentatywnych kart: zwykły produkt, produkt z wariantami, produkt dostępny oraz taki, którego dostępność się zmienia. Następnie warto:
- sprawdzić dane w Rich Results Test;
- użyć URL Inspection, aby zobaczyć, jak Google odczytuje stronę;
- zweryfikować, czy strona nie jest blokowana przez
robots.txt,noindexani logowanie; - porównać dane zwykłego produktu z danymi jego wariantów;
- sprawdzić zgodność ceny, waluty, zdjęcia, adresu URL i dostępności.
Dane produktowe mogą być przekazywane nie tylko przez dane uporządkowane na stronie, ale także przez feed w Google Merchant Center. Wykorzystanie obu metod może pomóc w lepszym zrozumieniu i weryfikacji danych, jednak nie zastępuje kontroli zgodności informacji w samym sklepie.
Poprawne dane to warunek możliwości, nie obietnica wyniku
Walidacja pokazuje, czy wdrożenie spełnia określone warunki techniczne. Nie jest obietnicą, że Google wyświetli konkretny element, w konkretnym miejscu i dokładnie w oczekiwanym formacie. Systemy Google samodzielnie oceniają dane, stronę oraz możliwość prezentacji rozszerzonego wyniku. Sposób wyświetlania może się też zmieniać.
Dlatego dane uporządkowane warto traktować jako sposób na czytelniejsze przekazanie informacji o ofercie, a nie automat do zdobywania pozycji albo sprzedaży. Jeżeli dane są niezgodne z treścią strony, mogą nie pomóc. Jeżeli są poprawne, nadal nie ma gwarancji konkretnego rozszerzenia. To po prostu solidny element porządku w sklepie — ważny, ale nie magiczny.
Najpierw uporządkuj podstawy: nazwę, zdjęcie, ofertę, cenę, walutę i dostępność. Potem osobno sprawdź warianty, bo każdy z nich może mieć własne informacje. Na końcu porównaj kartę produktu z kodem i sposobem odczytu strony przez Google. Przy większym sklepie zacznij od kilku reprezentatywnych produktów, zamiast zakładać, że jedna poprawiona karta naprawi wszystko.
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ć.
