Gdzie w sklepie wdrożyć dane strukturalne, a gdzie nie ma to sensu

Dostajesz ofertę albo audyt, a w nim punkt: „wdrożyć dane strukturalne”. Brzmi poważnie i prawdopodobnie jest słuszne, tylko z samego zdania nie wynika, czego właściwie dotyczy ta praca — czy wszystkich stron w sklepie, czy kilku, i co dokładnie się po niej zmieni.

Zacznijmy więc od tego, czym to jest, bo bez tego cała reszta jest zgadywaniem. Twoja strona jest napisana dla człowieka. Klient patrzy na kartę produktu i od razu wie, że „129 zł” to cena, „Dostępny” to stan magazynowy, a „Ogrodnik” to marka. Wyszukiwarka i asystent AI tego nie wiedzą — widzą tekst i muszą zgadywać, co czym jest. Dane strukturalne są dodatkowym blokiem w kodzie strony, niewidocznym dla klienta, w którym mówisz wprost: to jest cena, to jest marka, to jest ocena. Dzięki temu Google może pokazać Twój wynik bogaciej — z ceną, dostępnością i gwiazdkami — a maszyna, która czyta Twoją stronę, nie musi niczego się domyślać.

Najłatwiej wyobrazić sobie taki blok jako wypełnioną metryczkę, której klient nie widzi. Przy karcie produktu jej rubryki to mniej więcej: nazwa produktu, zdjęcie, marka, numer katalogowy, kod kreskowy, parametry takie jak waga czy wymiary, a obok tego cena, waluta, dostępność, stan produktu oraz warunki dostawy i zwrotu. Przy opisie firmy rubryki są inne — nazwa, logo, adres, telefon, profile w serwisach społecznościowych. Treści się przy tym nie wymyśla: do metryczki wpisuje się dokładnie to, co klient i tak widzi na stronie, tylko w postaci, która nie wymaga interpretacji.

W skrócie: nie wdraża się tego wszędzie, bo każdy typ strony opisuje się czym innym. Na karcie produktu opisuje się produkt wraz z ofertą, na stronie kategorii listę prowadzącą do produktów, na stronie głównej firmę, a na wpisie blogowym artykuł. Przez cały sklep warto przy tym przeprowadzić ścieżkę nawigacyjną — to jest najtańsza i najpewniejsza rzecz w całym temacie. Najczęstszy błąd polega natomiast na powieleniu opisu produktu na stronach z listami, co nie daje nic, a mnoży miejsca, w których dane mogą się rozjechać.

W tym tekście: co należy na każdy typ strony i dlaczego akurat to, czego tam nie wstawiać, od czego zacząć oraz co z tego wszystkiego ma znaczenie przy asystentach AI.

Jedna zasada zamiast listy wyjątków

Cały temat da się sprowadzić do jednego pytania, które warto zadać przy każdej stronie w sklepie: czym ta strona jest dla kogoś, kto na nią trafia. Nie co na niej widać, nie co da się z niej kupić — czym ona jest.

Karta produktu jest produktem, więc opisuje się ją jako produkt. Kategoria produktem nie jest; jest listą prowadzącą do produktów, nawet jeśli przy każdym kafelku jest przycisk dodania do koszyka. Strona główna nie jest ani jednym, ani drugim, bo jest firmą. A koszyk nie jest niczym, co miałoby trafić do wyników wyszukiwania.

Google formułuje to zresztą wprost: wyniki produktowe obsługują strony skupione na jednym produkcie albo na wariantach tego samego produktu, a dokumentacja podaje przykład, że „buty zimowe w naszym sklepie” nie są konkretnym produktem. Zalecenie jest jednoznaczne — opisywać karty produktów, a nie strony z listami.

Karta produktu

To jest najważniejsza strona w całym zestawieniu i zarazem jedyna, na której metryczka produktu ma sens. Wypełnia się w niej dwie grupy rubryk — czym produkt jest i na jakich warunkach go sprzedajesz: nazwa, zdjęcie, marka, numer katalogowy, parametry, a obok tego cena, waluta, dostępność i stan produktu. Jeśli ten sam produkt występuje w wariantach — rozmiarach, pojemnościach, kolorach — całość opisuje się jako grupę produktów, a nie jako jeden produkt z widełkami cenowymi.

Co to daje: w wynikach wyszukiwania Google może pokazać przy Twojej stronie cenę i informację o dostępności, czyli wynik zajmuje więcej miejsca i mówi więcej, zanim ktokolwiek w niego kliknie. Szczegóły, włącznie z przykładami kodu, rozpisaliśmy w tekście o tym, jak zapisać dane produktowe w kodzie karty produktu.

