Specyfikacja feedu produktowego: wymagania Google Merchant Center

Specyfikacja feedu produktowego to zbiór technicznych i merytorycznych wytycznych określających strukturę danych o asortymencie, które muszą zostać dostarczone do Google Merchant Center, aby umożliwić wyświetlanie reklam produktowych (PLA) oraz bezpłatnych wyników zakupowych. Jest to ustandaryzowany język komunikacji między bazą danych sklepu internetowego a algorytmami Google, decydujący o tym, czy dany produkt zostanie w ogóle dopuszczony do aukcji reklamowej oraz na jakie zapytania się wyświetli.

Precyzyjne odwzorowanie tych wymagań nie jest jedynie kwestią techniczną, lecz fundamentem efektywności sprzedażowej. W mojej pracy z audytami kont e-commerce wielokrotnie obserwuję, że nawet najlepiej skonfigurowane kampanie Performance Max czy standardowe kampanie produktowe nie przynoszą oczekiwanych rezultatów, jeśli źródło danych - czyli feed - zawiera błędy strukturalne lub braki w atrybutach. Google Merchant Center (GMC) nie służy tylko do przechowywania produktów; to zaawansowany walidator, który weryfikuje wiarygodność oferty i dopasowuje ją do intencji zakupowych użytkowników. Zrozumienie każdego atrybutu to pierwszy krok do skalowania sprzedaży.

Skrót artykułu

Co warto wiedzieć

Wnioski, które decydują o tym, czy oferty ze sklepu w ogóle wejdą do aukcji Merchant Center.

• Google identyfikuje ofertę po GTIN i marce, nie po samej nazwie produktu

  Produkty fabrycznie nowe wymagają atrybutów gtin oraz brand. Bez nich oferta nie trafia na karty produktów grupujące sprzedawców i gorzej dopasowuje się do zapytań o konkretny model. Dla rękodzieła i marek własnych sklepu służy identifier_exists ustawione na no.

• Content API for Shopping przestało działać 18 sierpnia 2026 roku

  Integracje programistyczne z Merchant Center obsługuje wyłącznie Merchant API. Sklepy korzystające z wtyczek i gotowych integracji migrację mają po stronie dostawcy, ale własny konektor napisany na Content API przestał synchronizować dane produktowe.

• Rozbieżność ceny między feedem a stroną produktu grozi zawieszeniem konta Merchant Center

  Robot Google wchodzi na stronę docelową jak zwykły użytkownik i porównuje cenę z wartością w pliku danych. Pojedyncza różnica kończy się odrzuceniem oferty, powtarzalna - blokadą za Misrepresentation. Automatyczne aktualizacje elementów tylko łagodzą ryzyko.

• Zmiana atrybutu id kasuje historię skuteczności produktu w kampaniach Google Ads

  Identyfikator musi pozostać ten sam przez cały cykl życia oferty, najlepiej spięty z SKU z systemu magazynowego i mieszczący się w 50 znakach. Losowe generowanie id przy każdym eksporcie pliku wpycha produkt w ponowną fazę uczenia algorytmu.

• Google dopuszcza w atrybucie title 150 znaków, ale pokazuje zwykle 70 pierwszych

  Limit 150 znaków i próg widoczności około 70 znaków podaje dokumentacja Merchant Center (stan na 2026 rok), dlatego markę, model i cechę różnicującą wpisuj na początku. Nazwa skopiowana ze sklepu poza kontekstem kategorii zwykle nie wystarcza.

• Przepisanie tytułów plikiem uzupełniającym podniosło CTR kampanii produktowej o 64%

  W sklepie z częściami motoryzacyjnymi, który audytowałem, przepisanie 340 tytułów plikiem uzupełniającym z kolumnami id oraz title podniosło CTR kampanii produktowej z 1,4% do 2,3% w pięć tygodni. Katalog sklepu i jego wyniki organiczne zostały nietknięte.

Czym dokładnie jest plik danych o produktach w ekosystemie Google?

Plik danych o produktach, powszechnie nazywany feedem, stanowi kręgosłup każdej kampanii e-commerce w środowisku Google. Technicznie rzecz biorąc, jest to plik o określonej strukturze, w którym każdy wiersz reprezentuje osobny wariant produktu, a każda kolumna odpowiada konkretnemu atrybutowi opisującemu ten produkt. Jakość tych danych jest bezpośrednio skorelowana z wynikiem jakości (Quality Score) w kampaniach produktowych.

Algorytmy Google nie „widzą” produktów tak, jak widzi je człowiek przeglądający sklep. One „czytają” atrybuty. Im precyzyjniej te dane są sformatowane zgodnie z oficjalną specyfikacją, tym łatwiej systemowi zrozumieć, co sprzedajesz i komu warto to pokazać. Błędem jest traktowanie feedu jako jednorazowej konfiguracji „ustaw i zapomnij”. To żywy organizm, który wymaga ciągłej optymalizacji w odpowiedzi na zmieniające się trendy wyszukiwania i aktualizacje wymagań platformy.

Warto rozdzielić dwa pojęcia, które w rozmowach o pliku produktowym dla Google zlewają się w jedno. Specyfikacja to dokument opisujący, jakie atrybuty istnieją i jakie wartości przyjmują. Źródło danych to konkretna instancja pliku podpięta pod konto: arkusz, adres URL albo integracja programistyczna. Można mieć poprawną specyfikację i błędnie skonfigurowane źródło - efekt w Diagnostyce będzie ten sam.

Jakie formaty plików obsługuje Merchant Center?

