Magazyn i baza wiedzy / SEO

Merchant Center: odrzucony produkt przez cenę lub dostępność

Sprawdź dokładnie jedną odrzuconą ofertę w Merchant Center: feed, cenę, dostępność, wybrany wariant, URL produktu i techniczne dane Offer.

Autor: Kiljano · Aktualizacja: · Czas czytania: 12 min

Odrzucenie produktu w Google Merchant Center z powodu ceny lub dostępności najlepiej diagnozować na poziomie jednej konkretnej pozycji. Ten poradnik pokazuje, jak porównać feed, URL, domyślny wariant, widoczny stan magazynowy oraz dane Product/Offer. Dwa przykłady i tabela prowadzą od objawu do właściwej kontroli.

Co dokładnie oznacza odrzucenie produktu w Merchant Center?

Produkt może być oznaczony w Google Merchant Center jako odrzucony, mimo że jego karta w sklepie wyświetla prawidłowe zdjęcie, cenę i przycisk zakupu. Wyjaśnienie zwykle kryje się w różnicy między kilkoma wersjami informacji o tej samej ofercie. Google otrzymuje konkretną pozycję z identyfikatorem, adresem strony docelowej, ceną, walutą i dostępnością. Strona może natomiast pokazywać całą rodzinę wariantów, cenę promocyjną albo dane techniczne zaktualizowane w innym czasie.

Najpierw otwórz w Merchant Center konkretną pozycję w obszarze produktów wymagających uwagi. Przeczytaj dokładną przyczynę problemu. Ostrzeżenie nie jest tym samym co odrzucenie oferty, a problem pojedynczego produktu nie jest automatycznie problemem całego konta. Również niezgodność ceny i niezgodność dostępności wymagają odmiennych dowodów. Jeżeli komunikat dotyczy brakującego atrybutu lub niedostępnej strony, trzeba sprawdzić właśnie ten obszar zamiast szukać na siłę różnicy w kwocie.

Zapisz identyfikator pozycji, źródło danych, kraj docelowy oraz nazwę pola, którego dotyczy zgłoszenie. Skup się na jednym konkretnym wariancie. Bez tych informacji ponowny eksport całego asortymentu zwykle nie wskazuje przyczyny. Ten sam produkt może mieć różne oferty dla poszczególnych krajów, języków i walut. Porównuj więc wersję sklepu rzeczywiście przypisaną do zgłoszonej pozycji.

Najważniejsze pytanie brzmi: jaki wariant zobaczy klient po wejściu w dokładny link przekazany Google, jaką cenę zobaczy i czy zdoła go kupić? Nie wystarczy sprawdzenie, czy rodzina produktu istnieje w katalogu. Zdjęcie, ogólny tytuł i stan magazynowy produktu nadrzędnego nie zawsze odpowiadają wariantowi z konkretnego wiersza feedu.

Rozdziel problem ceny od problemu dostępności. Karta może pokazywać właściwą cenę, ale wariant jest wyprzedany i w danych nadal ma in_stock. Innym razem towar jest faktycznie dostępny, jednak feed zachował wcześniejszą cenę promocyjną. Precyzyjna diagnoza wskazuje wartość, miejsce niezgodności i dokładną ofertę, której dotyczy.

Zacznij od identyfikatora pozycji, wariantu i kraju docelowego

Produkty z wariantami wymagają szczególnej uwagi. Buty w rozmiarach 40, 41 i 42 należą do tego samego modelu, lecz mogą mieć różne stany magazynowe. Koszulka w dwóch kolorach może też mieć różną cenę. Jeśli w feedzie każdy wariant ma własną pozycję, nie wolno zastępować kontroli tej pozycji spojrzeniem na wspólną kartę produktu nadrzędnego.

Skopiuj URL bezpośrednio z danych zgłoszonego artykułu. Otwórz go w zwykłym oknie przeglądarki, bez logowania do zaplecza sklepu. Zwróć uwagę na domyślnie wybrany rozmiar, kolor, pakiet lub inną cechę. Jeśli feed dotyczy rozmiaru XL, a link wybiera automatycznie M, oglądasz inny wariant. Widoczna cena i komunikat o stanie magazynowym mogą być poprawne dla M, ale nie są dowodem poprawności oferty XL.

