Migracja WooCommerce na Merchant API

Google wyłączył Content API for Shopping 18 sierpnia 2026. Od 19 sierpnia każde wywołanie starych endpointów v2.1 wraca jako HTTP 410 Gone, więc integracja wciąż na nie skierowana nie wysyła już produktów, cen ani stanów do Google Merchant Center. Jeśli czytasz to, bo szukasz, dlaczego feed zamarł, zacznij od ustalenia, czym Merchant Center jest w ogóle zasilany, bo spora część sklepów WooCommerce nie miała tu nic do zrobienia.

Uczciwa wersja tej historii to triaż, nie alarm. W WPPoland budujemy i utrzymujemy integracje WooCommerce dla sprzedawców działających w całej UE, więc oto kogo to naprawdę dotyczy, co się psuje teraz, gdy termin minął, i dlaczego ta sama migracja jest po cichu wejściem do commerce wspieranego przez agentów.

#Kiedy wyłączono Content API for Shopping

Content API for Shopping to stara programistyczna powierzchnia Google do zarządzania wszystkim, co sklep wysyła do Merchant Center: danymi produktów, magazynem, cenami i ustawieniami konta. Zastępuje je nowsze Merchant API, które pokrywa ten sam obszar, ale jest podzielone na wyspecjalizowane sub-API (Products, Inventories, Accounts, Reports) zamiast jednego monolitycznego endpointu.

Data, która się liczyła, to 18 sierpnia 2026. Od tamtego dnia stare Content API zwraca 410 Gone i nie wróci. Wcześniej, 28 lutego 2026, wygasło v1beta Merchant API, więc kod pisany pod betę musiał trafić na stabilne v1 jeszcze przed głównym terminem. Jeśli Twoja integracja przespała obie daty, masz do zrobienia jedno przejście, nie dwa.

#Które sklepy WooCommerce muszą przejść na Merchant API

To pytanie decyduje, czy możesz zamknąć tę kartę. Sklep WooCommerce zwykle rozmawia z Merchant Center na trzy sposoby.

• Oficjalna wtyczka Google dla WooCommerce. Jeśli synchronizacja produktów działa przez oficjalną wtyczkę (dawniej Google Listings and Ads), warunek jest jeden: aktualna wersja. Google i WooCommerce wdrożyli przejście na Merchant API wewnątrz wydania wtyczki, więc zwykła aktualizacja załatwiała sprawę bez kodu. Jeśli wtyczka stoi na starym wydaniu, zaktualizuj ją i sprawdź, czy feed znów się pobiera.
• Zewnętrzna wtyczka feedowa lub marketingowa. Część z nich wywoływała Content API bezpośrednio. Sprawdź u dostawcy, czy wydał wersję pod Merchant API, i porównaj ją z tą, którą masz zainstalowaną. Jeśli dostawca milczy, traktuj ten feed jak martwy, dopóki nie zobaczysz świeżego pobrania w Merchant Center.
• Własna integracja. Autorskie konektory, własne eksportery feedów, konfiguracje headless wysyłające do Merchant Center z Twojego kodu i narzędzia wewnętrzne napisane pod Content API. To grupa z realną pracą, i dokładnie taki rodzaj wdrożeń agencje stawiają dla większych lub nietypowych sklepów.

Na polskim rynku dochodzi tu jeszcze jeden typowy przypadek: sklep, który jednym autorskim eksporterem zasila naraz Google Merchant Center i Ceneo (albo Allegro Ads). Google to tylko jeden z wielu kanałów w takim skrypcie, więc migracja tej jednej gałęzi na Merchant API musi się odbyć bez ruszania pozostałych feedów, które działają dalej po staremu.

Niezależnie od grupy pierwszy ruch jest ten sam i zajmuje kilka minut. Wejdź w Merchant Center, otwórz diagnostykę produktów i sprawdź datę ostatniego pobrania oraz to, czy liczba aktywnych ofert nie zaczęła zjeżdżać po 18 sierpnia. Po stronie sklepu zajrzyj w logi integracji i poszukaj odpowiedzi 410 z endpointów shoppingcontent.googleapis.com. Jedno i drugie odpowiada na pytanie szybciej niż czytanie kodu.