Google Merchant Center jest elastycznym narzędziem, akceptującym kilka standardów przesyłu danych. Wybór odpowiedniego formatu zależy zazwyczaj od wielkości asortymentu (SKU) oraz możliwości technicznych platformy sklepowej.

• Formaty tekstowe (TXT, CSV, TSV): Są to najczęściej stosowane formaty, szczególnie w mniejszych i średnich sklepach. Ich zaletą jest prostota - plik można otworzyć i edytować w dowolnym arkuszu kalkulacyjnym (np. Excel czy Google Sheets). Wymagają jednak ścisłego przestrzegania separatorów (np. przecinek lub tabulator), aby struktura kolumn nie uległa rozsypaniu.
• XML (Extensible Markup Language): Format preferowany przy większych zbiorach danych oraz w sytuacjach, gdy struktura informacji jest bardziej złożona (np. zawiera wiele wartości dla jednego atrybutu). XML jest mniej czytelny dla ludzkiego oka, ale znacznie bezpieczniejszy z punktu widzenia integralności danych przesyłanych między serwerami.
• Arkusz Google: Wariant pośredni, w którym plikiem danych jest po prostu arkusz kalkulacyjny podpięty do konta. Zmiana wartości w komórce wchodzi do Merchant Center po najbliższym pobraniu, bez generowania i wysyłania czegokolwiek z serwera sklepu.

Czym zastąpić Content API po wyłączeniu 18 sierpnia 2026?

Jedyną drogą programistycznej integracji z Merchant Center jest dziś Merchant API. Content API for Shopping zostało wyłączone 18 sierpnia 2026 roku, a jego następca przejął zarówno zarządzanie produktami, jak i ustawienia konta, wysyłki oraz raportowanie. Integracje oparte na starym interfejsie przestały synchronizować dane.

Zmiana nie dotyczy jednak wszystkich sklepów w równym stopniu. Google w przewodniku migracyjnym rozstrzyga to wprost: sprzedawca korzystający z zewnętrznego dostawcy technologii, na przykład aplikacji Google & YouTube w Shopify, nie musi robić nic - migrację przeprowadza dostawca. Obowiązek spada wyłącznie na te sklepy, które mają własny konektor napisany przez zespół programistyczny.

Praktyczna konsekwencja jest taka, że pytanie „czy wdrożyć API” przestało być pytaniem o przewagę, a stało się pytaniem o skalę. Merchant API pozwala aktualizować pojedyncze rekordy, więc cena zmieniona w sklepie o 14:00 może trafić do reklam w ciągu minut, a nie po nocnym pobraniu pliku. Dla sklepu z kilkuset produktami i stabilnym cennikiem ta różnica nie zwraca kosztu wdrożenia. Dla sklepu przeceniającego setki pozycji w ciągu doby - zwraca się w pierwszym tygodniu, głównie przez uniknięcie odrzuceń za niezgodność ceny.

Który sposób dostarczania feedu wybrać przy jakiej skali?

Sposób dostarczania pliku dobiera się do liczby SKU i tempa zmian cen, nie do wielkości firmy. Poniższe progi to moja robocza heurystyka z audytów kont sklepowych, a nie wymóg zapisany w specyfikacji Google - traktuj je jako punkt wyjścia do rozmowy z zespołem technicznym.

Najczęstszy błąd wyboru, który widzę na kontach, to przeskok z arkusza prosto do integracji programistycznej z pominięciem środkowej kolumny. Plik generowany przez sklep i pobierany z adresu URL obsługuje większość katalogów w polskim e-commerce, kosztuje kilka dni pracy i nie wymaga utrzymywania konektora. Do Merchant API przechodzi się wtedy, gdy nocne pobranie realnie nie nadąża za zmianami stanów magazynowych.

Jakie atrybuty produktu są bezwzględnie wymagane do akceptacji pliku?

Specyfikacja Google dzieli atrybuty na wymagane i opcjonalne. Brak atrybutu wymaganego skutkuje błędem krytycznym i wykluczeniem produktu z aukcji. Poniżej omawiam te, które stanowią absolutny fundament każdego feedu.

Budowa pliku danych

Wiersz feedu - z czego składa się jedna oferta

Jeden wiersz to jeden wariant produktu. Atrybuty dzielą się na cztery grupy, a brak choćby jednej z trzech pierwszych blokuje ofertę w aukcji.

WIERSZ PLIKU DANYCHJeden wariant produktu w Merchant Center

Identyfikacja

Atrybuty id, gtin, brand oraz mpn. Mówią Google, jaki dokładnie przedmiot sprzedajesz, i pozwalają zestawić ofertę z ofertami innych sprzedawców na jednej karcie produktu.

Treść ofertowa

Atrybuty title, description i image_link. Decydują o dopasowaniu do zapytania i o klikalności reklamy w wynikach zakupowych, bo to je widzi użytkownik.

Warunki handlowe

Atrybuty price, availability oraz shipping. Muszą zgadzać się ze stroną docelową, bo Google weryfikuje je automatycznym skanem karty produktu.

Klasyfikacja biznesowa

Atrybuty google_product_category, product_type i custom_label. Nie są wymagane do akceptacji oferty, ale bez nich nie posterujesz budżetem na poziomie grup produktów.

Jak poprawnie skonstruować atrybut ID?

Atrybut id [identyfikator] to unikalny ciąg znaków przypisany do konkretnego produktu lub jego wariantu.

ID (identyfikator): Musi być unikalny w obrębie całego konta i niezmienny w czasie.

