WordPress og WooCommerce
hvordan du sender en WooCommerce-produktfeed til Google Merchant Center
hvorfor Google Merchant-avvisninger vises etter WooCommerce-katalogredigeringer
Google Merchant Center avviser eller begrenser produkter når titler, GTIN-er, bilder, priser eller tilgjengelighet ikke stemmer overens med landingssiden. WooCommerce-kataloger endres hele tiden: lagernedgang ved bestilling, kampanjepriser med planlegging, attributtredigeringer for størrelsesdiagrammer og manglende identifikatorer på eldre SKU-er. Programtillegg som dumper en fullstendig XML-feed én gang om dagen, lar Shopping-annonser kjøres med gammel tilgjengelighet, noe som fører til avvisninger og bortkastede forbruk. Flerspråklige butikker og butikker med flere valutaer må sende ut riktig språk og valuta per målland, ikke en eneste PL-feed for hver EU-kampanje. GTIN- og merkevaregap er kroniske på private merkevarer. Kategorikartlegging fra WooCommerce-kategorier til Googles produkttaksonomi beveger seg når selgere finner opp nye butikkkategorier. Variantprodukter trenger disiplin for item_group_id, eller selgeren behandler hver størrelse som et ikke-relatert tilbud. Frakt- og avgiftsfelt som er nøyaktige ved kassen kan være fraværende i feeden, så gratisoppføringen ser billigere ut enn kassen og blir suspendert. Uten automatisering som regenererer på kataloghendelser, validerer obligatoriske felt og varsler om avvisningstopper, oppdager kanaloperasjoner problemer i Merchant UI dager senere. Innen da har Shopping-kampanjer begrenset leveringen. Markedsledede kataloger skaper ekstra drift. Hvis Baselinker eller en ERP presser pris inn i WooCommerce etter at selgeren allerede har hentet morgenfeeden, kan Shopping-annonser være uenige med kassen i timevis. Automatiseringen må enten lappe selger raskt gjennom Content API eller midlertidig pause SKU-en når et konfliktvindu oppdages. Tilbakevendende kunder som ser én pris i Google og en annen i kassen genererer støttebilletter som ser ut som kupongfeil, men som egentlig er feedlag. Regionale sortimentsregler har også betydning. Noen SKU-er kan selges innenlands, men ikke i selgerens destinasjonsland på grunn av frakt eller overholdelse. Å sende dem ut globalt inviterer til avvisning av retningslinjer. Kod destinasjonskvalifisering ved siden av produktet, ikke i en engangsekskludering av selgergrensesnittet som ingen speiler tilbake til WooCommerce. Friskheten til image_link er også viktig: Bytting av et livsstilsbilde uten å oppdatere feeden fører til en ødelagt eller utdatert CDN-bane og utløser feil gjennomsøking av bilder som undertrykker gratis oppføringer. Skriv ned eiere for hvert URL-mønster før live, slik at varsler ikke hopper mellom SEO, betalte medier og utvikling uten oppløsning. En navngitt eier forkorter gjennomsnittlig tid til å omdirigere reparasjoner mer enn en annen dashbord-widget.
når du skal regenerere og sende inn Merchant Center-produktfeeden på nytt
Regenerer berørte SKU-er når produktpris, lager, synlighet, avgiftsklasse eller primærbilde endres, og når en planlagt kampanje starter eller slutter. Kjør en full feed-rebuild nattlig som avstemming. Utløs også etter bulk-CSV-import og etter markedsplasssynkroniseringsjobber som omskriver WooCommerce-priser. For mål for flere land, gjenoppbygg den lokalitetsspesifikke feeden når oversettelsesfeltene endres i WPML eller når en valutakurstabell som brukes for selgerpriser oppdateres. På lager null, trykk tilgjengeligheten ut av lager umiddelbart, selv om hele gjenoppbyggingen er timer unna. Prioritet bør favorisere tilgjengelighet og prisriktighet fremfor beskrivende tekstoppdateringer.
hvordan bygge validere og laste opp en WooCommerce Google Merchant-feed
- Velg produkter som er publisert, kjøpbare, på lager eller restordre i henhold til retningslinjene, og som ikke ekskluderes av et selgerundertrykkelsesattributt.
- Tilordne WooCommerce-felter til selgerattributter: id, tittel, beskrivelse, lenke, bildelink, tilgjengelighet, pris, salgspris, merke, gtin eller identifikator_eksisterer, item_group_id og google_product_category.
- Valider nødvendige attributter per destinasjonsland; karantene-SKU-er som mangler GTIN når identifier_exists er falsk bare hvis policyen tillater det, ellers blokker dem fra feeden og åpne en salgsoppgave.
- Skriv XML- eller tekstfeed til en stabil HTTPS-URL beskyttet mot tilfeldig skraping om nødvendig, eller trykk via Content API for Shopping for raskere delvise oppdateringer.
- Be Merchant Center om å hente feeden eller oppdateringsproduktene gjennom API-en. lagre batch-ID og tidsstempel i en synkroniseringslogg.
- Trekk avslag og ventende tellinger via Merchant API inn i et dashbord og varsle når frekvensen overstiger grunnlinjen etter et katalogendringsvindu.
- På lager som når null eller en prisendring over en terskel, send en prioritert tilgjengelighet eller prisoppdatering gjennom Content API uten å vente på den nattlige full gjenoppbyggingen.
Systemer
- WooCommerce
- Google Merchant Center
- Baselinker (optional)
- ERP price source
Verktøy
- custom PHP feed endpoint
- Content API for Shopping
- WP-Cron
- n8n
dataflyt fra WooCommerce-katalogen til Merchant Center
WooCommerce er katalogautoriteten. En generator implementert som et tilpasset plugin-endepunkt, WP-Cron pluss statisk fil i opplastinger, eller en n8n-arbeidsflyt som leser REST API, bygger feeden. For store kataloger, foretrekk differensielle Content API-oppdateringer på webhookte produktendringer og hold en daglig full avstemmingsfil for revisjon. Googles produktklassifikasjonskartlegging kan brukes i et regneark speilvendt til butikken. Pris og valuta må samsvare med landingssiden feedlinken peker til. hvis du bruker geolokaliserte priser, sender du ut separate feeder per selgerdestinasjon. Verktøy som Make er akseptable for små kataloger; n8n eller tilpasset PHP-skala bedre når SKU-teller treffer titusenvis og hastighetsgrenser betyr noe. Hold en karantenetabell over SKU-er ekskludert fra feeden med årsaker (manglende bilde, manglende GTIN, destinasjonsside noindex, undertrykt merkevare). Merchandisers bør jobbe med den køen i WordPress eller et delt ark. Koble varsler til den samme ops-kanalen som synkroniseringsfeilvarsler, slik at feedhentingsfeil ikke bare er synlige i Merchant Center. Persondata følger Datatilsynet-krav i databehandleravtalen med integrasjonsleverandøren. Regnskapssystemet kan være Tripletex, Fiken eller et ERP i stedet for kun et faktura-SaaS. For feed-google-merchant: dokumenter Slack-varsel-eier, retry-grense, dead-letter-kriterium og tre staging-tester før produksjon. Ikke bland denne runbooken med andre butikkautomatiseringer.
fikse Merchant Center-avvisninger og feil ved innmating
Hvis feed-hosting returnerer 500 under Merchant-henting, la den forrige vellykkede filen være uforanderlig til den nye versjonen valideres, og deretter atomic-swap. Hvis Content API returnerer kvotefeil, senker køen og prioriter tilgjengelighet og prisoppdateringer over beskrivelsestekst. Når avvisninger oppgir feil pris, frys kampanjeautomatisering som skriver sale_price uten å oppdatere landingssidemalen. Ved feil med image_link, fall tilbake til et sekundært bilde bare hvis det oppfyller selgerens regler; ellers ekskluder SKU-en og varsle merchandising. Slipp aldri mer enn en konfigurert prosentandel av katalogen uten et varsel. Hvis Google returnerer gratis oppføringssuspensjoner på kontonivå, må du stoppe støyende varsler per SKU og søke en menneskelig eier med kontoproblemet. Per-SKU-forsøk vil ikke fjerne tilbakehold av kontopolicyer. Når en landingsside ikke er indeksert ved en feiltakelse, må du oppdage den i validatoren før opplasting i stedet for å vente på avvisning under gjennomsøking. For feed-google-merchant: dokumenter Slack-varsel-eier, retry-grense, dead-letter-kriterium og tre staging-tester før produksjon. Ikke bland denne runbooken med andre butikkautomatiseringer.
når en Merchant Center-feedautomatisering ikke er verdt det
En butikk med ti SKUer som redigerer produkter ukentlig, kan laste opp et manuelt ark i Merchant Center. Automatisering lønner seg når katalogavgang, annonseforbruk eller SKU-antall gjør gammel tilgjengelighet dyrt. Vent også hvis merkevare-, GTIN- og taksonomidata fortsatt er så ufullstendige at hver automatisert versjon vil sette det meste av butikken i karantene. Hvis Shopping-annonser er satt på pause på ubestemt tid og du bare trenger en symbolsk tilstedeværelse i selgeren, er en månedlig manuell opplasting nok. Gå tilbake til automatiseringen når annonseforbruket gjenopptas eller organiske gratisoppføringer genererer materialøkter. For feed-google-merchant: dokumenter Slack-varsel-eier, retry-grense, dead-letter-kriterium og tre staging-tester før produksjon. Ikke bland denne runbooken med andre butikkautomatiseringer.
KPI-er for automatisering av Google Merchant-feed
- Andel av aktive SKU-er godkjent i Merchant Center
- Mediantid fra WooCommerce-pris eller lagerendring til selgersynlig oppdatering
- Avvisninger åpnet per 1000 matede SKU-er per uke
- Feil fra fôrhenting per måned
ROI-kalkulator for automatisering
Skriv inn kjøringer per måned, minutter per kjøring og belastet timekostnad. Resultatet er en simulering, ikke et tilbud på vårt arbeid.
Timer = kjøringer × minutter / 60 × tilbake %. Tidsverdi = timer × sats × realisering %. Unngåtte feil = kjøringer × feil % × feilkostnad × realisering %. Netto = sum − drift. Tilbakebetaling = bygging / netto, bare når netto > 0.
Timer hentet tilbake / måned: -
Timer hentet tilbake / år: -
Tidsverdi / måned: -
Unngått feilkostnad / måned: -
Netto / måned: -
Tilbakebetaling (måneder): -
Resultat første år: -
Ofte stilte spørsmål
Praktiske svar for å bruke temaet i faktisk arbeid.
Feedfil eller Content API?
#Hvordan skal variable produkter fremstå?
#Hva med manglende GTIN-er på private label-varer?
#Hvordan skal fraktkostnadene vises i feeden?
#Trenger du FAQ tilpasset bransje og marked? Vi lager en versjon som støtter dine forretningsmål.
Ta kontakt