Dane strukturalne w sklepie internetowym - co wdrożyć i jak sprawdzić

W sklepie internetowym najwięcej dają dane Product z Offer na kartach produktów, bo od nich zależy, czy Google może pokazać przy wyniku cenę, dostępność i oceny. Do tego dochodzi BreadcrumbList na produktach i kategoriach oraz Organization, a dla sklepu jego odmiana OnlineStore, na stronie głównej. Każdy typ musi opisywać to, co widać na stronie, i każdy sprawdzam w narzędziach Google przed wdrożeniem i po nim.

Jak Google traktuje dane strukturalne w sklepie

• Zalecany format to JSON-LD. Wstawiam go w kod generowany na serwerze, żeby był w HTML od pierwszego pobrania strony.
• Dane muszą odpowiadać widocznej treści. Google nie pozwala oznaczać treści, której użytkownik nie widzi, a za nadużycia może nałożyć działanie ręczne, po którym strona traci prawo do wyników z elementami rozszerzonymi (ogólne wytyczne Google).
• Poprawne dane nie gwarantują elementów rozszerzonych. O tym, czy je pokazać, Google decyduje sam.
• Dla produktów Google rozróżnia dwa rodzaje wyników: oferty sprzedawcy (merchant listings) dla stron, na których można kupić produkt, i fragmenty produktów (product snippets) dla stron bez możliwości zakupu, na przykład recenzji. Dane strukturalne i plik produktowy w Merchant Center się uzupełniają (dokumentacja Product).

Product i Offer na karcie produktu

To podstawowe oznaczenie w sklepie. Pola, które uzupełniam:

• Produkt - name, image, description, sku, kod EAN jako gtin, brand.
• Oferta - price, priceCurrency, availability, url, itemCondition.
• Promocje - cena promocyjna z datą końca, jeśli promocja ma termin. Google opisuje w dokumentacji, jak oznaczyć czas trwania obniżki.
• Dostawa i zwroty - koszty dostawy i zasady zwrotów. Google zaleca je podawać, bo pomagają kupującemu ocenić łączny koszt zakupu. Zasady wspólne dla całego sklepu można opisać raz, w danych sklepu.
• Warianty - przy produktach w kilku kolorach lub rozmiarach oznaczam grupę produktów (ProductGroup) z polami productGroupID, variesBy i hasVariant, a każdy wariant ma własny kod (dokumentacja wariantów).

Typowy problem to rozjazd: inna cena w danych, inna na stronie, a jeszcze inna w pliku dla Merchant Center. Dlatego wartości pobieram z bazy sklepu w chwili generowania strony, a nie wpisuję ich ręcznie. Po zmianie ceny pilnuję też, żeby pamięć podręczna nie serwowała starej wersji strony z nieaktualną ceną. Przy tworzeniu sklepów internetowych ustawiam to od pierwszego dnia, w istniejącym sklepie zaczynam od sprawdzenia, skąd dziś biorą się wartości w danych.

AggregateRating i Review tylko z prawdziwych opinii

Gwiazdki przy wyniku to element, przy którym najłatwiej złamać wytyczne. Zasady Google są jednoznaczne (wytyczne dotyczące opinii):

• oceny muszą pochodzić bezpośrednio od użytkowników,
• treść opinii musi być dostępna na oznaczonej stronie,
• opinia dotyczy konkretnego produktu, a nie kategorii czy listy produktów,
• nie wolno agregować ocen z innych serwisów,
• strony z danymi Organization lub LocalBusiness nie dostają gwiazdek, jeśli firma sama kontroluje opinie o sobie.

W praktyce AggregateRating dodaję tylko na produktach, które mają opinie klientów zebrane w sklepie i wyświetlone na karcie produktu. Produkt bez opinii nie dostaje pustej ani wymyślonej oceny. Nie przenoszę gwiazdek z profilu firmy w Google ani z zewnętrznych serwisów z opiniami. Jeśli opinie ładuje zewnętrzny widżet, sprawdzam, czy oznaczenie jest w wyrenderowanym kodzie strony i czy liczba ocen zgadza się z tym, co widzi klient.

BreadcrumbList w kategoriach i produktach

• Ścieżka w danych odpowiada widocznej ścieżce nawigacyjnej na stronie.
• Google zaleca ścieżkę, którą typowo przechodzi użytkownik, a nie odwzorowanie struktury adresu.
• Produkt w kilku kategoriach może mieć więcej niż jedną ścieżkę. Zwykle wybieram kategorię główną, żeby ścieżka była przewidywalna.
• Od stycznia 2025 roku Google pokazuje ścieżki nawigacyjne w wynikach tylko na komputerach (dokumentacja BreadcrumbList). Oznaczenie zostawiam, bo Google używa go także do porządkowania informacji o miejscu strony w serwisie.

Organization i OnlineStore na stronie głównej

• Google zaleca umieścić dane organizacji na stronie głównej albo na jednej stronie o firmie. Nie trzeba ich powtarzać na każdej podstronie (dokumentacja Organization).
• Pola: name, url, logo (co najmniej 112 na 112 pikseli), sameAs z profilami firmy, address, contactPoint i vatID z numerem NIP.
• Dla sklepu Google zaleca odmianę OnlineStore, w której opiszesz zasady zwrotów i dostawy dla całego sklepu.
• Dane muszą zgadzać się z tym, co jest w stopce, na stronie kontaktu i w regulaminie.

