Schema Product i Offer: dane, które naprawdę czyta AI

Sklep, który chce trafiać do odpowiedzi generowanych przez modele językowe, potrzebuje czegoś więcej niż estetycznej karty produktu. Potrzebuje danych dających się odczytać bez zgadywania: ceny w jednoznacznym formacie, statusu dostępności, identyfikatora produktu i czytelnej relacji między wariantami. Tę warstwę opisuje znacznik Product razem z zagnieżdżonym Offer. Jeśli dopiero układasz całość implementacji, zacznij od przewodnika dane strukturalne pod AI 2026, a potem wróć tutaj po szczegóły dotyczące sklepu.

Po co modelom znacznik produktu

Model, który kompletuje odpowiedź na pytanie zakupowe, działa pod presją dwóch ograniczeń: ma skończone okno kontekstu i musi ocenić, czy dana informacja jest wystarczająco pewna, żeby ją zacytować. Tekst opisu produktu jest drogi w przetwarzaniu i niejednoznaczny, bo cena potrafi być zapisana jako „od 199 zł brutto”, „199,00” albo w grafice. Znacznik JSON-LD rozwiązuje oba problemy naraz: podaje wartość w polu o ustalonej semantyce, w formacie, którego nie trzeba interpretować.

W praktyce widać to po tym, które sklepy pojawiają się w zestawieniach typu „najlepszy X do 1000 zł”. Wygrywają nie te z najdłuższym opisem, tylko te, z których da się wyciągnąć komplet: nazwa, cena, waluta, dostępność i marka. Ta sama logika stoi za widocznością w narzędziach zakupowych asystentów, o czym pisaliśmy przy okazji analizy rekomendacji produktów w ChatGPT.

Pola obowiązkowe w Product

Dokumentacja Google dzieli pola na wymagane i zalecane, ale z perspektywy modelu ten podział wygląda inaczej. Wymagane minimum pozwala w ogóle zakwalifikować obiekt jako produkt. Pola zalecane decydują o tym, czy produkt da się porównać z konkurencją, a to właśnie porównanie jest najczęstszym zadaniem, jakie dostaje asystent.

Największą wartość w tej tabeli ma gtin13. To jedyne pole, które pozwala zestawić Twoją ofertę z tym samym produktem u innego sprzedawcy, więc jego brak realnie wycina sklep z porównań cenowych. Pole brand warto traktować jako łącznik z profilem marki: żeby zadziałało, marka musi być opisana także na poziomie całego serwisu, co omawiamy w tekście o znaczniku Organization i sameAs.

Offer: cena, waluta, dostępność, termin ważności

