Niezgodność ceny i dostępności między feedem a witryną - jak naprawić?

Niezgodność ceny w Merchant Center to błąd, który Google zgłasza wtedy, gdy wartość atrybutu price w feedzie produktowym różni się od ceny widocznej na stronie produktu albo od ceny zapisanej w danych strukturalnych schema.org/Offer. Analogicznie działa niezgodność dostępności: atrybut availability deklaruje inny stan magazynowy niż landing page. Oba błędy prowadzą najpierw do odrzucenia pojedynczych ofert, a przy większej skali do ostrzeżenia o wprowadzaniu w błąd i zawieszenia konta.

Sklep robi promocję w piątek o 22:00, cena na stronie spada o 15%, a plik z feedem pobiera się dopiero w niedzielę nad ranem. Przez półtorej doby Google widzi dwie różne ceny tego samego produktu i reaguje tak, jak reaguje zawsze: wstrzymuje ofertę. Przez lata audytowania kont Merchant Center widziałem ten scenariusz w kilkudziesięciu wariantach - raz winna była integracja ERP, raz cena renderowana w JavaScripcie, raz zwykły VAT policzony inaczej po dwóch stronach. Mechanizm był zawsze ten sam, a naprawa zaczynała się od ustalenia, którą z trzech cen Google właściwie porównuje.

Na czym polega niezgodność ceny i dostępności w Merchant Center?

Niezgodność ceny polega na tym, że wartość atrybutu price przesłana w feedzie produktowym nie zgadza się z ceną, którą Google odczytuje ze strony docelowej tego produktu. Merchant Center traktuje stronę jako źródło prawdy, a feed jako deklarację - jeśli deklaracja odbiega od rzeczywistości, oferta zostaje wstrzymana. Dokładnie ten sam mechanizm obejmuje atrybut availability, gdzie sklep deklaruje in_stock, a karta produktu pokazuje brak towaru.

Kluczowe rozróżnienie dotyczy tego, co Google uznaje za cenę na stronie. Robot nie ogląda strony jak człowiek. Odczytuje serwerowy HTML, szuka znacznika schema.org/Offer, a dopiero potem próbuje wyłuskać cenę z widocznej treści. Trzy warstwy, trzy potencjalne źródła rozjazdu.

Warto zapamiętać jedną rzecz: zgodność musi zachodzić między wszystkimi czterema wierszami tej tabeli, nie tylko między feedem a tym, co widzi człowiek. Sklep może mieć idealnie poprawną cenę na ekranie i mimo to zbierać odrzucenia, bo znacznik schema.org został wygenerowany z innej zmiennej niż ta drukowana w szablonie. Widziałem takie wdrożenie w sklepie z armaturą łazienkową: cena widoczna była brutto, cena w danych strukturalnych netto, a różnica 23% wystarczyła, by 1 842 produkty wypadły z Zakupów Google w ciągu 36 godzin.

Pełny kontekst konfiguracyjny opisuję w przewodniku po Google Merchant Center, tutaj skupiam się wyłącznie na rozbieżności danych cenowych i magazynowych.

Jak Google wykrywa rozbieżność między feedem a stroną produktu?

Google wykrywa rozbieżność przez cykliczny crawl stron docelowych wskazanych w atrybucie link każdego produktu. Robot pobiera stronę, odczytuje z niej cenę oraz dostępność i porównuje je z wartościami z ostatniego przetworzonego feedu. Weryfikacja jest automatyczna, działa niezależnie od tego, czy kampania produktowa jest aktywna, i obejmuje także oferty w bezpłatnych listach produktowych.

Kolejność odczytu ma znaczenie praktyczne, bo decyduje o tym, gdzie szukać przyczyny błędu:

1. Serwerowy HTML - robot pobiera dokument w postaci, w jakiej wysyła go serwer, bez wykonywania kodu po stronie klienta.
2. Znacznik schema.org/Offer - jeśli istnieje, pola price, priceCurrency i availability są traktowane jako deklaracja sklepu o cenie.
3. Widoczna treść strony - przy braku znacznika Google próbuje rozpoznać cenę z układu karty produktu, co jest zawodne przy wielu wariantach.
4. Renderowanie z JavaScriptem - może nastąpić później i w osobnej kolejce, więc cena dostawiana skryptem bywa niewidoczna w momencie pierwszego porównania.