Jeśli jesteś w pierwszej grupie i wtyczka jest aktualna, kończ tutaj. Jeśli w trzeciej, czytaj dalej.

#Merchant Center nie aktualizuje produktów z WooCommerce

Nic nie degradowało się łagodnie. Od 19 sierpnia 2026 wywołania po prostu padają z 410 Gone, a skutki się kaskadują:

• Oferty się starzeją. Nowe produkty przestają się pojawiać, a usunięte mogą zostać. Katalog w Merchant Center odjeżdża od realnego katalogu WooCommerce.
• Ceny i stany przestają się aktualizować. To ten groźny. Merchant Center dalej pokazuje ostatnią otrzymaną cenę i dostępność, więc możesz reklamować cenę, której już nie masz, albo produkt, którego już nie ma na stanie, co grozi odrzuceniami i utratą zaufania konta.
• Kampanie Shopping i Performance Max głodują. Kampanie Google Ads żywią się danymi produktowymi z Merchant Center. Gdy feed zamarza, kampanie działają na przeterminowanym magazynie, aż po cichu zaczną tracić.

Ponieważ padło wszystko naraz, a nie z ostrzeżeniem, żadna z tych rzeczy nie zgłosi się sama. Dopóki nie sprawdzisz daty ostatniego pobrania w Merchant Center i logów po stronie sklepu, nie wiesz, czy patrzysz na aktualny katalog, czy na zamrożoną kopię sprzed 18 sierpnia.

Google zaznacza w dokumentacji Merchant Center, że automatyczne aktualizacje nie zastępują regularnego odświeżania danych produktowych. Mają naprawiać tylko sporadyczne błędy ceny, dostępności i stanu. Jeśli cena, dostępność i stan produktów zmieniają się często, Google zaleca używać do tego Merchant API. Dla sklepu z szybko zmieniającym się magazynem oznacza to wysyłanie zmian przez integrację, a nie liczenie na to, że Google poprawi dane z samej strony.

#Checklista migracji dla własnych integracji WooCommerce

Praca jest metodyczna, nie trudna, i to zwykła inżynieria WooCommerce po stronie serwera.

• Zinwentaryzuj wywołania Content API. Wypisz każdy endpoint, którego dotyka integracja, i zdarzenie WooCommerce, które go wyzwala (zapis produktu, zmiana stanu, zaplanowana pełna synchronizacja).
• Zmapuj każde wywołanie na jego sub-API Merchant API. Products, Inventories, Accounts i Reports przejmują po części to, co Content API robiło w jednym miejscu.
• Uwierzytelnij się ponownie. Merchant API używa OAuth 2.0 lub konta usługi. Sprawdź, czy Twoje poświadczenia i zakresy się przenoszą.
• Po przełączeniu sprawdź etykiety feedu. Konfiguracja etykiet nie zawsze przetrwa migrację, a etykiety sterują strukturą kampanii, więc zweryfikuj je, zamiast zakładać.
• Pobierz zbiorcze powody odrzuceń z sub-API Reports, gdy nowa integracja ruszy, żeby złapać wszystko, co zmienił przełącznik, zanim zrobią to algorytmy Google.

#Jak przetestować własny feed na Merchant API przed przełączeniem

Przepisanie konektora to nie tylko nowe adresy endpointów. Zmienia się model danych, więc warto znać różnice, zanim kod dotknie produkcyjnego konta. Google opisuje je w przewodniku po migracji z Content API i w osobnej stronie o produktach.

• Zapis i odczyt to dwa różne zasoby. Dane wysyłasz przez ProductInput, a gotowy produkt po przetworzeniu przez Google czytasz z zasobu Product, który jest tylko do odczytu. Integracja, która po zapisie od razu odczytywała ten sam obiekt, żeby porównać wynik, musi się z tym pogodzić.
• Każdy zapis wskazuje źródło danych. Operacje na productInputs wymagają parametru dataSource, więc najpierw trzeba ustalić, do którego źródła danych w Merchant Center ma trafiać feed z WooCommerce.
• Zmienia się identyfikator produktu. Zamiast pola id w formacie channel:contentLanguage:targetCountry:offerId produkt ma nazwę zasobu accounts/{account}/products/{product}, gdzie część produktowa wygląda jak contentLanguage~feedLabel~offerId. Jeśli w bazie sklepu trzymasz mapowanie ID WooCommerce na ID Google, to ono wymaga przebudowy.
• Nie ma już custombatch. Pełną synchronizację katalogu trzeba przepisać na żądania asynchroniczne albo batching HTTP.
• Projekt Google Cloud trzeba zarejestrować. Merchant API wymaga powiązania konta Merchant Center z projektem Google Cloud metodą Developer Registration, zanim pierwsze wywołanie przejdzie.