Zagnieżdżony obiekt Offer jest tą częścią znacznika, w której najłatwiej o błąd, bo zmienia się najczęściej. Minimalny, poprawny zestaw wygląda tak:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nazwa produktu",
  "gtin13": "5901234123457",
  "brand": { "@type": "Brand", "name": "Marka" },
  "offers": {
    "@type": "Offer",
    "url": "https://sklep.pl/produkt",
    "price": "199.00",
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

Cztery rzeczy, które wymagają dyscypliny. Po pierwsze, price zapisujemy z kropką dziesiętną i bez symbolu waluty, bo przecinek i „zł” w tym polu bywają odrzucane. Po drugie, priceCurrency to zawsze kod ISO 4217, czyli PLN, nie „zł”. Po trzecie, availability przyjmuje pełny URL ze słownika schema.org, a nie luźny tekst „na stanie”. Po czwarte, priceValidUntil z datą w przeszłości sprawia, że oferta jest traktowana jako nieaktualna, więc data w tym polu musi być generowana dynamicznie, a nie wpisana ręcznie przy wdrożeniu.

Do Offer warto dołożyć jeszcze dwa obiekty, które w polskich sklepach bywają pomijane, a odpowiadają na pytania zadawane asystentom najczęściej po cenie. shippingDetails opisuje koszt i czas dostawy razem z obszarem, którego dotyczy, dzięki czemu model potrafi odpowiedzieć na pytanie o całkowity koszt zakupu, a nie tylko o cenę katalogową. hasMerchantReturnPolicy podaje okres na zwrot, kto płaci za przesyłkę zwrotną i czy obowiązuje opłata manipulacyjna. Oba pola mają tę samą własność co cena: jeśli ich nie ma, model albo pominie temat, albo sięgnie po regulamin konkurencji i przypisze Twojej ofercie cudze warunki.

Osobna decyzja dotyczy tego, czy cenę w ogóle publikować. W modelu B2B kusi ukrycie cennika za formularzem, ale wtedy pole price nie istnieje i produkt wypada z porównań. Rozważaliśmy ten kompromis szerzej w analizie cennika na stronie a rekomendacji AI.

Opinie i oceny: co wolno, a co jest ryzykiem

Pola aggregateRating i review podnoszą wiarygodność produktu, ale są też najczęstszym powodem ręcznych działań za spam w danych strukturalnych. Zasada jest prosta: oznaczać wolno tylko te opinie, które faktycznie są widoczne na stronie produktu i pochodzą od klientów. Ocena zaciągnięta z innego serwisu, uśredniona z całej kategorii albo wyliczona z ocen podobnych produktów to naruszenie.

Dwie sytuacje graniczne warto rozstrzygnąć zawczasu. Produkt bez ani jednej opinii nie powinien mieć aggregateRating z wartością zero ani z wartością domyślną; lepiej pominąć pole w całości. Opinie zebrane w zewnętrznym narzędziu można oznaczyć, o ile są renderowane na stronie, a reviewCount odpowiada liczbie widocznych wpisów. Model, który znajdzie ocenę 4,9 przy jednej opinii, potraktuje ją zresztą jako słaby sygnał, więc gra jest warta świeczki dopiero przy kilkunastu recenzjach.

Warianty produktu i zestawy

Sklep z rozmiarami i kolorami ma do wyboru dwa poprawne podejścia. Pierwsze to ProductGroup z listą hasVariant, gdzie grupa trzyma cechy wspólne, a warianty tylko to, co je różni, wskazane przez variesBy. Drugie to oddzielny obiekt Product na każdej podstronie wariantu, z isVariantOf wskazującym na grupę. Pierwsze rozwiązanie sprawdza się przy jednej podstronie z przełącznikiem, drugie przy osobnych adresach dla każdego wariantu.

Błędem, który spotyka się najczęściej, jest wariant opisany przez AggregateOffer z widełkami lowPrice i highPrice podanymi tam, gdzie użytkownik widzi jedną konkretną cenę. Widełki są uczciwe na stronie grupy, natomiast na karcie konkretnego rozmiaru model dostaje przedział zamiast liczby i zwykle pomija taką ofertę w zestawieniach. Zestawy i pakiety opisuje się z kolei przez isAccessoryOrSparePartFor lub isRelatedTo, nie przez sztuczne mnożenie osobnych produktów.

Spójność znacznika z tym, co widzi użytkownik

Rozjazd między JSON-LD a treścią renderowaną w przeglądarce jest problemem technicznym, nie redakcyjnym, i dlatego bywa niewidoczny dla zespołu contentowego przez wiele miesięcy. Typowy scenariusz: cena w znaczniku pochodzi z cache po stronie serwera, a cena na stronie z zapytania do API po stronie klienta. Promocja rusza o północy, znacznik dalej podaje starą wartość, a produkt zaczyna być cytowany z ceną, której nie da się uzyskać w koszyku.

Ten sam mechanizm dotyczy dostępności. Jeżeli stan magazynowy spada do zera, a availability pozostaje na InStock, sklep traci zaufanie nie tylko w wyszukiwarce. Warto dopisać do checklisty wdrożeniowej jeden test: pobranie strony bez JavaScriptu i porównanie trzech wartości, czyli ceny, waluty i dostępności, z tym, co widać w przeglądarce. Jeśli któraś się różni, znacznik jest do poprawy.

Walidacja i monitoring błędów

Jednorazowa walidacja przy wdrożeniu nie wystarcza, bo dane produktowe zmieniają się codziennie. Sensowny proces ma trzy poziomy. Na etapie wdrożenia sprawdzamy pojedyncze adresy w teście wyników z elementami rozszerzonymi i w walidatorze schema.org. Po wdrożeniu włączamy raport „Produkty” w Search Console, który pokazuje błędy w skali całego katalogu i rozdziela je na krytyczne oraz ostrzeżenia. Na trzecim poziomie dokładamy własny monitoring: skrypt, który raz na dobę pobiera próbkę stu adresów z sitemapy, parsuje JSON-LD i alarmuje, gdy brakuje ceny albo gdy priceValidUntil wypadł w przeszłość.

Warto pilnować hierarchii błędów. Brak gtin13 to ostrzeżenie, z którym sklep żyje, natomiast nieprawidłowa wartość availability albo cena zapisana z przecinkiem unieważniają całą ofertę. Szczegóły wymagań dla tego typu znacznika Google opisuje w dokumentacji structured data dla produktów, i to ona, a nie zbiorcze poradniki, jest źródłem rozstrzygającym przy sporach w zespole.

Na koniec rzecz, o której łatwo zapomnieć: poprawny znacznik zwiększa szansę na cytowanie, ale cytowanie nie zawsze przychodzi z linkiem. Jak wychwycić sytuację, w której model wymienia markę bez odesłania do sklepu, pokazujemy w tekście o wzmiankach w AI bez linku.

FAQ