Jestem przekonany, że cena renderowana wyłącznie po stronie klienta to dziś najkosztowniejszy błąd techniczny w sklepach internetowych opartych o nowoczesne frameworki. Nie dlatego, że Google nie potrafi wykonać skryptu - potrafi. Dlatego, że robi to z opóźnieniem, a weryfikacja ceny w Merchant Center dzieje się wcześniej.

Jakie komunikaty o niezgodności ceny pokazuje Merchant Center?

Merchant Center rozdziela komunikaty według tego, skąd pochodzi sprzeczna wartość, i ta etykieta jest najszybszą wskazówką diagnostyczną. Inaczej naprawia się rozbieżność wykrytą podczas crawlu strony, a inaczej rozbieżność wykrytą w mikrodanych, mimo że w interfejsie obie wyglądają podobnie i obie kończą się odrzuceniem oferty.

• Niezgodność wartości ceny (page crawl): cena z feedu różni się od ceny odczytanej z treści strony podczas pobrania landing page.
• Niezgodność wartości ceny (mikrodane): cena z feedu różni się od wartości pola price w znaczniku schema.org/Offer.
• Niezgodność wartości dostępności: atrybut availability deklaruje inny stan magazynowy niż strona lub znacznik.
• Nieprawidłowa waluta: priceCurrency w danych strukturalnych nie zgadza się z walutą kraju sprzedaży zadeklarowanego w feedzie.
• Brakująca cena na stronie docelowej: robot nie znalazł żadnej ceny, najczęściej przy renderowaniu po stronie klienta lub blokadzie w pliku robots.txt.

Dlaczego cena w feedzie różni się od ceny na stronie produktu?

Cena w feedzie różni się od ceny na stronie z trzech powodów źródłowych: opóźnienia w aktualizacji danych, innego sposobu liczenia ceny po obu stronach oraz obecności rabatów, których feed w ogóle nie widzi. Każda z tych rodzin przyczyn wymaga innej naprawy, dlatego diagnozę zaczynam od ustalenia, która z nich odpowiada za konkretne odrzucenie.

Opóźnienie aktualizacji danych

• Zaplanowane pobieranie raz na dobę: każda promocja uruchomiona poza oknem pobrania żyje z nieaktualną ceną nawet przez 24 godziny.
• Cache po stronie sklepu: plik XML generuje się z pamięci podręcznej, więc feed pokazuje ceny sprzed przebudowy cache.
• Kolejka integracji ERP: zmiana ceny w systemie magazynowym trafia do sklepu z opóźnieniem, a do feedu z kolejnym.
• Timeout generowania pliku: przy dużym katalogu eksport przerywa się w połowie, a Merchant Center przetwarza ostatnią kompletną wersję.

Inny sposób liczenia ceny po obu stronach

• Netto kontra brutto: feed eksportuje cenę bez podatku, a karta produktu prezentuje cenę z VAT.
• Wariant domyślny: strona pokazuje cenę najtańszego wariantu, feed wysyła cenę wariantu bazowego.
• Zaokrąglenia i separatory: wartość 129.9 zamiast 129.90 albo przecinek zamiast kropki bywa odczytana jako inna kwota.
• Waluta kraju sprzedaży: feed deklaruje PLN, a znacznik schema.org podaje EUR dla tej samej strony.

Rabaty niewidoczne dla feedu

• Cena po zalogowaniu: zniżka dla zarejestrowanych klientów obniża cenę widoczną, ale robot ogląda stronę jako gość.
• Rabat naliczany w koszyku: promocja typu drugi produkt taniej nie ma odzwierciedlenia w cenie karty produktu.
• Licznik promocji: cena zmienia się co godzinę, a feed nie nadąża z aktualizacją w tym tempie.
• Kod rabatowy w banerze: baner sugeruje niższą cenę niż deklarowana w feedzie, co bywa czytane jako rozbieżność.

Jak naprawić niezgodność ceny krok po kroku?

