Dane strukturalne produktów WooCommerce — schema Product, Offer i Review

Produkt w sklepie ma nazwę, zdjęcia, cenę, dostępność, markę, warianty i opinie. Klient widzi te informacje na karcie produktu. Google musi jednak samodzielnie ustalić, który fragment strony jest ceną, który stanem magazynowym, a który oceną klientów.

Dane strukturalne produktów opisują te elementy w uporządkowanym formacie. Dzięki nim wyszukiwarka może lepiej zrozumieć ofertę oraz zakwalifikować stronę do rozszerzonych wyników zawierających między innymi cenę, dostępność i ocenę produktu.

Problem zaczyna się wtedy, gdy kod pokazuje inną cenę niż karta produktu, niedostępny wariant jest oznaczony jako dostępny albo kilka wtyczek tworzy trzy różne obiekty Product. Technicznie strona może nadal działać, ale Google i Merchant Center otrzymują sprzeczne informacje.

Ten artykuł odpowiada za techniczną część danych produktów: Product, Offer, warianty, identyfikatory, opinie i konflikty między wtyczkami. Proces pozyskiwania oraz moderowania recenzji opisujemy osobno w poradniku o opiniach i ocenach produktów w WooCommerce. Jeżeli dopiero porządkujesz całą widoczność sklepu, zacznij od poradnika SEO sklepu WooCommerce — od czego zacząć. Szerszą diagnostykę techniki, treści i struktury znajdziesz natomiast w artykule audyt SEO sklepu internetowego — co zawiera i kiedy go zlecić.

Odpowiedź wprost

Poprawne dane strukturalne produktu w WooCommerce powinny:

1. Opisywać dokładnie ten produkt, który użytkownik widzi na stronie.
2. Zawierać aktualną nazwę, zdjęcie i adres produktu.
3. Przekazywać rzeczywistą cenę oraz właściwą walutę.
4. Pokazywać aktualną dostępność.
5. Wskazywać markę, SKU i GTIN, jeżeli takie identyfikatory istnieją.
6. Rozróżniać produkt prosty od wariantów.
7. Łączyć warianty za pomocą ProductGroup, gdy wymaga tego konstrukcja sklepu.
8. Przekazywać opinie i średnią ocenę tylko wtedy, gdy są widoczne na stronie.
9. Zgadzać się z danymi w feedzie Google Merchant Center.
10. Być generowane przez jeden spójny system, a nie kilka konkurujących wtyczek.
11. Aktualizować się po zmianie ceny, promocji, wariantu lub stanu magazynowego.
12. Przechodzić test wyników z elementami rozszerzonymi bez błędów krytycznych.

Dane strukturalne zwiększają możliwość wyświetlenia rozszerzonego wyniku, ale nie gwarantują, że Google pokaże cenę, gwiazdki lub dostępność przy każdym zapytaniu.

W skrócie (TL;DR)

• Product opisuje produkt, a Offer przedstawia konkretną ofertę sprzedaży.
• AggregateOffer pokazuje zakres cen wielu ofert, ale nie zawsze dobrze opisuje wariant kupowany bezpośrednio w sklepie.
• Review opisuje pojedynczą opinię, a AggregateRating średnią ocenę produktu.
• ProductGroup pomaga połączyć warianty różniące się kolorem, rozmiarem, materiałem lub inną cechą.
• Cena, waluta i dostępność muszą zgadzać się na stronie, w schema, podczas zakupu oraz w Merchant Center.
• Nie wymyślaj kodów GTIN. Dodawaj je tylko wtedy, gdy zostały rzeczywiście nadane produktowi.
• WooCommerce generuje podstawowe dane automatycznie, ale motyw i wtyczki mogą tworzyć duplikaty.
• Poprawny kod daje możliwość rozszerzonego wyniku, a nie gwarancję jego wyświetlenia.
• Najpierw napraw dane produktu w WooCommerce, a dopiero później poprawiaj sam kod schema.

Czym są dane strukturalne produktów?

Dane strukturalne to informacje zapisane w kodzie strony w formacie zrozumiałym dla wyszukiwarki. Klient widzi na stronie: „Biurko regulowane Varius — 2999 zł — Dostępne — Kolor: dąb naturalny — Ocena: 4,7 na podstawie 38 opinii". W kodzie można przekazać te same informacje w uporządkowanej formie:

{
  "@type": "Product",
  "name": "Biurko regulowane Varius",
  "offers": {
    "@type": "Offer",
    "price": 2999,
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock"
  }
}

Schema nie jest osobnym opisem przeznaczonym wyłącznie dla Google — powinna odzwierciedlać to, co rzeczywiście znajduje się na stronie. Jeżeli klient widzi cenę 2999 zł, a kod pokazuje 2699 zł, dane są niespójne.

Czym jest Schema.org, JSON-LD i rich result?

Te pojęcia są często używane razem, ale oznaczają różne rzeczy.

