Produkty z PrestaShop odrzucone w Merchant Center: cena, dostępność i warianty

Gdy Merchant Center odrzuca produkt z powodu ceny lub dostępności, porównaj ten sam wariant w trzech miejscach: danych przetworzonych przez Google, publicznym feedzie i na stronie sklepu. Zapisz również czas odczytu. Plik XML wygenerowany przed promocją może być poprawnym plikiem, ale zawierać nieaktualną ofertę. Z kolei aktualny feed nie pomoże, jeśli link otwiera inny rozmiar albo sklep pokazuje robotowi inną cenę.

Poradnik jest przeznaczony dla osób prowadzących kampanie i zarządzających katalogiem PrestaShop. Skupia się na cenie, dostępności i wariantach. Odrzucenie związane z zasadami konta, weryfikacją firmy czy ograniczeniami sprzedaży wymaga osobnego postępowania.

1. Najpierw zapisz konkretny problem i identyfikator oferty

Otwórz szczegóły odrzuconej oferty w Merchant Center i zapisz treść komunikatu, identyfikator, kraj, język oraz źródło danych. Nazwy sekcji panelu mogą się zmieniać; kluczowe są dane wybranej oferty, a nie miejsce przycisku na zrzucie ekranu.

Nie zaczynaj od eksportu całego sklepu na nowych identyfikatorach. Najpierw ustal, czy problem obejmuje jedną kombinację, produkty promocyjne czy cały feed. Jeżeli wszystkie odrzucone pozycje mają wspólną walutę albo pochodzą z jednego źródła, jest to użyteczna wskazówka. Nie przesądza jednak o przyczynie.

• Wyszukuj po pełnym identyfikatorze, wraz z prefiksem i numerem kombinacji.
• Sprawdź, jakie wartości Google faktycznie przetworzył, nie tylko to, co obecnie zawiera plik.
• Otwórz dokładny adres feedu pobierany przez Merchant Center i odnotuj datę jego wygenerowania.
• Sprawdź źródła uzupełniające i reguły, które mogą zmieniać dane po imporcie.

Znaczenie pól i warunki ich stosowania opisuje oficjalna specyfikacja danych produktów. Użyj jej do rozpoznania wymagań dla swojego asortymentu, kraju i sposobu prezentacji oferty.

2. Porównaj konkretny wariant, nie tylko nazwę produktu

Przykład demonstracyjny: sklep sprzedaje koszulkę w rozmiarach M i L. Produkt ma ID 812, kombinacje odpowiednio 41 i 42. Rozmiar M kosztuje 129 zł i jest dostępny. Rozmiar L kosztuje 139 zł i jest wyprzedany. Feed zawiera osobną ofertę dla każdej kombinacji.

Tutaj poprawny identyfikator grupy nie naprawia trzech innych rozbieżności. Trzeba skorygować cenę, dostępność i link. Google wymaga, aby strona docelowa przedstawiała wariant odpowiadający przesłanej ofercie; szczegóły opisują wymagania dotyczące stron docelowych.

3. Cena: promocja, waluta i kontekst odbiorcy

Porównuj ceny w tym samym kontekście: kraju, walucie i warunkach dostępnych dla kupującego. Cena widoczna po zalogowaniu do uprzywilejowanej grupy klientów nie musi być ceną dla anonimowego użytkownika. Podobnie wartość netto z panelu administracyjnego nie jest właściwym punktem porównania, gdy oferta wymaga ceny z podatkiem.

Przy promocji sprawdź cenę podstawową price, promocyjną sale_price i ewentualny przedział sale_price_effective_date. Upewnij się, że obniżka obowiązuje w chwili wejścia na stronę i nie zależy od warunku, którego oferta nie ujawnia. Nie wpisuj po prostu niższej liczby w XML, jeśli koszyk nadal nalicza więcej. Zasady ceny: Google — atrybut price; zasady promocji: Google — atrybut sale_price.

Jeżeli źródłem problemu jest cennik dostawcy, popraw dane wejściowe i zasady ich aktualizacji. Pomocny będzie istniejący poradnik o aktualizacji cen z CSV. Dopiero potem odśwież feed i sprawdź, czy zmiana dotarła do Google.

4. Dostępność: zero sztuk nie wyjaśnia całej konfiguracji

Sprawdź stan konkretnej kombinacji, możliwość zakupu przy braku towaru i komunikat na stronie. Istotna jest rzeczywista oferta dla kupującego. Dodatni stan zapisany w bazie nie wystarcza, jeśli produkt jest nieaktywny albo nie można go dodać do koszyka.

