WooCommerce-migrering til Merchant API

Google slo av Content API for Shopping 18. august 2026. Hvert kall til de gamle v2.1-endepunktene kommer nå tilbake som HTTP 410 Gone, og en integrasjon som fortsatt peker mot dem, sender ikke lenger produkter, priser og lager til Google Merchant Center. Det første du bør gjøre er derfor ikke å lese videre, men å sjekke om din egen feed står stille. For en stor andel av WooCommerce-butikkene er svaret at alt går som før.

Den ærlige versjonen av denne historien er en triage, ikke en krise. Hos WPPoland bygger og vedlikeholder vi WooCommerce-integrasjoner for handlende som selger over hele EU, så her er hvem avviklingen faktisk traff, hvordan du bekrefter om butikken din er blant dem, og hvorfor den samme migreringen stille er døren inn til agentdrevet handel.

#Når ble Content API for Shopping slått av

Content API for Shopping er Googles gamle programmatiske flate for å styre alt en butikk sender til Merchant Center: produktdata, lager, priser og kontoinnstillinger. Den er erstattet av den nyere Merchant API, som dekker samme område, men er delt i fokuserte sub-API-er (Products, Inventories, Accounts, Reports) i stedet for ett monolittisk endepunkt.

Datoen som betyr noe, var 18. august 2026. Fra da av returnerer den gamle Content API 410 Gone, og den kommer ikke tilbake. En tidligere dato er også passert: v1beta av Merchant API ble avviklet 28. februar 2026, så kode som fortsatt står på betaen, må over på stabil v1 på samme måte.

#Hvilke WooCommerce-butikker må migrere til Merchant API

Dette spørsmålet avgjør om du kan lukke denne fanen. En WooCommerce-butikk snakker typisk med Merchant Center på tre måter.

• Den offisielle utvidelsen Google for WooCommerce. Hvis produktsynkroniseringen din går gjennom den offisielle utvidelsen (tidligere Google Listings and Ads), er du dekket. Overgangen til Merchant API kom inne i en utgivelse av utvidelsen, så det eneste som krevdes av butikken, var å kjøre en oppdatert versjon. Bekreft versjonsnummeret og at produktene fortsatt oppdateres i Merchant Center, så er du ferdig.
• En tredjeparts feed- eller markedsføringsutvidelse. Noen av disse kalte Content API direkte. Bekreft hos leverandøren at Merchant API-oppdateringen er levert, og at butikken faktisk kjører versjonen som inkluderer den.
• En egen integrasjon. Skreddersydde koblinger, egne feed-eksportører, headless-oppsett som pusher til Merchant Center fra din egen kode, og interne verktøy skrevet mot Content API. Dette er gruppen der feeden stopper hvis migreringen ikke ble gjort, og nettopp den typen bygg byråer setter opp for større eller ustandardiserte butikker.

I det norske markedet kommer det gjerne til et typisk tilfelle: en butikk som med én egen eksportør mater både Google Merchant Center og Prisjakt samtidig. Google er da bare én av flere kanaler i det skriptet, så migreringen av denne ene grenen til Merchant API må skje uten å røre de øvrige feedene, som fortsetter som før.

Er du i den første gruppen og produktene fortsatt oppdateres, stopp her. Er du i den tredje, les videre.

#Merchant Center-feeden oppdateres ikke lenger

Ingenting degraderes pent. Fra 19. august 2026 feiler kallene rett og slett med 410 Gone, og virkningene kaskaderer:

• Oppføringene blir foreldet. Nye produkter dukker ikke lenger opp, og fjernede produkter kan bli hengende igjen. Merchant-Center-katalogen din driver bort fra den faktiske WooCommerce-katalogen din.
• Priser og lager slutter å oppdateres. Dette er den farlige. Merchant Center viser fortsatt den siste prisen og tilgjengeligheten den mottok, så du kan ende opp med å annonsere en pris du ikke lenger tar, eller et produkt du ikke lenger har på lager, noe som risikerer avvisninger og tap av kontotillit.
• Shopping- og Performance Max-kampanjer sulter. Google Ads-kampanjer lever av produktdataene fra Merchant Center. Når feeden fryser, kjører kampanjene på utdatert lager til de stille begynner å underprestere.

