Dane strukturalne Product opisują produkt, a Offer jego aktualną ofertę sprzedaży. Na karcie sklepu oznacz nazwę i zdjęcie produktu oraz ofertę z poprawną ceną i walutą; stan dostępności i identyfikatory dodaj, gdy są prawdziwe. JSON-LD musi odpowiadać temu, co kupujący widzi na stronie. Poprawny kod daje możliwość kwalifikacji do funkcji zakupowych Google, bez gwarancji wyświetlenia.
Najpierw uporządkuj samą kartę produktu. Znaczniki nie naprawią błędnej ceny, obcego zdjęcia ani nieaktualnego komunikatu o dostępności. Dopiero potem mapuj widoczne pola na schema.org. W sklepie ważne jest również rozróżnienie dwóch funkcji Google: informacji o produkcie umieszczonych przez sprzedawcę, gdzie kupujący może kupić produkt na tej stronie, oraz krótkiego opisu produktu, który może dotyczyć także recenzji i porównań. Ten tekst dotyczy przede wszystkim pierwszego przypadku.
Poniższe przykłady służą do zaplanowania wdrożenia. Nie są gotowym kodem dla Twojego sklepu: adresy, cena i produkt muszą pochodzić z rzeczywistego katalogu. W szerszej pracy nad SEO sklepu dane strukturalne stanowią jedną z warstw obok architektury kategorii, treści i dostępności produktów.
Kiedy Product i Offer pasują do strony?
Product opisuje jeden produkt lub wariant tego samego produktu. Google zaleca skupienie znacznika na stronie danego produktu, a nie na liście wielu niezależnych pozycji. Strona kategorii lampy nie staje się pojedynczym produktem tylko dlatego, że pokazuje karty z cenami. Jej główną rolą jest pomoc w wyborze grupy produktów i prowadzenie do odpowiednich kart. Jeśli użytkownik może kupić konkretną lampę na jej własnej stronie, ta karta jest kandydatem do danych Product z Offer.
Offer opisuje ofertę sprzedawcy: cenę, walutę, dostępność i powiązane warunki. W przypadku merchant listing Google wymaga oferty typu Offer, ponieważ właściciel strony jest sprzedawcą. AggregateOffer opisuje zbiór ofert i nie zastępuje jej w tej funkcji. Gdy strona tylko porównuje oferty innych sklepów, jej kwalifikacja i wymagania są inne. Nie przenoś bez sprawdzenia instrukcji z artykułu o recenzjach na koszyk produktu.
Istotne są też warianty. Jeżeli każdy rozmiar lub kolor ma własny URL i własny stan magazynowy, trzeba wiedzieć, który wariant opisuje bieżąca strona. Jeśli warianty są na jednej stronie, mechanizm sklepu powinien aktualizować widoczną cenę, zdjęcie i dane w sposób spójny z wyborem klienta. Dokumentacja Google opisuje osobno ProductGroup dla rodzin wariantów; nie dodawaj go automatycznie, zanim ustalisz rzeczywistą strukturę URL.
Jakie pola są wymagane, a które zalecane?
W aktualnej dokumentacji Google dla merchant listings wymagane są name, image oraz offers jako Offer. Oferta potrzebuje dodatniej aktualnej price i priceCurrency. To minimum funkcji zakupowej Google, a nie pełna lista danych, które powinien zobaczyć kupujący. availability, opis, marka i identyfikatory są wartościowymi polami zalecanymi, gdy sklep ma ich wiarygodne źródło. Sprawdź tabelę wymagań ponownie w dniu wdrożenia, bo Google może ją zmienić.
name ma odpowiadać nazwie widocznej na karcie. Nie dopisuj do znacznika fraz reklamowych, których nie ma w tytule produktu. image powinno prowadzić do pobieralnego obrazu przedstawiającego ten sam model lub wariant. price powinna być liczbą odpowiadającą aktywnej cenie, a priceCurrency kodem waluty, np. PLN, jeśli to rzeczywista oferta w złotych. availability opisuje stan, którego kupujący doświadcza podczas zakupu. Nie deklaruj InStock tylko dlatego, że system ma domyślną wartość, kiedy przycisk zakupu jest nieaktywny.
Marka, SKU, GTIN lub MPN pomagają rozpoznać konkretny towar, ale nie wolno ich zgadywać. SKU jest identyfikatorem wewnętrznym sprzedawcy. GTIN jest nadawanym kodem produktu i ma sens tylko wtedy, gdy konkretny wariant rzeczywiście go posiada. Recenzje i średnią ocenę dodawaj jedynie dla prawdziwych opinii o danym produkcie, widocznych na stronie i zgodnych z zasadami Google. Puste pole jest lepsze niż uwiarygodnienie fikcyjnej oceny.
Mapa widocznej karty do JSON-LD
Ta tabela jest demonstracyjnym arkuszem wdrożenia. Jej przykład „Lampa biurkowa Model A” nie oznacza realnego produktu, a pola bez źródła pozostają do uzupełnienia. Kolumna „weryfikacja” jest częścią pracy redakcyjnej i technicznej, nie ozdobą.
| Co widzi kupujący | Źródło prawdy w sklepie | Właściwość JSON-LD | Weryfikacja |
|---|---|---|---|
| Dokładna nazwa modelu | Karta katalogowa | Product.name | H1 i JSON-LD opisują ten sam wariant |
| Zdjęcie wybranego wariantu | Galeria produktu | Product.image | URL obrazu działa i pokazuje właściwy model |
| Bieżąca cena | Aktywna oferta w koszyku | Offer.price | Cena strony, koszyka i znacznika jest zgodna |
| Waluta | Ustawienie rynku/oferty | Offer.priceCurrency | Kod waluty odpowiada widocznej ofercie |
| Dostępność | Magazyn i możliwość zakupu | Offer.availability | Stan nie przeczy przyciskowi zakupu |
| Identyfikator produktu | Potwierdzona baza katalogowa | sku, gtin lub mpn | Nie kopiuj identyfikatora innego wariantu |
| Opinie produktu | Rzeczywiste opinie na karcie | review lub aggregateRating | Liczba i ocena zgadzają się z widocznymi wpisami |
Taka mapa ujawnia częsty problem: różne systemy aktualizują dane w różnym czasie. Cena może zmienić się w panelu sklepu, ale stary JSON-LD pozostanie w cache. Dostępność na stronie może uwzględniać sklep stacjonarny, a Offer opisywać sprzedaż internetową. Trzeba ustalić właściciela każdego pola oraz test po zmianie. Sama obecność klucza w kodzie nie potwierdza prawdziwości wartości.
Jak wygląda bezpieczny przykład kodu?
Poniżej jest szablon poglądowy, nie dane gotowe do publikacji. Teksty w nawiasach kwadratowych muszą zostać zastąpione rzeczywistymi wartościami; przykład celowo nie zawiera ceny ani opinii, których nie znamy. Po uzupełnieniu sprawdź poprawność JSON i wymagane pola w teście Google.
``json { "@context": "https://schema.org", "@type": "Product", "name": "[dokładna nazwa produktu]", "image": "[kanoniczny adres rzeczywistego zdjęcia]", "offers": { "@type": "Offer", "url": "[kanoniczny adres karty]", "price": "[aktualna dodatnia cena]", "priceCurrency": "[kod waluty]" } } ``
JSON-LD jest wygodnym formatem, bo oddziela dane od widocznego układu karty. To jednak nie jest osobna wersja prawdy. Kod powinien być generowany z tych samych danych, które zasilają stronę i koszyk. Gdy sklep ma feed w Merchant Center, sprawdź również jego cenę oraz dostępność. Google może korzystać z obu źródeł i wykryć niespójność. Nie zakładaj, że sama obecność feedu zastąpi poprawny opis na stronie.
Jeżeli karta ma promocję, cenę regularną, koszt dostawy lub zasady zwrotu, najpierw ustal semantykę rzeczywistej oferty. Nie kopiuj przypadkowego przykładu z internetu z dodatkowymi polami, które nie odpowiadają działalności sklepu. Właściwości dotyczące dostawy i zwrotów mają osobne reguły oraz mogą być opisane na poziomie sprzedawcy. Wdrożenie powinno odzwierciedlać faktyczne warunki zakupu, a nie próbę uzyskania większej liczby elementów w wyniku.
Jak utrzymać zgodność strony, kodu i feedu?
Zgodność sprawdzaj w trzech stanach: normalna sprzedaż, promocja i brak towaru. Dla każdego stanu zapisz zrzut widocznej karty, wartość JSON-LD oraz rekord feedu, jeżeli Merchant Center jest używane. Porównaj dokładny wariant, cenę, walutę, dostępność i adres. Test tylko jednego produktu w normalnym stanie często przepuszcza błąd pojawiający się podczas promocji lub wyprzedania rozmiaru.
Adres karty powinien odpowiadać temu, co sklep uważa za główną stronę produktu. Jeśli parametr wariantu zmienia cenę, ale canonical wskazuje na inny wariant, trzeba sprawdzić, jak Google rozumie te strony. To temat architektury wariantów, nie powód do ukrywania sprzeczności w znacznikach. Nie dodawaj Product na każdej stronie sklepu przez globalny szablon. Kategoria, artykuł blogowy i karta produktu mają inne główne jednostki treści.
Warto też ustalić harmonogram aktualizacji. Zmiana magazynu powinna dotrzeć do strony i JSON-LD razem. Jeśli cache odświeża się później, zapisz maksymalne opóźnienie i sprawdź ryzyko wyświetlania nieaktualnej ceny. Nie obiecuj, że Google zobaczy zmianę natychmiast; robot pobiera stronę według własnego harmonogramu. Przewodnik po SEO sklepu pokazuje, jak tę kontrolę połączyć z kategoriami i indeksowaniem.
Jak przetestować dane po wdrożeniu?
Najpierw użyj testu wyników z elementami rozszerzonymi dla konkretnego adresu. Zobacz, czy Google odczytuje jeden właściwy Product, jego Offer i wymagane właściwości. Odróżnij błąd uniemożliwiający kwalifikację od ostrzeżenia o polu zalecanym. Następnie porównaj wyświetlony w teście kod z rzeczywistą kartą w przeglądarce. Walidator nie zna Twojego magazynu; może zaakceptować technicznie poprawną, ale fałszywą cenę.
W Search Console sklep powinien sprawdzić raport informacji o produktach sprzedawcy. Raport krótkich opisów produktów ma inny zakres. Po naprawie błędów obserwuj próbki URL i użyj walidacji poprawek, jeśli raport ją oferuje. Po stronie Merchant Center kontroluj diagnostykę danych produktów. Nie traktuj pojawienia się zielonego wyniku w teście jako gwarancji obecności ceny w każdym wyniku wyszukiwania; Google wyraźnie jej nie zapewnia.
Co sprawdzić dalej?
Temat łączy się z kolejnymi decyzjami w serwisie. Zobacz także shopify seo, migracja sklepu seo oraz seo kategorii produktów.