Zanotuj item-ID, ewentualne item_group_id, wybrane cechy, walutę, kraj docelowy i stan selektora zaraz po załadowaniu strony. Przy linkach zawierających parametry sprawdź, czy parametr rzeczywiście aktywuje właściwy wariant. Jeśli każdy wariant ma osobny adres, zweryfikuj pełną ścieżkę. Nazwa produktu i główne zdjęcie nie wystarczają do identyfikacji konkretnej pozycji.

Przetestuj następnie realną możliwość zakupu. Czy dla domyślnie wybranej opcji działa przycisk dodania do koszyka? Czy komunikat o dostępności zmienia się po przełączeniu wariantu? Czy zmiana rozmiaru lub koloru aktualizuje również cenę? Takie sprawdzenie pozwala odróżnić problem jednego wariantu od ogólnego błędu szablonu strony.

W sprzedaży na różne rynki sprawdzaj wersję faktycznie przeznaczoną dla danego kraju. Cena wyświetlana w polskim sklepie nie musi odpowiadać ofercie kierowanej na inny rynek. Diagnoza nie polega na ujednolicaniu wszystkich sklepów narodowych, lecz na upewnieniu się, że konkretny feed, link, waluta i strona docelowa opisują tę samą ofertę.

Użyteczna notatka z tej fazy zawiera kilka pól: identyfikator, wariant z feedu, wariant otwarty przez URL, widoczna cena, dostępność i stan przycisku zakupu. Z takim zestawem łatwiej przejść do źródła problemu niż z samym zrzutem ekranu strony głównej sklepu.

Porównaj feed, cenę na stronie, stan magazynowy i dane Offer

Porównaj pięć reprezentacji danych jednej oferty: cenę i stan w głównym systemie sklepu, wyeksportowany wiersz feedu, wariant wybrany po otwarciu linku, informacje widoczne dla zwykłego klienta oraz ewentualne dane strukturalne Product/Offer. Wszystkie elementy powinny przedstawiać tę samą pozycję, a nie podobny produkt lub jego sąsiedni wariant.

Przy cenie zweryfikuj wartość price, walutę, regularną cenę i sale_price, jeśli trwa promocja. Rabat może już działać na stronie, podczas gdy feed został wygenerowany wcześniej. Może być też odwrotnie: kampania zakończyła się w sklepie, a stara kwota pozostała w pliku. Przy cenach od–do upewnij się, że porównujesz kwotę dla wybranego wariantu, nie dla całej rodziny produktów.

Przy dostępności odczytaj availability oraz zachowanie przycisku koszyka dla tego wariantu. In_stock opisuje inną możliwość zakupu niż out_of_stock. Osobno występują stany preorder i backorder odpowiadające określonym modelom sprzedaży. Jeżeli wybrany rozmiar nie może zostać zamówiony, sama dostępność innego rozmiaru nie uzasadnia oznaczenia go jako dostępnego.

Kolejny krok to sprawdzenie danych publikowanych w kodzie strony. Blok Offer może zawierać price, priceCurrency i availability. Zdarza się, że motyw wyświetla już nową cenę, lecz JSON-LD nadal zawiera poprzednią. Test wyników z elementami rozszerzonymi Google pomaga odczytać opublikowane dane strukturalne. Nie zastępuje jednak porównania prawdziwej strony produktu z konkretnym wierszem danych.

Przy każdym wyniku zanotuj czas pomiaru. Stan sklepu po porannej sprzedaży może różnić się od nocnego eksportu. Jeśli cena zmieniła się o 9:00, a plik powstał o 6:00, wiadomo, skąd może pochodzić różnica. Kiedy wartości rozjeżdżają się także po kolejnych aktualizacjach, warto prześledzić, które moduły generują feed, HTML i dane strukturalne.