Do testów służą konta testowe Merchant API, tworzone metodą accounts.createTestAccount. Dane wysłane na takie konto nigdy nie trafiają do wyszukiwarki ani reklam produktowych, a limity zapytań są te same co na koncie produkcyjnym, więc pełna synchronizacja katalogu pokaże realne zachowanie pod kwotami. Google pozwala na najwyżej pięć takich kont na jedno konto Google, a konta testowego nie da się później zamienić w produkcyjne. Praktyczna kolejność: podpiąć stagingową kopię sklepu do konta testowego, puścić pełną synchronizację i kilka zmian ceny oraz stanu, porównać to, co zwraca zasób Product, z danymi w WooCommerce, i dopiero wtedy przepiąć poświadczenia na konto produkcyjne.

Przewodnik Google zaznacza też, że Merchant API zaprojektowano do pracy obok funkcji Content API, więc w dokumentacji opisano migrację po jednym sub-API naraz. Po 18 sierpnia 2026 ta ścieżka nie ma już znaczenia dla starych endpointów, które zwracają 410, ale sama zasada zostaje: przy eksporterze, który obsługuje też Ceneo, przepisujesz wyłącznie gałąź Google i testujesz ją osobno.

#Jak podłączyć WooCommerce Merchant API i MCP dla agentów AI?

Migracja jako uciążliwy obowiązek mija się z sednem. Przejście na Merchant API otwiera też Merchant API MCP Access Service, alfowy most udostępniający dane Merchant Center modelom LLM i agentom AI przez Model Context Protocol, na razie do odczytu plus kilka narzędzi zapisu niskiego ryzyka. Po ludzku: ta sama platforma, na której żyje teraz Twój feed, jest tą, z której zakupowi asystenci AI będą czytać, decydując, które produkty pokazać.

To łączy wyłączenie z większą zmianą, o której piszemy: sklepy przechodzą od bycia przeglądanymi przez ludzi do bycia odpytywanymi przez agentów. Migracja, którą i tak trzeba było zrobić, jest zarazem wjazdem na to, by być odnajdywalnym i kupowalnym dla tych agentów, co jest całą tezą naszego przewodnika gotowości na AI commerce.

Atrybuty konwersacyjne, aktualizacja z 23 października 2026: od Google Marketing Live w maju 2026 specyfikacja danych produktowych Merchant Center ma sześć opcjonalnych pól przeznaczonych dla trybu AI i podobnych powierzchni AI. Wymienia je strona pomocy Google o atrybutach konwersacyjnych: question_and_answer (pytania i odpowiedzi o produkcie, do 1000 znaków każde), document_link (instrukcje w PDF, podręczniki, instrukcje montażu), related_product (akcesoria, części wymagane do działania, zamienniki), item_group_title i variant_option (wspólna nazwa rodziny produktów i cechy, którymi różnią się warianty) oraz popularity_rank (liczba od 0 do 100 określająca miejsce produktu na tle reszty twojego asortymentu). Google zaleca przesyłanie ich dodatkowym źródłem danych, zapewnia, że nie zmieniają statusu zatwierdzenia istniejących produktów, i prosi, by nie powtarzać w nich tego, co już jest w polach description, product_highlight czy product_detail. Kolumny są te same niezależnie od tego, co generuje plik produktowy: wtyczka WooCommerce, aplikacja w sklepie na Shopify czy własny eksport. Najtańszym źródłem jest treść, którą już masz: pytania i odpowiedzi przy produkcie oraz instrukcje PDF podlinkowane na kartach produktów.

#Co zrobić, gdy feed Google z WooCommerce stoi

