Googles Content API lukkes 18. august 2026: Ryd op i feedet før migreringen til Merchant API

Af Greg Nowak. Senest opdateret 2026-06-26.

Google har fastsat datoen: Content API for Shopping lukkes den 18. august 2026. Pr. 26. juni 2026 er der mindre end otte uger til at finde samtlige afhængigheder, rydde op i svag feedlogik og flytte produktionsworkflows til Merchant API uden at skade produkternes synlighed.

For ecommerceteams er det ikke blot en opgave til udviklerne. Produktfeeds indeholder typisk priser, lagerstatus, landemålretning, lokal lagerbeholdning, kampagner, PIM-berigelse, ERP-data, manuelle rettelser og scripts, som vedligeholdes af bureauer. Hvis der ikke er overblik over disse dele nu, vil en forhastet API-migrering gøre rodet sværere at gennemskue – ikke driften lettere.

Hvad Merchant API ændrer i praksis

Merchant API er Googles aktuelle programmatiske platform til arbejdet med Merchant Center. Den omfatter produkter, konti, lagerbeholdninger, datakilder, kampagner, rapporter, returpolitikker, diagnostik med mere. Det brede omfang er vigtigt, fordi mange Content API-installationer gør mere end at uploade produkter. De kontrollerer også status, afstemmer lagerbeholdning, tilføjer supplerende attributter, henter rapporter eller understøtter interne administrationsværktøjer.

Vejledningen til produktmigrering peger på flere ændringer, som påvirker virkelige systemer:

Indsendte og behandlede data er adskilt. Merchant API bruger ProductInput til indsendte skriveoperationer, mens read-only-ressourcen Product viser det behandlede produkt, efter at Google har anvendt regler, kombineret kilder og tilføjet statusoplysninger.
Skriveoperationer kræver en datakilde. Skriveoperationer med productInputs kræver en dataSource. Det tvinger teamet til at beslutte, hvilket system der ejer det primære feed, og hvilke systemer der må tilføje supplerende data.
Identifikatorerne får en ny form. Produkt-id'er bevæger sig mod REST-ressourcenavne som accounts/{account}/products/{product}, hvor produktnøglerne baseres på sprog, feed label og offer ID. Kodning og opslagslogik kræver opmærksomhed.
Statusworkflows skal genopbygges. Den gamle productstatuses-service fjernes. Statusoplysninger er nu en del af den behandlede Product-ressource.
Batch- og opdateringsadfærd ændres. products.custombatch findes ikke i Merchant API, og productInputs.patch opfører sig anderledes end antaget i ældre opdateringslogik. Køer, retries og opdateringer, der ankommer i forkert rækkefølge, bør testes.
Felterne er mere restriktive. Attributter som titel, pris og link ligger nu i productAttributes, og nogle værdier, der tidligere var frie tekststrenge, er nu enums.

Migreringsområde	Risiko, hvis det overses	Praktisk handling
Datakilder	Systemerne overskriver hinandens data eller flytter tilbud til den forkerte kilde.	Kortlæg ejerskabet over primære og supplerende data, før der skrives ny kode.
Produkt-id'er	Teamene kan ikke spore fejlede produkter på tværs af logs, feeds og Merchant Center.	Standardisér offer ID'er, feed labels, kodning og opslagsværktøjer.
Statushåndtering	Afviste produkter bliver overset, indtil salget eller trafikken falder.	Genopbyg overvågningen omkring behandlede produkter og diagnostik.
Batch-jobs	Store opdateringer fejler langsomt, håndterer retries dårligt eller anvendes i forkert rækkefølge.	Test batching, samtidighed, retries og versionsstyring under belastning.
Oprydning i feeds	Gamle regler for lande, lagerbeholdning og overrides kopieres over i den nye API.	Ryd op i feedmodellen før overgangen – ikke bagefter.

En praktisk migrering til Merchant API forbinder de tekniske ændringer med ejerskab over feeds, overvågning og ecommercedrift.

Hvorfor oprydning hører hjemme i migreringen

Ældre Content API-opsætninger afspejler ofte mange års små ændringer. Googles egne release notes viser, hvordan feedmodellen har udviklet sig, blandt andet med supplerende Content API-feeds, feedLabel og udfasningen af targetCountry. Hvis jeres katalog stadig bygger på nedarvede antagelser om lande, manuelle overrides eller uklare regler for lokale produkter i forhold til onlineprodukter, er overgangen til Merchant API det rette tidspunkt at få dem rettet.

Det er også et spørgsmål om forretningsmæssigt ejerskab. Udviklerne kan oversætte endpoints, men driftsorganisationen skal bekræfte, hvilket system der må ændre pris, tilgængelighed, titel, leveringsberettigelse, lokal lagerbeholdning, kampagner og supplerende attributter. Uden den afklaring kan den nye integration være teknisk korrekt og alligevel skabe uigennemskuelig adfærd i kataloget.

En realistisk plan frem mod 18. august

Begynd med at registrere alle afhængigheder af Content API. Medtag planlagte jobs, lagersynkroniseringer, scripts til supplerende feeds, kampagneværktøjer, rapportudtræk, diagnostik, interne administrationsknapper, bureauscripts og manuelle runbooks. Det er ofte i de små scripts, at de risikable antagelser gemmer sig.

Kortlæg derefter hver afhængighed i forhold til Merchant API-ressourcerne, og beslut, om den skal genopbygges, erstattes eller udfases. Produktskrivninger, behandlede læsninger, diagnostik, rapporter, lageropdateringer og kampagner skal hver især have en navngiven proces og en navngiven ejer.

Ryd dernæst op i katalogmodellen. Normalisér offer ID'er, feed labels, sproghåndtering, logik for leveringslande, lagerfelter, enum-værdier, håndtering af lokale produkter og supplerende overrides. Hvis de personer, der driver butikken, ikke klart kan forklare en regel, bør den ikke genopbygges i stilhed.

Til sidst skal overgangen forberedes trinvis. Kør det nye flow parallelt, hvor det er muligt, sammenlign indsendte ProductInput-data med behandlede Product-data, gennemgå diagnostikken, test sletninger og opdateringer, og øv rollback. Vær særligt opmærksom på forsinket synlighed, delvise fejl, retry-loops og rækkefølgen af opdateringer. Merchant API indeholder styringsmekanismer som versionNumber af en grund.

Her kan Greg hjælpe

Opgaven egner sig godt til en ekstern digital projektleder, når virksomheden forstår sin webshop, men mangler ledig integrationskapacitet. Greg kan hjælpe med at gennemgå den nuværende feed-stack, koordinere udviklere og bureauer, omsætte brugen af Content API til konkrete Merchant API-opgaver, skabe klarhed over ejerskabet af datakilder og sikre, at udrulningen styres efter driftsrisiko – ikke blot efter identiske endpoints.

Hvis Content API stadig findes et sted i jeres ecommerce-stack, bør 18. august 2026 betragtes som stopdatoen – ikke som projektets startdato.

Relateret indhold på GrN.dk

Har I brug for hjælp til denne type opgave?

Få afgrænset jeres Merchant API-migrering. Kontakt Greg.

Kilder

Sidst ændret

2026-08-23