Warianty produktów w opisach: jak nie mylić modeli AI

Kurtka w trzech kolorach i pięciu rozmiarach to dla sklepu jeden produkt, a dla modelu językowego piętnaście osobnych faktów, które trzeba poprawnie połączyć. Kiedy strona podaje tylko cenę „od 199 zł” i jedną etykietę „dostępny”, asystent AI nie ma z czego odczytać, że rozmiar XL kosztuje więcej, a zielony wariant wraca do magazynu za dwa tygodnie. Odpowiedź wygląda wtedy wiarygodnie, ale jest błędna. Ten tekst pokazuje, jak zbudować kartę produktu z wariantami tak, żeby wyszukiwarka i model językowy mogły odczytać właściwą cenę i dostępność konkretnej wersji.

Temat jest częścią szerszego zagadnienia przygotowania oferty, które opisujemy w przewodniku sklepy pod AI: feed, opisy, kategorie i schema produktu. Tutaj skupiamy się wyłącznie na wariantach.

Skąd biorą się błędne ceny w odpowiedziach AI

Model nie widzi sklepu tak jak klient. Klient klika w przełącznik koloru i patrzy, jak zmienia się cena. Model dostaje tekst strony, dane strukturalne i czasem feed produktowy przetworzony przez porównywarki lub Google. Jeśli w tych źródłach jest tylko jedna liczba, model użyje właśnie jej.

Najczęstsze mechanizmy błędu są trzy. Pierwszy: cena „od” bez dopisku, której wersji dotyczy, czytana jako cena całego produktu. Drugi: przełącznik wariantów oparty na JavaScripcie, który podmienia cenę dopiero po kliknięciu, więc w HTML zostaje tylko wartość domyślna. Trzeci: rozbieżność między stroną a feedem, kiedy porównywarka pokazuje inny wariant jako „główny” niż sklep. O tym, jak serwisy porównujące ceny zasilają odpowiedzi modeli, piszemy w tekście porównywarki i AI: skąd model bierze ceny produktów.

Nie mamy własnego pomiaru, jak często konkretne modele mylą warianty. Mechanizm jest jednak prosty do sprawdzenia na własnej karcie, o czym w ostatniej sekcji.

Jedna karta z wariantami czy osobne adresy

Google w dokumentacji danych strukturalnych dla wariantów produktu opisuje dwa modele budowy sklepu i oba uznaje za poprawne.

Przy modelu jednej strony Google stawia dwa wymagania techniczne. Grupa produktów musi mieć jeden kanoniczny adres, zwykle bazowy URL bez wybranego wariantu. Jednocześnie każdy wariant musi dać się otworzyć bezpośrednim adresem z parametrami, który od razu pokazuje właściwe zdjęcie, cenę i dostępność oraz pozwala dodać ten wariant do koszyka. Jeśli Twój sklep po wejściu na adres z parametrem pokazuje wariant domyślny, wyszukiwarka nie ma jak odczytać pozostałych.

Przy modelu wielu stron każda strona musi mieć kompletne, samodzielne oznaczenia dla tego, co na niej jest. Odsyłanie do danych z innej podstrony nie wystarczy.

Jak opisać różnice między wersjami w treści

Dane strukturalne to jedno, ale model czyta też zwykły tekst. Dobra praktyka redakcyjna jest taka, żeby różnice między wariantami były zapisane słowami w widocznej części strony, a nie tylko w rozwijanej liście.

• Jeśli warianty różnią się ceną, podaj zakres i powód: „rozmiary XS–L: 199 zł, XL–XXL: 229 zł (więcej materiału)”.
• Jeśli różnią się parametrem technicznym (pojemność, moc, procesor), daj krótką tabelę wersji z ceną w każdym wierszu.
• Nie pisz wspólnego opisu, który przypisuje wszystkim wersjom cechę jednej z nich, np. „wodoodporna membrana”, jeśli ma ją tylko wersja premium.

Google radzi to samo na poziomie danych: nazwa i opis wariantu powinny być bardziej szczegółowe niż nazwa grupy i zawierać słowa identyfikujące wersję, takie jak kolor, rozmiar czy materiał. Ta sama logika działa w treści. Jasne nazywanie rzeczy pomaga modelowi rozpoznać, o którym obiekcie mowa; szerzej opisujemy to w tekście o encjach w treści.

Dane strukturalne dla wariantów i zakresów cenowych

Do grupowania wariantów Google używa typu ProductGroup z właściwościami variesBy, hasVariant i productGroupID, obok zwykłego oznaczenia Product. Z dokumentacji wynikają reguły, które warto mieć na liście kontrolnej:

• każdy wariant ma unikalny identyfikator w oznaczeniu, np. sku lub gtin;
• grupa ma unikalny identyfikator: productGroupID na grupie albo inProductGroupWithID na wariantach (jeśli podajesz oba, muszą być identyczne);
• variesBy wskazuje cechy różnicujące przez pełny adres schema.org; obsługiwane są kolor, rozmiar, wiek, płeć, materiał i wzór;
• wariant może być zagnieżdżony w grupie przez hasVariant albo wskazywać grupę przez isVariantOf;
• każdy wariant ma własną ofertę z ceną, walutą, dostępnością i adresem prowadzącym do tego wariantu.