Fordi alt feiler på én gang i stedet for med en advarsel, ser en butikk som ikke rakk fristen, fortsatt normal ut i WooCommerce-admin. Den trygge antakelsen er at du må verifisere i Merchant Center i stedet for å stole på at ingen har klaget.

Google skriver i hjelpen for Merchant Center at automatiske oppdateringer ikke erstatter jevnlige oppdateringer av produktdataene dine. De skal bare rette sporadiske feil i pris, tilgjengelighet og stand. Hvis du forventer at pris, tilgjengelighet og stand på produktene endrer seg ofte, sier Google at du bør bruke Merchant API. For en butikk med raskt skiftende lager betyr det å sende endringene fra integrasjonen, ikke å vente på at Google retter dataene fra sidene dine.

#Slik migrerer du en WooCommerce-integrasjon til Merchant API

Arbeidet er metodisk snarere enn vanskelig, og det er alminnelig serverside-WooCommerce-utvikling. Ett punkt er endret nå som fristen er passert: du begynner med å bekrefte statusen.

• Bekreft at feeden faktisk står. Se i Merchant Center når produktdataene sist ble oppdatert, og let etter 410-svar i loggene til integrasjonen. Det avgjør om dette er en planlagt migrering eller en opprydding.
• Kartlegg Content API-kallene dine. List opp hvert endepunkt integrasjonen berører, og WooCommerce-hendelsen som utløser det (produktlagring, lagerendring, planlagt fullsynkronisering).
• Kartlegg hvert kall til sin Merchant API-sub-API. Products, Inventories, Accounts og Reports overtar hver sin del av det Content API gjorde på ett sted.
• Autentiser på nytt. Merchant API bruker OAuth 2.0 eller en tjenestekonto. Bekreft at legitimasjonen og scopene dine overføres.
• Sjekk feed-etiketter etter overgangen. Etikettkonfigurasjonen overlever ikke alltid overgangen, og etiketter styrer kampanjestrukturen, så verifiser dem i stedet for å anta.
• Hent de samlede avvisningsgrunnene fra Reports-sub-API-en når den nye integrasjonen kjører, slik at du fanger opp alt overgangen endret før Googles algoritmer gjør det.

#Merchant API og MCP for KI-handleagenter

Migrering forstått som en plikt bommer på poenget. Overgangen til Merchant API åpner også Merchant API MCP Access Service, en alfa-bro som eksponerer Merchant-Center-data for LLM-er og KI-agenter over Model Context Protocol, foreløpig kun lesing pluss noen få lavrisiko-skriveverktøy. Enkelt sagt: den samme plattformen produktfeeden din nå bor på, er den KI-handleassistenter leser fra når de avgjør hvilke produkter de skal vise.

Det knytter avviklingen til det større skiftet vi har skrevet om: butikker går fra å bli bladd i av mennesker til å bli spurt av agenter. Migreringen du uansett måtte gjøre, er samtidig påkjøringen til å bli oppdagbar og kjøpbar for disse agentene, som er hele poenget i vår guide til KI-handelsberedskap.

Samtaleattributter, oppdatert 23. oktober 2026: Siden Google Marketing Live i mai 2026 har produktdataspesifikasjonen i Merchant Center seks valgfrie felt beregnet på AI-modus og lignende AI-flater. Googles hjelpeside om samtaleattributter lister dem opp: question_and_answer (spørsmål og svar om produktet, opptil 1000 tegn hver), document_link (PDF-manualer, brukerveiledninger, monteringsanvisninger), related_product (tilbehør, nødvendige deler, erstatningsprodukter), item_group_title og variant_option (en felles tittel for en produktfamilie og egenskapene som skiller variantene) og popularity_rank (et tall fra 0 til 100 som plasserer produktet mot resten av sortimentet ditt). Google anbefaler en supplerende datakilde, sier at feltene ikke endrer godkjenningsstatusen til eksisterende produkter, og ber deg ikke gjenta det som allerede står i description, product_highlight eller product_detail. Kolonnene er de samme uansett hva som lager produktfeeden: en WooCommerce-utvidelse, en feed-app i en Shopify-butikk eller en egen eksport. Den billigste kilden er innhold du allerede har, som spørsmål og svar på produktsiden og PDF-manualene som er lenket fra produktsidene.