Częstym błędem, który obserwuję, jest generowanie ID w sposób losowy przy każdym generowaniu pliku lub zmiana ID po ponownym zaimportowaniu produktów do sklepu. Konsekwencje są poważne: zmiana ID powoduje, że Google traktuje produkt jako zupełnie nowy. Tracisz całą historię skuteczności, wynik jakości i zebrane dane historyczne, co zmusza algorytm do ponownej nauki (faza learningu) i przepalania budżetu. Dobre ID powinno być powiązane z SKU (Stock Keeping Unit) z systemu magazynowego, np. PL-12345. Maksymalna długość to 50 znaków.

W jaki sposób optymalizować atrybut Title pod intencje wyszukiwania?

Atrybut title [tytuł] jest, obok ceny i zdjęcia, najważniejszym czynnikiem wpływającym na CTR (współczynnik klikalności) oraz dopasowanie do zapytań użytkowników.

Title (tytuł): Musi precyzyjnie opisywać produkt, zawierając słowa kluczowe, których użytkownicy używają w wyszukiwarce, z limitem do 150 znaków.

Optymalizacja tytułu nie polega na skopiowaniu nazwy ze sklepu. W sklepie nazwa „Czarna Sukienka” może wystarczyć, bo użytkownik widzi kategorię. W Google Zakupy produkt jest wyrwany z kontekstu. Tytuł musi być autonomiczny.

Struktura tytułu powinna zależeć od kategorii:

• Elektronika: Marka + Model + Specyfikacja (np. RAM, Dysk) + Kolor.
• Odzież: Marka + Płeć + Rodzaj produktu + Cechy szczególne + Kolor + Rozmiar.
• Części zamienne: Rodzaj części + Marka pojazdu + Model + Zakres roczników + Numer katalogowy.

Zgodnie z dokumentacją Merchant Center użytkownicy widzą zwykle tylko do 70 pierwszych znaków tytułu. Dlatego kluczowe informacje muszą znaleźć się na początku. Nie pisz „Wspaniała i wygodna kurtka zimowa marki X”, lecz „Kurtka zimowa X, Puchowa, Czarna, Męska”.

W jednym z audytowanych przeze mnie sklepów z częściami motoryzacyjnymi przepisanie 340 tytułów według schematu „rodzaj części + marka pojazdu + model + rocznik” podniosło CTR kampanii produktowej z 1,4% do 2,3% w ciągu pięciu tygodni, przy niezmienionym budżecie i tej samej strukturze kampanii. To obserwacja z jednego konta, nie benchmark rynkowy, ale kierunek powtarza się na tyle regularnie, że tytuły audytuję zawsze jako pierwsze.

Co musi zawierać opis produktu (Description), a czego unikać?

Atrybut description [opis] pozwala na dostarczenie do 5000 znaków tekstu, który pomaga algorytmom zrozumieć niuanse produktu, których nie udało się zawrzeć w tytule.

Choć opis rzadziej jest czytany w całości przez użytkowników w wynikach zakupowych (często jest ukryty za przyciskiem „więcej”), jest intensywnie indeksowany przez roboty Google.

Należy unikać:

• Tekstów marketingowych typu „najlepszy na rynku”, „darmowa wysyłka” (od tego jest atrybut shipping).
• Opisów innych produktów (cross-selling w opisie jest zabroniony).
• Formatowania HTML (z wyjątkiem podstawowych znaczników jak łamanie linii, choć czysty tekst jest najbezpieczniejszy).

Dobry opis skupia się na cechach fizycznych, materiale, zastosowaniu i technicznych aspektach produktu.

Jakie wymagania techniczne muszą spełniać linki do strony i zdjęć?

Atrybuty link oraz image_link to mosty łączące reklamę z Twoim sklepem.

Link (link do strony): Musi prowadzić bezpośrednio do karty konkretnego wariantu produktu, a nie do strony głównej czy kategorii. Domena w linku musi być zweryfikowana i zgłoszona w Merchant Center. Ważne jest, aby linki zaczynały się od protokołu https://.

Image_link (link do zdjęcia): Wskazuje na główny obraz produktu, który wyświetli się w reklamie.

Wymogi Google co do zdjęć są bardzo rygorystyczne:

• Rozdzielczość: Minimum 500 x 500 pikseli we wszystkich kategoriach, przy czym ostrzeżenia w Merchant Center pojawiają się od kwietnia 2026 roku, a egzekwowanie ruszy 31 stycznia 2027 roku.
• Tło: Musi być białe lub przezroczyste. Zdjęcia typu „lifestyle” (produkt w użyciu) są zazwyczaj odrzucane jako zdjęcie główne (można je dodać w atrybucie additional_image_link).
• Czystość: Brak znaków wodnych, napisów promocyjnych, logo czy ramek. Produkt musi zajmować od 75% do 90% kadru.

Zignorowanie zasad dotyczących zdjęć to prosta droga do masowych odrzuceń (Item Disapprovals). W panelu diagnostycznym błąd „Promotional overlay on image” jest jednym z najczęściej spotykanych.

Dlaczego cena i dostępność muszą być aktualizowane w czasie rzeczywistym?

Atrybuty price [cena] oraz availability [dostępność] są monitorowane przez boty Google z najwyższą częstotliwością.

Price (cena): Musi zawierać kwotę oraz walutę (np. 199.99 PLN) i musi być identyczna z ceną widoczną na stronie docelowej. Availability (dostępność): Przyjmuje tylko predefiniowane wartości: in_stock, out_of_stock, preorder, backorder.

