Product i Offer w JSON-LD: po co to Twojemu sklepowi

Wyobraź sobie klienta, który pyta asystenta AI o odżywkę białkową z zawartością co najmniej osiemdziesięciu gramów białka w stu gramach produktu. W Twoim sklepie taki produkt jest. Pytanie brzmi, czy asystent ma skąd o tym wiedzieć.

Jeśli w kodzie Twojej strony znajduje się tylko nazwa i cena, to nie ma. Zawartość białka jest wprawdzie na zdjęciu etykiety i gdzieś w długim opisie, ale nie w postaci, którą maszyna odczyta jednoznacznie. W sklepie obok ta sama informacja jest zapisana osobno, jako liczba z jednostką. I to ten sklep ma szansę trafić do odpowiedzi.

Ta różnica to są dane produktowe zapisane maszynowo, w formacie JSON-LD. Ten tekst wyjaśnia, czym są, po co je wdrażać i co realnie dają — a dopiero na końcu, dla tych, którzy chcą albo muszą, pokazuje kod.

Czym jest schema.org

Strona sklepu jest napisana dla człowieka. Człowiek patrzy na kartę produktu i od razu wie, że „129 zł” to cena, „Dostępny” to stan magazynowy, a „Ogrodnik” to marka. Maszyna tego nie wie. Widzi tekst i musi zgadywać, co czym jest.

schema.org to wspólny słownik, którym można to maszynie powiedzieć wprost. Powstał po to, żeby wszyscy nazywali te rzeczy tak samo: żeby cena nazywała się price w każdym sklepie na świecie, niezależnie od języka strony i od tego, kto ją zbudował. Słownik ma hasła na produkty, firmy, wydarzenia, opinie i kilkaset innych rzeczy.

Nas interesują dwa i warto je od razu rozdzielić, bo bywają mylone:

• Product opisuje rzecz: co to jest, jakiej marki, jakie ma parametry, ile waży, z czego jest zrobione.
• Offer opisuje warunki, na jakich ją sprzedajesz: za ile, w jakiej walucie, czy jest na stanie, nowa czy powystawowa, jak wysyłasz i na jakich zasadach przyjmujesz zwrot.

Ten sam produkt może być przedmiotem różnych ofert — inna cena w promocji, inna dostępność w drugim magazynie. Stąd podział.

Rzecz, która na starcie bywa zaskoczeniem: sam słownik niczego nie wymaga. Nie ma w nim pól obowiązkowych. Możesz opisać produkt jedną właściwością albo trzydziestoma. Wymagania pojawiają się dopiero z drugiej strony — od tego, kto te dane czyta i co za nie daje. I tu zaczyna się najważniejsza część.

Co to realnie daje

Dwie różne rzeczy, w dwóch różnych miejscach.

W wyszukiwarce Google: Twój wynik wygląda inaczej

To jest część w pełni udokumentowana i przewidywalna. Jeśli spełnisz wymagania, Google może pokazać Twój wynik bogaciej niż zwykły tytuł z opisem: z ceną, informacją o dostępności, gwiazdkami z ocenami, okruszkami nawigacyjnymi. Twój wynik zajmuje więcej miejsca i mówi więcej, zanim ktokolwiek w niego kliknie. Ten mechanizm działa w ten sposób od wielu lat.

U asystentów AI: masz czym odpowiedzieć albo nie masz

Tu sprawa jest ciekawsza i dla większości sklepów ważniejsza, bo ruch przenosi się dziś z klasycznych wyników wyszukiwania do odpowiedzi generowanych przez asystentów — a ta część rośnie.

Wróćmy do białka z pierwszego akapitu. Klient pyta o odżywkę z zawartością powyżej osiemdziesięciu gramów w stu gramach produktu. Asystent musi z czegoś taką odpowiedź złożyć. Jeśli w Twoim sklepie ta liczba istnieje jako osobna wartość z jednostką, jest czym odpowiedzieć. Jeśli u konkurencji nie istnieje — a u większości sklepów dziś nie istnieje — to Twój produkt ma szansę w tej odpowiedzi być, a ich nie.