#Hva gjør du når WooCommerce-feeden til Google står

Bruker du den offisielle utvidelsen, bekreft versjonen, se at produktene fortsatt oppdateres i Merchant Center, og gå videre med dagen. Har du en egen eller tredjeparts integrasjon som ennå ikke er migrert, står den stille nå: finn ut hvilke sub-API-er du er avhengig av, og kjør migreringen mot en ikke-produksjonskonto før du peker produksjonstrafikk mot de nye verktøyene, for det er nettopp det Google anbefaler.

Vi håndterer disse migreringene som en del av arbeidet vårt som WooCommerce-utvikler, ved siden av analysesiden av agentdrevne bestillinger, som vi dekker i hva som skjer når en KI-agent sjekker ut, og den kun lesende WooCommerce-MCP-serveren, som viser hvordan agenter i det hele tatt leser en katalog.

#Slik sjekker du at Merchant API-synkroniseringen virker

Når den migrerte integrasjonen peker mot produksjon, er det Merchant Center som viser om den virker. Endre prisen eller lagerstatusen på et par testprodukter i WooCommerce og se at endringen kommer fram i Merchant Center. Priser og lager gjør mest skade når de fryser, så de bør testes først. Sammenlign deretter antall aktive produkter i Merchant Center med den publiserte katalogen i WooCommerce, slik at nye produkter kommer med og fjernede produkter ikke blir hengende.

Gå så gjennom feed-etikettene og kampanjestrukturen de styrer i Shopping og Performance Max, og hent avvisningsgrunnene fra Reports-sub-API-en på nytt etter de første fullsynkroniseringene. Mater den samme eksportøren også Prisjakt eller andre kanaler, sjekk at de feedene fortsatt oppdateres som før, siden migreringen bare skulle berøre Google-grenen. Behold loggingen av svarkoder fra integrasjonen, så en ny feil viser seg i loggen før den viser seg i kampanjetallene.

#Hvorfor Google viser en salgspris som ikke står i WooCommerce-feeden

En fungerende Merchant API-synkronisering forteller Google hva butikken sender i dag. Google fører likevel sin egen logg over hva den har sett tidligere. Emina Demiri-Watson beskrev 5. oktober 2026 i Search Engine Journal en britisk butikk der Google viste Was £474, now £355 med salgsmerke i Shopping. Butikken hadde ikke salg, og hadde aldri sendt attributtet sale_price, verken i dagens feed eller i eldre. Tre signaler ga merket til sammen:

• feeden sendte £355 som pris uten MVA, mens Googles siste gjennomsøking av siden leste £426, altså samme pris med MVA,
• Product-markeringen var en AggregateOffer med to priceSpecification-nivåer, List price til £395 og Sale price til £355, og £395 uten MVA er £474 med MVA,
• HTML-en på siden skrev Now ved siden av prisen, og en feed-eksport fra 15. april hadde fortsatt £474 i prisfeltet.

Ingen av signalene ba om et merke alene. Forfatteren oppsummerer med to setninger: “Folk glemmer. Systemer gjør det ikke” (Emina Demiri-Watson, Search Engine Journal, egen oversettelse).

Merker som butikken selv ber om via sale_price, har egne vilkår. Google sjekker at rabatten ligger mellom 5% og 90%, og at grunnprisen er sendt lenge nok, i Storbritannia “minst 30 dager i løpet av de siste 200 dagene” (Emina Demiri-Watson, Search Engine Journal, egen oversettelse). Prisfall-merknader krever ingen innsending i det hele tatt: Google sammenligner dagens pris med gjennomsnittet den selv har registrert de siste 60 dagene. Omfanget av denne hukommelsen ifølge samme artikkel: Shopping Graph inneholder “over 50 milliarder produktoppføringer, og mer enn 2 milliarder av dem oppdateres hver time” (Emina Demiri-Watson, Search Engine Journal, egen oversettelse).