Pojęcie	Co oznacza po ludzku?
Schema.org	Słownik typów i właściwości używanych do opisywania treści
Dane strukturalne	Informacje zapisane według ustalonego schematu
JSON-LD	Format zapisu danych strukturalnych w kodzie strony
Product	Typ opisujący produkt
Offer	Typ opisujący ofertę sprzedaży
Rich result	Rozszerzony wynik w Google, np. z ceną lub oceną
Merchant listing	Wynik produktowy związany z ofertą możliwą do kupienia
Product snippet	Wynik tekstowy zawierający dodatkowe dane o produkcie

Google obsługuje kilka formatów danych strukturalnych, ale w praktyce najczęściej stosuje się JSON-LD. Przykładowy kod znajduje się zwykle w sekcji <script type="application/ld+json">…</script> — nie jest widoczny jako zwykły tekst na stronie, ale opisane w nim informacje powinny być widoczne dla klienta.

Co dane strukturalne mogą zmienić w wynikach Google?

Poprawne dane produktu mogą zwiększyć możliwość pokazania między innymi ceny, waluty, dostępności, oceny, liczby opinii, stanu produktu, informacji o wysyłce i zwrotach, wariantów oraz zdjęć produktu.

Produkt może pojawić się w różnych miejscach i formach: w zwykłym wyniku tekstowym, w wynikach produktowych, w Google Images, w Google Lens, w panelach produktowych albo w bezpłatnych informacjach produktowych. Nie oznacza to, że wdrożenie schema automatycznie doda wszystkie te elementy. Google sam decyduje, czy pokazać wynik rozszerzony, jakie elementy wyświetlić, dla jakiego zapytania, na jakim urządzeniu i w jakiej lokalizacji. Dane strukturalne zwiększają czytelność informacji dla wyszukiwarki — nie są poleceniem wymuszającym określony wygląd wyniku.

Product snippet a merchant listing — jaka jest różnica?

Google rozróżnia dwa główne zastosowania danych produktów.

Product snippet to najczęściej zwykły wynik tekstowy wzbogacony o informacje produktowe — może zawierać cenę, dostępność, ocenę i liczbę opinii. Ten typ może być używany także na stronach, na których produkt jest opisywany, ale niekoniecznie bezpośrednio sprzedawany: recenzja produktu na portalu, porównanie modeli albo strona producenta bez możliwości zakupu.

Merchant listing dotyczy strony, na której klient może kupić produkt — w sklepie WooCommerce jest to zwykle właściwy model. Poza podstawowymi danymi produktu może obejmować konkretną ofertę sprzedaży, cenę, dostępność, wysyłkę, zwroty, stan produktu, warianty oraz ceny członkowskie lub promocyjne. Jeżeli prowadzisz sklep, nie ograniczaj się wyłącznie do opinii i ogólnego zakresu cen — produkt powinien mieć rzeczywistą ofertę Offer, odpowiadającą warunkom zakupu widocznym na stronie.

Najważniejsze typy schema dla produktu

Typ	Co opisuje?	Przykład
Product	Sam produkt	Biurko Varius
Offer	Konkretną ofertę sprzedawcy	Cena 2999 zł, produkt dostępny
AggregateOffer	Zbiorczy zakres wielu ofert	Cena od 2999 do 3499 zł
ProductGroup	Rodzinę wariantów	Biurko w kilku kolorach i rozmiarach
Review	Pojedynczą recenzję	Opinia konkretnego klienta
Rating	Ocenę w konkretnej opinii	5 na 5
AggregateRating	Średnią ocenę produktu	4,7 na podstawie 38 ocen
Brand	Markę produktu	Marka X
Organization	Sprzedawcę lub firmę	Nazwa sklepu
OfferShippingDetails	Warunki wysyłki oferty	Koszt i czas dostawy
MerchantReturnPolicy	Zasady zwrotu	Zwrot w określonym terminie

Nie każdy produkt potrzebuje wszystkich elementów. Kod powinien odpowiadać rzeczywistemu modelowi sprzedaży.

Product — co opisuje produkt?

Obiekt Product identyfikuje produkt znajdujący się na stronie. Najczęściej zawiera nazwę, zdjęcia, opis, adres URL, markę, SKU, GTIN, MPN, kolor, materiał, rozmiar, ofertę, opinie i średnią ocenę. Przykładowa podstawa:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Biurko regulowane Varius 120 × 65 cm",
  "description": "Biurko z elektryczną regulacją wysokości i dębowym blatem.",
  "image": [
    "https://sklep.pl/wp-content/uploads/biurko-varius-1.webp",
    "https://sklep.pl/wp-content/uploads/biurko-varius-2.webp"
  ],
  "sku": "VARIUS-120-OAK",
  "brand": {
    "@type": "Brand",
    "name": "Przykładowa marka"
  }
}

Sam Product nie opisuje jeszcze warunków zakupu. Do tego służy Offer.

Jakie informacje produktu warto przekazywać?

name powinno odpowiadać nazwie produktu widocznej na stronie. Nie wstawiaj do schema innej, sztucznie rozbudowanej nazwy tylko po to, aby dodać więcej fraz — jeżeli na stronie widnieje „Biurko Varius 120 cm", w kodzie nie powinno nagle pojawić się „Najlepsze tanie biurko elektryczne regulowane do biura promocja".

