Illustration de l'article sur le balisage Schema.org Product en 2026
SEO e-commerce

Schema.org Product w 2026: co jest obowiązkowe, co zalecane i gdzie deklarować zwroty oraz dostawę

·sasha

Dokumentacja Google o kartach produktów rozróżnia dwie rzeczy, które wiele artykułów miesza: właściwości wymagane, aby strona była w ogóle uprawniona do wyniku wzbogaconego, oraz właściwości, które ten wynik wzbogacają, gdy są obecne. Informacje o zwrotach i dostawie należą do drugiej kategorii. Search Central zalicza je wprost do wzbogaceń wyniku, obok ocen, dostępności i obniżek ceny.

Ten artykuł omawia oznaczenie Product tak, jak jest udokumentowane, sekcja po sekcji: co jest obowiązkowe, co nie jest i gdzie umieścić każdy blok w PrestaShop 8 i 9 oraz WooCommerce.

Obowiązkowy fundament mieści się w pięciu właściwościach

Na Product:

  • name
  • image, jeden lub więcej adresów URL możliwych do crawlowania i indeksowania
  • offers

Na Offer:

  • price albo priceSpecification.price
  • priceCurrency albo priceSpecification.priceCurrency

Dochodzą trzy ograniczenia. Doświadczenia typu Merchant listing wymagają Offer, a nie AggregateOffer, ponieważ to Ty sprzedajesz. Cena musi być ściśle większa od zera. A strona musi dotyczyć jednego produktu albo jego odmian, a nie listy czy kategorii.

Google rozróżnia poza tym dwie rodziny oznaczeń. Product snippet dotyczy stron, na których nie da się kupić bezpośrednio, typowo recenzji redakcyjnej, z dodatkowymi opcjami po stronie opinii. Merchant listing dotyczy stron, na których odwiedzający kupuje u Ciebie, wraz z rozmiarami, dostawą i zwrotami. Wypełnienie właściwości wymaganych przez merchant listing zwykle czyni stronę uprawnioną także do product snippet.

Cała reszta jest zalecana

Tabela właściwości zalecanych dla Offer zawiera availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy i shippingDetails. Po stronie Product: brand.name, sku, mpn, kody gtin, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf i subjectOf.

Te właściwości służą odblokowaniu wyświetleń: średniej oceny, kosztu dostawy i darmowej dostawy, dostępności, informacji o zwrotach, obniżki ceny. Google zaznacza, że te wzbogacenia są pokazywane według uznania każdego doświadczenia i mogą się zmieniać, więc zaleca dostarczyć jak najwięcej informacji produktowej, zamiast celować w konkretny sposób wyświetlania.

Punkt rozstrzygający: procedura wdrożenia nakazuje poprawić błędy krytyczne zgłoszone przez Rich Results Test, a następnie dodaje, że problemy niekrytyczne mogą poprawić jakość oznaczenia, ale ich naprawa nie jest konieczna, aby kwalifikować się do wyników wzbogaconych. Tymczasem „Missing field hasMerchantReturnPolicy” i „Missing field shippingDetails” zgłaszane są w Search Console właśnie jako niekrytyczne.

Zwroty i dostawa: właściwym poziomem jest Organization

Dla polityki zwrotów obejmującej cały katalog albo prawie cały Google nakazuje zadeklarować ją jeden raz, na stronie opisującej tę politykę, w obiekcie MerchantReturnPolicy zagnieżdżonym pod Organization (albo OnlineStore) przez hasMerchantReturnPolicy. Nie ma potrzeby powtarzać jej na każdej stronie witryny.

Na tym poziomie są dwie opcje minimalnego oznaczenia:

  • Opcja A: applicableCountry i returnPolicyCategory. Jeśli kategoria ma wartość MerchantReturnFiniteReturnWindow, to merchantReturnDays staje się obowiązkowe.
  • Opcja B: merchantReturnLink, czyli adres strony opisującej politykę klientom.

Reszta jest zalecana i pozwala na precyzję: returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, warianty customerRemorse* i itemDefect* oraz returnPolicySeasonalOverride do zawężenia okna w okresie świątecznym.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Nazwa sklepu",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/zwroty#policy",
    "applicableCountry": ["PL", "CZ", "DE"],
    "returnPolicyCountry": "PL",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