I en norsk butikk endrer bare tallet seg. For en vare med alminnelig sats på 25% ligger den gjennomsøkte prisen 25% over feed-prisen når feeden sender pris uten MVA og siden viser pris med MVA. Matvarer med 15% gir et annet avvik. En butikk med blandede satser ser derfor ikke ett jevnt avvik i hele katalogen.

#Slik sammenligner du feed-prisen med prisen i Product-schema i WooCommerce

• Start med det Google så. Åpne produktet i Merchant Center under Products > All products (navn fra det engelske grensesnittet) og bla til bunnen av fanen Product details. Delen Information found on your site viser prisen Google sist leste fra siden, med dato. Er avviket lik MVA-satsen, sender feeden netto og siden viser brutto.
• Sjekk WooCommerce > Settings > Tax. Valget for om priser legges inn med avgift avgjør hva den lagrede prisen betyr, og valget for prisvisning i butikken avgjør om kunden ser den med eller uten MVA. Sammenlign med det feed-eksportøren sender. Viser siden brutto og feeden netto, må Google gjette avgiften selv.
• Les den ferdige JSON-LD-en, ikke innstillingssiden. Åpne kildekoden til en produktside og finn hver application/ld+json-blokk med en Product. WooCommerce skriver ut sin egen Product-markering, og en SEO-utvidelse kan legge til en til som ikke stemmer med den. Se etter en ekstra pris og etter navn i priceSpecification med Sale eller List.
• Let etter salgsord i HTML-en. WooCommerce legger ordinær pris i <del> og salgspris i <ins> når produktet har en salgspris, og temaer legger ofte til etiketter som “Før” og “Nå”. Viser et produkt uten salg noen av dem, bytt etiketten. Forfatteren råder til det samme.
• Ta vare på daterte feed-eksporter. Den britiske saken ble løst fordi en eksport fra april tilfeldigvis lå lagret. Én lagret eksport i måneden gjør neste feilsøking til en sammenligning av to filer, også for feeden til Prisjakt hvis den kommer fra samme eksportør.

#Hva du gjør med bilder av utgåtte produkter i WooCommerce

Google har sin egen indeks over produktbilder, uavhengig av image_link i feeden og av schema. Så lenge en gammel bilde-URL svarer, kan Google fortsette å bruke bildet i annonser og gratis produktoppføringer, selv om butikken byttet det for lenge siden. Artikkelen nevner WooCommerce direkte: “WooCommerce-opplastinger ligger i det vanlige mediebiblioteket i WordPress og blir sjelden ryddet når produkter tas ut av sortimentet” (Emina Demiri-Watson, Search Engine Journal, egen oversettelse).

• Å slette et produkt sletter ikke bildene. Når du tar et produkt ut av salg eller bytter et bilde, slett det gamle vedlegget under Media > Library med Delete permanently. WordPress fjerner filen og de genererte størrelsene, og den gamle URL-en svarer 404, det rene signalet artikkelen anbefaler. Sjekk først at ingen andre produkter eller sider bruker bildet.
• Et nytt filnavn lar den gamle filen ligge ute. Et bilde lastet opp under et annet navn gir Google to bilde-URL-er for ett produkt, og Google velger ikke alltid det nyeste.
• Bekreft 404 på selve adressen. Åpne den gamle bildeadressen etter slettingen. Et CDN eller en sidebuffer kan fortsatt levere filen etter at WordPress har fjernet den.
• Søk etter det gamle filnavnet i Google Bilder. En kopi på en markedsplass eller en glemt side hos noen andre kan være kilden til feil bilde, og den kopien må fjernes der den ligger.

Sist oppdatert: 11. oktober 2026.