description powinien odpowiadać rzeczywistemu produktowi. Nie musi zawierać pełnego opisu strony — może być krótszym, konkretnym podsumowaniem: czym jest produkt, jakie ma główne właściwości i do czego służy.

image — adresy powinny prowadzić do zdjęć dostępnych dla Google, przedstawiających ten produkt, odpowiedniej jakości, niezablokowanych w robots.txt i niewymagających logowania. Nie używaj zdjęcia kategorii albo logo sklepu jako głównej fotografii produktu.

url powinien wskazywać właściwy adres karty produktu. Jeżeli produkt ma kilka wariantów pod różnymi URL-ami, każdy adres musi być prawidłowo powiązany z konkretnym wariantem.

brand powinna odpowiadać rzeczywistemu producentowi lub marce produktu. Nie wpisuj automatycznie nazwy sklepu jako marki każdego produktu, jeżeli sprzedajesz towary innych producentów.

sku jest wewnętrznym identyfikatorem magazynowym produktu (np. VARIUS-120-OAK-BLACK). W sklepie z wariantami każdy wariant może mieć własne SKU.

gtin jest globalnym identyfikatorem handlowym. W zależności od długości może występować jako gtin8, gtin12, gtin13 lub gtin14. W Polsce często spotykany jest kod EAN-13 przekazywany jako gtin13. Nie wymyślaj kodu GTIN, jeżeli produkt go nie ma — fałszywy identyfikator jest gorszy niż brak identyfikatora, ponieważ może połączyć produkt z niewłaściwym towarem.

mpn to numer części nadany przez producenta. Może być przydatny, gdy produkt nie ma GTIN, producent używa własnego oznaczenia modelu albo ten sam produkt jest sprzedawany w wielu sklepach. MPN nie powinien być automatycznie zastępowany SKU sklepu, jeżeli są to dwa różne identyfikatory.

Offer — cena, waluta i dostępność

Offer opisuje konkretną ofertę sprzedaży produktu. Najważniejsze informacje to cena, waluta, dostępność, adres oferty, stan produktu, sprzedawca, wysyłka i zwroty. Przykład:

{
  "@type": "Offer",
  "url": "https://sklep.pl/biurko-varius-120/",
  "price": 2999,
  "priceCurrency": "PLN",
  "availability": "https://schema.org/InStock",
  "itemCondition": "https://schema.org/NewCondition"
}

price powinna być aktualną ceną, za którą klient może kupić produkt. Nie wpisuj ceny przed rabatem jako aktualnej, ceny netto jeżeli klient widzi brutto, ceny najtańszego wariantu gdy otwarty jest droższy wariant, kwoty bez obowiązkowych dopłat ani ceny widocznej wyłącznie po zalogowaniu, jeśli kod sugeruje ofertę publiczną.

priceCurrency powinna być zapisana trzyliterowym kodem (PLN, EUR, CZK, GBP, USD). Nie używaj zapisu zł, PL ani „polski złoty".

availability powinna odpowiadać realnej możliwości zakupu.

Wartość	Znaczenie
InStock	Produkt dostępny
OutOfStock	Produkt niedostępny
BackOrder	Produkt dostępny na zamówienie
PreOrder	Można złożyć zamówienie przed premierą
LimitedAvailability	Ograniczona dostępność
Discontinued	Produkt wycofany
SoldOut	Produkt wyprzedany

Nie oznaczaj produktu jako InStock, jeżeli nie można dodać go do koszyka, żaden wariant nie jest dostępny, sprzedaż została zakończona albo produkt pełni wyłącznie funkcję katalogową.

itemCondition — najczęściej spotykane wartości to NewCondition, UsedCondition i RefurbishedCondition. Jeżeli sklep sprzedaje wyłącznie nowe produkty, parametr może być generowany automatycznie; przy produktach używanych albo odnowionych stan musi być zgodny z opisem na stronie.

Przykład kompletnego schema dla prostego produktu

Poniższy przykład jest poglądowy. Należy go dostosować do danych konkretnego produktu i sposobu działania sklepu.

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "@id": "https://sklep.pl/biurko-varius-120/#product",
  "name": "Biurko regulowane Varius 120 × 65 cm",
  "url": "https://sklep.pl/biurko-varius-120/",
  "description": "Biurko z elektryczną regulacją wysokości, dębowym blatem i pamięcią trzech pozycji.",
  "image": [
    "https://sklep.pl/wp-content/uploads/biurko-varius-120-front.webp",
    "https://sklep.pl/wp-content/uploads/biurko-varius-120-detal.webp"
  ],
  "sku": "VARIUS-120-OAK-BLACK",
  "gtin13": "5901234567890",
  "brand": {
    "@type": "Brand",
    "name": "Przykładowa marka"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://sklep.pl/biurko-varius-120/",
    "price": 2999,
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "Przykładowy sklep"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.7,
    "ratingCount": 38
  }
}
</script>