Zamiast ogólnej informacji „cena nie zgadza się”, stwórz konkretne porównanie: „pozycja czarny-XL: feed 49,00 EUR, karta po wybraniu XL 54,00 EUR, znacznik Offer 49,00 EUR”. Takie zestawienie pokazuje, który poziom wymaga weryfikacji. Nie przypisuj znalezionej przyczyny do całego katalogu, dopóki nie porównasz innych pozycji w podobny sposób.

Tabela diagnostyczna: objaw, kontrola i następne działanie

ObjawCo porównaćNastępny krokDowód poprawności
Różnica cenyprice, waluta, aktywny wariant i cena na PDPPopraw źródło danych ofertyTa sama kwota dla tej samej pozycji w feedzie i na stronie
Niezgodna promocjaregularna cena, sale_price i okres promocjiZsynchronizuj moment aktualizacjiAktywna promocja i pola feedu opisują tę samą ofertę
Niezgodna dostępnośćstan wariantu, availability i przycisk koszykaUaktualnij status konkretnego wariantuWskazany wariant można kupić zgodnie z deklaracją
Zły wariant po wejściuitem-ID, link i domyślnie wybrana opcjaPopraw adres lub wybór wariantuLink otwiera właściwy produkt i odpowiednią opcję
Widok wygląda dobrzeHTML, JSON-LD, cache i znaczniki czasuZnajdź przestarzałą reprezentację danychWidoczna strona i Offer przekazują aktualne dane
Inny powód odrzuceniaDokładna treść komunikatu Merchant CenterSprawdź właściwe wskazane poleStatus i jego przyczyna są ponownie odczytane

Tabela służy do kontroli jednego artykułu, a nie masowej zamiany danych. Jeśli problem powtarza się dla kilku wariantów, zachowaj rozdzielenie identyfikatorów. Błąd linku może dotyczyć tylko jednego rozmiaru, natomiast nieaktualny eksport promocji może obejmować wiele towarów. Zakres działania wynika z dowodu, nie z samej liczby zgłoszeń.

Najpierw popraw wartości decydujące o zakupie: wybraną ofertę, cenę i stan. Potem zweryfikuj synchronizację oraz dane techniczne. Ponowne wysłanie identycznego feedu nie naprawi niewłaściwego wariantu docelowego, a dopisanie tekstu obok ceny nie usunie starej wartości w JSON-LD.

Przykład 1: cena promocyjna na stronie, starsza cena w feedzie

Przykład całkowicie fikcyjny. Sklep z lampami oferuje biurkową lampę w kolorze czarnym i białym. Czarny wariant kosztuje regularnie 89 €, ale podczas promocji jest oferowany za 79 €. Na stronie wybrana jest wersja czarna i widnieje 79 €. Feed wygenerowany przed uruchomieniem rabatu nadal zawiera 89 € dla tej konkretnej pozycji. Wersja biała pozostaje w regularnej cenie 89 €. Wszystkie kwoty są wyłącznie ilustracją sposobu sprawdzenia, nie danymi rzeczywistego sklepu.

W Merchant Center przy czarnej lampie pojawia się komunikat o niezgodnej cenie. Sprzedawca kopiuje identyfikator i adres docelowy z wiersza oferty. Sprawdza, czy link naprawdę wybiera czarną lampę, odczytuje kwotę widoczną dla niezalogowanego klienta, a następnie porównuje price i sale_price w feedzie z trwającą promocją. W ten sposób wykrywa różnicę między starym plikiem a aktualną ofertą.

Poprawka powinna dotyczyć miejsca, z którego obie reprezentacje czerpią dane. Ważne są cena regularna, aktualna promocyjna oraz moment rozpoczęcia i zakończenia akcji. Samo wizualne nadpisanie kwoty w motywie nie usuwa przyczyny, jeśli eksport nadal pobiera poprzednią wartość. Celem jest zgodna informacja dla tej samej oferty we wszystkich kanałach.