Jeśli używasz oficjalnej wtyczki, sprawdź jej wersję i datę ostatniego pobrania feedu, a potem wracaj do pracy. Jeśli masz własną lub zewnętrzną integrację i nie potwierdziłeś migracji, przyjmij, że feed stoi: ustal, od których sub-API zależysz, i przełącz się, testując najpierw wobec konta nieprodukcyjnego, bo dokładnie to zaleca Google, zanim skierujesz produkcyjny ruch na nowe narzędzia.

Robimy te migracje w ramach naszej pracy programisty WooCommerce, obok strony analitycznej zamówień od agentów, którą omawiamy w co dzieje się, gdy agent AI robi zakup, oraz tylko-do-odczytu serwera MCP dla WooCommerce, który pokazuje, jak agenci w ogóle czytają katalog.

#Jak sprawdzić, że nowa integracja naprawdę wysyła dane

Przełączenie na Merchant API bez błędu w logach nie potwierdza jeszcze, że feed żyje. Po pierwszym uruchomieniu nowej integracji przejdź przez kilka kontroli.

• Data ostatniego pobrania. W diagnostyce produktów Merchant Center powinna być późniejsza niż moment przełączenia.
• Liczba aktywnych ofert. Jeśli spadała od 18 sierpnia, powinna przestać spadać i wrócić do liczby produktów w WooCommerce.
• Logi sklepu. Żadnych odpowiedzi 410 z endpointów shoppingcontent.googleapis.com. Każda oznacza wywołanie, którego inwentaryzacja nie złapała.
• Cena i stan. Zmień cenę albo stan jednego produktu w WooCommerce i sprawdź, czy zmiana dotarła do Merchant Center. Ten test mówi więcej niż sam import katalogu.
• Etykiety i odrzucenia. Porównaj etykiety feedu z konfiguracją sprzed migracji i pobierz zbiorcze powody odrzuceń z sub-API Reports.
• Pozostałe kanały. Jeśli ten sam eksporter zasila Ceneo albo Allegro Ads, upewnij się, że te feedy wychodzą tak samo jak przed zmianą.

Dopiero gdy wszystkie punkty się zgadzają, kampanie Shopping i Performance Max znów pracują na aktualnym katalogu.

#Dlaczego Google pokazuje cenę promocyjną, której nie ma w feedzie WooCommerce

Sprawna synchronizacja z Merchant API mówi Google, co sklep wysyła dziś. Google trzyma jednak własny zapis tego, co widział wcześniej. Emina Demiri-Watson opisała 5 października 2026 w Search Engine Journal brytyjski sklep, przy którym Google pokazywał w Zakupach Was £474, now £355 z plakietką promocji. Sklep nie prowadził promocji i nigdy nie wysłał atrybutu sale_price, ani w obecnym feedzie, ani w starszych. Plakietkę złożyły trzy sygnały:

• feed wysyłał £355 jako cenę netto, a ostatni crawl strony odczytał £426, czyli tę samą cenę z VAT,
• znaczniki Product miały postać AggregateOffer z dwoma progami priceSpecification: List price za £395 i Sale price za £355, a £395 netto to £474 brutto,
• HTML strony wypisywał przy cenie słowo Now, a eksport feedu z 15 kwietnia miał w polu ceny właśnie £474.

Żaden z tych sygnałów osobno nie prosił o plakietkę. Autorka podsumowuje to dwoma zdaniami: “Ludzie zapominają. Systemy nie” (Emina Demiri-Watson, Search Engine Journal, tłumaczenie własne).

Plakietki, o które sklep prosi sam przez sale_price, mają osobne warunki. Google sprawdza, czy rabat mieści się między 5% a 90% i czy cena bazowa była wysyłana przez wymagany okres, w Wielkiej Brytanii “co najmniej 30 dni w ciągu ostatnich 200 dni” (Emina Demiri-Watson, Search Engine Journal, tłumaczenie własne). Adnotacje o spadku ceny w ogóle nie wymagają zgłoszenia: Google porównuje bieżącą cenę ze średnią, którą sam zapisał w ostatnich 60 dniach. Skala tej pamięci według tego samego tekstu: Shopping Graph zawiera “ponad 50 miliardów ofert produktów, z czego ponad 2 miliardy są odświeżane co godzinę” (Emina Demiri-Watson, Search Engine Journal, tłumaczenie własne).