Ważne: nie kopiuj przykładowego GTIN, nie wpisuj przykładowej oceny, nie hardkoduj ceny, nie deklaruj dostępności niezależnie od magazynu i nie dodawaj opinii, których nie ma na stronie. Dane powinny być generowane dynamicznie na podstawie WooCommerce.

Offer czy AggregateOffer?

To częsty problem w sklepach z wariantami.

Offer opisuje konkretną ofertę („krzesło czarne, rozmiar standardowy, cena 399 zł, dostępne"). Dla strony sklepu, na której klient może kupić konkretny produkt, Offer jest zwykle najbardziej precyzyjny.

AggregateOffer opisuje zakres wielu ofert:

{
  "@type": "AggregateOffer",
  "lowPrice": 2999,
  "highPrice": 3499,
  "priceCurrency": "PLN",
  "offerCount": 8
}

Może mieć sens, gdy strona pokazuje kilka ofert różnych sprzedawców, kilka cen produktu albo zakres cen wariantów.

Dlaczego sam zakres cen może być problemem? Załóżmy, że biurko ma warianty:

Wariant	Cena
120 cm, stelaż czarny	2999 zł
140 cm, stelaż czarny	3299 zł
160 cm, stelaż biały	3499 zł

WooCommerce może pokazać na początku „2999–3499 zł", ale feed Merchant Center przesyła każdy wariant osobno. Jeżeli reklama prowadzi do wariantu za 3499 zł, a kod strony pokazuje jedynie zakres zaczynający się od 2999 zł, Google może mieć problem z potwierdzeniem ceny konkretnego wariantu. W takim przypadku trzeba sprawdzić, czy URL otwiera właściwy wariant, czy wariant jest od razu zaznaczony, czy widoczna cena odpowiada feedowi, czy schema opisuje konkretną wersję i czy każdy wariant ma własny identyfikator. Nie należy automatycznie zmieniać AggregateOffer na Offer bez analizy konstrukcji karty produktu.

Produkty wariantowe i ProductGroup

Produkt wariantowy to produkt dostępny w kilku wersjach — kolorach, rozmiarach, materiałach, pojemnościach, wzorach lub konfiguracjach. Każda kombinacja może mieć inną cenę, własne SKU, osobny GTIN, inną dostępność, własne zdjęcie i inny czas dostawy. Jeżeli schema opisuje tylko produkt nadrzędny i zakres cen, Google może nie otrzymać pełnych danych konkretnych wariantów.

Do czego służy ProductGroup? Łączy produkty będące wersjami tej samej rodziny. Najważniejsze właściwości: productGroupID (identyfikator grupy lub produktu nadrzędnego), variesBy (cechy rozróżniające warianty), hasVariant (warianty należące do grupy) i isVariantOf (wskazanie grupy przez wariant). Przykład uproszczony:

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Biurko regulowane Varius",
  "productGroupID": "VARIUS",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size",
    "https://schema.org/material"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Biurko Varius 120 cm — dąb, czarny stelaż",
      "sku": "VARIUS-120-OAK-BLACK",
      "color": "Dąb naturalny / czarny",
      "size": "120 × 65 cm",
      "offers": {
        "@type": "Offer",
        "price": 2999,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Biurko Varius 160 cm — dąb, biały stelaż",
      "sku": "VARIUS-160-OAK-WHITE",
      "color": "Dąb naturalny / biały",
      "size": "160 × 80 cm",
      "offers": {
        "@type": "Offer",
        "price": 3499,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/BackOrder"
      }
    }
  ]
}

Jeden adres dla wszystkich wariantów. W tym modelu klient wybiera wariant na jednej karcie produktu. Trzeba sprawdzić, czy po zmianie wariantu aktualizują się cena, dostępność, zdjęcie, SKU, GTIN, adres URL lub parametr wariantu oraz dane przekazywane do koszyka. Schema powinna odzwierciedlać warianty dostępne na stronie albo właściwie opisywać aktualnie wybraną wersję.

Osobny adres dla każdego wariantu. W tym modelu każdy wariant ma własny URL (np. /biurko-varius-120-dab-czarne/, /biurko-varius-160-dab-biale/). Każda strona powinna opisywać konkretny wariant: własną cenę, dostępność, SKU, GTIN, właściwe zdjęcie i prawidłowy canonical. Wariant może wskazywać grupę przez isVariantOf.

Kiedy wdrożenie wariantów wymaga pracy programistycznej? Najczęściej wtedy, gdy WooCommerce zwraca tylko zakres cen, każdy wariant ma własny GTIN, feed przesyła warianty osobno, wybrany wariant nie zmienia URL-a, schema nie aktualizuje ceny, wtyczka pokazuje inną dostępność niż magazyn, część wariantów jest niedostępna, każdy wariant ma osobną stronę SEO albo Google zgłasza niezgodność ceny lub dostępności.

Review i AggregateRating

Dane opinii są częścią oznaczenia produktu, ale mają własne zasady.

Review opisuje pojedynczą opinię — może zawierać autora, treść, datę i ocenę:

{
  "@type": "Review",
  "author": {
    "@type": "Person",
    "name": "Anna"
  },
  "datePublished": "2026-05-20",
  "reviewBody": "Biurko jest stabilne i cicho zmienia wysokość.",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 5,
    "bestRating": 5,
    "worstRating": 1
  }
}

AggregateRating opisuje zbiorczą średnią ocen:

{
  "@type": "AggregateRating",
  "ratingValue": 4.7,
  "ratingCount": 38
}

Najważniejsza zasada: oceny muszą być widoczne dla klienta. Jeżeli kod zawiera średnią 4,9 i liczbę ocen 127, to użytkownik powinien móc znaleźć na stronie tę samą średnią i liczbę ocen. Nie przypisuj oceny sklepu do każdego produktu, opinii z Profilu Firmy w Google do konkretnego produktu, recenzji innego wariantu bez jasnego sposobu agregacji ani fikcyjnej liczby opinii. Pełny temat zbierania, moderowania i weryfikowania recenzji opisujemy w poradniku opinie i oceny produktów w WooCommerce — SEO, gwiazdki i UGC.

Dane strukturalne a Google Merchant Center

Schema na stronie i feed produktowy to dwa osobne źródła informacji.

Dane strukturalne na stronie Google odczytuje podczas odwiedzania karty produktu — opisują m.in. produkt, cenę, dostępność, identyfikatory, wariant i opinie.

Feed Merchant Center przesyła dane produktowe bezpośrednio do Google. Może być aktualizowany przez plik XML, integrację WooCommerce, API albo zewnętrzny system produktowy. W większym sklepie feed daje większą kontrolę nad częstotliwością aktualizacji, wariantami, dostępnością, kampaniami Shopping i bezpłatnymi wynikami produktowymi. Dane strukturalne nie zastępują feedu, a feed nie zwalnia z uporządkowania strony.

Miejsce	Co trzeba porównać?
Karta produktu	Cena i dostępność widoczne dla klienta
Dane strukturalne	price, priceCurrency, availability
Feed Merchant Center	Cena, waluta, dostępność i wariant
Koszyk lub checkout	Końcowa cena i możliwość zakupu

Przykład błędu: karta produktu 199 zł, schema 179 zł, feed 199 zł, koszyk 199 zł. Google może uznać dane za niespójne, nawet jeżeli klient ostatecznie płaci właściwą kwotę.

Skąd biorą się różnice? Najczęstsze przyczyny: cache przechowuje starą cenę, promocja zakończyła się tylko w jednym systemie, feed aktualizuje się raz dziennie, schema używa ceny regularnej zamiast promocyjnej, wariant nie jest poprawnie zaznaczony, kod JavaScript aktualizuje cenę z opóźnieniem, integracja magazynowa nie odświeżyła dostępności, ceny zależą od waluty/kraju/grupy klienta albo wtyczka B2B pokazuje cenę netto a schema brutto. Jeżeli prowadzisz kampanie produktowe, sprawdź również poradnik reklama produktowa Google — Shopping i Performance Max.

Cena regularna, promocyjna i najniższa cena

Sklep może pokazywać jednocześnie cenę regularną, promocyjną, najniższą z określonego okresu, cenę dla zalogowanych klientów, hurtową i cenę wariantu. Schema nie powinna przypadkowo wybierać pierwszej liczby znalezionej na stronie.

Aktualna cena sprzedaży. Pole price powinno odpowiadać cenie, po której klient może obecnie kupić produkt. Jeżeli cena regularna to 499 zł, a promocyjna 399 zł, aktywną ceną oferty jest 399 zł.

Ceny B2B. Jeżeli sklep pokazuje cenę brutto dla konsumenta, netto dla firmy, rabat po zalogowaniu albo indywidualny cennik, trzeba ustalić, która oferta jest publicznie dostępna i jak działa wybór klienta. Nie można bez analizy przekazać jednej ceny wszystkim użytkownikom.

Produkty konfigurowalne. Jeżeli końcowa cena zależy od wymiaru, materiału, liczby elementów, wybranego dodatku, graweru albo projektu klienta, prosty Offer może nie wystarczyć do opisania wszystkich scenariuszy. Dane muszą odpowiadać realnej, możliwej do zakupu konfiguracji, a nie teoretycznej cenie bazowej ukrytej przed klientem.

Wysyłka i zwroty w danych strukturalnych

Dane produktu mogą zostać uzupełnione o informacje o koszcie wysyłki, kraju dostawy, czasie przygotowania, czasie transportu i zasadach zwrotu.

Nie zawsze trzeba powielać pełną politykę przy każdym produkcie. Jeżeli zasady są takie same dla większości oferty, można opisać je na poziomie firmy. Jeżeli konkretny produkt ma inne warunki — transport meblowy, brak standardowego zwrotu produktu personalizowanego, wysyłkę paletową albo wydłużony termin realizacji — można przygotować wyjątek na poziomie oferty. Najpierw jednak zadbaj o podstawy: poprawną cenę, walutę, dostępność, identyfikatory i warianty. Rozbudowane informacje o wysyłce nie naprawią błędnej ceny produktu.