To jest przewaga, którą dziś realnie da się zbudować, bo prawie nikt tego nie robi. Typowe wdrożenie kończy się na nazwie, cenie i dostępności, czyli na tym, co ma każdy.

Ktoś w tym miejscu zapyta: przecież mam to wszystko w opisie produktu. I to jest dobre pytanie. Odpowiedź brzmi: masz, ale w formie, która wymaga od maszyny przeczytania długiego tekstu i wyłuskania z niego właściwego zdania. Opisy w sklepach potrafią mieć kilka tysięcy znaków, a maszyna nie zawsze czyta stronę w całości — czasem bierze tyle, ile jej wystarczy, i idzie dalej. Dane strukturalne są skrótem: krótką, jednoznaczną listą faktów, która nie wymaga interpretacji i nie znika w połowie opisu. Opis zostaje dla człowieka. Znacznik jest dla maszyny.

Uczciwie o granicy: żaden dostawca nie ogłosił, czym dokładnie kieruje się, wybierając produkty do odpowiedzi — to jest nowa dziedzina i wszyscy się jej uczą. Nasze obserwacje z wdrożeń, w zgodzie z tym, co pokazują dostępne badania, są jednak jednoznaczne: produkt opisany kompletnie ma czym wygrać, a produkt opisany trzema polami nie bierze udziału w rozmowie.

Jeśli chcesz sprawdzić, jak Twoje produkty wyglądają dziś z tej strony, zamów u nas darmowy raport GEO — pokazuje, które informacje asystent z Twojego sklepu wyczytuje, a które zostały w opisie dla człowieka.

Czym jest JSON-LD

Skoro ma być słownik, potrzebny jest jeszcze sposób zapisu. Są trzy; ten, który dziś ma sens, nazywa się JSON-LD.

W praktyce dane produktowe w JSON-LD to osobny blok umieszczony w kodzie strony, obok treści, a nie wpleciony w nią. Klient go nie widzi. Jeśli otworzysz podgląd źródła strony produktu w dowolnym większym sklepie, znajdziesz tam kilkanaście linijek wyglądających jak lista „nazwa: wartość” — to właśnie on.

Google zaleca akurat ten format i podaje powód: jest najłatwiejszy do wdrożenia i utrzymania w skali, czyli najmniej podatny na ludzkie błędy. Z naszej praktyki utrzymaniowej dochodzi drugi argument, mocniejszy: starsze sposoby zapisu są wplecione w wygląd strony, więc każda przebudowa karty produktu grozi ich rozjechaniem — i zwykle je rozjeżdża. Blok JSON-LD stoi osobno i przeżywa zmianę szablonu.

Jedna zasada, o którą warto pytać wdrożeniowca: ten blok ma powstawać z tych samych danych, z których renderuje się strona. Jeśli powstaje z osobnego miejsca — z ustawień wtyczki, z ręcznie wpisanych wartości — prędzej czy później pokaże inną cenę niż ta, którą widzi klient.

Pola, od których się zaczyna

Nazwy są po angielsku, bo słownik jest jeden dla całego świata. Znaczenia są proste.

Dwa ostatnie pola są w polskich sklepach pomijane najczęściej ze wszystkich. Są też jedynymi, które mówią cokolwiek o warunkach zakupu, a nie o samym produkcie — czyli o tym, czym się od kogoś różnisz.

Dlaczego przy dostępności widnieje adres internetowy, a nie słowo

W kodzie zobaczysz zapis w rodzaju https://schema.org/InStock i to wygląda na link. Nie jest linkiem do kliknięcia. To jest numer katalogowy pojęcia.

Gdyby wpisać po prostu „dostępny”, maszyna musiałaby zgadywać: dostępny od ręki, na zamówienie, tylko w sklepie stacjonarnym? A na stronie po angielsku byłoby to inne słowo, po niemiecku jeszcze inne. Adres ze słownika znaczy dokładnie jedno i to samo dla każdej maszyny, niezależnie od języka strony — tak jak książkę jednoznacznie identyfikuje numer ISBN, a nie jej tytuł.