in_stock, out_of_stock, preorder i backorder mają określone znaczenie. Nie używaj przedsprzedaży jako sposobu ukrycia braków. Dla przedsprzedaży i zamówień oczekujących na dostępność sprawdź wymagania dotyczące terminu oraz zgodność informacji na stronie. Aktualne zasady zawiera dokumentacja atrybutu availability.

Jeśli dane magazynowe przychodzą z zewnętrznego źródła, kontroluj cały łańcuch: aktualizacja źródła → import do sklepu → generowanie feedu → pobranie przez Google. Włączenie częstszego pobierania feedu nie przyspieszy hurtowni, która publikuje nowy stan raz dziennie. Zobacz także poradnik o stanach z CSV.

5. Jak powinien wyglądać fragment XML?

Poniżej są dwa demonstracyjne elementy item dla tego samego modelu. To fragment do porównania ID, ceny, dostępności i rozmiaru, nie kompletny feed gotowy do wysłania. Adresy w domenie example.com są przykładowe. W sklepie użyj linków, które faktycznie otwierają właściwe kombinacje, oraz wszystkich wymaganych atrybutów dla danego produktu.

<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-41</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>Koszulka oliwkowa, M</g:title>
  <g:link>https://example.com/koszulka?variant=41</g:link>
  <g:price>129.00 PLN</g:price>
  <g:availability>in_stock</g:availability>
  <g:color>oliwkowy</g:color>
  <g:size>M</g:size>
</item>
<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-42</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>Koszulka oliwkowa, L</g:title>
  <g:link>https://example.com/koszulka?variant=42</g:link>
  <g:price>139.00 PLN</g:price>
  <g:availability>out_of_stock</g:availability>
  <g:color>oliwkowy</g:color>
  <g:size>L</g:size>
</item>

Warianty mają różne id i wspólne item_group_id. Samo ID sklepu nie musi być numerem GTIN. Nie wpisuj wymyślonego EAN ani nie zastępuj nim identyfikatora oferty. Zasady grupowania opisuje Google — item_group_id.

6. Sprawdź wynik po ponownym pobraniu

1. Popraw dane lub konfigurację odpowiedzialną za rozbieżność.
2. Wygeneruj feed i odczytaj go z jego publicznego adresu.
3. Sprawdź, czy serwer zwraca XML, a nie stronę błędu, ekran logowania lub zabezpieczenie blokujące roboty.
4. Po pobraniu źródła w Merchant Center sprawdź czas przetworzenia i wartości tej samej oferty.
5. Otwórz link bez sesji uprzywilejowanego klienta i skontroluj wariant, cenę oraz możliwość zakupu.
6. Wróć do statusu problemu. Jeśli pozostaje, przeczytaj aktualny komunikat zamiast zakładać, że dotyczy poprzedniej przyczyny.

Automatyczne aktualizacje produktu mogą ograniczać niektóre rozbieżności, ale nie zastępują utrzymywania poprawnego źródła. Dodatkowo skontroluj cenę i dostępność w danych strukturalnych strony: Google — obsługiwane dane strukturalne.

7. Rzeczywista próba: link wariantu w feedzie PrestaDev

27 września 2026 sprawdziliśmy zachowaną kopię publicznego pliku google-merchant_id-1.xml sprzed poprawki (nagłówek Last-Modified: 26.09.2026, 18:54:27 GMT) i otworzyliśmy strony docelowe bez logowania. Kopia zawierała 360 ofert i 181 różnych linków. Przy 166 linkach kilka wariantów miało różne ceny w feedzie. To był sygnał do kontroli tych adresów, a nie liczba potwierdzonych odrzuceń w Merchant Center. Bieżący plik pod podanym adresem został później wygenerowany ponownie.

W tej próbie adres produktu z id_product_attribute=409 zwrócił HTTP 200, wybrał opcję przedłużenia i pokazał 247 zł zarówno w widocznej cenie, jak i metadanych ceny. Adres dla 408 wybrał pełną licencję i 492 zł. Wartości odczytano z początkowego HTML; nie wykonywano zakupu.

Wniosek z próby: poprawne g:id, g:item_group_id i cena nie wystarczają, gdy g:link nie wybiera sprzedawanego wariantu. Google zaleca wstępne wybranie właściwego wariantu w linku i zgodność ceny widocznej na stronie docelowej z danymi oferty. g:canonical_link może nadal prowadzić do bazowego adresu produktu bez wyboru wariantu.