Rozbieżność między ceną w feedzie a ceną na stronie (np. feed pokazuje 100 zł, a po kliknięciu klient widzi 120 zł) jest traktowana jako poważne naruszenie zasad (Misrepresentation). Google wykonuje automatyczne testy, „wchodząc” na stronę jako użytkownik. Jeśli bot wykryje różnicę, produkt zostanie odrzucony. Przy powtarzających się błędach zablokowane zostanie całe konto. Dlatego, jeśli nie korzystasz z API, upewnij się, że masz włączoną funkcję „Automatyczne aktualizacje elementów” (Automatic Item Updates) w ustawieniach Merchant Center. Funkcja ta pozwala Google na tymczasową poprawę ceny w reklamie na podstawie skanu strony, chroniąc przed zawieszeniem konta.

Dlaczego identyfikatory unikalne (GTIN, MPN, Brand) decydują o widoczności?

Google odchodzi od polegania wyłącznie na słowach kluczowych na rzecz rozpoznawania konkretnych produktów. Do tego służą Globalne Numery Jednostki Handlowej (GTIN).

GTIN (Global Trade Item Number): To unikalny kod kreskowy produktu (np. EAN w Europie, UPC w USA, ISBN dla książek). Brand (marka): Producent towaru. MPN (Manufacturer Part Number): Numer katalogowy nadany przez producenta.

Dla większości produktów fabrycznie nowych, markowych, Google wymaga podania atrybutów gtin oraz brand. Produkty posiadające poprawny GTIN mają priorytet w aukcjach, ponieważ Google „wie” dokładnie, co to za przedmiot i może go porównać z tym samym przedmiotem u innych sprzedawców (podstawa działania zakładki „Zakupy”). Zgodnie z dokumentacją Google podanie poprawnego numeru GTIN może zwiększyć skuteczność produktu, a oferty bez unikalnych identyfikatorów są trudne do zaklasyfikowania i mogą nie kwalifikować się do wszystkich funkcji Zakupów, ponieważ trudniej dopasować je do precyzyjnych zapytań („produkt X cena”).

Kiedy stosować atrybut identifier_exists z wartością „no”?

Nie każdy produkt posiada kod EAN. Dotyczy to rękodzieła, antyków, produktów wykonywanych na zamówienie (custom) czy marek własnych sklepu (jeśli nie wykupiłeś puli kodów GS1).

W takiej sytuacji nie wolno wymyślać kodów GTIN ani wpisywać zer. Należy użyć atrybutu identifier_exists i ustawić jego wartość na no. (W polskiej wersji specyfikacji: „czy_istnieje_identyfikator”).

Sygnalizuje to Google’owi, że produkt jest specyficzny i nie należy oczekiwać od niego standardowych kodów. Należy jednak pamiętać, że nadużywanie tego atrybutu dla produktów, które faktycznie posiadają kody EAN (np. sprzedajesz buty Nike, ale nie chce Ci się uzupełniać kodów), skończy się odrzuceniem produktów, ponieważ Google posiada bazę kodów GS1 i zweryfikuje to kłamstwo.

Jakie są konsekwencje braku numeru GTIN dla algorytmu aukcyjnego?

Brak GTIN (tam, gdzie jest on wymagany) lub błędny GTIN sprawia, że Google degraduje jakość oferty.

Skutki braku poprawnego identyfikatora:

1. Ograniczona widoczność: Produkt nie pojawi się w porównywarkach cenowych Google ani na kartach produktów grupujących oferty wielu sprzedawców.
2. Niższy CTR: Reklamy mogą być wyświetlane na mniej trafne zapytania ogólne, zamiast na konkretne zapytania produktowe (long-tail), które najlepiej konwertują.
3. Odrzucenie: W wielu kategoriach (np. Elektronika, Media) brak GTIN skutkuje natychmiastowym błędem w Diagnostyce.

Uzupełnianie kodów jest pracą żmudną i dlatego regularnie odkładaną na później. Uważam, że to najgorzej policzony kompromis w całym e-commerce: godziny spędzone na dopisaniu kodów do kilkuset pozycji zwracają się raz, a brak tych kodów kosztuje przy każdej aukcji, w której oferta nie wchodzi na kartę produktu.

Jak wykorzystać atrybuty opcjonalne do segmentacji i zwiększenia ROAS?

Kiedy „obowiązek” mamy spełniony, przechodzimy do atrybutów, które budują przewagę konkurencyjną. To tutaj wygrywa się bitwę o efektywność.

Czym różni się google_product_category od product_type?

Wielu marketerów myli te dwa pojęcia.

google_product_category (kategoria produktów Google): To atrybut, w którym przyporządkowujesz swój produkt do oficjalnej taksonomii Google (drzewa kategorii). Musisz wybrać kategorię z listy udostępnionej przez Google (np. Odzież i akcesoria > Odzież > Odzież wierzchnia > Płaszcze i kurtki). Google potrafi automatycznie przypisać kategorię, ale ręczne wskazanie jest zawsze bardziej precyzyjne i zalecane.

product_type (typ produktu): To Twoja własna kategoryzacja, przeniesiona ze sklepu (np. Strona główna > Kobieta > Kurtki zimowe > Puchowe).

Używanie product_type jest kluczowe dla strukturyzowania kampanii produktowych. Pozwala ono na dzielenie produktów w kampaniach według logiki, którą masz w sklepie, co jest znacznie bardziej intuicyjne przy zarządzaniu stawkami i raportowaniu.

Jak używać Custom Labels do zarządzania stawkami w kampaniach?

Etykiety niestandardowe (custom_label_0 do custom_label_4) to najpotężniejsze narzędzie strategiczne w feedzie. Pozwalają one na oznaczanie produktów według kryteriów biznesowych, niewidocznych dla klienta, ale widocznych dla Ciebie w panelu Google Ads.

Przykłady zastosowania Custom Labels:

• Marżowość: custom_label_0: „HighMargin”, „LowMargin”. Pozwala licytować agresywniej na produkty, na których więcej zarabiasz.
• Sezonowość: custom_label_1: „Winter”, „Summer”, „AllYear”.
• Bestsellery: custom_label_2: „TopSeller”, „LowPerformer”.
• Wyprzedaż: custom_label_3: „Clearance”.

Dzięki temu w kampanii Performance Max lub standardowej kampanii produktowej możesz wydzielić grupę produktów „HighMargin” i przypisać jej wyższy budżet lub inny cel ROAS (Return on Ad Spend) niż produktom z etykietą „LowMargin”. Bez tych etykiet algorytm traktuje cały asortyment „płasko” i kieruje wydatek tam, gdzie sprzedaż przychodzi najłatwiej, a niekoniecznie tam, gdzie zostaje marża.

Jestem przekonany, że jedna kolumna z marżowością w pliku danych daje więcej niż tydzień pracy nad strukturą kampanii. Kolejność optymalizacji na koncie sklepowym powinna wyglądać tak: najpierw dane, potem struktura, na końcu stawki.

Jak poprawnie skonfigurować dane o wysyłce i podatkach w feedzie?

Informacje o kosztach dostawy są decydujące dla klienta. Możesz je skonfigurować na poziomie całego konta Merchant Center (co jest prostsze, jeśli masz stałą stawkę), ale jeśli koszty różnią się w zależności od produktu (np. gabaryty), musisz użyć atrybutu shipping w feedzie.

Atrybut ten ma strukturę zagnieżdżoną, zawierającą kraj, region, usługę (np. „Kurier”) i cenę. Od aktualizacji specyfikacji z kwietnia 2026 roku doszły do niego dwie podrzędne wartości powiązane z programami lojalnościowymi: loyalty_program_label oraz loyalty_tier_label. Pozwalają one wskazać, że dany produkt ma inne warunki dostawy dla uczestników programu.

Brak precyzyjnej informacji o wysyłce często prowadzi do porzuceń koszyka, ale z perspektywy Google Merchant Center najważniejsza jest zgodność. Jeśli w reklamie wyświetli się „Wysyłka gratis”, a w koszyku klient zobaczy „15 zł”, naruszasz zasady. Badania Baymard Institute wskazują, że zbyt wysokie koszty dodatkowe (wysyłka, podatki, opłaty) to najczęstszy powód rezygnacji z zakupu, wskazywany przez 40% porzucających koszyk. Stąd tak restrykcyjne podejście Google do transparentności tych danych już na poziomie reklamy.

Co zmieniła specyfikacja pliku danych z 14 kwietnia 2026?

Aktualizacja specyfikacji z 14 kwietnia 2026 roku dołożyła trzy nowe atrybuty i zaostrzyła wymagania wobec zdjęć produktowych. Google rozpisał ją na trzy terminy: część obowiązuje od razu, część rusza 30 czerwca 2026 roku, a najbardziej kosztowna zmiana wchodzi w życie dopiero 31 stycznia 2027 roku.

Nowości w specyfikacji pliku danych na 2026 rok w kolejności praktycznej ważności:

• Rozdzielczość zdjęć 500 x 500 pikseli: Minimalna rozdzielczość dla image_link i additional_image_link obowiązuje we wszystkich kategoriach produktowych. Ostrzeżenia w Merchant Center pojawiają się od 14 kwietnia 2026 roku, a egzekwowanie zaczyna się 31 stycznia 2027 roku.
• handling_cutoff_time: Dzienna godzina graniczna przyjmowania zamówień do realizacji tego samego dnia. Pozwala pokazać realny termin dostawy zamiast ogólnej deklaracji.
• minimum_order_value: Minimalna wartość zamówienia wymagana do zakupu i wysyłki. Wcześniej ten warunek klient poznawał dopiero w koszyku.
• video_link: Opcjonalny atrybut z adresem filmu produktowego. Adresy można przesyłać od kwietnia 2026 roku, ale wyświetlanie oraz walidacja jakościowa i polityczna startują 30 czerwca 2026 roku.

Największy dług techniczny generuje wymóg 500 x 500 pikseli, bo dotyczy zdjęć wyprodukowanych lata temu, często w rozdzielczości dopasowanej do starego szablonu sklepu. Google deklaruje, że część zbyt małych zdjęć zoptymalizuje automatycznie i oznaczy ostrzeżeniem, ale opieranie katalogu na tej furtce uważam za ryzykowne. Ostrzeżenie zamienia się w odrzucenie z dnia na dzień, a sesji zdjęciowej nie da się zorganizować w tydzień.

Harmonogram zmian 2026-2027

Specyfikacja pliku danych - co i od kiedy obowiązuje

Terminy z aktualizacji specyfikacji Google. Kolejność prac w sklepie warto ustawić odwrotnie do kolejności dat, bo najdalszy termin wymaga najwięcej pracy.

Do zrobienia2

Zdjęcia 500 x 500 pikseliEgzekwowanie od 31 stycznia 2027. Audyt rozdzielczości katalogu robi się dziś, bo sesji zdjęciowej nie da się zorganizować w tydzień.

Migracja na Merchant APIDotyczy własnych konektorów. Content API for Shopping zostało wyłączone 18 sierpnia 2026 roku.

W trakcie1

Filmy produktowe w video_linkWyświetlanie oraz walidacja jakościowa i polityczna działają od 30 czerwca 2026. Atrybut pozostaje opcjonalny.

Już obowiązuje2

handling_cutoff_timeDzienna godzina graniczna przyjmowania zamówień do realizacji tego samego dnia. Dostępny od 14 kwietnia 2026.

minimum_order_valueMinimalna wartość zamówienia wymagana do zakupu i wysyłki produktu. Dostępny od 14 kwietnia 2026.

