Dane strukturalne pod AI: Product, Offer i FAQ, których szukają agenci

Żeby wyszukiwarka i agent AI jednoznacznie rozumieli Twój sklep, produkt po produkcie potrzebujesz kilku typów schema.org zapisanych jako JSON-LD: Product (co to za produkt), Offer (cena, waluta i dostępność), AggregateRating i Review (opinie, ale wyłącznie realne), BreadcrumbList (miejsce produktu w strukturze sklepu), FAQPage (pytania i odpowiedzi) oraz Organization (kim jesteś jako sprzedawca). Dane strukturalne to nie dekoracja pod Google, tylko maszynowo czytelne fakty, które model AI może wziąć wprost, porównać z konkurencją i wskazać w rekomendacji, zamiast zgadywać ze zbioru słów rozsypanych po stronie. Poniżej: które typy są kluczowe, jak je wdrożyć poprawnie i jakie błędy potrafią ściągnąć karę zamiast widoczności.

Dlaczego agenci AI potrzebują tego bardziej niż klasyczne Google

Wyszukiwarka od lat potrafi wyciągnąć sens z samego HTML, więc dane strukturalne były dla niej dodatkiem: pomagały wyświetlić gwiazdki, cenę czy breadcrumb w wynikach. Agent AI działa inaczej. Kiedy asystent porównuje produkty z kilku sklepów albo dobiera rekomendację, potrzebuje twardych, jednoznacznych faktów: ile kosztuje, w jakiej walucie i czy jest dostępny. Prozą tego nie da się pewnie odczytać, bo „149 zł, ostatnie sztuki, wysyłka gratis od 200 zł” to dla maszyny mieszanka, którą trzeba interpretować i łatwo pomylić. Ten sam produkt opisany w Offer jako cena, priceCurrency i availability jest policzalny bez interpretacji.

Dlatego dostępność zapisujemy jako pełny adres schema.org, na przykład https://schema.org/InStock albo https://schema.org/OutOfStock, a nie jako słowo „dostępny” czy wartość logiczną. To nie jest formalność. Pełny URL wskazuje jedno konkretne pojęcie ze słownika schema.org, identyczne dla każdego sklepu na świecie, więc agent porównuje jabłka z jabłkami. Im mniej zostawiasz do zgadywania, tym większa szansa, że Twój produkt trafi do porównania po właściwej cenie i statusie, a nie zostanie pominięty jako niejednoznaczny.

Sześć typów schema.org, które musi opisać sklep

Każdy typ dostarcza inny zestaw faktów, a razem opisują produkt, ofertę i sprzedawcę tak, że nie trzeba ich zgadywać:

Jeden typ = jeden zestaw jednoznacznych faktów. Nazwy właściwości podane tak, jak zapisujesz je w JSON-LD.

Product i Offer: serce oferty

Product opisuje tożsamość: name, image, sku lub gtin, brand i opis. To po tych polach agent poznaje, że Twój „Zaparzacz Kyusu 300 ml” i ten sam produkt w innym sklepie to jedna rzecz. Sercem jest jednak zagnieżdżony w Product węzeł Offer, bo to on niesie decyzję zakupową. Kompletny Offer ma cztery rzeczy, których nie wolno pominąć: price (sama liczba, bez waluty w polu), priceCurrency w kodzie ISO (PLN, EUR), availability jako pełny URL i url prowadzący do produktu. Warto dołożyć itemCondition i priceValidUntil, jeśli cena ma termin ważności.

Wartości dostępności to zamknięty słownik: między innymi https://schema.org/InStock, https://schema.org/OutOfStock, https://schema.org/PreOrder i https://schema.org/BackOrder. Wybierasz jedną, która odpowiada realnemu stanowi na stronie. Tak wygląda minimalny, poprawny blok dla jednego produktu:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Zaparzacz Kyusu 300 ml",
  "sku": "KYU-300",
  "brand": { "@type": "Brand", "name": "Twoja Marka" },
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock",
    "url": "https://twojsklep.pl/kyusu-300"
  }
}
</script>

AggregateRating i Review: tylko na realnych danych

AggregateRating (ratingValue plus reviewCount lub ratingCount) i pojedyncze Review to mocny sygnał zaufania i źródło gwiazdek w wynikach. Mają jednak twardy warunek: muszą odpowiadać realnym opiniom, które użytkownik widzi na tej samej stronie. Liczba w reviewCount to liczba faktycznych recenzji, a ratingValue to ich rzeczywista średnia. Nie podpinaj pod produkt oceny całej marki ani ocen zebranych gdzie indziej i niewidocznych na stronie produktu.

