W skrócie: Zostały cztery tygodnie. Content API for Shopping v2.1 zostaje wyłączone 18 sierpnia 2026 i przedłużenia nie będzie. To plan działania na pozostałe tygodnie. Najpierw jednym grepem znajdź każdą integrację, która przestanie działać, potem przenieś procesy wpływające na przychody, następnie procesy odczytu, a na końcu uruchom oba API równolegle, aby samodzielnie wyłączyć stare API, zanim zrobi to Google.
Rano odezwało się przypomnienie. Ustawiłem je w dniu, w którym pisałem o wyłączeniu Content API, i umieściłem je dokładnie cztery tygodnie przed terminem. 18 sierpnia 2026 Google wyłącza Content API for Shopping v2.1 na dobre. Cztery tygodnie wystarczą na spokojną migrację. Wystarczą też, żeby cztery razy z rzędu wmówić sobie, że zrobisz to w przyszłym tygodniu.
W wcześniejszym artykule wyjaśniłem, co się psuje i dlaczego Merchant API to lepsze narzędzie. Nie będę się powtarzał. To jest plan, który stosuję, kiedy zbliża się twardy termin. Jedna faza na tydzień.
W tym tygodniu znajdź wszystko, co przestanie działać
Nie zmigrujesz tego, czego nie znalazłeś. Uruchom to w każdym repozytorium korzystającym z Merchant Center:
grep -rEn \
"shoppingcontent\.googleapis\.com|ShoppingContent|content/v2(\.1)?([^[:alnum:]_.-]|$)|[\"']content[\"'][,[:space:]]+[\"']v2(\.1)?[\"']|\.content\([\"']v2(\.1)?[\"']" .Pierwszy wzorzec łapie bezpośrednie wywołania REST. Pozostałe łapią oficjalne biblioteki klienckie, bo one chowają przed tobą URL. Python buduje skazanego klienta przez build('content', 'v2.1'), PHP nazywa go Google_Service_ShoppingContent, Node używa google.content('v2.1'), a projekty Apps Script ładują zaawansowaną usługę ShoppingContent, która nie pokazuje się w żadnym repo. Projekty skryptowe przejrzyj ręcznie.
Potem wpisz każde trafienie do arkusza z czterema kolumnami. Co to robi, jak często się uruchamia, kto jest właścicielem i ile czasu minie, zanim ktoś zauważy, że umarło po cichu. Sortujesz po tej ostatniej kolumnie.
Twój grep pokrywa tylko kod, który sam napisałeś. Scenariusze Zapiera, narzędzia do feedów, repricery i konektory też mogą nadal korzystać ze starego API. Napisz w tym tygodniu do każdego dostawcy i poproś o pisemne potwierdzenie terminu przejścia na Merchant API. Jeśli go nie dotrzyma, awaria dotknie ciebie.
Tydzień drugi: migruj procesy wpływające na przychody
Zacznij tam, gdzie cisza kosztuje przychód. Aktualizacje cen, aktualizacje stanów, wysyłka feedów. W Merchant API v1, GA od lipca 2025 obsługują je pod-API products, inventories i datasources, a przewodnik po kompatybilności mapuje stare wywołania na ich nowe adresy.
Jedna rzecz zaskoczyła mnie pozytywnie, kiedy w Lyncie skierowaliśmy własne narzędzia na nowe endpointy. Istniejący token OAuth ze starym scope content po prostu zadziałał. Poświadczenia zachowują ważność, kod nie. Przepisujesz wywołania i oszczędzasz sobie nowego tańca autoryzacji z każdym klientem.
Tydzień trzeci: procesy odczytu
Kontrole odrzuceń i raportowanie idą w następnej kolejności. To też tydzień, w którym migracja zaczyna ci się zwracać. Raporty mają strony po 1 000 wierszy zamiast 250, więc to samo zadanie kończy się w jednej czwartej wywołań. A tam, gdzie twój stary kod odpytywał statusy produktów według harmonogramu, pod-API notifications samo wypycha do ciebie zmiany.
Tydzień czwarty: wyłącz to sam
Puść oba pipeline’y równolegle i przez kilka dni porównuj wyniki. Potem wyłącz starą integrację mniej więcej tydzień wcześniej, celowo, póki v2.1 jeszcze odpowiada. Jeśli coś przeoczonego po cichu od niej zależy, wyjdzie na jaw, kiedy jeszcze możesz na dzień przywrócić stare wywołania i naprawić rzecz porządnie.
Po 18 sierpnia nie ma odwrotu. Google wyłącza API wszystkim jednocześnie, a czego grep nie znalazł, umiera w środowisku produkcyjnym.
Dwanaście lat pracy z Google Ads API nauczyło mnie, że twarde terminy są rzadkie. Google zwykle wydłuża terminy, utrzymuje starsze wersje albo odkłada wyłączenie. Tym razem nie. Więc odpal ten grep, zanim zamkniesz tę kartę. Liczba, którą wypisze, to jedyny szacunek migracji, jakiego potrzebujesz.