Praktyczny wniosek z tego harmonogramu jest prosty: kolejność prac odwzorowuje kolejność terminów. Audyt rozdzielczości zdjęć robi się dziś, bo poprawa zajmuje miesiące. Atrybuty wysyłkowe dopisuje się przy najbliższej edycji reguł pliku danych. Filmy produktowe wchodzą do planu wtedy, gdy sklep faktycznie ma materiał wideo, a nie po to, żeby wypełnić nową kolumnę.

Jakie są najczęstsze przyczyny odrzuceń produktów w Merchant Center?

Najczęstsze przyczyny odrzuceń to nieprawidłowe identyfikatory, naruszenia zasad reklamowych i nakładki promocyjne na zdjęciach. Analiza błędów danych opublikowana w Search Engine Land pokazuje skalę zjawiska: nieprawidłowy GTIN dotyka 48,43% sprzedawców, naruszenia zasad Google 44%, a nakładki promocyjne na obrazach 40%. Utrzymanie „czystego” konta to ciągła walka, a panel Diagnostyka jest miejscem, które powinieneś odwiedzać przynajmniej raz w tygodniu.

Diagnostyka Merchant Center

Katalog sklepu 10 tygodni po porządkach w pliku danych

Panel z audytowanego sklepu z częściami motoryzacyjnymi, stan po dziesięciu tygodniach prac nad plikiem danych. Dane własne z jednego konta, nie benchmark rynkowy.

Oferty aktywne 3 412 +18 %

Oferty odrzucone 96 -74 %

Ostrzeżenia 210 -41 %

Liczba ofert aktywnych w katalogu10 tygodni

Panel powyżej pochodzi z jednego z audytowanych przeze mnie sklepów z częściami motoryzacyjnymi, dziesięć tygodni po uporządkowaniu pliku danych. Liczba aktywnych ofert wzrosła do 3412, odrzucenia spadły z 369 do 96, a ostrzeżenia z 356 do 210. To jedno konto i jeden kwartał, więc traktuj te liczby jako ilustrację tempa, a nie jako obietnicę wyniku.

Jak interpretować komunikaty w zakładce Diagnostyka?

Zakładka ta dzieli problemy na trzy poziomy:

1. Problemy z kontem: Najpoważniejsze (np. wygasła karta kredytowa, brak zweryfikowanej domeny, zawieszenie za naruszenie zasad).
2. Problemy z plikiem danych: Błędy parsowania, zły format, brak dostępu do pliku na serwerze.
3. Problemy z produktami: Konkretne błędy przypisane do poszczególnych ID.

Kluczowe jest rozróżnienie między Odrzuceniem (Disapproved) a Ostrzeżeniem (Warning). Odrzucenie oznacza, że produkt nie wyświetla się w ogóle. Ostrzeżenie (np. „Słaba jakość zdjęcia”, „Brakujący atrybut zalecany”) oznacza, że produkt się wyświetla, ale jego potencjał jest ograniczony. Ignorowanie ostrzeżeń w dłuższej perspektywie często prowadzi do odrzuceń.

Kolejność napraw ustalam zawsze według liczby dotkniętych ofert, nie według tego, jak groźnie brzmi komunikat. Jeśli w Diagnostyce widzisz kilkaset odrzuceń i nie wiesz, od której grupy błędów zacząć, to dokładnie ta sytuacja, którą rozkładam na czynniki pierwsze podczas audytu konta.

Jakie naruszenia zasad najczęściej blokują konta reklamowe?

Najbardziej bolesne są blokady wynikające z naruszenia polityki „Misrepresentation” (Wprowadzanie w błąd).

Oto najczęstsze powody:

• Brak danych kontaktowych na stronie: Sklep musi posiadać fizyczny adres, numer telefonu i e-mail widoczny dla klienta.
• Niejasna polityka zwrotów: Musisz jasno określić warunki zwrotu towaru.
• Niezabezpieczony proces checkoutu: Cały proces zakupu musi odbywać się przez protokół HTTPS.
• Promocje „na zawsze”: Jeśli produkt jest przeceniony przez 365 dni w roku, Google uzna to za manipulację ceną (fake sale) i może zablokować konto.

Naruszenia z tej listy różnią się od błędów atrybutów jedną rzeczą: nie da się ich naprawić w pliku danych. Wymagają zmian na stronie sklepu, więc ich obsługa wychodzi poza kompetencje osoby prowadzącej kampanie i musi trafić do zespołu odpowiedzialnego za serwis.

W jaki sposób feedy uzupełniające mogą naprawić błędy bez ingerencji w sklep?

To technika dla zaawansowanych, która oszczędza tysiące złotych na pracach programistycznych.

Feed uzupełniający (Supplemental Feed) to dodatkowy plik (np. prosty arkusz Google Sheets), który zawiera tylko dwie kolumny: id (żeby połączyć się z produktem głównym) oraz atrybut, który chcemy zmienić lub dodać.

Scenariusz z życia: Masz świetne produkty, ale ich tytuły w sklepie są fatalne („Koszula Męska 001”). Zmiana nazw w sklepie zepsułaby SEO organiczne lub integrację z magazynem. Rozwiązanie: Tworzysz feed uzupełniający z kolumnami id i title. Wpisujesz tam zoptymalizowane tytuły pod Google Ads. Łączysz ten plik z feedem głównym w GMC za pomocą reguł plików danych. Efekt: W sklepie nazwa pozostaje bez zmian, a w reklamach Google wyświetla się nowy, idealny tytuł.