FAQPage w sklepie: co się zmieniło

Przez lata oznaczenie FAQPage rozwijało w wynikach listę pytań pod linkiem. Od 2023 roku Google pokazywał je już tylko dla autorytatywnych stron rządowych i medycznych, a od 7 maja 2026 roku przestał je pokazywać całkowicie. W czerwcu 2026 roku usunął też dokumentację tej funkcji (historia zmian w dokumentacji Google). W 2023 roku z wyników zniknęły też instrukcje HowTo.

Wniosek dla sklepu: FAQPage nie da już rozwinięcia pytań w wynikach Google. Jeśli na stronie jest widoczna sekcja pytań i odpowiedzi, oznaczenie może zostać jako opis tej treści, bo słownik schema.org jest wspólny dla różnych wyszukiwarek i narzędzi. Nie dodaję go jednak w nadziei na dodatkowe miejsce w wynikach i nigdy nie oznaczam pytań, których klient nie widzi.

Czego nie oznaczać

• Treści ukrytych przed użytkownikiem, w tym cen i opinii, których nie ma na stronie.
• Ocen na stronach kategorii i list produktów.
• Tych samych typów z kilku źródeł naraz. Motyw, wtyczka SEO i dodatkowy kod potrafią każdy wstawić własny Product, a wtedy na stronie są dwa sprzeczne opisy tego samego produktu.
• Pól z wartościami domyślnymi, na przykład dostępności „w magazynie” przy produkcie, którego nie ma.
• Danych firmy na każdej podstronie w kilku różnych wersjach, na przykład z innym adresem lub nazwą.

W jakiej kolejności wdrażać

W istniejącym sklepie pracuję w kolejności, która najszybciej daje kompletne i poprawne dane na wszystkich produktach:

1. Product i Offer w szablonie karty produktu, z ceną i dostępnością z bazy.
2. BreadcrumbList na produktach i kategoriach, zgodny z widoczną ścieżką.
3. Organization lub OnlineStore na stronie głównej, razem z zasadami zwrotów i dostawy.
4. ProductGroup dla produktów z wariantami.
5. AggregateRating i Review, jeśli sklep zbiera opinie klientów i pokazuje je na kartach produktów.

Każdy krok zamykam testem, zanim przejdę do następnego, bo błąd w szablonie powiela się na wszystkich produktach naraz.

Jak sprawdzić dane strukturalne w sklepie

1. Test wyników z elementami rozszerzonymi (search.google.com/test/rich-results) - pokazuje, do których elementów rozszerzonych Google kwalifikuje stronę, jakie są błędy i ostrzeżenia oraz jak wygląda wyrenderowany kod.
2. Walidator schema.org (validator.schema.org) - sprawdza zgodność z całym słownikiem schema.org, także z typami, których Google nie wykorzystuje w wynikach.
3. Raporty w Search Console - raporty dla produktów i ścieżek nawigacyjnych pokazują listę adresów z błędami w całym sklepie, a nie na pojedynczej stronie.
4. Próbki trudnych przypadków - produkt z wariantami, produkt niedostępny, produkt w promocji, produkt bez opinii, produkt w kilku kategoriach.
5. Kontrola po zmianach - po każdej zmianie szablonu karty produktu, motywu albo wtyczki SEO powtarzam testy na tych samych próbkach.

Najczęstsze pytania

Czy dane strukturalne poprawiają pozycje sklepu?

Nie są bezpośrednim czynnikiem rankingowym. Pomagają Google zrozumieć, że strona jest ofertą produktu, i są warunkiem części elementów rozszerzonych, takich jak cena czy oceny przy wyniku.

Czy mogę pokazać gwiazdki z opinii o firmie w Google?

Nie. Google nie pozwala agregować ocen z innych serwisów, a oceny firmy w danych Organization nie dają gwiazdek, jeśli firma sama kontroluje te opinie. Gwiazdki przy produktach są możliwe tylko z opinii o konkretnym produkcie, widocznych na jego stronie.

Czy wtyczka SEO w WooCommerce wystarczy?

Do podstawowych typów często tak. Sprawdzam jednak, czy nie dubluje danych z motywem, czy oznacza warianty i czy cena oraz dostępność zgadzają się ze stroną. Brakujące elementy dopisuję bez powielania tego, co już generuje wtyczka.

Czy nadal warto oznaczać FAQ w sklepie?

Dla wyników Google nie, bo od maja 2026 roku FAQ nie jest już pokazywane jako element rozszerzony. Oznaczenie widocznej sekcji pytań nie szkodzi, ale nie oczekuj po nim efektu w wynikach.

Kiedy pojawią się elementy rozszerzone po wdrożeniu?

Dopiero po ponownym przeskanowaniu stron przez Google, a i wtedy bez gwarancji. W Search Console widać, kiedy Google zaczął odczytywać dane i czy zgłasza błędy.

Dane strukturalne dla sklepów wdrażam w ramach implementacji schema.org: wzorce powstają na serwerze, pobierają ceny i dostępność z bazy i są sprawdzone w obu narzędziach Google. Jeśli dane strukturalne to tylko jeden z punktów audytu SEO, rozsądniej objąć je szerszym wdrożeniem technicznych rekomendacji SEO.