Poziom Offer służy tylko dwóm przypadkom: odstępstwu od polityki standardowej dla konkretnego produktu albo sytuacji, w której polityki standardowej w ogóle nie ma. Obsługiwane tam właściwości są podzbiorem tych dostępnych na poziomie sklepu. Aby jednoznacznie odwołać się z karty do polityki globalnej, wystarczy zwykłe @id:

"hasMerchantReturnPolicy": { "@id": "https://example.com/zwroty#policy" }

Dostawa działa tak samo. Politykę standardową deklarujemy pod Organization, z szerszym zestawem właściwości niż dostępny na poziomie produktu, a karta może się do niej odwołać przez hasShippingService:

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "hasShippingService": { "@id": "https://example.com/dostawa#policy" }
}

Na poziomie Offer, jeśli opisujesz dostawę na sztywno, do wzbogacenia wymagane są cztery właściwości: deliveryTime (z handlingTime i transitTime), shippingDestination (z addressCountry w formacie ISO 3166-1 alfa-2), shippingRate.currency oraz shippingRate.value albo shippingRate.maxValue. Jedna stawka na jeden blok OfferShippingDetails: przy kilku stawkach potrzeba kilku bloków.

Oznaczenie jest ostatnie w kolejności pierwszeństwa

Google dokumentuje kolejność pierwszeństwa informacji o zwrotach, od źródła najsilniejszego do najsłabszego:

  1. Content API for Shopping, ustawienia zwrotów
  2. Ustawienia w Merchant Center albo w Search Console
  3. Oznaczenie na poziomie karty produktu
  4. Oznaczenie na poziomie Organization

Wynikają z tego dwa praktyczne wnioski. Jeśli Twoje zwroty są już skonfigurowane w Search Console albo Merchant Center, to właśnie ta konfiguracja zostanie użyta, a oznaczenie staje się redundantne. Brak oznaczenia na karcie nie oznacza też „brak polityki zwrotów”, bo Google po prostu schodzi niżej w łańcuchu, aby znaleźć informację. Przy katalogu, w którym koszty wysyłki często się zmieniają, dokumentacja sugeruje zresztą korzystanie z Merchant Center zamiast z oznaczenia.

priceValidUntil nie jest datą do odnawiania co roku

Definicja oficjalna: data i godzina, po których cena nie będzie już dostępna, w formacie ISO 8601. Dokumentacja dodaje jedno ostrzeżenie, i nie jest to to, które czyta się wszędzie: karta może się nie wyświetlić, jeśli priceValidUntil wskazuje datę przeszłą. Ryzyko bierze się z daty przeterminowanej, a nie z braku właściwości.

Po przebudowie sekcji poświęconej czasowi trwania promocji rola tej właściwości jest precyzyjna: ograniczyć obniżkę. Początek deklarujemy przez validFrom, koniec przez validThrough albo priceValidUntil. Google zaleca podać obie granice, sprawdzić, że początek poprzedza koniec, i uwzględnić godzinę oraz strefę czasową.

"offers": {
  "@type": "Offer",
  "price": 10.00,
  "priceCurrency": "PLN",
  "validFrom": "2026-11-20T08:00:00+01:00",
  "priceValidUntil": "2026-11-30T23:59:59+01:00",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 15.00,
    "priceCurrency": "PLN"
  }
}

Uwaga na umiejscowienie. Na węźle Offer właściwości priceValidUntil i validThrough są wymienne. Na węźle PriceSpecification działa wyłącznie validThrough, bo priceValidUntil nie ma tam zastosowania.

Jeśli Twoja cena nie ma realnej daty końcowej, nie umieszczaj priceValidUntil. Przesuwana data roczna, generowana automatycznie, niczego nie opisuje i sprowadza się do ogłaszania końca promocji, która nie istnieje.

Cena przekreślona, cena członkowska, cena jednostkowa