Możesz w ten sposób masowo dodawać custom_labels, podmieniać zdjęcia, czy uzupełniać brakujące gtin bez konieczności angażowania działu IT.

Granica tej techniki jest jedna i warto ją znać przed startem: plik uzupełniający modyfikuje istniejące oferty, ale nie tworzy nowych. Produkt, którego nie ma w źródle podstawowym, nie pojawi się w Merchant Center, choćbyś opisał go w arkuszu uzupełniającym co do przecinka.

Czy mały sklep potrzebuje płatnego narzędzia do feedów?

Przy katalogu poniżej mniej więcej 500 SKU i jednym kanale sprzedaży arkusz Google z regułami plików danych zwykle wystarcza, a płatne narzędzie dokłada wtedy koszt bez przyrostu przychodu. Powyżej kilku tysięcy pozycji albo przy drugim kanale (Meta, Allegro, porównywarki) proporcja się odwraca, bo ręczne utrzymanie reguł zaczyna kosztować więcej godzin niż abonament.

Rozstrzygający jest nie rozmiar katalogu sam w sobie, tylko liczba wyjątków. Sklep z 4000 jednorodnych produktów obsłużysz kilkoma regułami w Merchant Center. Sklep z 800 produktami w dwunastu kategoriach, z których każda ma inny schemat tytułu, inne wymagania GTIN i inne koszty wysyłki, zje więcej pracy niż tamten pierwszy.

Utrzymanie pliku danych

Arkusz, reguły w Merchant Center czy płatne narzędzie

Trzy sposoby utrzymania pliku danych. O wyborze decyduje liczba wyjątków w katalogu i liczba kanałów sprzedaży, nie sama liczba produktów.

Wariant A Arkusz Google Sklep do około 500 SKU, jeden kanał sprzedaży, stabilny cennik.

Zero kosztu abonamentu Wdrożenie w jeden dzień Brak reguł warunkowych

Rekomendowany Wariant B Reguły plików danych w GMC Sklep od 500 do kilku tysięcy SKU, jeden lub dwa kanały sprzedaży.

Reguły warunkowe bez dodatkowego kosztu Feedy uzupełniające w komplecie Zmiany bez pracy programisty

Wariant C Płatne narzędzie do feedów Katalog z wieloma wyjątkami albo trzy i więcej kanałów sprzedaży.

Jedno źródło, wiele plików wyjściowych Mapowanie kategorii między platformami Stały koszt abonamentu

Zanim podejmiesz decyzję, policz jedną rzecz: ile godzin miesięcznie zespół realnie spędza dziś na poprawianiu pliku danych. Jeśli wychodzi mniej niż dwie, płatne narzędzie kupujesz na zapas. Jeśli wychodzi kilkanaście, decyzja zapadła sama. Przy audycie liczę to na konkretnym katalogu klienta, nie na średniej rynkowej, bo rozrzut między sklepami jest tu ogromny.

Jak dbać o higienę danych produktowych w długim okresie?

Specyfikacja feedu produktowego nie jest dokumentem statycznym. Google aktualizuje ją regularnie, a rok 2026 pokazał to wyraźnie: w kwietniu doszły atrybuty wysyłkowe i wideo, w sierpniu wyłączony został Content API for Shopping. Praca z plikiem danych wymaga więc podejścia procesowego, a nie projektowego.

1. Audyt cykliczny: Raz na kwartał przeglądaj ostrzeżenia w Diagnostyce, nie tylko odrzucenia.
2. Subskrypcja zmian: Śledź dziennik zmian Merchant Center. Nowe atrybuty pojawiają się z kilkumiesięcznym wyprzedzeniem przed egzekwowaniem.
3. Testowanie: Używaj plików testowych w GMC, aby sprawdzać zmiany przed wdrożeniem ich na produkcję.
4. Automatyzacja: Jeśli Twój asortyment przekracza 500 produktów, ręczna edycja plików mija się z celem. Rozważ narzędzia do zarządzania feedami, które pozwalają mapować i modyfikować dane w locie, w oparciu o reguły warunkowe.
5. Właściciel danych: Wyznacz jedną osobę odpowiedzialną za plik. Rozmyta odpowiedzialność między marketingiem a IT jest powodem, dla którego poprawki czekają miesiącami.

Uważam, że traktowanie feedu jako zadania działu IT jest najkosztowniejszym błędem organizacyjnym w e-commerce. Programista wygeneruje poprawny technicznie plik, ale nie wie, które produkty mają najwyższą marżę ani jak wygląda tytuł, którego szuka klient. Kiedyś rekomendowałem oddawanie całego pliku danych zespołowi technicznemu i uważałem to za czystszy podział pracy. Zmieniłem zdanie po kilku audytach, w których poprawne technicznie pliki nie sprzedawały nic.

Specyfikacja feedu produktowego - od czego zacząć porządki

Przestań traktować plik danych jak eksport z bazy sklepu. Zacznij postrzegać go jako ofertę handlową składaną Google - dokument, na podstawie którego system decyduje, czy Twój produkt w ogóle stanie do aukcji i przy jakim zapytaniu. Ta zmiana perspektywy zmienia też kolejność prac: najpierw kompletność i zgodność danych, potem struktura kampanii, na końcu stawki.

Praktyczna kolejność porządków na koncie, która sprawdza się u mnie niezależnie od branży, wygląda tak:

1. Zdejmij odrzucenia blokujące ofertę - identyfikatory, cena, dostępność, linki.
2. Sprawdź rozdzielczość zdjęć pod kątem progu 500 x 500 pikseli, zanim ostrzeżenia zamienią się w odrzucenia.
3. Przepisz tytuły według schematu właściwego dla kategorii, najlepiej plikiem uzupełniającym.
4. Dołóż warstwę biznesową - product_type i etykiety niestandardowe z marżowością.
5. Ustal właściciela pliku i cykl przeglądu Diagnostyki.