Na karcie produktu opisuje się też oceny, jeśli je zbierasz — przy czym obowiązuje reguła, która bywa źródłem nieporozumień i kosztuje wiele sklepów gwiazdki w wynikach: oceny produktu wolno opisywać, oceny własnej firmy nie. Wyjaśniamy to w tekście o tym, jak opisać oceny i opinie w kodzie sklepu.

Strona kategorii

Kategoria jest listą, więc opisuje się ją jako listę pozycji prowadzących do kart produktów — i tu tkwi szczegół, o który najczęściej pytają wdrożeniowcy, a który oszczędza sporo pracy. Pozycja na takiej liście zawiera tylko numer w kolejności i adres strony ze szczegółami. Nie powtarza się w niej ceny, dostępności ani opisu, bo te siedzą na kartach produktów, do których lista prowadzi.

Mówiąc po ludzku, kategoria informuje: mam tu trzydzieści rzeczy, w tej kolejności, każda opisana pod swoim adresem. Nie: mam tu trzydzieści produktów, a oto ich ceny. Konsekwencja jest praktyczna — taka lista nie dezaktualizuje się przy każdej zmianie ceny, bo cen w ogóle nie zawiera.

Warto wiedzieć, że powiązany z tym wynik w formie karuzeli Google dopiero rozwija, choć jest dostępny także w Polsce. Jest to jednak funkcja młoda i zmienna, więc traktujemy ją jako dodatek, a nie jako powód do przebudowy sklepu. Na kategorii zdecydowanie bardziej przyda się ścieżka nawigacyjna, o której za chwilę.

Ścieżka nawigacyjna, czyli rzecz do zrobienia w pierwszej kolejności

Przez cały sklep przechodzi jeden znacznik, tani we wdrożeniu i działający od lat: okruszki nawigacyjne, czyli ścieżka „Sklep › Suplementy › Odżywki białkowe”. Google pokazuje ją w wyniku wyszukiwania zamiast surowego adresu, dzięki czemu wynik jest czytelniejszy, a klikający od razu wie, w którym miejscu sklepu wyląduje.

Jest jedno zalecenie merytoryczne, które w sklepach bywa ignorowane, a robi różnicę: ścieżka ma odwzorowywać typową drogę użytkownika, a nie strukturę adresu. To są dwie różne rzeczy, bo adres bywa płaski albo niesie historyczne pozostałości po dawnej strukturze sklepu, a ścieżka ma mówić, gdzie klient się znajduje.

Gdyby trzeba było wskazać jedną rzecz do zrobienia w sklepie, który nie ma jeszcze żadnych danych strukturalnych, byłaby to właśnie ścieżka nawigacyjna — kosztuje najmniej, nie wymaga żadnych decyzji i poprawia wygląd każdego wyniku, nie tylko produktowego.

Strona główna

Tutaj opisuje się firmę: nazwę, logo, dane kontaktowe, profile w serwisach społecznościowych, a przy sprzedaży stacjonarnej także adres i godziny otwarcia. Jest to wdrożenie szybkie i bezbolesne, bo wszystkie te dane i tak już na stronie masz — chodzi wyłącznie o zapisanie ich w postaci, którą maszyna odczyta bez zgadywania.

Czego natomiast na stronie głównej nie wstawiać: oceny własnej firmy. Wygląda to niewinnie i bywa wdrażane w dobrej wierze, zwłaszcza gdy sklep ma kilkaset opinii i ładny widżet ze średnią — a jest to dokładnie ten przypadek, w którym Google nie pokazuje gwiazdek nikomu, bo firma ocenia sama siebie. Opisujemy to szerzej w tekście o tym, jak opisać oceny i opinie w kodzie sklepu.

Wpisy blogowe i poradniki

Wpis blogowy opisuje się jako artykuł: tytuł, autor, data publikacji i data ostatniej aktualizacji. Brzmi to banalnie, a zwłaszcza ta ostatnia data ma konkretne znaczenie przy treściach poradnikowych, bo odróżnia tekst sprawdzony od takiego, który leży bez zmian od trzech lat — i jest to rozróżnienie istotne zarówno dla czytelnika, jak i dla asystenta budującego z tego odpowiedź.

Jeśli w poradniku masz sekcję pytań i odpowiedzi, warto wiedzieć, że Google wycofał dla niej wynik rozszerzony. Nie znaczy to wcale, że taka sekcja przestała mieć sens — wręcz przeciwnie — i wyjaśniamy to w tekście o tym, co dziś daje sekcja pytań i odpowiedzi po zmianach w Google.

Strony, na których nie robi się nic