Klient tego nigdy nie widzi. To siedzi w kodzie i jest po to, żeby nie było miejsca na interpretację.

Dwa zestawy wymagań — Google obsługuje osobno dwa przypadki

Mówimy tu cały czas o zawartości bloku danych, nie o wyglądzie strony. Google czyta ten blok i sprawdza, czy zawiera to, czego wymaga dana funkcja. Funkcje są dwie i mają różne listy.

Pierwszy przypadek: strona opisuje produkt, ale nie da się go na niej kupić. Recenzja, porównanie, artykuł poradnikowy. Lista jest krótka: nazwa produktu i jedna z trzech rzeczy — opinia, ocena zbiorcza albo informacja o ofercie.

Drugi przypadek: strona, na której klient kupuje u Ciebie. Czyli Twoja karta produktu. Tu Google wymaga więcej: nazwy, zdjęcia i bloku oferty, a w nim ceny większej od zera razem z walutą. To jest zestaw, który dotyczy sklepu.

Pułapka polega na tym, że wdrożenie zrobione pod pierwszy przypadek przechodzi kontrolę bez błędu, a do funkcji sklepowych się nie kwalifikuje. Nikt nie dostaje ostrzeżenia, nic się nie pali, po prostu efektu nie ma. Jeśli kiedykolwiek słyszałeś „narzędzie świeci na zielono, a w wynikach nic się nie zmieniło”, to jest pierwsze miejsce do sprawdzenia.

A co ze stronami kategorii

To pytanie pada zawsze, zwłaszcza gdy na liście produktów jest przycisk dodania do koszyka.

Odpowiedź Google jest jednoznaczna: wyniki produktowe obsługują strony skupione na jednym produkcie albo na wariantach tego samego produktu. Dokumentacja podaje wprost przykład, że „buty zimowe w naszym sklepie” nie są konkretnym produktem, i zaleca dodawanie znacznika na kartach produktów zamiast na stronach z listą. Przycisk do koszyka na kategorii tego nie zmienia — kryterium jest jeden produkt na stronie, nie możliwość kupienia.

Dla stron z listą istnieje osobny mechanizm: znacznik listy pozycji. Powiązany z nim wynik karuzelowy jest u Google w fazie beta i — co dla nas istotne — udostępniony w krajach Europejskiego Obszaru Gospodarczego, między innymi dla zapytań produktowych. Polska się w tym mieści. To osobne wdrożenie i osobna decyzja; przy większości sklepów zaczynamy od kart produktów, bo tam jest pewny zwrot.

Pamiętaj: produkt i oferta to nie wszystko

Zasada, którą warto mieć w głowie przy rozmowie z wdrożeniowcem: znacznik opisuje to, czym dana strona jest, a nie to, co na niej leży.

Karta produktu jest produktem — stąd Product i Offer. Ale kategoria jest listą prowadzącą do produktów, strona główna jest firmą, a wpis na blogu artykułem. Każda z nich ma w słowniku własny typ. Okruszki nawigacyjne, czyli ścieżka „Sklep › Suplementy › Odżywki białkowe” widoczna w wyniku zamiast surowego adresu, to kolejny osobny znacznik — prosty, tani i działający na całym sklepie.

Sklep opisany porządnie ma więc kilka różnych znaczników w różnych miejscach, a nie jeden powielony wszędzie. Rozłożenie ich po sklepie opisujemy w tekście jaki znacznik na jaką stronę w sklepie.

Czym można dziś wygrać

Tu zaczyna się część, której w większości wdrożeń po prostu nie ma.

Typowe wdrożenie kończy się na nazwie, cenie, dostępności i marce. Robi to każdy, więc nikogo to nie wyróżnia. Tymczasem słownik pozwala opisać produkt dużo dokładniej i to właśnie te pola odpowiadają na pytania, które klienci naprawdę zadają.

additionalProperty — dowolna para „nazwa parametru i jego wartość”, z jednostką. Tu wpisujesz zawartość białka w stu gramach, moc silnika, nośność, wydajność, grubość, pojemność. Cokolwiek, co w Twojej branży rozstrzyga o wyborze.