Po zmianie sprzedawca otwiera link ponownie. Jeżeli przypadkiem wybrała się biała lampa, pojawia się osobny problem wariantu. Kwoty mogą być wtedy poprawne dla innego towaru. Trzeba więc porównać identyfikator, domyślną opcję, wyświetloną cenę i ewentualne dane Product/Offer. Podobne zdjęcie lub wspólny tytuł nie zastępują identyfikacji czarnej wersji.

Na zakończenie należy sprawdzić świeżą pozycję w feedzie, publiczną stronę i stan zgłoszenia w Merchant Center. Aktualizacja źródła oraz przetworzenie i ponowna ocena po stronie Google są odrębnymi etapami. Zapisz czas zmiany i wartości przed oraz po, żeby kolejna kontrola odnosiła się do tego samego produktu i okresu.

Przykład wskazuje również ważną zasadę operacyjną: promocji nie warto utrzymywać niezależnie w kilku systemach, które nie znają swoich zmian. Jeden odpowiednio zsynchronizowany stan produktu ułatwia zarówno prawidłową prezentację ceny klientom, jak i przygotowanie danych do Merchant Center.

Przykład 2: wyprzedany rozmiar przy pozornie dostępnym produkcie

Drugi przykład całkowicie fikcyjny. Sklep obuwniczy sprzedaje model butów w rozmiarach 40, 41 i 42. Rozmiary 40 i 41 są dostępne, ale 42 został wyprzedany. Karta całego modelu nadal pokazuje „dostępny”, bo inne rozmiary można kupić. W feedzie pozycja dla rozmiaru 42 ma jednak availability in_stock, a podany link otwiera stronę z wybranym domyślnie rozmiarem 41.

Sprzedawca wybiera z Merchant Center wiersz dotyczący rozmiaru 42. Otwiera dokładny adres i zapisuje, że aktywna jest opcja 41. Po ręcznym przełączeniu na 42 widzi wyłączony przycisk zakupu. Otrzymuje więc dowód na dwie niespójności: link wskazuje inną wersję niż oferta, a feed deklaruje dostępność wariantu, którego nie da się zamówić.

Poprawka musi działać na poziomie rozmiaru 42: właściwy status magazynowy, odpowiedni link i informacja widoczna po otwarciu strony. Jeśli w kodzie nadal znajduje się Offer z InStock dla wyprzedanej wersji, należy go powiązać z aktualnym stanem wariantu. Uzupełnienie kosmetycznego komunikatu obok nieaktywnego przycisku nie wystarczy, jeżeli dane techniczne mówią coś innego.

Odróżnij brak magazynowy od przedsprzedaży lub zamówienia z późniejszą realizacją. Każdy z tych stanów opisuje inną możliwość zakupu i powinien wynikać z faktycznego modelu sprzedaży. Nie warto ustawiać wszystkich produktów jako in_stock wyłącznie po to, aby stale wyświetlały aktywny przycisk. Klient musi wiedzieć, którą wersję i w jakim trybie zamawia.

Po korekcie rozmiaru 42 trzeba sprawdzić rozmiar 41. Jeżeli pozostaje dostępny, powinien nadal mieć działający zakup. Oznaczenie całej rodziny butów jako out_of_stock spowodowałoby nowy błąd. Kontrola sąsiedniego wariantu pozwala upewnić się, że korekta nie objęła produktów, które nie były problematyczne.

Ta sama metoda dotyczy odzieży, kolorów urządzeń, mebli z opcjami i zestawów. Tam, gdzie klient wybiera wykonanie, ocena dostępności powinna zawsze dotyczyć dokładnego wariantu z odpowiedniego wiersza danych.

Synchronizacja, dane strukturalne i kontrola po poprawce

Różnica może wynikać z opóźnienia między sklepem a kanałem danych. Sprzedaż zmniejsza dostępny stan w sklepie, a feed jest eksportowany dopiero wieczorem. Promocja kończy się w CMS, podczas gdy zewnętrzny system nadal przechowuje starszą kwotę. Zapisz trzy momenty: aktualizację produktu, utworzenie feedu i ostatnie przetworzenie pozycji przez Merchant Center. Ta chronologia pozwoli ustalić, który etap jest opóźniony.