Naprawa niezgodności ceny zaczyna się od zestawienia czterech wartości dla jednego odrzuconego produktu i ustalenia, która z nich odstaje. Dopiero potem sięga się po narzędzia. Kolejność ma znaczenie, bo przy odwrotnym podejściu sklep zmienia feed, cena na stronie zostaje bez zmian, a odrzucenie wraca przy kolejnym crawlu.

1. Wybierz jeden reprezentatywny produkt z listy odrzuconych i otwórz jego podgląd w Merchant Center, żeby zobaczyć wartość, którą Google przypisał obu stronom.
2. Otwórz stronę produktu z wyłączonym JavaScriptem i sprawdź, czy cena jest widoczna w serwerowym HTML. Brak ceny na tym etapie przesądza o przyczynie.
3. Zweryfikuj znacznik schema.org/Offer w Teście wyników z elementami rozszerzonymi - porównaj pola price, priceCurrency i availability z feedem.
4. Porównaj datę ostatniego przetworzenia feedu z datą ostatniej zmiany ceny w sklepie. Różnica większa niż jeden cykl pobierania wskazuje na problem harmonogramu.
5. Popraw źródło, nie objaw - jeśli rozjazd wynika z netto i brutto, zmień eksport, a nie pojedynczy rekord w regule feedu.
6. Wyślij zaktualizowane dane plikiem, feedem suplementarnym albo przez Merchant API, w zależności od tego, jak pilna jest poprawka.
7. Poczekaj na ponowny crawl strony i dopiero po zmianie statusu produktu rozszerz poprawkę na cały katalog.

W pracy z moimi klientami zawsze stosuję jedną dodatkową regułę: poprawkę testuję na próbce 10 produktów, zanim przepuszczę ją przez pełny katalog. Właściciel sklepu z armaturą łazienkową wdrożył u siebie zmianę w znaczniku schema.org od razu na całym asortymencie. Poprawka zawierała błąd w separatorze dziesiętnym i przez trzy dni odrzuconych było więcej produktów niż przed naprawą. Po powrocie do próbkowania liczba odrzuceń spadła z 1 842 do 12 w ciągu tygodnia.

Jeśli po tej procedurze część ofert nadal wisi z innym komunikatem, przyczyna leży poza ceną - zebrałem najczęstsze scenariusze w tekście o tym, jak diagnozować odrzucone produkty w Merchant Center. To dokładnie ten typ analizy, który przeprowadzam podczas audytu konta.

Jak naprawić niezgodność dostępności produktu?

Niezgodność dostępności naprawia się przez zsynchronizowanie atrybutu availability ze stanem magazynowym prezentowanym na karcie produktu i z polem availability w znaczniku schema.org/Offer. Google akceptuje kilka wartości, ale wymaga, żeby wybrana wartość miała pokrycie w tym, co zobaczy klient po kliknięciu w reklamę produktową.

Najczęstszy błąd w tej kategorii nie dotyczy wcale wyboru wartości. Dotyczy momentu, w którym stan magazynowy schodzi do zera. Sklep sprzedaje ostatnią sztukę o 14:20, karta produktu natychmiast pokazuje brak towaru, a feed wciąż deklaruje in_stock aż do nocnego eksportu. W tym oknie każde kliknięcie w reklamę prowadzi klienta do produktu, którego nie da się kupić - i właśnie takie sytuacje Google traktuje najostrzej.

• Ustaw próg bezpieczeństwa magazynowego: przy stanie równym jednej sztuce oznaczaj produkt jako niedostępny w feedzie, jeśli eksport jest rzadszy niż godzinny.
• Zsynchronizuj znacznik z bazą, nie z szablonem: pole availability w schema.org powinno czytać ten sam stan magazynowy co widoczny komunikat.
• Nie usuwaj produktów niedostępnych z feedu: oznacz je jako out_of_stock, żeby zachować historię oferty i szybciej wrócić po uzupełnieniu stanu.
• Sprawdź warianty osobno: dostępność rozmiaru 42 nie oznacza dostępności rozmiaru 39, a Google porównuje ofertę wariantu, nie produktu nadrzędnego.

Czym są automatyczne aktualizacje produktów i kiedy je włączyć?

Automatyczne aktualizacje produktów to funkcja Merchant Center, która pozwala Google samodzielnie skorygować cenę, dostępność lub stan produktu w feedzie na podstawie danych odczytanych ze strony docelowej. Google w dokumentacji Merchant Center opisuje je jednoznacznie jako mechanizm naprawy tymczasowych rozbieżności dla niewielkiej części asortymentu, nie jako zamiennik regularnej aktualizacji danych.