Koszyk, podsumowanie zamówienia, konto klienta, wyniki wyszukiwania wewnętrznego i strony techniczne nie potrzebują żadnych danych strukturalnych, ponieważ nie mają trafiać do wyników wyszukiwania. Nie znaczy to jednak, że należy je blokować w pliku z regułami dostępu — wręcz odwrotnie, bo zablokowana strona nie zostanie przeczytana, więc robot nie zobaczy umieszczonego na niej znacznika zakazującego indeksowania. Rozróżnienie między tymi dwoma mechanizmami opisujemy w tekście o tym, czym różnią się robots.txt, mapa strony i llms.txt.

Co gdzie idzie: zestawienie

Najczęstszy błąd: opis produktu na stronie z listą

Warto zatrzymać się przy nim dłużej, bo jest to odruch wtyczek, bywa wdrażany z całkiem dobrych pobudek i kosztuje więcej, niż się wydaje.

Pokusa jest zrozumiała: skoro opis produktu działa na karcie, to trzydzieści takich opisów na stronie kategorii powinno działać trzydzieści razy lepiej. W rzeczywistości nie działa wcale, ponieważ strona z listą nie kwalifikuje się do funkcji produktowych — a przy okazji mnoży przez trzydzieści ryzyko, że dane się rozjadą, bo ceny na liście i na kartach aktualizują się osobno i nie zawsze w tej samej chwili. Efekt jest więc podwójnie niedobry: zero korzyści i trzydzieści miejsc, w których kod może powiedzieć coś innego, niż widzi klient. A obowiązuje przy tym reguła, że w kodzie ma być dokładnie to, co widać na stronie.

Od czego zacząć

Zaczynamy od ścieżki nawigacyjnej w całym sklepie, bo jest tania, działa od lat, nie wymaga żadnych decyzji i poprawia wygląd każdego wyniku, nie tylko produktowego.

Drugim krokiem jest komplet danych o produkcie i ofercie na kartach produktów. Mowa tu o metryczce w kodzie, a nie o tekście opisu, który czyta klient — choć jedno z drugim się wiąże, bo jeśli parametr nie istnieje nigdzie w sklepie, nie ma go czym wypełnić. Chodzi o to, żeby w kodzie znalazła się nie tylko nazwa, cena i dostępność, ale też te parametry, po których klienci wybierają w Twojej branży: pojemność, moc, wymiary, nośność. To jest największy zwrot z całej tej pracy i zarazem część, która zajmuje najwięcej czasu, zwłaszcza przy dużym katalogu.

Trzecim, szybkim i bezbolesnym, jest opis firmy na stronie głównej. Czwartym lista pozycji na kategoriach, przy czym nie spieszylibyśmy się z nią: ma sens dopiero wtedy, gdy dwa pierwsze punkty są wdrożone, a związana z nią funkcja w wynikach dopiero się rozwija.

Jeśli zastanawiasz się, jak ta praca układa się w szerszym planie — razem z dostępem dla botów, treścią i pomiarem — opisaliśmy to w tekście o tym, od czego zacząć pracę nad widocznością w AI.

Co z tego ma znaczenie przy asystentach AI

Trzeba tu rozdzielić dwie rzeczy, bo rynek chętnie je zlepia, a z tego zlepienia biorą się zarówno przesadzone obietnice, jak i przesadzone lekceważenie.

Z jednej strony Google pisze wprost, że do pojawienia się w jego własnych funkcjach opartych na AI nie trzeba dodawać żadnych specjalnych danych strukturalnych. Jest to jednak stanowisko jednego dostawcy i jego ekosystemu — pozostali nie składali podobnych deklaracji, a dane produktowe zapisane maszynowo pozostają tym, z czego korzystają powierzchnie zakupowe i kanały, którymi katalogi trafiają do asystentów.

Z drugiej strony jest rzecz praktyczna, którą widać u klientów: uporządkowane dane są jedyną postacią, w której informacja o produkcie daje się przenieść poza stronę — do porównywarki, do kanału produktowego, do narzędzia, które powstanie za rok. Opis wtopiony w akapit zostaje tam, gdzie jest; cena, dostępność i parametr zapisane jako osobne wartości jadą dalej bez przepisywania.

Dla rozkładu danych strukturalnych po sklepie wynika z tego jeden wniosek, który warto zapamiętać: najwięcej daje porządek na kartach produktów, a nie liczba typów wdrożonych w sklepie. Sklep z dobrze opisanymi kartami i ścieżką nawigacyjną jest w lepszej sytuacji niż taki, który ma pięć różnych typów rozsianych po wszystkich stronach, ale na karcie produktu wyłącznie nazwę i cenę.

Jeśli chcesz zobaczyć, co asystenci wyczytują dziś z Twojego sklepu i gdzie są największe luki — zamów darmowy raport GEO. Jeśli wolisz od razu zobaczyć, ile kosztuje wdrożenie i co obejmuje, mamy zakres i ceny pakietów GEO.