Każda godzina zainwestowana w dopracowanie atrybutów title, gtin czy custom_label zwraca się wielokrotnie w postaci niższego kosztu za kliknięcie (CPC) i wyższego współczynnika konwersji, co w skali roku może decydować o rentowności całego kanału e-commerce. A ponieważ specyfikacja zmienia się co kilka miesięcy, najlepszy moment na wpisanie przeglądu pliku danych do kalendarza jest teraz.

Na czym opieram te wnioski

Źródła i dokumentacja

Feed produktowy to dokument techniczny, więc każdą regułę opisaną w tym artykule opieram na oficjalnej specyfikacji Google, na dokumentacji migracyjnej Merchant API i na twardych danych o realnych odrzuceniach ofert. Poniżej cztery źródła, do których wracam przy audycie pliku danych i przy planowaniu zmian w kampaniach produktowych.

support.google.com

Specyfikacja pliku danych o produktach

Pełna lista atrybutów wymaganych i opcjonalnych wraz z dopuszczalnymi formatami wartości, limitami znaków i regułami dla wariantów. Bezpośrednia podstawa sekcji o atrybutach bezwzględnie wymaganych do akceptacji pliku oraz opisu atrybutów ID, title i description.

Google Merchant Center Help Otwórz

developers.google.com

Migracja z Content API do Merchant API

Oficjalny przewodnik migracyjny z datą wyłączenia Content API for Shopping i mapowaniem metod na nowe zasoby. Podstawa sekcji o tym, czym zastąpić Content API, oraz rozstrzygnięcia, kto realnie musi ruszyć integrację, a kogo migracja nie dotyczy.

Merchant API - dokumentacja Otwórz

searchengineland.com

Błędy danych, które blokują oferty

Zestawienie najczęstszych błędów danych blokujących oferty, z udziałem sprzedawców dotkniętych każdym z nich. Materiał liczbowy do sekcji o przyczynach odrzuceń w Merchant Center i do rozstrzygnięcia, od której grupy błędów zaczynać porządki w Diagnostyce.

Search Engine Land Otwórz

optmyzr.com

Segmentacja produktów w kampaniach Shopping

Praktyczne ujęcie segmentacji katalogu etykietami niestandardowymi i typem produktu. Odniesienie do sekcji o atrybutach opcjonalnych i do kroku z ustawianiem osobnych celów dla produktów wysokomarżowych.

Optmyzr Otwórz

Najczęściej zadawane pytania

Pytania i odpowiedzi (FAQ)

Sześć pytań, które wracają po uporządkowaniu pliku danych: zakres asortymentu w feedzie, czas ponownej akceptacji, ceny segmentowane, podział odpowiedzialności w firmie i los feedu przy zmianie platformy sklepowej.

01Czy plik danych o produktach musi zawierać cały asortyment sklepu w Merchant Center?

Nie i często nie powinien. Produkty niedostępne, o zerowej marży albo z niekompletnymi danymi obniżają ogólną jakość pliku i psują statystyki konta. Bezpieczniej wysyłać mniejszy, kompletny plik danych i rozszerzać go w miarę uzupełniania atrybutów.

02Ile trwa ponowna akceptacja produktu w Google Merchant Center po poprawce w feedzie?

Po pobraniu poprawionych danych weryfikacja w Merchant Center zajmuje zwykle do 3 dni roboczych, choć część błędów formalnych znika już przy najbliższym pobraniu pliku. Przy odrzuceniach z powodu niezgodności ceny czas liczy się od momentu, w którym robot ponownie odwiedzi stronę produktu, a nie od wgrania pliku.

03Czy feed produktowy do Google Zakupów może mieć inną cenę dla zalogowanych klientów?

Cena w pliku danych musi odpowiadać tej, którą widzi niezalogowany użytkownik wchodzący z reklamy. Ceny hurtowe i rabaty odblokowywane po zalogowaniu nie mogą być podstawą oferty w feedzie produktowym. Taka rozbieżność jest klasyfikowana jako wprowadzanie w błąd i kończy się odrzuceniem ofert.

04Kto w sklepie internetowym odpowiada za feed produktowy do Google Merchant Center?

Właścicielem pliku danych powinien być zespół e-commerce lub marketingu, a nie dział IT. Programiści odpowiadają za wygenerowanie eksportu i jego stabilność, natomiast o treści atrybutów title, product_type i custom_label decydują osoby znające marże i sezonowość. Rozdzielenie tych dwóch ról jest warunkiem, żeby poprawki nie czekały w kolejce sprintów.

05Czy jeden plik produktowy obsłuży Google Merchant Center, Meta i porównywarki cenowe?

Formaty są zbliżone, ale wymagania różne: inne nazwy atrybutów, inne taksonomie kategorii, inne limity tytułu. W praktyce buduje się jedno źródło danych i kilka plików wyjściowych generowanych regułami. Jeden plik wysyłany wszędzie zwykle spełnia wymagania tylko jednej platformy.

06Co dzieje się z feedem produktowym w Merchant Center po zmianie platformy sklepowej?

Migracja sklepu najczęściej zmienia identyfikatory produktów, a zmiana atrybutu id kasuje historię skuteczności oferty w kampaniach. Przed przenosinami warto wymusić zachowanie dotychczasowych wartości id w nowym eksporcie, choćby przez mapowanie w feedzie uzupełniającym. Sam plik danych trzeba wtedy podpiąć od nowa i przejść pełną walidację w Diagnostyce.

---