Headless WordPress for WooCommerce: når det lønner seg, og hva du bør droppe
Spørsmålet “passer headless WordPress for WooCommerce” handler sjelden om teknologi. Det handler om nettbutikken fortsetter å fungere gjennom migreringen, om de eksisterende utvidelsene overlever, og om den nye arkitekturen betaler seg tilbake innenfor én budsjettsyklus. Det ærlige svaret: det kommer an på butikken.
Denne artikkelen gjør vurderingen konkret. Den hører til tjenestesiden vår for Headless WordPress og artikkelen vår om økonomien i headless, der kostnadsmodellen er beskrevet.
Hvilke nettbutikker passer headless WooCommerce for
- Godt valg for nettbutikker der mobile Core Web Vitals begrenser konverteringen.
- Godt valg for nettbutikker med stabile kataloger som caches godt på edge.
- Dårlig valg for små nettbutikker der orkestreringskostnaden er større enn besparelsen.
- Dårlig valg for nettbutikker med tunge WooCommerce-utvidelser som forutsetter PHP-gjengitt frontend.
- Edge-kjøremiljø: Cloudflare Workers håndterer både Astro og Next.js med WordPress som origin.
Hva headless WooCommerce faktisk betyr
WordPress med WooCommerce beholder den redaksjonelle arbeidsflyten, ordrehåndteringen, lageret og betalingsbehandlingen. Den headless frontenden (Astro eller Next.js) gjengir den offentlige katalogen, produktsidene og grensesnittet for handlekurv og kasse. De to kommuniserer via Store API i WooCommerce, REST API eller GraphQL.
Tre deler av arkitekturen er avgjørende:
Originen. Fortsatt WordPress. Fortsatt WooCommerce. Samme adminpanel, samme utvidelser, samme betalingsflyt. Redaktørene bytter ikke verktøy.
Frontenden. Astro eller Next.js på Cloudflare Workers. Leverer ferdigbygd HTML for katalog og produktsider, og faller tilbake til SSR for handlekurv og kasse. Leser fra WordPress-originen.
Grensen. REST eller GraphQL mellom de to. Informasjonskapsler og headere bevares over grensen slik at økten henger sammen. Dette er den bærende delen, og den som brekker først hvis en juniorutvikler leverer.
Når lønner headless WooCommerce seg
Konkrete scenarier der regnestykket blir positivt:
- En motebutikk med 200 produkter, 70 prosent mobiltrafikk og en mobil LCP under 2 sekunder som er direkte knyttet til konvertering.
- En B2B-katalog med 5000 stabile SKU-er der de fleste sidene ligger i edge-cache i flere timer.
- En WooCommerce-butikk som også er katalogkilde for en mobilapp eller en AI-handleagent (Universal Commerce Protocol).
- Et nettsted som allerede leverer sin egen JS-bunt med mye interaktivitet, der redaksjonell WordPress og Next.js sammen ikke koster stort mer enn dagens oppsett.
I alle fire er gevinsten en blanding av Core Web Vitals gjengitt på edge (effekt på omsetningen) og forutsigbare kostnader for Cloudflare Workers (besparelse).
Når lønner headless WooCommerce seg ikke
Konkrete scenarier der det ikke lønner seg:
- Nettbutikker med ett produkt eller under 20 SKU-er og lite trafikk. Migreringskostnaden overskygger besparelsen.
- Nettbutikker med over 10 aktive WooCommerce-utvidelser som berører frontenden. Hver av dem trenger en gjennomgang, ofte en ny implementering eller et hybridbygg.
- Svært ustabil beholdning (live-auksjoner, lynsalg, sanntidsbookinger). Kostnaden ved cache-invalidering stiger raskere enn besparelsen i frontenden.
- Sterkt personaliserte priser per kunde. Edge-caching svekkes, og arkitekturen mister mye av fordelen.
Den spissformulerte versjonen: headless er ikke standardvalget. Standardvalget er å bli værende monolittisk til flaskehalsen flytter seg til frontenden. Når flaskehalsen er mobile Core Web Vitals, begynner byttet å lønne seg.
Hva du bør sjekke før headless WooCommerce
Gjennomgangen en erfaren utvikler gjør før noen forpliktelse til migrering:
- List opp alle aktive WooCommerce-utvidelser. Merk hver som “støtter headless”, “må implementeres på nytt” eller “blokkerer headless”.
- Ta et øyeblikksbilde av mobile Core Web Vitals for de 50 viktigste produktsidene. Er LCP og INP allerede gode, blir besparelsen med headless mindre.
- Kartlegg trafikkprofilen: besøksvolum, andel tilbakevendende besøkende, mobilandel, geografisk fordeling. Høy mobilandel og spredt geografi taler for headless på Cloudflare Workers.
- Kartlegg historikken for videresendinger. WooCommerce-nettsteder samler opp videresendinger fra omdøpte produkter og omstrukturerte kategorier. Migreringen må bevare dem.
- Finn kundespesifikke priser og øktstyrt innhold. Jo mer det finnes av det, desto mindre blir fordelen med headless.
Resultatet er et ja eller et nei. Vi har frarådet headless-migreringer like ofte som vi har anbefalt dem.
Hva et headless WooCommerce-bygg består av
Når gjennomgangen faller positivt ut, ser bygget til et erfarent team slik ut:
- WordPress med WooCommerce på et lite administrert webhotell som origin.
- Frontend i Astro eller Next.js (etter beslutningsmatrisen Next.js eller Astro).
- Cloudflare Workers + Pages for levering fra edge.
- Redis på WordPress-originen for objektcache og øktlagring.
- WooCommerce Store API aktivert, med rate limiting i Workeren.
- Alle de sju SEO-mønstrene for headless WordPress bevart.
Beslutningene tas i den rekkefølgen. TCO-modellen fra artikkelen om økonomien i headless lukker sirkelen.
Flere artikler om headless WordPress
Denne long tail-artikkelen er forankret i tjenestesiden vår for Headless WordPress og tre støtteartikler. For migreringsrisiko er sjekklisten med sju punkter i artikkelen om SEO-mønstre utgangspunktet. For selve beslutningen bærer matrisen Next.js eller Astro og artikkelen om økonomien i headless tyngden.
For en plattformsammenligning, se Shopify Plus mot WooCommerce headless.
