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 odliczania na czas, który został. Jeden grep, który znajdzie każdą integrację skazaną na śmierć, najpierw migrujesz ścieżki pieniędzy, potem ścieżki odczytu, a na końcu bieg równoległy, żebyś stare API wyłączył sam, zanim zrobi to za ciebie Google.
Rano odezwało się przypomnienie. Ustawiłem je w czerwcu, 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.
Co się psuje i dlaczego Merchant API to lepsze narzędzie, wyjaśniłem już w czerwcowym artykule. Nie będę się powtarzał. To jest plan, który odpalam, kiedy zbliża się twardy termin. Jedna faza na tydzień.
W tym tygodniu znajdź wszystko, co umrze
Nie zmigrujesz tego, czego nie znalazłeś. Przepuść to przez każde repo, które dotyka 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ą advanced service ShoppingContent, który 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ą siedzieć na starym API. Napisz w tym tygodniu do każdego dostawcy i zażądaj jego daty Merchant API na piśmie. Jego termin migracji to twoja awaria.
Tydzień drugi, migruj ścieżki pieniędzy
Zacznij tam, gdzie cisza kosztuje przychód. Aktualizacje cen, aktualizacje stanów, wysyłka feedów. W Merchant API v1, GA od lipca 2025, mieszkają w sub-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ł. Dostępy przechodzą dalej, kod nie. Przepisujesz wywołania i oszczędzasz sobie nowego tańca autoryzacji z każdym klientem.
Tydzień trzeci, ścieżki odczytu
Kontrole odrzuceń i raportowanie idą w następnej kolejności. To też tydzień, w którym migracja zaczyna ci się zwracać. Raporty stronicują po 1 000 wierszy zamiast 250, więc ten sam job kończy się w jednej czwartej wywołań. A tam, gdzie twój stary kod odpytywał statusy produktów według harmonogramu, sub-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 przestawia wyłącznik wszystkim naraz, a czego grep nie znalazł, umiera na produkcji.
Dwanaście lat na Google Ads API nauczyło mnie, że twarde terminy są rzadkie. Google zwykle przedłuża, toleruje stare, odkłada. Tego nie. Więc odpal ten grep, zanim zamkniesz tę kartę. Liczba, którą wypisze, to jedyny szacunek migracji, jakiego potrzebujesz.