Jak WooCommerce generuje dane strukturalne?

WooCommerce generuje podstawowe dane produktów automatycznie — mogą one obejmować m.in. nazwę produktu, zdjęcie, opis, SKU, ofertę, cenę, dostępność i oceny. Ostateczny kod zależy jednak również od wersji WooCommerce, motywu, wtyczki SEO, wtyczki opinii, integracji Merchant Center, systemu wariantów, wtyczek cenowych i modyfikacji programistycznych. Dlatego samo stwierdzenie „WooCommerce ma schema" nie oznacza jeszcze, że dane są kompletne i poprawne.

Najczęstszy problem: kilka obiektów Product

Na jednej karcie mogą działać jednocześnie: schema generowane przez WooCommerce, schema z wtyczki SEO, schema z motywu, dane z wtyczki opinii, dane z integracji produktowej i ręcznie dodany JSON-LD. Efektem może być kilka obiektów Product przekazujących sprzeczne informacje — np. obiekt pierwszy: cena 2999 zł / InStock / ocena 4,7; obiekt drugi: cena 3299 zł / OutOfStock / brak oceny; obiekt trzeci: cena 2999–3499 zł / InStock / ocena 5,0. Każdy fragment kodu może być poprawny składniowo, ale razem przekazują sprzeczne informacje.

Czy dwa obiekty Product zawsze są błędem? Nie zawsze. Kilka obiektów może mieć uzasadnienie, gdy strona faktycznie opisuje kilka produktów, produkt i jego warianty, zestaw albo rodzinę produktów. Problem występuje wtedy, gdy kilka systemów opisuje ten sam produkt na różne sposoby.

Jak znaleźć źródło dublowania?

Wyłączanie wtyczek na działającym sklepie nie powinno być pierwszym krokiem. Bezpieczniejszy proces:

1. Otwórz kod źródłowy strony.
2. Wyszukaj application/ld+json.
3. Znajdź wszystkie wystąpienia "@type":"Product" lub "@type": "Product".
4. Porównaj dane.
5. Sprawdź klasy, komentarze i strukturę skryptu.
6. Ustal, która wtyczka albo motyw generuje dany blok.
7. Wykonaj test na środowisku stagingowym, czyli roboczej kopii sklepu niewidocznej dla klientów.
8. Wyłącz tylko zbędne źródło schema.
9. Ponownie sprawdź kartę produktu.

Nie usuwaj całego schema WooCommerce tylko dlatego, że test pokazuje ostrzeżenie. Najpierw ustal, czy inna wtyczka przejmuje pełny zakres danych.

Błędy a ostrzeżenia w testach Google

Test danych może pokazywać błędy, ostrzeżenia i elementy prawidłowe.

Błąd najczęściej oznacza, że brakuje elementu wymaganego do danego rodzaju rozszerzonego wyniku — np. brak ceny, brak waluty, nieprawidłowy format wartości albo brak nazwy produktu.

Ostrzeżenie oznacza, że brakuje informacji zalecanej, ale obiekt może nadal kwalifikować się do wyniku — np. brak marki, GTIN, opinii albo informacji o wysyłce. Nie każde ostrzeżenie trzeba usuwać za wszelką cenę. Jeżeli produkt nie ma GTIN, nie twórz fałszywego kodu tylko po to, aby komunikat zniknął. Najpierw sprawdź, czy pole rzeczywiście dotyczy produktu, czy dane istnieją, czy można je wiarygodnie uzupełnić i czy mają znaczenie dla sklepu.

Szybki recap: pięć błędów, które łatwo przeoczyć

Poniższa lista nie zastępuje wcześniejszej analizy. Zbiera problemy, które często ujawniają się dopiero przy bardziej złożonej konfiguracji sklepu.

1. Cena pojawia się dopiero po wykonaniu JavaScript. Pierwszy kod strony nie zawiera aktualnej ceny, a skrypt pobiera ją dopiero po chwili albo po wyborze wariantu. Trzeba sprawdzić, czy Google otrzymuje właściwą wartość po wyrenderowaniu strony, czyli po wykonaniu potrzebnych skryptów.

2. Cache przechowuje zakończoną promocję. Klient widzi już cenę regularną, ale schema lub wybrana wersja strony nadal przekazuje cenę promocyjną. Problem może dotyczyć cache strony, cache obiektowego, CDN, pamięci przeglądarki albo osobnego cache feedu.

3. Cena zależy od typu użytkownika. Sklep pokazuje inną kwotę klientowi detalicznemu, firmie, zalogowanemu partnerowi albo odbiorcy z innego kraju. Schema musi odpowiadać ofercie publicznie dostępnej w danym kontekście, a nie przypadkowej cenie pobranej z jednego cennika.

4. Konfigurator jest opisany jak prosty produkt. Na stronie widnieje cena „od 1000 zł", ale rzeczywista konfiguracja wymaga obowiązkowych dopłat. Kod nie powinien przedstawiać ceny bazowej jako pełnej ceny produktu, jeżeli klient nie może kupić takiej konfiguracji.

