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.
Jak postąpić, gdy produkt pasuje do kilku kategorii albo promocja zmienia się często?
W takim przypadku trzeba ustalić jedną wersję referencyjną dla produktu i osobno prowadzić zmiany promocji. Product.category nie powinien zmieniać się tylko dlatego, że sklep chce podkreślić inny kontekst sprzedażowy, a daty promocji nie powinny zastępować klasyfikacji produktu.
Jeśli produkt pasuje do kilku kategorii, wybierz tę, która najlepiej odpowiada stronie produktu i podstawowemu feedowi. Pozostałe konteksty można zachować w wewnętrznej strukturze sklepu, ale nie trzeba ich wtłaczać do jednego pola, jeśli prowadziłoby to do chaosu. Gdy promocja zmienia się często, najważniejsze jest szybkie aktualizowanie zakresu ważności oferty, żeby strona i dane strukturalne nie opisywały już nieaktualnej ceny.
Takie rozdzielenie ogranicza ryzyko, że zmiana kampanii promocyjnej zacznie niepotrzebnie wymuszać zmianę kategorii produktu. To są dwa różne procesy i powinny mieć osobne reguły aktualizacji.
Jakie korzyści biznesowe daje uporządkowanie tych danych w e-commerce?
Uporządkowanie Product.category i dat promocji daje przede wszystkim czytelniejszy opis oferty dla systemów Google i dla zespołu sklepu. Kiedy źródła danych mówią jednym głosem, łatwiej utrzymać porządek przy większej liczbie produktów i mniejszym nakładzie ręcznych poprawek.
Korzyść operacyjna jest prosta: mniej przypadkowych rozjazdów między stroną, feedem i markupiem. Korzyść komunikacyjna jest równie ważna: użytkownik widzi ofertę zgodną z tym, co sklep faktycznie przekazuje do systemów Google. To nie jest strategia wzrostu sama w sobie, ale porządek danych zmniejsza liczbę sytuacji, w których promocja lub klasyfikacja produktu są interpretowane inaczej niż zamierzono.
Dla małego sklepu to też ma sens, bo kilka produktów szybciej da się sprawdzić ręcznie, a błędny wzorzec nie rozchodzi się po całej ofercie. Przy większym katalogu porządek w tych dwóch polach ułatwia późniejsze aktualizacje bez poprawiania wszystkiego od nowa. W praktyce pomocny bywa też powiązany materiał WEBEO o tym, jak Jak opisać produkty, by Google lepiej rozumiało ofertę sklepu, bo rozwija on temat spójności produktu, kategorii i promocji.
Najczęstsze pytania
Czy trzeba zawsze wskazywać jedną główną kategorię produktu?
Nie ma podstaw, by z samego schema.org wyprowadzać obowiązek jednej głównej kategorii dla każdego produktu. W praktyce jednak jedna wersja referencyjna upraszcza spójność między stroną, feedem i markupiem. Jeśli produkt naturalnie mieści się w kilku grupach, lepiej ustalić jedną kategorię używaną publicznie, a pozostałe relacje zostawić w strukturze wewnętrznej sklepu.
Czy brak dat promocji zawsze oznacza problem, jeśli promocja jest bardzo krótka?
Nie da się tego sprowadzić do prostego „zawsze” na podstawie samej dokumentacji. Google wprowadziło sekcję o czasie trwania promocji, więc jeśli sklep komunikuje okresową cenę, powinien ten okres opisać spójnie. Krótka promocja bez dat może być po prostu słabiej udokumentowana niż promocja z jasno wskazanym zakresem ważności.
Co zrobić, jeśli feed ma inną nazwę kategorii niż strona produktu?
Najpierw ustal, czy to tylko inna etykieta, czy faktycznie inna klasyfikacja produktu. Jeśli nazwy opisują ten sam segment, ujednolić trzeba mapowanie, a niekoniecznie literalny tekst. Jeśli opisują różne segmenty, problemem jest źródło danych, a nie sam feed. Wtedy warto poprawić katalog lub reguły eksportu, zanim zaktualizujesz schema.org.
Czy validFrom i validThrough muszą występować zawsze razem?
Źródło potwierdza użycie tych właściwości w sekcji o „Sale duration”, ale nie daje podstaw, by ogłosić sztywny obowiązek wspólnego występowania w każdej implementacji. Z perspektywy praktycznej para dat jest jednak czytelniejsza, bo pozwala opisać pełny zakres ważności promocji. Gdy sklep operuje na innym modelu publikacji, trzeba go i tak dopasować do widoczności na stronie.
Jak odróżnić problem w danych strukturalnych od problemu w feedzie Merchant Center?
Jeśli strona pokazuje jedną informację, a markup i feed przekazują inną, problem może leżeć w obu miejscach naraz. Dane strukturalne dotyczą widoku strony i schema.org, a feed jest osobnym kanałem wejściowym do Merchant Center. Rozdzielenie tych warstw pomaga ustalić, czy błąd powstał przy generowaniu treści, czy przy eksporcie danych.
Czy mały sklep też powinien porządkować te pola, jeśli ma tylko kilka produktów?
Tak, bo mały katalog jest łatwiejszy do naprawienia niż duży. Nawet przy kilku produktach niespójność między stroną, feedem i markupiem potrafi wprowadzać zamieszanie, zwłaszcza gdy promocje zmieniają się ręcznie. Porządek na małej skali pozwala też zbudować poprawny wzorzec przed rozbudową oferty.
Jeśli w sklepie kategoria produktu, feed i dane promocji rozjeżdżają się po kilku miejscach, przydatne bywa uporządkowanie modelu danych już na etapie wdrożenia lub przebudowy szablonu. W takich sytuacjach Projektowanie sklepów internetowych pomaga spiąć strukturę oferty z publikacją danych w jednym procesie.
