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
ProductInputtil indsendte skriveoperationer, mens read-only-ressourcenProductviser det behandlede produkt, efter at Google har anvendt regler, kombineret kilder og tilføjet statusoplysninger. - Skriveoperationer kræver en datakilde. Skriveoperationer med
productInputskræver endataSource. 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 behandledeProduct-ressource. - Batch- og opdateringsadfærd ændres.
products.custombatchfindes ikke i Merchant API, ogproductInputs.patchopfø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. |
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
- AI-shoppingflader gør produktdataintegritet til en opgave for Technical Ops
- Risikoen ved Google AI Overviews gør rettelse af brandresuméer til en oprydning i den autoritative datakilde
- Efter Googles ændrede vejledning for 2026 er synlighed i AI-søgning blevet et måleproblem
Har I brug for hjælp til denne type opgave?
Få afgrænset jeres Merchant API-migrering. Kontakt Greg.