Włączenie tej funkcji wymaga jednego warunku technicznego: strona produktu musi mieć poprawne dane strukturalne z ceną, dostępnością i stanem. Bez znacznika schema.org Google nie ma z czego pobrać wartości korygującej, więc funkcja pozostaje bezczynna mimo aktywnego przełącznika w ustawieniach.

• Włącz, gdy: sklep prowadzi częste promocje, a eksport feedu jest dobowy i nie da się go w krótkim czasie przyspieszyć.
• Włącz, gdy: stany magazynowe zmieniają się szybciej niż cykl integracji z systemem magazynowym.
• Nie polegaj na tym, gdy: rozbieżność dotyczy większości katalogu - funkcja obejmuje ułamek ofert, a problem systemowy zostanie.
• Wyłącz, gdy: dane strukturalne na stronie są niepewne, bo wtedy automat nadpisze poprawny feed błędną wartością ze znacznika.

Uważam, że automatyczne aktualizacje produktów są plastrem, nie leczeniem. Ratują konto w dniu wyprzedaży i realnie zmniejszają liczbę odrzuceń, ale sklep, który opiera na nich zgodność danych, oddaje kontrolę nad ceną prezentowaną w reklamie zewnętrznemu mechanizmowi. Kiedyś rekomendowałem je szerzej, dopóki nie zobaczyłem konta, na którym automat przez tydzień utrwalał błędną cenę z niedziałającego znacznika.

Kiedy niezgodność ceny prowadzi do zawieszenia konta?

Niezgodność ceny prowadzi do zawieszenia konta wtedy, gdy przestaje wyglądać na incydent techniczny, a zaczyna wyglądać na wzorzec. Google ocenia skalę rozbieżności, jej powtarzalność w czasie i kierunek - cena w feedzie niższa od ceny w sklepie jest traktowana surowiej niż odwrotna, bo bezpośrednio wprowadza kupującego w błąd co do kosztu zakupu.

Polityka wprowadzania w błąd nie wymaga wcześniejszego ostrzeżenia. To odróżnia ją od zwykłych odrzuceń ofert i tłumaczy, dlaczego sklepy budzą się z zawieszonym kontem po tygodniu ignorowania czerwonych statusów w diagnostyce.

Sygnały ostrzegawcze, które w audytach traktuję jako czerwoną flagę, są dość powtarzalne:

• Odrzucenia przekraczają jedną piątą katalogu i utrzymują się dłużej niż dwa tygodnie bez reakcji.
• Rozbieżność wraca po każdej promocji, co pokazuje, że problem jest procesowy, nie jednorazowy.
• W diagnostyce pojawia się ostrzeżenie o polityce obok zwykłych błędów danych produktowych.
• Ta sama rozbieżność występuje w kilku krajach sprzedaży, co mnoży skalę naruszenia.

Jeśli rozpoznajesz u siebie dwa z tych sygnałów naraz, to moment na zewnętrzne spojrzenie na feed, zanim konto trafi na listę do zawieszenia - taką diagnostykę robię w ramach audytu konta.

Jak zapobiegać rozbieżnościom cen na stałe?

Trwałe zapobieganie rozbieżnościom opiera się na jednej zasadzie architektonicznej: cena widoczna na stronie, cena w danych strukturalnych i cena w feedzie muszą pochodzić z tego samego pola w bazie danych. Wszystko inne - harmonogramy, reguły, alerty - jest tylko zabezpieczeniem drugiej linii dla tej podstawowej decyzji technicznej.

1. Jedno źródło ceny - szablon karty produktu, generator znacznika schema.org i eksport feedu czytają tę samą zmienną, bez pośrednich przeliczeń.
2. Aktualizacje przyrostowe przez Merchant API - zmiany ceny i stanu wysyłane przy zdarzeniu, a nie przy nocnym eksporcie całego katalogu.
3. Feed suplementarny na promocje - oddzielny plik z sale_price i datami obowiązywania, podmieniany bez ruszania feedu podstawowego.
4. Cotygodniowy przegląd diagnostyki - stała pozycja w kalendarzu, nie reakcja na spadek wyświetleń w kampanii produktowej.
5. Alert przy progu odrzuceń - powiadomienie, gdy liczba odrzuconych ofert przekroczy ustalony poziom, wysyłane do osoby od sklepu, nie tylko do specjalisty od kampanii.