weight — waga produktu jako liczba z jednostką, a nie zdanie w opisie.

material, color, size — materiał, kolor i rozmiar, przy odzieży z pełną specyfikacją rozmiarówki.

hasCertification — certyfikaty: ekologiczne, jakościowe, branżowe.

hasEnergyConsumptionDetails — klasa energetyczna, w polu przewidzianym dokładnie do tego.

countryOfOrigin — kraj pochodzenia.

Do tego słownik ma węższe typy dla konkretnych rodzajów produktów. Suplement diety można opisać typem, który poza wszystkim powyższym ma osobne pole na substancję czynną.

Jak to wygląda w dwóch branżach

Suplementy. Dwa sklepy sprzedają tę samą odżywkę białkową w tej samej cenie. Pierwszy ma w kodzie nazwę, cenę i dostępność. Drugi ma to samo plus zawartość białka w stu gramach jako liczbę z jednostką, wagę opakowania, liczbę porcji, substancję czynną i certyfikat jakości. Klient pyta o białko powyżej osiemdziesięciu gramów, bez laktozy, w opakowaniu na miesiąc. Tylko drugi sklep ma czym odpowiedzieć na wszystkie trzy warunki naraz.

Sprzęt elektryczny i AGD. Pytanie brzmi „zmywarka do zabudowy sześćdziesiąt centymetrów, klasa energetyczna A, cicha”. Klasa energetyczna ma w słowniku własne, dedykowane pole. Szerokość i poziom hałasu wpisuje się jako parametry z jednostkami. Sklep, który ma to w kodzie, jest w tej rozmowie. Sklep, który ma te dane wyłącznie w tabeli w opisie albo na grafice producenta, ma je dla człowieka, ale nie dla maszyny.

Ta sama logika działa w meblach — wymiary, materiał, nośność — i w budowlance, gdzie rozstrzygają parametry techniczne i deklaracje zgodności. Zasada jest jedna: to, po czym klient wybiera w Twojej branży, powinno istnieć w kodzie jako osobna wartość, a nie jako zdanie w opisie.

A co ze sklepem w kilku językach

Pytanie pada zawsze, gdy w grę wchodzą nazwy parametrów po polsku, i jest zasadne: skoro „Zawartość białka w 100 g” to zwykły tekst, to co z wersją niemiecką i angielską?

Odpowiedź jest prostsza, niż się wydaje. Blok danych należy do konkretnej strony, a każda wersja językowa jest osobną stroną pod osobnym adresem. Niemiecka karta produktu ma własny blok, z nazwą produktu, opisem i nazwami parametrów po niemiecku. Nie ma jednego bloku obsługującego wszystkie języki naraz i nie ma potrzeby, żeby był.

Co się przy tym nie tłumaczy, i to jest dobra wiadomość: wszystko, co jest identyfikatorem, a nie tekstem do czytania. Dostępność i stan produktu to adresy ze słownika, więc są takie same na każdej wersji językowej. Kody jednostek są międzynarodowe — gram to GRM niezależnie od języka strony. Kod kreskowy, numer katalogowy i cena też się nie zmieniają, poza walutą, jeśli sprzedajesz w kilku.

Tłumaczy się tylko to, co i tak tłumaczysz: nazwę produktu, opis, nazwy parametrów. W sensownym wdrożeniu blok powstaje z tych samych danych, z których renderuje się strona — więc jeśli masz nazwy parametrów w słowniku tłumaczeń sklepu, znacznik weźmie właściwą wersję sam. Ręcznej pracy nie ma.

Kiedy ręczna praca jest: gdy parametry są wpisane w treść opisu jako tekst, a nie jako pola w bazie sklepu. Wtedy ktoś musi je stamtąd wyjąć i poukładać. To jest argument za trzymaniem parametrów w polach, nie w akapicie, dużo mocniejszy niż cokolwiek związanego z wyszukiwarką.

