Sklep może opisać kategorię produktu i daty promocji spójnie tylko wtedy, gdy rozdzieli dwa różne obszary danych: klasyfikację produktu oraz czas obowiązywania ceny promocyjnej. W praktyce chodzi o zgodność między kartą produktu, feedem i znacznikami schema.org, a nie o dopisywanie tych samych informacji w kilku miejscach na ślepo.
Krótka odpowiedź: Product.category opisuje kategorię produktu, a dane promocji opisuje się w Offer, z uwzględnieniem zakresu ważności ceny. Google w lipcu 2026 doprecyzowało dokumentację Merchant listing dla Product.category oraz sekcję o czasie trwania promocji, więc sklep powinien trzymać jedną, spójną logikę dla strony, feedu i markup. Wyjątek pojawia się wtedy, gdy produkt pasuje do kilku kategorii albo promocja zmienia się często — wtedy trzeba świadomie ustalić jedną wersję referencyjną.
Czym różni się kategoria produktu od danych o promocji i kiedy te pola są mylone?
Kategoria produktu opisuje co sprzedajesz, a dane promocji opisują na jakich warunkach czasowych sprzedajesz ofertę. Te pola często są mylone, bo oba wpływają na sposób prezentacji produktu, ale odpowiadają na inne pytania i powinny być utrzymywane osobno.
Google Search Central w aktualizacji dokumentacji z lipca 2026 doprecyzowało, że Merchant listing documentation obejmuje Product.category z typami Text i CategoryCode, a osobno wyjaśniono sekcję Sale duration dla cen promocyjnych. To oznacza, że kategoria i promocja nie są jednym polem, nawet jeśli w sklepie bywają prowadzone w tym samym panelu administracyjnym. Szczegóły tej zmiany są opisane w oficjalnych aktualizacjach Google Search Central pod adresem Google Search documentation updates.
W schema.org punkt odniesienia też jest rozdzielony: Product zawiera właściwość category, a Offer opisuje ofertę i zawiera pola związane z czasem obowiązywania oferty, takie jak availabilityStarts i availabilityEnds. To wystarcza, by nie mieszać klasyfikacji z promocją w jednym fragmencie danych, jeśli trzymasz się jednej logiki publikacji.
Jak opisać Product.category, żeby był spójny ze stroną i feedem?
Product.category powinien odzwierciedlać tę samą logikę klasyfikacji, którą sklep pokazuje na stronie i przekazuje w feedzie. Jeśli nazwa kategorii różni się między kanałami, użytkownik i systemy Google dostają sprzeczny sygnał o tym, czym jest produkt i gdzie go przypisać.
W dokumentacji Google z lipca 2026 wskazano, że Product.category można stosować z typami Text i CategoryCode, a to ma się zgadzać z danymi z feedu Merchant Center, w szczególności z product_type oraz google_product_category; podobny porządek opisu kategorii i oferty omawia też materiał WEBEO Jak ujednolicić Product, Offer i category w sklepie. Nie trzeba udawać identyczności nazw w każdym systemie, ale trzeba utrzymać wspólną logikę klasyfikacji. Jeśli strona używa nazwy handlowej, a feed kodu kategorii, oba opisy nadal powinny prowadzić do tego samego produktu w tej samej rodzinie asortymentowej.
Najbezpieczniej jest przyjąć jedną kategorię referencyjną dla danego produktu i przepisać ją konsekwentnie do wszystkich warstw. Gdy sklep posiada rozbudowane drzewo kategorii, można użyć opisu hierarchii w sposób zgodny z dokumentacją schema.org, ale bez mieszania tego z informacjami o promocji.
Jeżeli chcesz uporządkować to szerzej w całym sklepie, pomocny bywa też materiał WEBEO o tym, jak ujednolicić Product, Offer i category w sklepie. Ten artykuł rozwija temat spójności modelu danych, a nie samej promocji.
Jak ustawić daty obowiązywania ceny promocyjnej w Offer?
Daty promocji należy przypisać do oferty, nie do kategorii produktu. W aktualizacji Google Search Central z lipca 2026 opisano nową sekcję Sale duration, która wyjaśnia użycie właściwości schema.org validFrom, validThrough i priceValidUntil dla cen promocyjnych.
W praktyce oznacza to, że sklep powinien wskazać okres obowiązywania oferty tak, aby był zgodny z Merchant Center i z tym, co użytkownik widzi na stronie. Google podało też, że przykłady mogą dotyczyć umieszczenia tych informacji na węźle Offer albo PriceSpecification. Źródło wiąże ten opis z atrybutem feedu sale_price_effective_date, więc chodzi o spójność między structured data a feedem, a nie o odrębny system promocji.
Nie rozszerzaj tego mechanizmu na ogólne planowanie rabatów. W tym temacie liczy się tylko jedno: jeśli promocja ma ograniczony czas, ten czas powinien być zapisany w danych oferty w sposób czytelny dla Google i zgodny z prezentacją na stronie.
| Obszar | Co opisuje | Gdzie szukać spójności |
|---|---|---|
| Product.category | Rodzaj lub klasa produktu | Strona produktu, feed, schema.org/Product |
| Oferta w Offer | Warunki sprzedaży i czas ważności oferty | Strona produktu, feed, schema.org/Offer |
| Daty promocji | Okres obowiązywania ceny promocyjnej | Sale duration, sale_price_effective_date |
Jakie niespójności najczęściej pojawiają się między kartą produktu, feedem i schema.org?
Najczęstszy problem to różne nazwy tej samej kategorii w trzech miejscach. Drugi to brak jasnego okresu obowiązywania promocji, mimo że na stronie cena jest pokazana jako czasowa. Trzeci to mieszanie danych kategorii z danymi oferty, przez co markup staje się trudny do interpretacji.
Jeśli karta produktu pokazuje nazwę handlową, feed używa kodu kategorii, a schema.org zawiera skrócony opis, sklep nie musi mieć błędu technicznego, ale ma niespójność semantyczną. Google może wtedy dostać poprawne technicznie, lecz słabiej zbieżne informacje o produkcie. To samo dotyczy promocji: jeśli strona pokazuje cenę promocyjną bez dat, a feed zawiera zakres ważności, systemy widzą dwa różne opisy tej samej oferty.
Warto sprawdzać takie rozjazdy na poziomie jednego produktu, zanim zostaną przeniesione na całą ofertę. Temat spójności produktu, oferty i kategorii WEBEO omawia także w tekście Jak opisać produkty, by Google lepiej rozumiało ofertę sklepu, który rozwija praktykę porządkowania informacji produktowych.
Jak sprawdzić jeden produkt przed wdrożeniem zmian na całą ofertę?
Najpierw wybierz jeden produkt, który ma prostą kategorię i jedną promocję, a potem porównaj trzy widoki: kartę produktu, feed i markup schema.org. Taka kontrola pozwala wychwycić rozjazdy w nazwie kategorii oraz w dacie obowiązywania ceny bez uruchamiania zmian w całym katalogu.
Kontrola powinna odpowiedzieć na cztery pytania: czy Product.category opisuje ten sam segment co strona; czy feed ma odpowiadający mu atrybut; czy oferta zawiera czas ważności promocji; oraz czy data widoczna dla użytkownika nie przeczy danym strukturalnym. Jeśli choć jedna odpowiedź jest niejednoznaczna, produkt testowy warto poprawić, zanim zostanie przyjęty jako wzorzec dla reszty sklepu.
Dobrym punktem wyjścia jest też techniczny audyt, bo problem często nie leży w samym schema.org, tylko w mapowaniu danych między CMS, feedem i szablonem. Jeśli sklep działa na WooCommerce, taka weryfikacja bywa częścią szerszej opieki nad danymi produktowymi i publikacją ofert.</