Uproszczony szablon dla kurtki w dwóch rozmiarach (wartości przykładowe):

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Kurtka zimowa wełniana",
  "productGroupID": "KZ-100",
  "variesBy": ["https://schema.org/size"],
  "url": "https://sklep.example/kurtka-zimowa",
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Kurtka zimowa wełniana, rozmiar M",
      "sku": "KZ-100-M",
      "size": "M",
      "offers": {
        "@type": "Offer",
        "url": "https://sklep.example/kurtka-zimowa?rozmiar=m",
        "price": 199.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Kurtka zimowa wełniana, rozmiar XL",
      "sku": "KZ-100-XL",
      "size": "XL",
      "offers": {
        "@type": "Offer",
        "url": "https://sklep.example/kurtka-zimowa?rozmiar=xl",
        "price": 229.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/BackOrder"
      }
    }
  ]
}

Zamiast oznaczenia wariantów spotyka się często jedno AggregateOffer z lowPrice i highPrice. Taki zakres jest zgodny ze schema.org, ale mówi tylko „od do”, bez przypisania ceny do wersji. Jeśli zależy Ci na tym, żeby odpowiedź podawała cenę konkretnego rozmiaru, potrzebne są osobne oferty. Więcej o polach, które faktycznie są czytane, piszemy w artykule schema Product i Offer: dane, które naprawdę czyta AI.

Jedna uwaga techniczna z dokumentacji Google: oznaczenia generowane JavaScriptem mogą sprawić, że indeksowanie zakupowe będzie rzadsze i mniej niezawodne, co jest problemem przy szybko zmieniających się cenach i stanach. Google zaleca umieszczanie danych Product w początkowym HTML.

Dostępność i czas dostawy jako osobne informacje

„Dostępny” i „wyślemy jutro” to dwie różne informacje, a w wielu sklepach są sklejone w jedną etykietę. Dla wariantów to szczególnie ważne, bo zielony rozmiar S może być na magazynie, a zielony XL tylko na zamówienie.

W danych strukturalnych dostępność należy do oferty konkretnego wariantu (InStock, BackOrder, OutOfStock i inne wartości schema.org), a czas obsługi i transportu opisuje osobny obiekt OfferShippingDetails. W przykładach Google wspólna polityka wysyłki jest zdefiniowana raz i przywoływana przez identyfikator w ofercie każdego wariantu. W treści strony zrób to samo: stan magazynowy przy wybranym wariancie, termin wysyłki w osobnej linii.

Nazewnictwo modeli: spójność między kartą, feedem i katalogiem

Modele składają obraz produktu z wielu źródeł. Jeśli na karcie wariant nazywa się „Kurtka Alpi, butelkowa zieleń, XL”, w feedzie „ALPI-GRN-XL”, a w katalogu PDF „Alpi 2026 zielona duża”, rośnie ryzyko, że zostaną potraktowane jak różne produkty.

W feedzie Google Merchant Center rolę grupującą pełni atrybut item_group_id. Według pomocy Merchant Center jest wymagany dla wariantów w bezpłatnych informacjach o produktach. Każdy wariant wysyłasz jako osobny produkt z własnym id, a wszystkie warianty jednego produktu dostają tę samą wartość item_group_id. Google zaleca używanie nadrzędnego SKU jako tej wartości, nie wysyłanie nadrzędnego SKU jako osobnego produktu i niezmienianie raz nadanego identyfikatora grupy. Wielkość liter nie rozróżnia grup: „abc123” i „ABC123” to dla systemu ta sama wartość.

Najprostsza zasada porządkowa: niech productGroupID na stronie i item_group_id w feedzie mają tę samą wartość, a sku wariantu zgadza się z id w feedzie. Pomoc Merchant Center wymaga też, żeby tytuł, cena, dostępność i zdjęcie na stronie docelowej odpowiadały danym wariantu z feedu. Jak to wpisuje się w wyniki zakupowe z podsumowaniami AI, opisujemy w tekście Google Shopping i AI Overviews.

Jak sprawdzić, co model mówi o Twoim produkcie

Kontrola zajmuje kilkanaście minut na produkt i warto zacząć od tych z największą rozpiętością cen między wersjami.

1. Otwórz adresy z parametrami dla dwóch skrajnych wariantów (najtańszy i najdroższy) w oknie prywatnym i sprawdź, czy od razu pokazują właściwą cenę i stan.
2. Wyświetl źródło strony (nie inspektor przeglądarki) i poszukaj ceny drogiego wariantu. Jeśli jej nie ma w HTML, część robotów jej nie zobaczy.
3. Przepuść adres przez test wyników z elementami rozszerzonymi Google i sprawdź, czy wykrywa grupę produktów i osobne oferty.
4. Zadaj kilku asystentom AI pytania o konkretną wersję: „ile kosztuje [produkt] w rozmiarze XL” i „czy [produkt] w kolorze zielonym jest dostępny”. Zapisz odpowiedź, datę i podane źródło.
5. Porównaj odpowiedzi z danymi w sklepie i w feedzie. Błąd wskazujący na porównywarkę naprawiasz w feedzie, błąd wskazujący na Twoją stronę naprawiasz na karcie.

Odpowiedzi modeli zmieniają się w czasie i zależą od tego, skąd dany system pobiera dane, więc pojedyncze pytanie nie jest pomiarem. Różnice w doborze źródeł między narzędziami Google opisujemy w tekście Gemini i Google AI Mode: różnice w doborze źródeł. Kontrolę warto powtarzać po każdej większej zmianie cennika.

FAQ