I tu dobra wiadomość dla sklepów z dużym katalogiem, bo pierwsza myśl przy pięciu tysiącach produktów w pięciu językach brzmi zwykle „to jest projekt na pół roku dla pięciu osób”. Nie jest. Wydobycie parametrów z istniejących opisów to dziś zadanie, które w dużej części robi się automatycznie — narzędzia oparte na modelach językowych radzą sobie z wyciągnięciem z opisu gramatury, mocy czy zawartości i zapisaniem tego w polach. Robimy to u klientów i wygląda to tak:

• na próbce stu produktów sprawdzamy, co i z jaką dokładnością da się wyciągnąć z Twoich opisów — to pokazuje, ile pracy zostanie dla człowieka;
• ustalamy listę parametrów, które w Twojej branży rozstrzygają o wyborze; nie wyciągamy wszystkiego, tylko to, co ma znaczenie;
• przetwarzamy katalog masowo, z kontrolą jakości na losowej próbce;
• wersje językowe schodzą z tego samego mechanizmu, bo nazwa parametru tłumaczy się raz, a nie przy każdym produkcie;
• od tego momentu nowe produkty trafiają od razu z wypełnionymi polami i problem nie wraca.

Uczciwie: nic z tego nie zwalnia z przejrzenia wyników. Model wyciągnie to, co w opisie jest — jeśli opis milczy o gramaturze, nie wymyśli jej i nie powinien. Ale różnica między „pięć osób na pół roku” a „kilka dni pracy plus przegląd” jest realna i to jest dziś standard, a nie wyczyn.

Jak to wygląda w kodzie

Od tego miejsca robi się technicznie. Jeśli wdrożenie zlecasz, przewiń do listy kontrolnej — wróć tutaj, gdy będziesz chciał sprawdzić, co dostałeś.

Minimum dla karty produktu

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Odżywka białkowa WPC 82, wanilia, 900 g",
  "image": "https://sklep-suplementy.example/img/wpc82-wanilia.jpg",
  "offers": {
    "@type": "Offer",
    "price": 129.00,
    "priceCurrency": "PLN"
  }
}

Cztery właściwości. Tyle wymaga Google, żeby strona kwalifikowała się do funkcji sklepowych.

To samo, opisane tak, żeby było czym wygrać

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Odżywka białkowa WPC 82, wanilia, 900 g",
  "image": "https://sklep-suplementy.example/img/wpc82-wanilia.jpg",
  "sku": "WPC82-WAN-900",
  "gtin13": "5901234567890",
  "brand": { "@type": "Brand", "name": "PrzykładNutrition" },
  "weight": {
    "@type": "QuantitativeValue",
    "value": 900,
    "unitCode": "GRM"
  },
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "Zawartość białka w 100 g",
      "value": 82,
      "unitCode": "GRM"
    },
    {
      "@type": "PropertyValue",
      "name": "Liczba porcji w opakowaniu",
      "value": 30
    }
  ],
  "offers": {
    "@type": "Offer",
    "url": "https://sklep-suplementy.example/wpc82-wanilia-900g",
    "price": 129.00,
    "priceCurrency": "PLN",
    "itemCondition": "https://schema.org/NewCondition",
    "availability": "https://schema.org/InStock"
  }
}

Różnica między tymi dwoma blokami to nie jest kosmetyka. Pierwszy mówi, że masz produkt w cenie. Drugi mówi, co to za produkt i dla kogo.

Warianty: rozmiary, pojemności, kolory

Najczęstsze pytanie przy wdrożeniu i miejsce, w którym najłatwiej zrobić to źle. Jeśli ten sam produkt występuje w trzech opakowaniach po różnych cenach, nie wpisuje się widełek cenowych. Google ma do tego osobną konstrukcję: grupę produktów.