5. Wycofany produkt nadal ma aktywny Offer. Produkt jest archiwalny albo nie można go kupić, ale schema nadal pokazuje InStock i aktualną ofertę sprzedaży. Trzeba wtedy dostosować dostępność, usunąć ofertę albo prawidłowo obsłużyć stronę produktu wycofanego.

Jak wdrożyć dane strukturalne bez chaosu?

Krok 1. Ustal źródło prawdy. Najpierw określ, skąd pochodzą nazwa, cena, dostępność, marka, SKU, GTIN, wariant i opinie. W większości sklepów źródłem powinien być WooCommerce albo nadrzędny system PIM lub ERP synchronizujący dane z WooCommerce. Nie poprawiaj schema ręcznie, jeżeli za godzinę integracja nadpisze cenę produktu.

Krok 2. Sprawdź podstawowe dane produktów. Przed pracą nad kodem zobacz, czy w WooCommerce są poprawne nazwy, ceny, warianty, stany magazynowe, SKU, marki, identyfikatory, zdjęcia i opinie. Schema nie naprawi nieuporządkowanego katalogu.

Krok 3. Zidentyfikuj wszystkie generatory schema: WooCommerce, wtyczka SEO, motyw, wtyczka opinii, integracja Merchant Center, dodatkowa wtyczka schema, własny kod. Ustal, który system ma odpowiadać za dane produktu.

Krok 4. Wybierz reprezentatywne produkty. Nie testuj wyłącznie jednego prostego produktu. Sprawdź co najmniej produkt prosty, promocyjny, niedostępny, wariantowy, z opiniami, bez GTIN, z różnymi cenami wariantów oraz w innej wersji językowej.

Krok 5. Porównaj dane widoczne z kodem. Dla każdego produktu przygotuj prostą tabelę:

Element	Strona	Schema	Merchant Center
Nazwa	Biurko Varius 120	Biurko Varius 120	Biurko Varius 120
Cena	2999 zł	2999 PLN	2999 PLN
Dostępność	Dostępne	InStock	in_stock
SKU	VARIUS-120	VARIUS-120	VARIUS-120
GTIN	590…	590…	590…

Każda różnica wymaga wyjaśnienia.

Krok 6. Napraw źródło, nie objaw. Jeżeli schema pokazuje złą cenę, problem może nie znajdować się w samym kodzie. Sprawdź metadane produktu, cache, synchronizację, harmonogram promocji, ustawienia podatków, wybrany wariant, ceny B2B i przelicznik walut.

Krok 7. Testuj na środowisku stagingowym — roboczej kopii sklepu, na której można sprawdzić zmianę bez ryzyka dla klientów i zamówień. Zmiany schema mogą dotyczyć wszystkich produktów; błąd w szablonie zostanie powielony na tysiącach stron, dlatego przed publikacją sprawdź produkt prosty, warianty, promocje, brak magazynu, opinie, różne waluty i wersje językowe.

Krok 8. Opublikuj część zmian. Przy dużym sklepie nie zawsze warto modyfikować cały katalog jednocześnie. Można zacząć od jednej kategorii, wybranych produktów albo części wariantów, a następnie sprawdzić test wyników rozszerzonych, Search Console, Merchant Center, logi błędów i działanie sklepu.

Krok 9. Monitoruj dane po wdrożeniu. Schema może być poprawne w dniu publikacji, ale zepsuć się po aktualizacji WooCommerce, zmianie motywu, instalacji nowej wtyczki, zmianie podatków, integracji ERP, uruchomieniu promocji albo modyfikacji wariantów. Dlatego dane produktów wymagają regularnej kontroli.

Jak testować dane strukturalne produktów?

Poniższe narzędzia odpowiadają na różne pytania. Jedno nie zastępuje pozostałych.

Test wyników z elementami rozszerzonymi pozwala sprawdzić m.in. czy Google wykrywa Product, czy występują błędy krytyczne, jakie właściwości są odczytywane i czy strona może kwalifikować się do wyniku produktowego. Test nie potwierdza jednak, że Google pokaże rozszerzony wynik, że Merchant Center zaakceptuje produkt, że cena jest biznesowo poprawna ani że wariant został właściwie powiązany.

Walidator Schema.org może pokazać szerszy zakres danych Schema.org, również tych, których Google nie wykorzystuje w konkretnym wyniku. Jest pomocny przy analizie składni, relacji między obiektami, własnych rozszerzeń i typów nieobsługiwanych przez test Google.

Kontrola adresu URL w Search Console pokazuje, jak Google widzi konkretną stronę — można sprawdzić dostępność strony, możliwość indeksowania, wyrenderowany kod (czyli stronę po wykonaniu skryptów), wykryte dane strukturalne i datę ostatniego odwiedzenia.