Osobnej kontroli wymagają cache oraz treści tworzone przez skrypty. Cena może pojawić się dopiero po wykonaniu JavaScript, podczas gdy HTML wysyła wcześniej inną informację. Czasem widoczny tekst jest już prawidłowy, ale blok JSON-LD zachował stary Offer. Porównaj kod strony i finalny widok odwiedzającego. Jeśli są różne, należy wskazać komponent, który przygotowuje daną wartość.

W sprzedaży międzynarodowej trzymaj się tego samego kraju docelowego od początku do końca. Oferta przeznaczona dla jednego rynku może mieć inną walutę i dostępność od wersji krajowej obok. Nie oceniaj feedu przeznaczonego na Polskę według przypadkowej zagranicznej strony. Zmiany uzależnione od IP lub sesji również mogą utrudnić odtworzenie warunków, które widzi system pobierający.

Po poprawieniu danych wróć do konkretnej pozycji w sekcji wymagającej uwagi w Merchant Center. Sprawdź aktualną przyczynę i dostępne działanie dla tego rodzaju problemu. Wysłanie nowego pliku, jego przetworzenie i zmiana statusu oferty są osobnymi etapami. Dopiero ponowne porównanie aktualnych wartości pokazuje, czy dane źródłowe i strona opisują spójną ofertę.

Oficjalne materiały Google omawiają niezgodność cen, niezgodność dostępności i problemy poszczególnych produktów w Merchant Center. W kontekście wariantów przydatny jest także dokument Google Search Central o ProductGroup.

Sprawdź Diagnostykę feedu Merchant Center. Przy rozbieżnościach w pliku źródłowym przydaje się Analiza XML/CSV hurtowni, a dla wielowariantowych produktów dostępne jest Sprawdzenie wariantów.

Najczęstsze pytania o różnice cen i dostępności

Dlaczego odrzucono tylko jeden wariant, skoro karta produktu działa?

Merchant Center ocenia konkretną ofertę. Jeden rozmiar lub kolor może mieć inną cenę, URL albo status magazynowy niż pozostałe wersje. Zacznij od identyfikatora i linku przypisanego właśnie do odrzuconej pozycji.

Czy przy niezgodnej cenie trzeba od razu poprawiać XML?

Najpierw porównaj feed, wariant otwarty z linku, widoczną cenę, walutę i dane Offer. Źródłem różnicy może być stara promocja, niewłaściwy wariant albo technicznie nieaktualna strona. Dopiero wtedy wiadomo, które miejsce wymaga korekty.

Jak sprawdzić cenę regularną i sale_price?

Porównaj kwotę regularną z aktualną promocją dla tego samego wariantu, uwzględnij termin obowiązywania oferty i walutę. Upewnij się, że na stronie docelowej wybierana jest właściwa opcja.

Co oznacza in_stock, gdy tylko jeden rozmiar jest dostępny?

Sprawdź, którego rozmiaru dotyczy wpis w feedzie. Jeśli reklamowany wariant jest wyprzedany, stan innego rozmiaru nie czyni go dostępnym. Oceń przycisk zakupu i status availability tej konkretnej pozycji.

Czy zły link wariantu może powodować rozbieżność ceny?

Tak. Feed może opisywać droższą wersję, a strona domyślnie otwierać tańszą. Porównaj identyfikator, parametr wariantu i widoczną cenę aktywnej opcji.

Po co sprawdzać dane strukturalne Product/Offer?

Dane strukturalne mogą zawierać odrębnie publikowane wartości price, priceCurrency i availability. Porównaj je z kartą widoczną dla klienta oraz feedem, aby wykryć przestarzałe informacje techniczne.

Co zrobić po usunięciu niezgodności?

Otwórz dokładną stronę docelową i aktualną pozycję źródła danych, sprawdź cenę, wariant oraz dostępność, a następnie odczytaj nowy status tego artykułu w Merchant Center. Zachowaj identyfikator i wynik porównania.

Ładowanie...
Powrót do góry