BreadcrumbList, FAQPage i Organization: kontekst i zaufanie

BreadcrumbList opisuje ścieżkę nawigacji (kolejne ListItem z pozycją i nazwą), więc i wyszukiwarka, i agent widzą, gdzie produkt leży w strukturze sklepu, zamiast domyślać się z adresu URL. FAQPage zamienia sekcję pytań i odpowiedzi w gotowe pary do wyciągnięcia, ale obowiązuje ta sama zasada co przy opiniach: znaczasz tylko pytania i odpowiedzi realnie widoczne na stronie, nie ukryty zestaw pod SEO. Organization opisuje sprzedawcę (name, logo, kanały w sameAs) i pozwala powiązać wszystkie oferty z jednym, wiarygodnym podmiotem, co dla systemów AI jest sygnałem, kto właściwie stoi za produktem.

Jak wdrożyć poprawnie: JSON-LD w znaczniku script

Google rekomenduje JSON-LD osadzony w <script type="application/ld+json">, umieszczony w sekcji head albo body strony. Format jest oddzielony od widocznego HTML, więc łatwiej go utrzymać niż mikrodane wplecione w znaczniki. Praktyczne zasady są trzy. Po pierwsze, dane muszą być w kodzie, który dostaje robot, więc na stronach renderowanych po stronie serwera (SSR) JSON-LD powinien wychodzić razem z HTML, a nie doklejać się dopiero skryptem po załadowaniu. Po drugie, jeden blok opisuje jedną encję (albo powiązany graf), a nie wszystko naraz bez struktury. Po trzecie, wartości pochodzą z tego samego źródła co treść strony: cena z JSON-LD to ta sama cena, którą widzi klient, pobrana z tego samego miejsca, a nie wpisana ręcznie obok.

Najczęstsze błędy, które ściągają karę zamiast widoczności

Cztery pomyłki wracają najczęściej i każda potrafi zamienić dane strukturalne z atutu w problem:

• Rozjazd danych z tym, co widzi użytkownik: JSON-LD podaje inną cenę, inną dostępność albo produkt, którego nie ma na stronie. To wprost spam danych strukturalnych i realne ryzyko ręcznego działania Google.
• AggregateRating bez realnych recenzji albo ocena całej strony czy marki podpięta pod pojedynczy produkt. Częsty powód ręcznych działań, opisany wyżej.
• Niekompletny Offer: brak priceCurrency lub availability, cena jako przedział „od X”, waluta w polu price. Produkt wypada z części wyników i traci jednoznaczność.
• Znaczniki dla treści, której nie ma na stronie: ukryte FAQ, niewidoczne opinie, dane doklejane wyłącznie dla robota. Zasada jest prosta: znaczasz to, co użytkownik realnie widzi.

Walidacja: zanim opublikujesz

Zanim wypuścisz zmiany, sprawdź je dwoma narzędziami, bo odpowiadają na różne pytania. Rich Results Test od Google mówi, czy strona kwalifikuje się do konkretnych wyników rozszerzonych i co Google faktycznie odczytał. Schema Markup Validator pod adresem validator.schema.org sprawdza ogólną poprawność względem słownika schema.org, niezależnie od Google. Testuj na żywym adresie po wdrożeniu, nie tylko na wklejonym kodzie, żeby złapać różnice z renderowaniem. Po publikacji warto obserwować raporty danych strukturalnych w Search Console. Żadne z tych narzędzi nie obiecuje pozycji ani wyniku; potwierdzają tylko, że dane są poprawne i czytelne.

Od poprawnych danych do widoczności w AI

Dane strukturalne to warunek wstępu do widoczności w wyszukiwaniu generatywnym i agentic commerce, nie sztuczka na skróty. Bez jednoznacznego Product, kompletnego Offer i uczciwych opinii Twój sklep zostaje zbiorem tekstu, który model musi interpretować i łatwo pominąć na rzecz konkurencji, która podała fakty wprost. Szerzej rozkładamy to w tekstach o tym, jak przygotować sklep pod agentic commerce, i o GEO dla eCommerce. Jeśli chcesz zacząć od strony technicznej, nasza Biblioteka AI ma gotowy generator JSON-LD Product i FAQ, a wdrożenie i utrzymanie danych strukturalnych w ramach całego sklepu prowadzimy jako usługę AI Visibility. Zastrzeżenie wprost: poprawne dane strukturalne zwiększają szansę na jednoznaczne zrozumienie oferty, ale nikt nie gwarantuje pozycji w Google ani cytowania przez systemy AI.