Produkty w AI to warstwa najbliższa transakcji – karta produktu jest ostatnim krokiem przed kliknięciem „Kup” i jednocześnie pierwszym źródłem, z którego modele AI zaciągają dane do rekomendacji. W 2026 roku ChatGPT w odpowiedzi „polec mi kawiarkę na 4 osoby do 300 zł” zwraca konkretne modele z ceną, opiniami i zdjęciem – ale tylko z tych sklepów, które mają poprawny schema Product i opisy wypełnione faktami.
Ten artykuł opisuje anatomię karty produktu pod LLM: pola schema, szablon opisu, atrybuty obowiązkowe, walidacja, pomiar. Punktem wyjścia jest przewodnik SEO dla e-commerce, do którego wraca każdy rozdział.
W skrócie
- Karta produktu pod AI potrzebuje schema Product + Offer + AggregateRating + 5-10 review jako minimum.
- Opis ma 400-700 słów i zawiera 15-25 atomowych faktów – liczb, nazw, materiałów.
- GTIN/EAN na 95%+ produktów – bez niego produkt jest deprioritized w Merchant Center i nie trafia do Google Shopping AI.
- FAQ 4-6 pytań per produkt daje modelom gotowe do zacytowania fragmenty.
- Walidacja przez Rich Results Test + Schema.org Validator co miesiąc, alert przy >5% błędów.
Anatomia karty produktu pod LLM
Karta produktu w 2026 to nie tylko cena i „Kup teraz”. To mikro-landing page z 8 strefami, z których każda służy innej warstwie indeksowania: Google, Google Shopping, ChatGPT, Perplexity, Gemini. Szczegóły warstw i jak je ze sobą integrować znajdziesz w artykule o sklepach pod AI.
- Tytuł H1 – marka + nazwa + kluczowy atrybut (rozmiar, kolor, pojemność).
- Galeria zdjęć – minimum 6, optymalnie 10-15, w tym widok 360° i packshot na białym tle.
- Blok ceny – cena brutto, rabat, dostępność, czas wysyłki.
- Opis krótki – 80-120 słów tuż pod ceną, 3-5 faktów.
- Tabela specyfikacji – 10-20 pól, strukturalnie.
- Opis długi – 400-700 słów z H2/H3, listami, tabelami.
- FAQ – 4-6 pytań z
<details>/<summary>. - Sekcja opinii – minimum 5 opinii widocznych, z Avg rating.
Schema Product – minimum vs optymalne
Schema.org Product to sztywna struktura, ale trzeba ją wypełnić tak, żeby była cytowalna. Minimum dla Google Rich Results to name, image, offers z price i priceCurrency. Optymalne dla AI – kilkukrotnie więcej pól. Checklistę całościową sklepu opisujemy w artykule o sklepach pod AI.
| Pole | Typ | Status | Uwagi |
|---|---|---|---|
| name | string | Wymagane | Pełna nazwa marketingowa |
| description | string | Wymagane | 300-600 znaków, fakty |
| image | URL[] | Wymagane | Minimum 3, optymalnie 6+ |
| brand | Brand | Wymagane | Pełna struktura z @type |
| sku | string | Wymagane | Wewnętrzny identyfikator |
| gtin13 | string | Silnie zalecane | EAN 13 dla produktów fizycznych |
| mpn | string | Zalecane | Kod producenta |
| offers | Offer | Wymagane | Zagnieżdżony obiekt |
| aggregateRating | AggregateRating | Zalecane | Gdy 5+ opinii |
| review | Review[] | Zalecane | 2-10 najnowszych |
| color | string | Sytuacyjne | Dla produktów kolorowych |
| size | string | Sytuacyjne | Dla odzieży i butów |
| material | string | Sytuacyjne | Dla mebli, odzieży, AGD |
| weight | QuantitativeValue | Sytuacyjne | Dla wysyłki |
Zagnieżdżony Offer
Offer to drugi najbardziej kluczowy obiekt. Bez Offer produkt nie trafia do Google Shopping, Rich Results Products i pomijają go rekomendacje AI.
price– number (nie string), 2 miejsca po przecinku.priceCurrency– ISO 4217, dla Polski „PLN”.availability– URL schema.org: InStock, OutOfStock, PreOrder, Discontinued.priceValidUntil– data ISO 8601, aktualizowana co 3-6 miesięcy.url– canonical URL produktu.itemCondition– NewCondition, UsedCondition, RefurbishedCondition.seller–Organizationz nazwą sklepu.shippingDetails– czas wysyłki, koszt, region (opcjonalne ale bardzo cenione przez AI).
Opis produktu – szablon pod AI
Opis produktu to miejsce, gdzie model pobiera zdania do cytowania. Każde zdanie, które nie zawiera faktu, jest marnowaniem budżetu. Opis szablonowy:
1. Zdanie otwierające
Jedno zdanie: nazwa + kategoria + główna zaleta + dla kogo. Przykład: „Kawiarka ciśnieniowa Bialetti Moka Express 6 TZ (300 ml) to aluminiowa kawiarka na 6 filiżanek espresso, idealna dla 3-4 osób piękne espresso bez elektrycznego ekspresu”.
2. Tabela specyfikacji
10-20 pól w strukturze pionowej. Nie opis prozą – tabela. ChatGPT wyciąga z tabeli zdanie „waży 480 g i ma średnicę 9.5 cm” w 100% przypadków. Z tekstu prozą – w 40% przypadków. Szablon wierszy: nazwa pola, wartość, jednostka.
3. Sekcja „Dla kogo”
Persony użytkowników: nowicjusz, zaawansowany, zawodowiec, tematyczny (np. kempingowicz, domownik, biurowy). 3-5 zdań per persona z konkretnym opisem.
4. Porównanie
Tabela porównawcza z 2-3 alternatywami w tym sklepie (nie konkurencyjnymi). Pomaga modelowi dobrać najlepszy produkt w klasie. Wierszy 4-6: cena, rozmiar, moc, materiał, gwarancja.
5. Zalety i ograniczenia
3-5 zalet + 2-3 ograniczenia. Ograniczenia są kluczowe – sklep, który je wymienia, jest postrzegany jako rzetelny przez model. Ukrywanie wad = zmniejszone zaufanie.
6. FAQ
4-6 pytań w <details>. Typowe: „Jak czyścić”, „Czy działa na kuchence indukcyjnej”, „Ile kaw zrobi jednorazowo”, „Czy jest gwarancja”. Każda odpowiedź 50-120 słów.
Atrybuty obowiązkowe dla Google Shopping
Feed Google Shopping jest jednym z ważniejszych źródeł Gemini w zapytaniach zakupowych. Niepoprawny feed = zero widoczności w AI Google. Szczegóły feedu opisaliśmy w przewodniku o Google Shopping i AI. Tu minimum dla karty produktu.
| Atrybut | Wymóg | Komentarz |
|---|---|---|
| id | Wymagany | Unikalny SKU |
| title | Wymagany | 70-150 znaków, marka + model + kluczowe atrybuty |
| description | Wymagany | 1000+ znaków, fakty |
| link | Wymagany | Kanoniczny URL |
| image_link | Wymagany | Minimum 250×250 px |
| availability | Wymagany | in_stock, out_of_stock |
| price | Wymagany | Format „99.99 PLN” |
| brand | Wymagany dla większości kategorii | Producent, nie sklep |
| gtin | Silnie zalecany | EAN 13 dla 95%+ produktów |
| mpn | Zalecany | Gdy brak GTIN |
| google_product_category | Zalecany | Z Google Product Taxonomy |
| product_type | Zalecany | Wewnętrzna kategoria sklepu |
| shipping | Zalecany | Koszt + czas per region |
Pułapki polskiego rynku
- GTIN dla polskich marek własnych – często brakuje. Rozwiązanie: rejestracja w GS1 Polska i generowanie własnych EAN.
- Tytuł z polskimi znakami – bezpiecznie są, ale niektóre integracje tracą diakrytyki. Audyt co miesiąc.
- Cena z VAT vs netto – w Merchant Center zawsze brutto dla B2C. B2B ma odrębny feed.
- Adresy z „ul.” – część parserów tego nie lubi, lepiej pełne „ulica”.
Opinie i AggregateRating
AggregateRating wymaga 5+ opinii. Bez niego schema produktu jest niekompletny. Mechanika opinii dla sklepów szerzej w artykule o sklepach pod AI. Na poziomie produktu kluczowe są trzy zasady.
- Opinia produktu, nie sklepu – w schema
Reviewdotyczy produktu, nie obsługi. „Kurier przyjechał na czas” to opinia o sklepie, „Kawa jest mocna” o produkcie. - Nazwisko autora realne – „Jan K.”, nie „Anonim”.
- Zdjęcia w opiniach – 15-25% opinii ze zdjęciami = znacząco wyższy wskaźnik cytowania.
Integracja z Opineo i Ceneo
Polskie sklepy często mają więcej opinii na Opineo i Ceneo niż na własnej stronie. Te opinie trzeba pokazywać na karcie produktu – przez widget producenta. Widget wlicza się do AggregateRating (z odpowiednim schema) i daje modelom dodatkowe źródło.
Walidacja schema
Walidacja to proces 3-warstwowy. Bez wszystkich trzech warstw są błędy cichego typu (schema istnieje, ale nie przechodzi). Narzędzia i procesy w przewodniku o narzędziach.
- Schema.org Validator (validator.schema.org) – sprawdza poprawność strukturalną.
- Google Rich Results Test – sprawdza czy Google będzie pokazywać Rich Results.
- Google Search Console – Products – historyczny widok błędów i ostrzeżeń w indeksie.
Alerty i monitoring
Automatyzacja walidacji: codzienny crawl 100 losowych produktów przez schemacrawler lub własny skrypt Python + Rich Results API. Alert w Slack przy >5% błędów. Tygodniowy raport wysokiej tabeli (kategorie z najwięcej błędów). Bez monitoringu błędy narastają – pojedyncza zmiana szablonu może popsuć 1000 produktów bez świadomości zespołu.
Obrazy produktowe pod AI
Obrazy produktu nie są tylko wizualne – ich alt-text i plik filename są indeksowane i wpływają na polecanie. Model AI potrafi zwrócić zdjęcie produktu w odpowiedzi (Perplexity, Gemini) – warunek: plik musi mieć opisowy alt, odpowiedni rozmiar i schema image.
- Minimum 6 zdjęć – główne, detal, w użyciu, packshot, tył, opakowanie.
- Rozmiar 1200×1200 px – minimum, optymalnie 2000×2000.
- WebP lub JPEG – PNG tylko gdy konieczna przezroczystość.
- Alt-text 8-15 słów – opis produktu i kontekstu, nie tylko nazwa.
- Filename descriptive –
bialetti-moka-express-6tz.webp, nieimg_4523.webp.
Kanonizacja wariantów
Produkt w 5 kolorach i 4 rozmiarach daje 20 wariantów. Każdy wariant = oddzielny URL albo wspólny URL z parametrami? Pod AI: wspólny URL z domyślnym wariantem + canonical na głównym. Każdy wariant ma własne Offer w schema, ale @id i url wskazują główny produkt. To pozwala modelowi zrozumieć że to ten sam produkt w wariantach.
Integracja z treścią
Karta produktu nie żyje w próżni. Musi być linkowana z bloga, kategorii, porównań. Blog pokazuje kontekst – „jak wybrać kawiarkę” z linkiem do konkretnego modelu. Kategoria pokazuje miejsce w ofercie. To wszystko wpływa na ranking konkretnego produktu. Strategię treści opisujemy w przewodniku o contencie pod AI.
Pomiar – czy produkt jest cytowany
Testowe zapytania do LLM co tydzień: „polec mi [kategoria] do [cena/użycie]”, „najlepsze [kategoria] 2026”, „[kategoria] dla [persona]”. Zapisuj czy produkt się pojawia i w jakim kontekście. Target: top 10 produktów sklepu cytowane w 40%+ zapytań po 6 miesiącach. Szerzej o pomiarze w artykule o widoczności e-commerce.
Automatyzacja produkcji kart
Przy 1000+ SKU ręczna edycja każdego opisu to nierealne. Rozwiązanie: szablon + AI + redakcja. Model (GPT-4o, Claude 3.5, Gemini 1.5 Pro) generuje draft opisu na podstawie danych technicznych + nazwa produktu + 3 przykładowe opinie. Redaktor dodaje unikalne fakty (10-15 minut per opis). Szczegóły w artykule o automatyzacji ofert.
Szablon promptu dla AI
Prompt dla generatora: „Napisz opis produktu X w formacie: [H1 tytuł], [3 zdania leadu], [tabela 12 specyfikacji], [3 zalety z liczbami], [2 ograniczenia], [sekcja 'Dla kogo’ – 3 persony], [FAQ 5 pytań z odpowiedziami 60-100 słów]. Dane: [karta techniczna]. Styl: konkretny, faktograficzny, polski. Długość: 500-600 słów”. Ten prompt daje ~70% docelowej jakości; reszta to redakcja.
Kara za duplikaty
Sklepy B2C często mają kilka wariantów tego samego produktu (różne rozmiary, kolory) z identycznym opisem. Google nie karze duplikatów wewnątrz sklepu, ale LLM wybiera jeden wariant z duplikatowej grupy – pozostałe są niewidoczne. Rozwiązanie: każdy wariant ma 200-300 słów unikalnej treści (dedykowana sekcja „Ten rozmiar/kolor dla kogo”) lub używa variesBy w schema.
Dark patterns do unikania
- Fałszywe ceny „promocyjne” – regulacje UE (Omnibus) wymagają pokazania najniższej ceny z ostatnich 30 dni. Niezgodność = kara + usunięcie z Merchant Center.
- Fałszywa dostępność – InStock gdy brakuje na stanie, żeby klient zaczął proces zakupu.
- Ukryty brand – podobne nazwy do znanych marek w celu oszukiwania klienta.
- Copy-paste opisów konkurencji – model to wykrywa i obniża zaufanie.
Cost i ROI poprawnych kart produktów
| Zakres SKU | Nakład pracy | Koszt |
|---|---|---|
| 100 top produktów | 1 redaktor x 3 tyg | 8-12 tys zł |
| 500 produktów | 2 redaktorów x 4 tyg | 25-40 tys zł |
| 2000 produktów | 3 redaktorów + AI + QA x 8 tyg | 60-100 tys zł |
| 10000+ produktów | Zespół 5+ etatów + AI pipeline | 200+ tys zł startowy |
Efekt: średni wzrost konwersji per-produkt 18-35%, wzrost ruchu organicznego na karty 40-80% w 6 miesięcy, cytowania AI dla top 100 – 4-15 miesięcznie (więcej w dokumentacji Schema.org Product).
Najczęstsze błędy w schema Product
- Cena jako string, nie number.
- priceCurrency „zł” zamiast „PLN”.
- Brak priceValidUntil – Google pokazuje ostrzeżenie po 3 miesiącach.
- availability bez pełnego URL schema.org.
- Review bez author (wymagane od 2024).
- AggregateRating z liczbą opinii 0 lub 1.
- Brand jako string, nie obiekt.
- Image jako lista stringów (URL), nie tablica
ImageObject. - Duplikat schema (z motywu + z wtyczki SEO).
- Nieaktualny schema po zmianie szablonu.
Plan wdrożenia dla nowego sklepu
- Tydzień 1: Audyt obecnego schema. Rich Results Test na 20 produktach.
- Tydzień 2: Poprawki w szablonie Product i Offer. Wdrożenie AggregateRating.
- Tydzień 3-4: Redakcja top 50 produktów (szablon, tabela spec, FAQ).
- Tydzień 5-8: Kolejne 200-500 produktów (redaktor + AI).
- Tydzień 9-12: Program opinii, monitoring błędów, pierwsze cykle zapytań do LLM.
FAQ – najczęstsze pytania
Czy muszę mieć GTIN dla wszystkich produktów?
Dla produktów markowych – tak, wymóg Google od 2022. Dla marek własnych (private label) – zalecane. Dla produktów unikalnych (rękodzieło, zamówienia) – niewymagane, ale wtedy potrzebujesz MPN. Brak GTIN = automatyczne obniżenie priorytetu w Merchant Center i 30-50% niższa widoczność w Google Shopping.
Ile FAQ per karta produktu to optymalnie?
4-6 pytań to złoty środek. Mniej – za mało materiału do cytowania. Więcej – rozwadnia kluczowe informacje. Każda odpowiedź 50-120 słów. Format <details>/<summary>, bo Google parsuje to poprawnie i UX jest czysty. Nie ma potrzeby FAQPage schema – Google ograniczył rich snippets do niektórych branż.
Czy AI-generated opis produktu to problem?
Nie sam w sobie, ale czysty output bez redakcji ma 35-50% niższy wskaźnik cytowania w LLM. Proces: AI generuje draft, redaktor dodaje 5-10 unikalnych faktów (wagi, wymiary, case użycia), redakcja stylu. 10-15 minut per opis. ROI dodatni przy 500+ SKU, ujemny przy mniej.
Jak obsłużyć produkty wariantowe?
Wspólny URL z domyślnym wariantem + canonical na głównym. Każdy wariant ma oddzielne Offer w schema z pełną ceną, GTIN i availability. Schema.org ProductGroup (nowe od 2024) może grupować warianty. Dla 3+ kolorów: oddzielne zdjęcia i 100-200 słów unikalnej treści per kolor.
Czy opinie z zewnętrznych platform wliczają się do schema?
Tak, pod warunkiem że widget strony trzeciej (Opineo, Trusted Shops) generuje poprawny schema AggregateRating. Widgety JavaScript bez schema są niewidoczne dla crawlerów AI. Alternatywa: serwerowa integracja przez API i własny render schema.
Jak walidować 10000 produktów miesięcznie?
Automatycznie – cron + Rich Results API (ma limit 500/dzień darmowo, 5000/dzień płatnie). Skrypt Python losuje 100 produktów dziennie i waliduje. Alert w Slack przy >5% błędów. Tygodniowy raport w BigQuery + Google Data Studio. Narzędzia jak Schema App czy SEO Pro mają gotowe moduły za 100-300 USD/mies.
Ile zdjęć produktu to minimum?
Dla Google Shopping: 1 zdjęcie 250×250+. Dla rich results: 3 zdjęcia w różnych proporcjach (1:1, 4:3, 16:9). Dla LLM: 6+ zdjęć ze scenariuszami użycia (packshot, w akcji, detal, tył, opakowanie, z akcesoriami). Każde zdjęcie z alt-textem i opisowym filename.
Czy schema mogę dodać ręcznie czy potrzebuję wtyczki?
Dla sklepu 100+ produktów – zdecydowanie wtyczka (WooCommerce SEO, Rank Math Pro, Yoast WooCommerce) lub dynamiczny JSON-LD wstrzykiwany przez backend. Ręcznie – tylko dla pojedynczych stron landingowych. Wtyczki pokrywają 80% potrzeb; customizacje (shippingDetails, dodatkowe review) przez hook.
Co dalej
Gdy karta produktu jest w formie, przejdź do kategorii (kategorie e-commerce w AI) i feedu Merchant Center (Google Shopping + AI). Całość spięta jest w przewodniku SEO dla e-commerce.