Raporty produktów w Search Console. W zależności od wdrożenia mogą pojawić się osobne raporty związane z fragmentami produktów, informacjami o sprzedawcy i błędami danych produktów. Raport pokazuje wzorce problemów, ale nie zawsze pełną listę wszystkich adresów.

Google Merchant Center. Sprawdź zakładki dotyczące produktów wymagających uwagi, niezgodności ceny, niezgodności dostępności, brakujących identyfikatorów, błędów wariantów i problemów z obrazami. Merchant Center może wykryć problem, którego nie pokazuje test jednego adresu.

Co możesz sprawdzić samodzielnie?

Poniższa checklista skupia się na zachowaniu realnego produktu. Nie zastępuje analizy narzędziowej opisanej w poprzedniej sekcji.

1. Przetestuj produkt promocyjny. Upewnij się, że na stronie widnieje aktualna cena sprzedaży, koszyk pokazuje tę samą kwotę, zakończenie promocji aktualizuje dane i stara cena nie pozostaje w cache.

2. Przetestuj kilka wariantów. Wybierz najtańszy, najdroższy, niedostępny i o innym kolorze. Sprawdź, czy po zmianie aktualizują się cena, SKU, dostępność, zdjęcie oraz adres lub parametr wariantu.

3. Zweryfikuj GTIN u źródła. Porównaj kod z opakowaniem, dokumentacją producenta, bazą produktową dostawcy oraz systemem PIM lub ERP. Upewnij się, że ten sam GTIN nie jest przypisany do kilku różnych wariantów.

4. Sprawdź produkt niedostępny. Zobacz, czy nadal można go dodać do koszyka, czy komunikat na stronie jest prawidłowy, czy wszystkie warianty są faktycznie niedostępne i czy produkt ma powrócić do sprzedaży.

5. Sprawdź produkt wycofany. Jeżeli produkt nie wróci, upewnij się, że strona nie przedstawia aktywnej oferty i nie sugeruje dostępności. Rozważ pozostawienie użytecznej strony informacyjnej, wskazanie następcy, właściwy kod odpowiedzi i logiczne przekierowanie.

6. Porównaj opinie z kartą produktu. Średnia ocen i ich liczba powinny odpowiadać temu, co użytkownik może zobaczyć. Sprawdź również, czy usunięta opinia przestaje być liczona, nowa recenzja aktualizuje średnią, a opinie dotyczą właściwego produktu.

7. Otwórz zdjęcia w trybie prywatnym. Sprawdź, czy adresy zdjęć działają bez logowania, nie zwracają błędu, przedstawiają właściwy produkt i nie prowadzą do miniatury bardzo niskiej jakości.

8. Zmień język, walutę lub typ klienta. Jeżeli sklep obsługuje kilka rynków albo B2B, sprawdź, czy po zmianie waluta jest właściwa, cena odpowiada danemu użytkownikowi, wariant pozostaje ten sam, a adres prowadzi do właściwej wersji językowej.

9. Wyczyść cache po zmianie ceny. Zmień testową cenę na środowisku roboczym, wyczyść pamięć podręczną i sprawdź, czy wszystkie miejsca aktualizują się jednocześnie.

Kiedy warto zlecić to specjaliście?

Pomoc techniczna jest uzasadniona, gdy Search Console pokazuje błędy produktów na dużej liczbie stron, Merchant Center odrzuca produkty albo kilka wtyczek generuje dane Product.

Rozważ wsparcie, gdy Search Console pokazuje błędy produktów na dużej liczbie stron, Merchant Center odrzuca produkty przez cenę lub dostępność, kilka wtyczek generuje dane Product, sklep ma setki wariantów, każdy wariant ma osobny GTIN i cenę, schema nie aktualizuje się po zmianie wariantu, sklep wykorzystuje ceny B2B, ceny zależą od waluty lub lokalizacji, działa integracja z ERP albo PIM, dane są generowane dopiero przez JavaScript, sklep został przeniesiony z innej platformy, opinie są importowane, dane produktów różnią się między stroną a feedem, motyw nadpisuje standardowe funkcje WooCommerce albo problem dotyczy tysięcy kart produktów.

W takich przypadkach trzeba połączyć analizę SEO, kod WooCommerce, strukturę produktów, feed Merchant Center, źródło cen, integrację magazynową, cache i testy wariantów. Samo doinstalowanie kolejnej wtyczki schema często zwiększa liczbę konfliktów zamiast je usuwać.

---

Jedna oferta opisana spójnie w czterech miejscach

Dane strukturalne produktów WooCommerce nie powinny być osobnym, ręcznie utrzymywanym opisem sklepu. Muszą wynikać z prawdziwych danych produktowych: aktualnej ceny, właściwej waluty, realnej dostępności, konkretnego wariantu, poprawnego SKU i GTIN, widocznych opinii oraz warunków zakupu.

W ramach SEO technicznego możemy przeanalizować dane produktów WooCommerce, kod Product i Offer, warianty, opinie oraz zgodność z Merchant Center. Otrzymasz listę problematycznych adresów, źródło każdego konfliktu i plan wdrożenia bez dokładania kolejnej warstwy niespójnego schema.