Product schema pod AI to zestaw danych strukturalnych, które w 2026 roku decydują o tym, czy karta produktu trafi do rekomendacji ChatGPT, Gemini czy Perplexity. Modele nie czytają całej strony: pobierają blok JSON-LD, sprawdzają zgodność z widocznym HTML i odrzucają oferty, w których brakuje ceny, dostępności lub warunków zwrotu. Poniżej rozkładamy pola typu Product i Offer na krytyczne oraz opcjonalne, z konkretnymi wartościami, które przechodzą walidację.
W skrócie:
- Minimum, bez którego produkt nie trafia do zestawień AI:
name,image,offers.price,offers.priceCurrency,offers.availability. - Pola przewagi w 2026:
shippingDetails,hasMerchantReturnPolicy,priceValidUntili identyfikatorygtin/sku. - Warianty opisujecie przez
ProductGroupzhasVariantivariesBy, nie przez pięć osobnych blokówProduct. - Rozjazd między JSON-LD a widoczną ceną to najczęstszy powód, dla którego model pomija ofertę.
- Walidację robicie w dwóch narzędziach i monitorujecie w Search Console co tydzień, nie raz na kwartał.
Jakie pola Product i Offer są obowiązkowe?
Google w dokumentacji wymienia trzy właściwości wymagane dla typu Product: name, image oraz co najmniej jedną z grupy offers, review lub aggregateRating. Dla listingu handlowego (merchant listing) lista rośnie: wewnątrz Offer muszą się znaleźć price, priceCurrency i availability. Pełną specyfikację znajdziecie w dokumentacji Google Search Central.
Modele językowe stosują ten sam próg, ale z dodatkowym filtrem: odrzucają oferty bez identyfikatora produktu. gtin13, mpn albo chociaż sku pozwalają modelowi połączyć waszą kartę z tym samym produktem w innych sklepach i w feedzie Merchant Center. Bez identyfikatora produkt istnieje tylko u was, a model traktuje go jako niezweryfikowany. Podobną logikę encji opisaliśmy w tekście o schema Organization i sameAs: identyfikator robi dla produktu to, co sameAs robi dla marki.
| Pole | Status | Przykładowa wartość |
|---|---|---|
name | krytyczne | „Ekspres ciśnieniowy X200” |
image | krytyczne | tablica 1–3 adresów URL, min. 800 px szerokości |
offers.price | krytyczne | 1899.00 (liczba, bez spacji i waluty) |
offers.priceCurrency | krytyczne | „PLN” |
offers.availability | krytyczne | „https://schema.org/InStock” |
gtin13 / sku | silnie zalecane | „5901234123457” |
brand | zalecane | {„@type”:”Brand”,”name”:”X”} |
description | zalecane | 200–500 znaków, identyczne z HTML |
Jak zapisać cenę, walutę i datę ważności oferty?
Cena w Offer to liczba w formacie z kropką dziesiętną, bez separatorów tysięcy i bez symbolu waluty. Zapis „1 899,00 zł” w polu price nie przechodzi walidacji, a model, który go napotka, najczęściej pomija ofertę zamiast zgadywać. Waluta idzie osobno, w priceCurrency, jako trzyliterowy kod ISO 4217.
Cenę promocyjną opisujecie przez UnitPriceSpecification: aktualna kwota w price, a cena przekreślona w osobnym obiekcie z priceType ustawionym na https://schema.org/StrikethroughPrice. To jedyny sposób, w jaki model odczyta, że 1899 zł to obniżka z 2299 zł, i użyje tej informacji w porównaniu. Pole priceValidUntil podajecie w formacie ISO 8601 (na przykład „2026-10-31”) i aktualizujecie je automatycznie z systemu promocji, ręczna data z zeszłego kwartału to sygnał nieaktualnej oferty.
Ten sam zestaw wartości powinien trafić do feedu produktowego, o czym piszemy w artykule o feedzie produktowym pod agentów AI. Model, który widzi 1899 zł w JSON-LD i 1949 zł w feedzie, nie wybiera niższej ceny, tylko obniża wiarygodność całego sklepu.
Jak opisać dostępność i warianty produktu?
Schema.org przewiduje osiem wartości availability, a modele w praktyce rozróżniają cztery: InStock, OutOfStock, PreOrder i BackOrder. Wartość LimitedAvailability jest odczytywana jako dostępny, Discontinued jako niedostępny. Produkt niedostępny powinien zostać w schemie z prawidłowym statusem, a nie zniknąć: model, który raz zapisał ofertę, przy kolejnym odczycie sprawdza, czy status się zmienił.
Warianty koloru, rozmiaru czy pojemności w 2026 roku obsługujecie przez typ ProductGroup. Grupa dostaje productGroupID, listę cech w variesBy (na przykład "https://schema.org/color" i "https://schema.org/size") oraz tablicę hasVariant, w której każdy wariant jest pełnym Product z własnym sku, offers i image. Dzięki temu model odpowiada na pytanie „czy czarny X200 jest dostępny”, zamiast uśredniać stan magazynu całej linii.
- Jeden
ProductGroupna kartę, wspólne pola (brand,description) tylko w grupie. - Każdy wariant z osobną ceną i dostępnością, nawet jeśli są identyczne.
- Adres URL wariantu w
urlz parametrem albo osobną podstroną, spójny z canonical. - Wariant wyprzedany zostaje w tablicy ze statusem
OutOfStock.
Jak zapisać wysyłkę i politykę zwrotów w danych strukturalnych?
Koszt i czas dostawy opisuje obiekt OfferShippingDetails w polu shippingDetails. Zawiera on shippingRate (kwota i waluta), shippingDestination z addressCountry ustawionym na „PL” oraz deliveryTime z dwoma przedziałami: handlingTime (czas pakowania) i transitTime (czas przewozu), oba w dniach roboczych jako QuantitativeValue z minValue i maxValue. Zapis „wysyłka 1–2 dni, dostawa 2–4 dni” staje się dzięki temu danymi, które model wykorzystuje przy pytaniu „gdzie dostanę to najszybciej”.
Zwroty obsługuje typ MerchantReturnPolicy w polu hasMerchantReturnPolicy. Kluczowe właściwości to applicableCountry, returnPolicyCategory (najczęściej MerchantReturnFiniteReturnWindow), merchantReturnDays (w Polsce 14 dni dla konsumenta, w praktyce sklepy deklarują 30), returnMethod oraz returnFees z wartością FreeReturn lub ReturnFeesCustomerResponsibility. Od 2024 roku Google pozwala umieścić tę politykę raz, na poziomie Organization, zamiast powtarzać ją w każdej ofercie. Model traktuje sklep bez danych o zwrotach jako ryzykowny, więc pomija go przy zapytaniach typu „bezpieczny zakup online”.
Jak dodać oceny i opinie bez naruszania wytycznych?
AggregateRating wymaga ratingValue oraz reviewCount lub ratingCount; jeśli skala różni się od 1–5, dodajecie bestRating i worstRating. Wartość musi wynikać z realnych opinii zebranych na stronie i widocznych dla użytkownika. Google od lat karze ręcznie za oceny, których nie da się zobaczyć w HTML, a modele językowe dodatkowo porównują ratingValue z tym, co widzą w treści strony i w zewnętrznych serwisach.
Pojedyncze opinie w tablicy review dostają author jako Person z nazwą, reviewRating i reviewBody. Nie umieszczacie tam opinii o sklepie ani o marce, tylko o konkretnym produkcie. Sklepy bez własnego systemu ocen powinny pominąć te pola w całości: pusty aggregateRating z wartością 5 i jednym głosem obniża wiarygodność bardziej niż jego brak.
Dlaczego spójność JSON-LD z widocznym HTML decyduje o cytowaniu?
Model pobiera JSON-LD i tekst strony jako dwa niezależne źródła, a następnie sprawdza, czy cena, nazwa, dostępność i marka zgadzają się w obu. Rozjazd w jednym polu wystarczy, żeby oferta wypadła z zestawienia. Najczęstsze źródła rozbieżności to cache HTML z ceną sprzed promocji, JSON-LD generowany z innej bazy niż szablon karty oraz dane strukturalne wstrzykiwane przez JavaScript po załadowaniu strony.
Bezpieczna konfiguracja: jeden blok JSON-LD w <head>, renderowany po stronie serwera z tej samej tablicy zmiennych, z której szablon buduje widoczną cenę i przycisk dostępności. Jakie elementy HTML muszą towarzyszyć schemie, opisaliśmy w artykule o karcie produktu pod LLM. Ogólne zasady doboru typów pod modele zebraliśmy w przeglądzie schema.org pod LLM.
Jak walidować i monitorować błędy product schema?
Walidację prowadzicie w dwóch narzędziach, bo każde sprawdza co innego. Test wyników z elementami rozszerzonymi Google pokazuje, czy strona kwalifikuje się do listingu handlowego i wskazuje brakujące pola wymagane przez Google. Schema Markup Validator (validator.schema.org) sprawdza poprawność względem samego słownika, w tym pola, których Google nie wymaga, a modele czytają. Procedurę testów krok po kroku opisaliśmy w tekście o walidacji schema pod wyszukiwarki AI.
Monitoring to raport „Listy produktów” i „Fragmenty produktów” w Search Console, przeglądany co tydzień. Trzy błędy, które pojawiają się najczęściej w polskich sklepach: brak priceCurrency po migracji na nowy szablon, availability jako zwykły tekst „dostępny” zamiast adresu schema.org oraz nieaktualne priceValidUntil po zakończeniu promocji. Każdy z nich wyłącza kartę z listingu Google i z rekomendacji AI w tym samym momencie.
Najczęstsze błędy w product schema
- Cena jako tekst z walutą i spacją („1 899 zł”) zamiast liczby 1899.
- Pięć bloków
Productdla pięciu kolorów zamiast jednegoProductGroup. - Brak
gtinisku, przez co model nie łączy oferty z produktem w innych źródłach. - Polityka zwrotów opisana tylko w regulaminie, bez
hasMerchantReturnPolicy. - JSON-LD wstrzykiwany skryptem po załadowaniu strony, niewidoczny dla części crawlerów AI.
aggregateRatingbez widocznych opinii na stronie.
FAQ: najczęstsze pytania
Czy modele AI czytają product schema bezpośrednio?
Tak, ale różnymi drogami. ChatGPT z wyszukiwaniem i Perplexity pobierają stronę własnym crawlerem i parsują JSON-LD z HTML. Gemini korzysta z indeksu Google, więc dziedziczy to, co Google odczytał z listingu handlowego. W obu przypadkach brak wymaganych pól Offer oznacza pominięcie oferty, dlatego jeden kompletny blok JSON-LD obsługuje wszystkie kanały jednocześnie.
Czy wystarczy feed w Merchant Center zamiast schemy na stronie?
Nie. Feed zasila Google Shopping i część integracji zakupowych ChatGPT, ale crawlery modeli odwiedzają samą kartę produktu i tam szukają danych. Feed i schema powinny zawierać identyczne ceny, dostępność i identyfikatory. Rozbieżność między nimi jest traktowana jako błąd danych, nie jako dwie niezależne oferty.
Ile pól musi mieć Offer, żeby produkt trafił do rekomendacji?
Minimum to trzy: price, priceCurrency i availability. W praktyce oferty z shippingDetails, hasMerchantReturnPolicy i priceValidUntil są wybierane częściej, bo model może odpowiedzieć na pytania o koszt dostawy i zwrot bez sięgania do innego źródła. Sześć pól w Offer to rozsądny standard dla sklepu w 2026 roku.
Jak opisać produkt niedostępny, żeby nie wypaść z indeksu AI?
Zostawiacie pełny blok Product z availability ustawionym na https://schema.org/OutOfStock lub BackOrder, jeśli towar wraca. Usunięcie schemy albo zwrócenie 404 kasuje encję z pamięci modelu, a jej odbudowa po powrocie towaru trwa tygodnie. Status niedostępności jest informacją, którą model przekazuje użytkownikowi, nie karą dla sklepu.
Czy JSON-LD generowany przez JavaScript działa pod AI?
Częściowo. Googlebot renderuje JavaScript, więc listing handlowy zwykle działa. Crawlery ChatGPT, Perplexity i większości narzędzi RAG pobierają surowy HTML bez wykonania skryptów, więc blok dodany po stronie klienta jest dla nich niewidoczny. Renderowanie JSON-LD po stronie serwera to jedyny wariant, który obsługuje wszystkie kanały bez wyjątków.
Co dalej
Po uporządkowaniu pól Product i Offer warto sprawdzić, czy sklep spełnia warunki wejścia do wyników zakupowych ChatGPT, o których piszemy w artykule o sklepie w wynikach zakupowych ChatGPT. Następny krok to podpięcie tych samych danych o marce pod encję Organization, tak aby model łączył produkt, sklep i producenta w jeden spójny graf.