Jak sprawdzić, co masz u siebie

Nie potrzebujesz do tego dostępu do kodu ani niczyjej pomocy. Otwórz walidator danych strukturalnych pod adresem validator.schema.org, wklej adres swojej karty produktu i uruchom sprawdzenie — narzędzie wypisze wszystkie typy, jakie znalazło na tej stronie, a nazwy będą po angielsku, bez spacji. Powtórz to samo dla kategorii, dla strony głównej i dla jednego wpisu blogowego.

Czego szukać: na karcie produktu metryczki produktu wraz z ofertą, na stronie kategorii ścieżki nawigacyjnej i ewentualnie listy pozycji, na stronie głównej danych firmy, a na wpisie opisu artykułu. Jeśli na stronie kategorii znajdziesz trzydzieści opisów produktów, wiesz już, co poprawić w pierwszej kolejności. Jeśli natomiast wyniki nic Ci nie mówią, pokaż je osobie utrzymującej sklep — odpowie w kilka minut, a Ty dostaniesz gotową listę rzeczy do zrobienia.

Najczęstsze pytania

Czym są dane strukturalne w sklepie internetowym?
To dodatkowy blok w kodzie strony, niewidoczny dla klienta, w którym zapisujesz wprost, co jest ceną, co marką, a co oceną. Dzięki niemu wyszukiwarka i asystenci AI nie muszą się domyślać, a Google może pokazać Twój wynik bogaciej — z ceną, dostępnością czy gwiazdkami.

Jakie dane strukturalne wdrożyć w sklepie internetowym?
Na kartach produktów opis produktu wraz z ofertą, na kategoriach listę pozycji prowadzących do kart, na stronie głównej dane firmy, a na wpisach blogowych opis artykułu. Przez cały sklep warto dodatkowo przeprowadzić ścieżkę nawigacyjną.

Czy wstawiać znacznik produktu na stronie kategorii?
Nie. Strona z listą nie kwalifikuje się do funkcji produktowych w wynikach wyszukiwania, a powielenie opisu produktu dla każdej pozycji mnoży ryzyko, że dane w kodzie rozejdą się z tym, co widzi klient.

Czy przycisk „dodaj do koszyka” na stronie kategorii zmienia sytuację?
Nie zmienia. Kryterium jest to, czy strona dotyczy jednego produktu, a nie czy da się z niej kupić — strona z trzydziestoma kafelkami pozostaje listą.

Od czego zacząć wdrażanie danych strukturalnych w sklepie?
Od ścieżki nawigacyjnej w całym sklepie, bo jest najtańsza i działa od lat. Potem porządny opis produktu i oferty na kartach, dane firmy na stronie głównej, a listy pozycji na kategoriach na końcu.

Czy dane strukturalne pomagają w widoczności w AI?
Google pisze, że do jego własnych funkcji opartych na AI nie trzeba ich dodawać, ale jest to stanowisko jednego dostawcy i jego ekosystemu. Uporządkowane dane pozostają jedyną postacią, w której informacja o produkcie daje się przenieść poza stronę — do porównywarek i do kanałów, którymi katalogi trafiają do asystentów.

Czy koszyk i konto klienta wymagają danych strukturalnych?
Nie, bo te strony nie mają trafiać do wyników wyszukiwania. Nie należy ich też blokować w pliku z regułami dostępu, bo wtedy robot nie przeczyta umieszczonego na nich zakazu indeksowania.

Ile typów danych strukturalnych powinien mieć sklep?
Tyle, ile ma rodzajów stron, i ani jednego więcej. Liczba typów nie jest miarą jakości wdrożenia — porządek na kartach produktów daje więcej niż pięć typów rozsianych po sklepie przy ubogim opisie produktu.

Czy mogę wdrożyć to wtyczką?
Przy większości platform tak i jest to rozsądny start, ale warto potem sprawdzić wynik: wtyczki bywają zbyt gorliwe i powielają opis produktu tam, gdzie nie powinien się znaleźć.

Znacznik opisuje stronę, a nie jej zawartość

Cały ten temat sprowadza się do jednego pytania, które warto zadawać przy każdej stronie w sklepie: czym ona właściwie jest — produktem, listą, firmą czy artykułem. Odpowiedź rozstrzyga, co w kodzie tej strony powinno się znaleźć, i oszczędza dyskusji o tym, czy wdrażać dane strukturalne wszędzie.

Otwórz więc walidator, wklej adres swojej najważniejszej kategorii i sprawdź jedną rzecz: czy nie siedzi tam trzydzieści opisów produktów. Jeśli siedzi, masz do zrobienia porządek, który nic nie kosztuje poza godziną pracy, a usuwa trzydzieści miejsc, w których dane mogą się rozjechać.