W polskim sklepie ten sam błąd różni się tylko liczbą. Dla produktu ze stawką podstawową 23% cena z crawla będzie wyższa od ceny z feedu o 23%, gdy feed podaje cenę netto, a strona brutto. Towary na stawkach obniżonych 8% i 5% dają inne różnice, więc sklep z mieszanymi stawkami nie zobaczy jednej równej różnicy w całym katalogu.

#Jak porównać cenę w feedzie z ceną w schema Product w WooCommerce

• Zacznij od tego, co zobaczył Google. W Merchant Center otwórz produkt z listy Products > All products (nazwy z angielskiego interfejsu) i przewiń kartę Product details do końca. Sekcja Information found on your site pokazuje cenę, którą Google ostatnio odczytał ze strony, razem z datą. Różnica równa stawce VAT znaczy, że feed wysyła netto, a strona pokazuje brutto.
• Sprawdź WooCommerce > Settings > Tax. Opcja wprowadzania cen z podatkiem decyduje, co znaczy cena zapisana w produkcie, a opcja wyświetlania cen w sklepie decyduje, czy klient widzi ją z VAT, czy bez. Porównaj to z tym, co wysyła eksporter feedu. Jeśli strona pokazuje brutto, a feed netto, Google musi sam domyślać się podatku.
• Czytaj wyrenderowany JSON-LD, nie ekran ustawień. Otwórz źródło strony produktu i znajdź każdy blok application/ld+json z typem Product. WooCommerce generuje własne znaczniki Product, a wtyczka SEO potrafi dodać drugie, które się z nimi nie zgadzają. Szukaj drugiej ceny i nazw w priceSpecification ze słowem Sale albo List.
• Szukaj promocyjnych słów w HTML. WooCommerce owija cenę regularną w <del>, a promocyjną w <ins>, gdy produkt ma ustawioną cenę promocyjną, a motywy często dokładają etykiety w rodzaju “Było” i “Teraz”. Jeśli produkt bez promocji pokazuje którąkolwiek z nich, zmień etykietę. Autorka radzi to samo.
• Trzymaj datowane eksporty feedu. Sprawę z Wielkiej Brytanii rozwiązał eksport z kwietnia, który przypadkiem leżał na dysku. Jeden zapisany eksport miesięcznie zamienia następne śledztwo w porównanie dwóch plików. Dotyczy to także feedów do Ceneo, jeśli wychodzą z tego samego eksportera.

#Co zrobić ze zdjęciami wycofanych produktów w WooCommerce

Google prowadzi własny indeks zdjęć produktów, niezależny od image_link w feedzie i od schema. Dopóki stary adres obrazka odpowiada, Google może dalej używać tego zdjęcia w reklamach i bezpłatnych informacjach o produktach, choć sklep dawno je podmienił. Tekst wymienia WooCommerce wprost: “pliki WooCommerce leżą w standardowej bibliotece mediów WordPressa i rzadko są sprzątane, gdy produkty wycofuje się ze sprzedaży” (Emina Demiri-Watson, Search Engine Journal, tłumaczenie własne).

• Usunięcie produktu nie usuwa jego zdjęć. Przy wycofaniu produktu albo wymianie zdjęcia usuń stary załącznik w Media > Library przyciskiem Delete permanently (w polskim panelu odpowiednio Media, Biblioteka i trwałe usunięcie). WordPress kasuje plik i wygenerowane rozmiary, więc stary adres zwraca 404, a to jest czysty sygnał, który poleca autorka. Wcześniej sprawdź, czy tego obrazka nie używa inny produkt albo strona.
• Nowa nazwa pliku zostawia stary plik w sieci. Zdjęcie wgrane pod inną nazwą daje Google dwa adresy obrazka dla jednego produktu, a Google nie zawsze wybiera aktualny.
• Potwierdź 404 na samym adresie. Otwórz stary adres obrazka po usunięciu. CDN albo cache strony potrafi serwować plik jeszcze po tym, jak WordPress go skasował.
• Wyszukaj starą nazwę pliku w Grafice Google. Kopia na aukcji w marketplace albo na zapomnianej cudzej stronie może być źródłem złego zdjęcia, i tę kopię trzeba usunąć tam, gdzie leży.

Ostatnia aktualizacja: 11 października 2026.