Rozpoznawane są trzy rodzaje cen, zakodowane w priceSpecification pod Offer:

  • Cena aktywna: bez priceType i bez validForMemberTier. Może też pozostać na poziomie oferty, w polu price.
  • Cena przekreślona: priceType ustawione na https://schema.org/StrikethroughPrice. To ona wyzwala wyświetlenie promocyjne, a cena aktywna staje się ceną po obniżce.
  • Cena członkowska: validForMemberTier wskazujące na MemberProgramTier zdefiniowany w Merchant Center albo w MemberProgram pod Organization.

Oba znaczniki nie łączą się ze sobą: specyfikacja ceny zawierająca jednocześnie priceType i validForMemberTier jest ignorowana. Jeśli podasz jednocześnie offers.price i offers.priceSpecification dla ceny aktywnej, Google przyjmie offers.price.

Przy produktach sprzedawanych na objętość, wagę albo długość cena jednostkowa przechodzi przez referenceQuantity w obiekcie UnitPriceSpecification. Dokumentacja sygnalizuje, że ten format ma szczególne znaczenie w Unii Europejskiej, Nowej Zelandii i Australii.

Odmiany: ProductGroup, dwie możliwe struktury

Na ProductGroup wymagana jest tylko jedna właściwość: name. Identyfikator grupy deklarujemy albo przez productGroupID na ProductGroup (SKU nadrzędne), albo przez inProductGroupWithID na każdej odmianie. Jeśli podasz oba, muszą być zgodne. variesBy wymienia osie zmienności, z sześcioma obsługiwanymi wartościami: color, size, material, pattern, suggestedAge i suggestedGender.

Udokumentowane są dwie struktury. Albo odmiany są zagnieżdżone w ProductGroup przez hasVariant, albo zadeklarowane obok i odwołują się do rodzica przez isVariantOf oraz @id. Google zaleca pierwszą, opisaną jako reprezentacja najbardziej zwarta i naturalna. Druga bywa łatwiejsza do wygenerowania z poziomu CMS-a.

Ograniczenia techniczne liczą się tu tyle samo co samo oznaczenie. Każda odmiana potrzebuje unikalnego identyfikatora (sku albo gtin) oraz odrębnego adresu URL pozwalającego ją wstępnie wybrać, z właściwym zdjęciem, ceną, dostępnością i możliwością dodania do koszyka. W witrynie, gdzie wszystko rozgrywa się na jednej stronie, grupę reprezentuje jeden adres kanoniczny. W witrynie wielostronicowej każda strona musi nieść kompletne i samodzielne oznaczenie, z powtórzoną definicją ProductGroup.

Etykieta energetyczna: hasCertification

Dla sprzętu AGD, żarówek i ekranów sprzedawanych w Unii Europejskiej właściwością do użycia jest hasCertification, z obiektem Certification:

  • issuedBy.name: EC albo European_Commission dla unijnych etykiet energetycznych, ADEME i BMWK dla klas CO2 pojazdów.
  • name: EPREL, Vehicle_CO2_Class albo Vehicle_CO2_Class_Discharged_Battery.
  • certificationIdentification: kod EPREL, wymagany dla europejskich etykiet energetycznych.
  • certificationRating: do użycia, gdy kod EPREL nie istnieje (Norwegia, Szwajcaria, Wielka Brytania) albo dla klas CO2. ratingValue jest wymagane, a dla efektywności energetycznej wymagane są także bestRating i worstRating.

Do dziesięciu certyfikatów na produkt. Dawna właściwość hasEnergyConsumptionDetails jest nadal odczytywana, ale dokumentacja zaleca przejście na hasCertification.

A co z AI Overviews?

Żadna publiczna dokumentacja Google nie uzależnia pojawienia się w AI Overviews od hasMerchantReturnPolicy, shippingDetails ani innej właściwości Product. Te właściwości są udokumentowane dla doświadczeń Merchant listing: panelu wiedzy Shopping, Popular products, Grafiki Google, Google Lens i product snippets.

Czyste oznaczenie pomaga systemom Google zrozumieć stronę, co pozostaje dobrym powodem, aby o nie zadbać. Ale dopóki nie potwierdza tego żadna dokumentacja ani powtarzalne badanie, lepiej nie budować decyzji budżetowych na domniemanym związku przyczynowym między tymi właściwościami a odpowiedziami generatywnymi.

