Kort sagt: Fyra veckor kvar. Content API for Shopping v2.1 stängs av den 18 augusti 2026 och det blir ingen förlängning. Det här är nedräkningsplanen för tiden som återstår. Ett grep-kommando hittar varje integration som kommer att dö. Migrera pengavägarna först, läsvägarna sedan och kör systemen parallellt, så stänger du av det gamla API:et på egna villkor innan Google gör det åt dig.
Påminnelsen dök upp i morse. Jag satte den samma dag som jag skrev om nedstängningen av Content API, och jag lade den exakt fyra veckor före deadline. Den 18 augusti 2026 stänger Google av Content API for Shopping v2.1 för gott. Fyra veckor räcker för att migrera i lugn och ro. Det räcker också för att intala dig att du gör det nästa vecka, fyra gånger i rad.
Jag har redan förklarat vad som går sönder och varför Merchant API är det bättre verktyget i den tidigare artikeln. Jag upprepar det inte. Det här är planen jag följer när en hård deadline närmar sig: en vecka per fas.
Den här veckan: hitta allt som kommer att dö
Du kan inte migrera det du inte har hittat. Kör det här i varje repo som rör Merchant Center:
grep -rEn \
"shoppingcontent\.googleapis\.com|ShoppingContent|content/v2(\.1)?([^[:alnum:]_.-]|$)|[\"']content[\"'][,[:space:]]+[\"']v2(\.1)?[\"']|\.content\([\"']v2(\.1)?[\"']" .Det första mönstret fångar direkta REST-anrop. Resten fångar upp användning av de officiella klientbiblioteken, för de gömmer URL:en för dig. Python bygger den dödsdömda klienten med build('content', 'v2.1'), PHP kallar den Google_Service_ShoppingContent, Node använder google.content('v2.1'), och Apps Script-projekt laddar den avancerade ShoppingContent-tjänsten, som aldrig dyker upp i något repo. Dina skriptprojekt går du igenom för hand.
Lägg sedan varje träff i ett kalkylark med fyra kolumner. Vad den gör, hur ofta den körs, vem som äger den och hur lång tid det tar innan någon märker att den dött i tysthet. Det är den sista kolumnen du sorterar på.
Ditt grep-kommando täcker bara kod du själv har skrivit. Zapier-scenarier, feedverktyg, verktyg för automatisk omprissättning och kopplingar kan också sitta på det gamla API:et. Mejla varje leverantör den här veckan och begär deras Merchant API-datum skriftligt. Deras migrationsdeadline är ditt driftstopp.
Vecka två, migrera pengavägarna
Börja där tystnad kostar intäkter. Prisuppdateringar, lageruppdateringar, feeduppladdningar. I Merchant API v1, som har varit GA sedan juli 2025, finns de i del-API:erna products, inventories och datasources, och kompatibilitetsguiden mappar de gamla anropen till deras nya adresser.
En sak överraskade mig positivt när vi på Lynt pekade om våra egna verktyg mot de nya endpointsen. Den befintliga OAuth-tokenen med det gamla content-scopet fungerade direkt. Inloggningsuppgifterna följer med, koden gör det inte. Du skriver om anropen och slipper en ny auktoriseringsdans med varje kund.
Vecka tre, läsvägarna
Kontroller av underkännanden och rapportering flyttar härnäst. Det är också veckan då migrationen börjar löna sig. Rapporterna delas upp i sidor om 1 000 rader i stället för 250, så samma jobb blir klart på en fjärdedel av anropen. Och där din gamla kod pollade produktstatusar enligt schema, pushar del-API:et notifications ändringarna till dig i stället.
Vecka fyra, stäng av det själv
Låt båda pipelines gå parallellt och diffa utdata i några dagar. Stäng sedan av den gamla integrationen ungefär en vecka i förväg, medvetet, medan v2.1 fortfarande svarar. Om något du har missat är beroende av den visar det sig medan du fortfarande kan slå på de gamla anropen en dag och laga det ordentligt.
Efter den 18 augusti finns ingen rollback. Google slår om strömbrytaren för alla samtidigt, och det som grep-kommandot inte hittade dör i produktion.
Tolv år på Google Ads API har lärt mig att hårda deadlines är sällsynta. Google brukar förlänga tidsfrister, låta äldre versioner leva vidare eller skjuta upp förändringar. Inte den här gången. Så kör grep-kommandot innan du stänger den här fliken. Siffran det skriver ut är den enda migrationsuppskattning du behöver.
