# Schema.org Product w 2026: co jest obowiązkowe, co zalecane i gdzie deklarować zwroty oraz dostawę
> Do kwalifikacji do wyników produktowych wymagane jest tylko pięć właściwości. hasMerchantReturnPolicy i shippingDetails to wzbogacenia, deklarowane najlepiej na poziomie Organization. Co mówi dokumentacja Google i jak zastosować to w PrestaShop 8 i 9 oraz WooCommerce.
- Strona:
- Język: pl
- Opublikowano: 2026-07-20
- Zaktualizowano: 2026-08-11
- Inne języki: [fr](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/index.md), [en](https://www.datafirefly.com/en/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-en/index.md), [es](https://www.datafirefly.com/es/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-es/index.md), [de](https://www.datafirefly.com/de/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-de/index.md), [it](https://www.datafirefly.com/it/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce-2/index.md), [nl](https://www.datafirefly.com/nl/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/index.md), [pt](https://www.datafirefly.com/pt/2026/07/20/schema-org-product-2026-devolucoes-entrega-prestashop-woocommerce/index.md)
- Indeks:
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](https://www.datafirefly.com/pl/product/dfallinoneseo/) 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](https://www.datafirefly.com/pl/product/llms-txt-aeo-woocommerce-schema-ia/) 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](https://www.datafirefly.com/pl/2026/05/01/seo-ecommerce-kompletny-przewodnik-2026/) oraz [FAQ Schema i rozszerzone wyniki](https://www.datafirefly.com/pl/2026/05/09/prestashop-faq-schema-rozszerzone-wyniki-google-przewodnik-2026/).
Aby przejść do działania: [nasz wybór modułów optymalizujących karty produktów](https://www.datafirefly.com/pl/solutions/prestashop/karta-produktu/).