Wdrożenie w PrestaShop 8 i 9

Motyw Classic generuje JSON-LD Product wraz z offers, ale bez polityk zwrotów i dostawy oraz bez struktury ProductGroup dla odmian. To dwa odrębne zadania, których nie należy mylić.

Po stronie katalogu. Albo nadpisujesz szablon emitujący JSON-LD w swoim motywie potomnym, z całym utrzymaniem, jakie to niesie przy każdej aktualizacji, albo korzystasz z modułu. W obu przypadkach sprawdź, czy na stronę emitowany jest tylko jeden blok Product: dwa aktywne jednocześnie moduły SEO produkują dwa konkurujące oznaczenia.

Po stronie sklepu. Politykę zwrotów i politykę dostawy deklarujemy raz, na odpowiadających im stronach CMS, w bloku Organization. Najprostsze pozostaje pole własnego kodu wstrzykiwane w sekcję head tych dwóch stron.

Moduł DataFirefly All in One SEO pokrywa pierwsze zadanie: graf JSON-LD z Organization, WebSite, BreadcrumbList oraz Product zawierającym offers, priceValidUntil i AggregateRating pochodzące z productcomments, plus FAQPage i LocalBusiness. Dostarcza też pola własnego kodu w sekcji head i na końcu body, w których deklarujesz polityki na poziomie sklepu.

Wdrożenie w WooCommerce

WooCommerce emituje natywnie Product z offers, modyfikowalny przez filtr woocommerce_structured_data_product. Yoast SEO i Rank Math generują każdy własny graf i wystawiają własny punkt rozszerzenia. Wybierz tylko jedno z tych trzech źródeł, bo ich kumulowanie oznacza publikowanie kilku bloków Product pod tym samym adresem.

Przy politykach logika jest identyczna jak w PrestaShop: blok Organization na stronie zwrotów i na stronie dostawy, przywoływany z kart przez @id, jeśli chcesz usunąć wszelką dwuznaczność. Wtyczka llms.txt plus AEO Schema WooCommerce obsługuje część grafową i FAQ na potrzeby agentów.

Weryfikacja wyniku

  1. Rich Results Test. Popraw błędy krytyczne. Ostrzeżenia niekrytyczne zostają w Twojej gestii, więc rozstrzygaj je zależnie od wzbogaceń, które chcesz uzyskać.
  2. Walidator schema.org. Składnia JSON-LD i spójność typów @type, niezależnie od reguł Google.
  3. Search Console, raport Merchant listings. Stan rzeczywisty na produkcji, po ponownym zaindeksowaniu stron. Licz kilka dni od publikacji.
  4. Merchant Center albo Search Console, ustawienia zwrotów. Sprawdź, czy istniejąca konfiguracja nie ma już pierwszeństwa nad Twoim oznaczeniem.

Od czego zacząć

  1. Sprawdzić, czy name, image, offers, price i priceCurrency są obecne i poprawne na 100 % kart. To jedyny punkt realnie blokujący.
  2. Dodać availability, itemCondition, sku, brand.name oraz GTIN tam, gdzie istnieje.
  3. Zadeklarować politykę zwrotów i politykę dostawy raz, na poziomie Organization, na dedykowanych stronach.
  4. Umieszczać priceValidUntil wyłącznie przy cenach mających realną datę końcową, z validFrom po drugiej stronie.
  5. Obsłużyć odmiany przez ProductGroup, po upewnieniu się, że każda odmiana ma własny adres URL.

Wszystko spina jedna zasada: oznaczenie ma opisywać to, co strona wyświetla. Oznaczony darmowy zwrot musi być ogłoszony w witrynie, a oznaczony termin 30 dni musi być rzeczywistym terminem 30 dni. To ta zasada, a nie liczba właściwości, tłumaczy większość ręcznych sankcji za dane strukturalne.

Przeczytaj także: kompletny przewodnik po SEO w e-commerce oraz FAQ Schema i rozszerzone wyniki.

Aby przejść do działania: nasz wybór modułów optymalizujących karty produktów.

Czytaj dalej

Powiązane artykuły