Konstrukcję samego pliku i kolejność atrybutów omawiam szerzej w tekście o tym, czym jest feed produktowy i jak go poprawnie utworzyć. Tutaj wystarczy zapamiętać, że reguły transformacji w Merchant Center są narzędziem korekcyjnym, a nie miejscem, w którym powinna powstawać cena.

Jakich błędów unikać przy naprawianiu niezgodności ceny?

Najkosztowniejszy błąd przy naprawianiu niezgodności ceny polega na dopasowaniu feedu do strony bez sprawdzenia, która wartość jest prawdziwa. Sklep podnosi cenę w pliku, komunikat znika, a klient nadal widzi w reklamie kwotę inną niż w koszyku - problem został ukryty, nie rozwiązany, i wraca przy pierwszej zmianie cennika.

• Reguła feedu zamiast poprawki w sklepie: nakładanie mnożnika 1,23 w Merchant Center maskuje błąd eksportu i rozjeżdża dane przy każdej zmianie stawki podatku.
• Wyłączanie odrzuconych produktów: usunięcie ofert z feedu czyści diagnostykę, ale kasuje też historię oferty i przychód z tych produktów.
• Zgłaszanie do weryfikacji przed poprawką: wniosek złożony, zanim robot zobaczy nowe dane, kończy się odrzuceniem i zużywa limit zgłoszeń.
• Poprawianie tylko produktów z listy błędów: ta sama przyczyna dotyczy zwykle całego katalogu, a lista pokazuje wyłącznie oferty już przecrawlowane.
• Blokada robota w pliku robots.txt: zablokowany dostęp do karty produktu uniemożliwia weryfikację i zamienia rozbieżność w trwały brak ceny.

Jest jeszcze jeden błąd, rzadziej opisywany: naprawa wykonana wyłącznie po stronie e-commerce, bez poinformowania osoby prowadzącej kampanie. Kampania produktowa po masowym odrzuceniu ofert wraca do wyścigu z uszczuploną pulą produktów i potrzebuje kilku dni na odbudowanie danych. Jeśli w tym czasie nikt nie zmieni oczekiwań wobec wyników, budżet zostanie oceniony na podstawie okresu, w którym połowa asortymentu w ogóle nie startowała w aukcji.

Podsumowanie

Niezgodność ceny i dostępności nie jest błędem feedu. Jest objawem tego, że sklep utrzymuje dwie prawdy o tym samym produkcie - jedną dla klienta, drugą dla Google - i pozwala im się rozjeżdżać. Dopóki cena widoczna, cena w danych strukturalnych i cena w pliku produktowym pochodzą z różnych miejsc, komunikat będzie wracał po każdej promocji.

Przestań traktować feed produktowy jak plik eksportowany raz na dobę. Zacznij postrzegać go jako publiczną deklarację ceny, za którą sklep odpowiada tak samo jak za metkę na półce. Ta zmiana perspektywy porządkuje wszystkie decyzje techniczne: częstotliwość aktualizacji, obecność znacznika schema.org, sposób obsługi promocji i to, kto w firmie dostaje alert, gdy coś się rozjedzie.

Zacznij od jednego produktu i czterech wartości z tabeli na początku tego tekstu. Jeśli zgadzają się co do grosza, przejdź do dziesięciu kolejnych. Konta, które przechodzą ten test na próbce, prawie nigdy nie trafiają na listę zawieszeń z tytułu wprowadzania w błąd.

Samodzielny Specjalista Google Ads

Artur Smolicki

Od ponad 15 lat specjalizuję się w przygotowaniu, wdrożeniu i optymalizacji kampanii Google Ads. W 2024 roku uzyskałem status Google Premier Partner dla 3% najlepszych specjalistów i agencji w Polsce. Prowadzę kampanie reklamowe na 29 rynkach zagranicznych, tak dla segmentu e-commerce jak i B2B.

Współpraca →Poznaj mnie →