Wynik po poprawce 27.09: zaktualizowaliśmy generator do wersji 2.11.1 i ponownie wygenerowaliśmy ten sam publiczny feed. Zachował 360 identyfikatorów ofert, a każdy z 346 wariantów ma teraz własny link z identyfikatorem kombinacji. Ponowny anonimowy odczyt sześciu ofert, w tym 60-408 i 60-409, potwierdził wybraną opcję oraz cenę widoczną i w metadanych strony; dla 60-409 jest to 247 zł. Kanoniczny adres nadal wskazuje bazową kartę produktu. To potwierdza publiczny XML i sprawdzone strony, ale nie mówi, czy Merchant Center pobrał już nowy plik ani czy dane oferty zostały tam zaakceptowane. Sprawdź status tych samych ID w swoim koncie po następnym przetworzeniu źródła.

Aktualizacja 27.09 po wykluczeniu pozycji prowizyjnej: Z pliku usunięto niemodułowy produkt 144 („Prowizja za płatność przez PayPal”) z wariantami 144-476 i 144-477. Bieżący publiczny XML ma 358 ofert i 344 warianty z osobnym linkiem. Liczby 360/346 powyżej opisują stan próby przed tym wykluczeniem. Sam odczyt XML nie potwierdza jeszcze pobrania ani akceptacji źródła w Merchant Center.

Kiedy przyda się Google Shopping Pro?

Google Shopping Pro generuje dane produktowe z PrestaShop. W sprawdzonym kodzie wersji 2.11.1 znajdują się ścieżki eksportu kombinacji, identyfikatorów grup, cen oraz cen promocyjnych. To narzędzie do przygotowania źródła; nie rozstrzyga wszystkich problemów konta Merchant Center i nie gwarantuje zatwierdzenia produktów.

Potrzebujesz uporządkowanego feedu? Sprawdź Google Shopping Pro. Jeśli problem obejmuje również stronę, kombinacje lub dane z integracji, przygotuj identyfikator przykładowej oferty, dokładny komunikat i trzy porównywane wartości do analizy integracji sklepu.

Weryfikacja merytoryczna: 27 września 2026. Przykład koszulki i jej XML są demonstracyjne. Próba 60-408/60-409 obejmuje kopię pliku PrestaDev sprzed poprawki oraz nowy plik i strony odczytane 27.09; nie potwierdza odrzucenia ani akceptacji w koncie Merchant Center. Zakres modułu sprawdzono w kodzie i publicznym XML, a znaczenie atrybutów w dokumentacji Google.

8. Co jeszcze sprawdzić w grupach wariantów feedu?

27.09.2026 sprawdziliśmy bieżący publiczny feed PrestaDev po wcześniejszej korekcie linków wariantów. Odczyt obejmował 358 ofert z pliku google-merchant_id-1.xml. Każda oferta miała item_group_id, ale feed nie zawierał pól item_group_title, variant_option ani standardowych atrybutów wariantów takich jak color, size, material albo pattern. To jest sygnał do kontroli jakości danych, nie potwierdzona przyczyna odrzuceń w Merchant Center.

Przykład produktu 60 pokazuje, dlaczego sama wspólna grupa nie wystarcza do decyzji. W odczycie z 27.09.2026 oferta 60-408 była pełną licencją za 492 PLN, a 60-409 przedłużeniem dostępu do aktualizacji za 247 PLN. To ceny z historycznej próbki, nie bieżący cennik. Oferty miały osobne ID i działające linki z parametrem wariantu, ale wspólny item_group_id=60. Trzeba ustalić, czy są to prawdziwe warianty jednej oferty, czy osobne warunki zakupu. Dopiero wtedy przygotować mały pilot: uzupełnić właściwą nazwę opcji dla prawdziwych wariantów albo rozdzielić oferty, które wariantami nie są.

Przy ocenie grup porównaj dane z oficjalnymi wymaganiami Google dla item_group_id. Sama obecność wspólnego identyfikatora nie potwierdza prawidłowego opisania wariantów.

Ten odczyt nie obejmował statusu konta Merchant Center. W opisanym etapie próba accounts.list zwróciła HTTP 403 PERMISSION_DENIED; nie jest to stwierdzenie o dzisiejszych uprawnieniach konta. Ostateczną diagnozę trzeba oprzeć na panelu Merchant Center albo osobno skonfigurowanym Merchant API oraz na statusie tych samych identyfikatorów ofert po przetworzeniu nowego źródła.