Uwaga, która oszczędza poprawek: cechę odróżniającą warianty wskazuje się z zamkniętej listy sześciu — kolor, rozmiar, materiał, wzór, sugerowany wiek i sugerowana płeć. Wagi na tej liście nie ma, więc różne gramatury opakowania opisuje się jako rozmiar.

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Odżywka białkowa WPC 82, wanilia",
  "url": "https://sklep-suplementy.example/wpc82-wanilia",
  "productGroupID": "WPC82-WAN",
  "brand": { "@type": "Brand", "name": "PrzykładNutrition" },
  "variesBy": "https://schema.org/size",
  "hasVariant": [
    {
      "@type": "Product",
      "name": "WPC 82, wanilia, 900 g",
      "sku": "WPC82-WAN-900",
      "size": "900 g",
      "offers": {
        "@type": "Offer",
        "url": "https://sklep-suplementy.example/wpc82-wanilia?opakowanie=900g",
        "price": 129.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "WPC 82, wanilia, 2000 g",
      "sku": "WPC82-WAN-2000",
      "size": "2000 g",
      "offers": {
        "@type": "Offer",
        "url": "https://sklep-suplementy.example/wpc82-wanilia?opakowanie=2000g",
        "price": 249.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}

Trzy warunki, których Google przy wariantach wymaga i o które warto zapytać wdrożeniowca:

• każdy wariant ma własny, unikalny numer — numer katalogowy albo kod kreskowy, nie ten sam dla wszystkich;
• każdy wariant da się otworzyć pod osobnym adresem, z już wybraną opcją, właściwą ceną i właściwą dostępnością;
• nazwa wariantu jest bardziej szczegółowa niż nazwa grupy — „WPC 82, wanilia, 900 g”, a nie „WPC 82”.

Najczęstsze błędy, które widzimy przy przejmowaniu sklepów

Dostępność wpisana na sztywno. Wdrożenie ustawia „na stanie” dla wszystkiego, bo tak było najprościej. Działa, dopóki nie masz braków, a potem kod mówi nieprawdę.

Cena netto w kodzie, brutto na stronie. Rozjazd bywa niezauważony miesiącami, bo nikt nie porównuje tych dwóch miejsc.

Kody kreskowe przepisane z pliku hurtowni bez sprawdzenia. Bywa to numer opakowania zbiorczego albo innego wariantu. Lepiej nie podać niż podać cudzy.

Dane, których nie ma na stronie. Kuszące jest dopisanie do kodu parametrów, których klient nie widzi — Google odradza to wprost i słusznie. W kodzie ma być to, co widać na stronie.

Dwa wdrożenia naraz. Wtyczka generuje swoje, motyw swoje, oba siedzą w kodzie i mówią różne rzeczy o tej samej cenie. Zdarza się częściej, niż mogłoby się wydawać.

Zanim uznasz temat za zamknięty

Do przejścia bez czytania kodu, w kilkanaście minut. Sprawdź po kolei:

• Wpisz w Google pełną nazwę swojego produktu. Przy wyniku widać cenę, dostępność albo gwiazdki? Jeśli tak, znacznik działa. Jeśli widzisz sam tytuł i opis — jest do sprawdzenia.
• Powtórz to dla trzech produktów: dostępnego, niedostępnego i przecenionego. To wyłapuje dostępność wpisaną na sztywno i rozjazd cenowy.
• Porównaj cenę w wyniku wyszukiwania z ceną na stronie. Muszą zgadzać się co do grosza.
• Sprawdź, czy znacznik stoi na kartach produktów, a nie na kategoriach. Zapytaj wdrożeniowca albo sprawdź, czy strona kategorii nie zgłasza w narzędziach Google błędów produktowych.
• Zapytaj, skąd biorą się dane w znaczniku. Właściwa odpowiedź brzmi: z tego samego miejsca, z którego renderuje się strona.
• Wypisz dwa, trzy parametry, po których klienci wybierają w Twojej branży — i sprawdź, czy są zapisane jako osobne wartości, czy tylko jako zdania w opisie. To jest najważniejszy punkt na tej liście.
• Przy produktach wariantowych sprawdź, czy każdy wariant otwiera się pod własnym adresem z właściwą ceną.

Najczęstsze pytania

Czym są dane strukturalne na karcie produktu?
To osobny blok w kodzie strony, niewidoczny dla klienta, w którym cena jest oznaczona jako cena, marka jako marka, a zawartość białka jako liczba z jednostką. Dzięki niemu wyszukiwarka i asystenci AI nie muszą niczego wyłuskiwać z opisu.

Jakie pola wypełnić przy produkcie?
Minimum to nazwa, zdjęcie oraz cena z walutą — tyle wymaga Google, żeby strona kwalifikowała się do funkcji sklepowych. Wyróżnia natomiast dopiero to, co idzie dalej: numer katalogowy, kod kreskowy, waga i parametry rozstrzygające o wyborze w Twojej branży.

Czy znacznik produktu wolno wstawić na stronie kategorii?
Nie. Wyniki produktowe obsługują strony skupione na jednym produkcie albo na wariantach tego samego produktu, a przycisk dodania do koszyka na liście tego nie zmienia. Dla stron z listą istnieje osobny znacznik listy pozycji.

Mam produkt w kilku pojemnościach. Jak to opisać?
Nie widełkami cenowymi, tylko grupą produktów z wariantami. Każdy wariant potrzebuje własnego numeru, własnego adresu z wybraną opcją oraz nazwy bardziej szczegółowej niż nazwa grupy.

Czy dane strukturalne sprawią, że asystent AI poleci mój sklep?
Nikt tego nie zagwarantuje, bo żaden dostawca nie ujawnił, jak dobiera produkty do odpowiedzi. Pewne jest co innego: asystent może użyć wyłącznie tego, co znalazł, a produkt opisany trzema polami nie bierze udziału w rozmowie o parametrach, których w kodzie nie ma.

Skąd mają pochodzić dane w znaczniku?
Z tego samego miejsca, z którego renderuje się strona. Jeśli powstają osobno — z ustawień wtyczki albo z ręcznie wpisanych wartości — prędzej czy później pokażą inną cenę niż ta, którą widzi klient.

Mam sklep w kilku językach. Czy potrzebuję osobnych znaczników?
Każda wersja językowa jest osobną stroną, więc ma własny blok. Tłumaczy się w nim tylko to, co i tak tłumaczysz: nazwę produktu, opis i nazwy parametrów. Dostępność, stan produktu i kody jednostek są identyfikatorami i pozostają takie same.

Czy wtyczka wystarczy?
Przy większości platform jest rozsądnym startem, ale warto sprawdzić wynik: typowe wdrożenie kończy się na nazwie, cenie i dostępności, czyli na tym, co ma każdy. Pola, które wyróżniają, zwykle trzeba uzupełnić samodzielnie.

Po co to robimy

Dane strukturalne nie są znacznikiem doklejanym dla wyszukiwarki. Są sposobem na to, żeby informacje, które i tak masz, przestały być zamknięte w zdaniach i na grafikach, a zaczęły istnieć w postaci, którą maszyna odczyta jednoznacznie.

W Google efekt jest widoczny od razu i przewidywalny: bogatszy wynik, który zajmuje więcej miejsca i mówi więcej. U asystentów AI kompletnie opisany produkt zwiększa widoczność — tak to widzimy po wdrożeniach u klientów i tak wynika z badań, które śledzimy. Mechanizmu nikt nie ujawnił i nikt uczciwy nie obieca Ci miejsca w konkretnej odpowiedzi, ale jedno jest pewne: asystent może użyć wyłącznie tego, co znalazł. Produkt, którego parametry istnieją tylko na zdjęciu etykiety, do rozmowy o tych parametrach nie wchodzi.

Zacznij od pytania, na które odpowiedź znasz najlepiej: po czym Twoi klienci wybierają w Twojej branży? Te dwa, trzy parametry powinny istnieć w kodzie Twoich kart produktów. Reszta to szczegóły wdrożenia — i z nimi możemy pomóc.

Jeśli chcesz zobaczyć, co asystent dziś z Twoich produktów wyczytuje, zamów darmowy raport GEO. Pokazuje, które informacje widzi, a które zostały w opisie dla człowieka. Jeśli wolisz od razu zobaczyć, ile kosztuje wdrożenie i co obejmuje, mamy zakres i ceny pakietów GEO.