Wat is headless commerce? Werking, voor- en nadelen en voorbeelden

Headless commerce is een e-commerce-architectuur waarin de webshop die klanten zien (de "head") los staat van het systeem dat producten, prijzen, winkelwagen, checkout en orders afhandelt (de back-end). De twee praten alleen via API's met elkaar. Je kunt de voorkant opnieuw bouwen, herontwerpen of uitbreiden zonder aan de back-end te komen, en één back-end kan meerdere voorkanten tegelijk bedienen: een webshop, een app, een kiosk in de winkel of een marketplace-feed.

In een traditionele opzet, zoals een Shopify-thema of een standaard Lightspeed- of Magento-webshop, horen de templates en de commerce-engine bij één product. Bij headless bouwt een developmentteam de storefront met een framework naar keuze en haalt het elke prijs, elk product en elke winkelwagen uit de API van het platform. Dat geeft je volledige controle over de beleving, maar kost meer ontwikkelwerk en stelt strengere eisen aan je productdata. Hieronder lees je hoe het werkt, wat het verschil is met traditionele en composable commerce, wanneer het loont en wat het verandert voor wie de catalogus beheert.

De drie lagen van een headless winkel

Een headless webshop bestaat uit drie lagen. Elke laag kun je los beheren, hosten en aanpassen.

• De front-end (de head): de code van de storefront, vaak gebouwd met een JavaScript-framework zoals React of Vue. Die rendert pagina's, regelt de navigatie en vraagt data op via API's. Er kunnen meerdere heads zijn: een webshop, een iOS-app en een kassascherm.
• De API-laag: het contract tussen voor- en achterkant. De Storefront API van Shopify werkt alleen met GraphQL, Adobe Commerce biedt GraphQL als basis voor headless storefronts en de Store API van WooCommerce geeft winkelwagen- en checkout-endpoints voor elke front-end.
• De back-end: het commerceplatform dat catalogus, voorraad, prijzen, acties, checkout, betalingen en orders beheert. Productcontent komt vaak uit extra systemen, zoals een headless CMS voor redactionele pagina's en een PIM voor productdata.

Een productpagina in een headless Shopify-shop laat de flow zien. Een klant in Duitsland opent /de/products/merino-sokken-3-pack. De storefront vraagt dat product op bij de Storefront API met land en taal op Duitsland en Duits, en krijgt de Duitse titel, beschrijving, variantopties (maat 39 tot 42, 43 tot 46), prijzen in euro en afbeeldings-URL's terug. Daarna rendert de storefront de pagina in een eigen ontwerp. Niets op die pagina komt uit een themabestand van het platform.

Headless vs traditionele (monolithische) e-commerce

Het verschil zit in waar de storefront draait en wie hem kan aanpassen.

Waar composable commerce en MACH verder gaan

De termen hangen samen, maar betekenen niet hetzelfde. Headless beschrijft één splitsing: de voorkant los van de achterkant. De back-end kan nog steeds één alles-in-één platform zijn. Veel headless shops draaien een eigen React-storefront op een gewone Shopify Plus- of Adobe Commerce-back-end.

Composable commerce gaat verder: ook de back-end bestaat uit losse diensten die je één voor één kiest, zoals zoeken van de ene leverancier, checkout van een tweede en acties van een derde. Headless is een voorwaarde voor composable, maar je kunt headless zijn zonder composable te zijn. MACH-architectuur (microservices, API-first, cloud-native, headless) is het label voor de volledig composable kant van dat spectrum.

Voorbeelden van headless opzetten

De meeste grote platforms ondersteunen een headless modus. Een paar veelvoorkomende patronen:

• Shopify met Hydrogen: Shopify's eigen React-framework voor maatwerk-storefronts, gehost op Oxygen en gevoed door de Storefront API. Shopify omschrijft het als het platform "under the hood" houden terwijl jij de voorkant bepaalt (Shopify).
• Shopify of BigCommerce met een Next.js-storefront: een framework dat het team al kent, op een algemene hostingdienst, met het commerceplatform als pure back-end.
• Adobe Commerce (Magento 2) met een PWA: een progressive web app die catalogus- en winkelwagendata via GraphQL ophaalt.
• Headless WooCommerce: WordPress en WooCommerce blijven catalogus en orders beheren, terwijl een aparte front-end de Store API gebruikt voor winkelwagen en checkout.
• Eén back-end, meerdere heads: een merk met een webshop, een app en touchscreens in de eigen winkels, allemaal op dezelfde producten en voorraad.

Voordelen van headless commerce

De voordelen zijn echt, maar je hebt een team nodig om ze te benutten.

• Vrijheid in ontwerp: de storefront kan er elke gewenste vorm en werking krijgen, zonder de grenzen van secties en instellingen in een thema.
• Snelle front-end: een modern framework met server-side rendering, caching aan de edge en lichte pagina's kan sneller laden dan een thema met een tiental app-scripts. Dat kan, het gaat niet vanzelf.
• Meerdere kanalen uit één bron: apps, kiosken, schermen en nieuwe storefronts gebruiken dezelfde catalogus en checkout in plaats van elk een eigen kopie.
• Losse releasecycli: het front-endteam kan dagelijks live gaan zonder risico voor de checkout, en een migratie van de back-end dwingt geen nieuw ontwerp af.
• Internationale storefronts: één back-end kan aparte landensites voeden met een eigen ontwerp en eigen content, met gedeelde voorraad en orders.

Nadelen en kosten van headless

Teams die overstappen op headless onderschatten vaak dezelfde kosten.

• Je bezit een softwareproduct. De storefront heeft developers nodig voor elke nieuwe functie, bugfix en framework-upgrade, zolang hij draait.
• Je verliest het app-ecosysteem: thema-apps voor reviews, bundels, verlanglijstjes en filters werken vaak niet meer en moeten via de API gekoppeld of opnieuw gebouwd worden.
• Minder zelfstandigheid voor merchandisers: zonder visueel CMS wordt een banner of landingspagina een ticket voor een developer.
• SEO-risico bij de migratie: pagina's die afhangen van JavaScript in de browser moeten eerst gerenderd worden voordat Google ze kan indexeren. Google zet JavaScript-pagina's in een wachtrij om te renderen en raadt server-side rendering of pre-rendering nog steeds aan, omdat niet elke bot JavaScript uitvoert (Google Search Central). Metatags, structured data, canonical tags en redirects moet je bewust opnieuw bouwen.
• Meer systemen om te bewaken: front-end-hosting, API, CMS en commerceplatform kunnen elk los uitvallen.
• Hogere totale kosten: bouwkosten, hosting, een headless CMS-licentie en doorlopende ontwikkeling komen bovenop de kosten van het platform.

Is headless commerce iets voor jou? Een beslislijst

Gebruik dit als snelle check. Herken je het meeste uit de eerste lijst, dan is headless een serieuze optie. Herken je vooral de tweede lijst, dan is een goed gebouwd thema waarschijnlijk de betere investering.

Signalen dat headless loont

• Je verkoopt via meer dan één front-end (webshop plus app, kiosken of meerdere landensites) die één catalogus en checkout moeten delen.
• Je thema blokkeert aantoonbaar functies die omzet opleveren, zoals een productconfigurator, redactioneel winkelen of maatwerkbundels.
• Je hebt een eigen front-endteam, of kunt een bureau op lange termijn betalen.
• Laadsnelheid is een gemeten probleem dat optimalisatie van het thema niet heeft opgelost.
• Je productdata is al gestructureerd: getypeerde attributen, nette varianten, vertalingen en afbeeldingen per kanaal.

Signalen dat het niet loont

• Je team past de shop vooral aan via de thema-editor en er is geen developer beschikbaar.
• Je omzetprobleem zit in verkeer, assortiment of productcontent, niet in de techniek van de storefront.
• Je hebt één webshop in één taal en het thema doet wat je nodig hebt.
• Je catalogus heeft nog gaten: ontbrekende attributen, beschrijvingen van één regel, wisselende eenheden. Een nieuwe front-end laat die gaten juist duidelijker zien.

Wat headless verandert voor je productdata

Dit deel slaan de meeste artikelen over. Een thema is vergevingsgezind: je plakt een maattabel in de HTML van de beschrijving, zet het materiaal in de titel en voegt een badge toe via een thema-instelling. Een headless storefront rendert velden. Staat een waarde niet in een veld, dan kan de front-end hem niet tonen, er niet op filteren en hem niet doorgeven aan de volgende head.

Neem de merino sokken weer. In een gemiddelde themashop ziet het product er zo uit: titel "Merino sokken 3-pack grijs/navy/zwart 43-46 SALE", een beschrijving met een geplakte HTML-tabel voor de maten, en het materiaal één keer genoemd in de derde alinea. Een headless storefront, een app en een feed voor bol hebben hetzelfde product nodig, opgeknipt in velden:

• title: Merino sokken 3-pack (geen maat, kleur of actietekst in de titel)
• short_description: één of twee zinnen voor productkaarten en app-schermen
• description: platte, gestructureerde tekst, zonder layout-HTML die maar in één thema werkt
• material: 80% merinowol, 18% polyamide, 2% elastaan (een getypeerd attribuut, zodat de storefront erop kan filteren)
• pack_size: 3
• variantopties: maat (39 tot 42, 43 tot 46) en kleur (grijs, navy, zwart) als echte opties, elke variant met eigen SKU, EAN en voorraad
• care_instructions: wassen op 30 °C, als attribuut dat de productpagina als iconenlijst kan tonen
• images: aparte foto's per kleurvariant, elk met alt-tekst
• seo_title en meta_description: per taal ingevuld, want de head rendert ze en er is geen thema dat iets aanvult
• vertalingen: elk veld hierboven in elke taal van de storefront, want een Duitse landensite heeft ook Duitse attribuutwaarden nodig (Wolle, niet wol)

Headless zorgt meestal ook voor meer kanalen, elk met eigen veldregels. De webshop toont een beschrijving van 1.200 woorden, de app-kaart twee regels en een marketplace-feed heeft limieten voor titellengte. De data moet één keer compleet zijn en per kanaal aangepast worden, en daar is productinformatiebeheer voor. Sommige teams voegen een headless PIM toe die productcontent via een API aan elke head levert, naast het commerceplatform dat prijzen, voorraad en checkout regelt.

Valkuilen bij een headless migratie, van redesign-denken tot verloren SEO

1. Het behandelen als redesign. Headless is een architectuurwijziging. Reken op het bouwen en onderhouden van software, niet op een nieuwe look.
2. Rommelige data één op één migreren. Feiten die in beschrijvings-HTML, afbeeldingstekst of titels stonden, verschijnen in de nieuwe storefront niet als filter of specificatie. Zet ze eerst in attributen.
3. SEO-pariteit vergeten. URL-structuur, redirects, canonical tags, structured data, hreflang en metavelden moet je vóór livegang opnieuw bouwen en testen. Onze gids over productpagina-SEO noemt de velden per pagina.
4. Alles tegelijk lanceren. Een gefaseerde uitrol, bijvoorbeeld eerst de categoriepagina's of één landensite, beperkt het risico.
5. Merchandisers zonder tools laten zitten. Plan een CMS of pagebuilder in, zodat het contentteam pagina's kan aanpassen zonder developer.
6. Cataloguslogica in de front-end bouwen. Variantregels, vertalingen en uitzonderingen per kanaal horen in de systemen die de data beheren, niet hard gecodeerd in storefront-componenten.

De productinformatielaag achter een headless storefront

WISEPIM is een laag voor productinformatie, geen storefront en geen commerce-engine. In een headless opzet staat het naast je platform: het importeert de catalogus, vult ontbrekende attributen, beschrijvingen en vertalingen aan met AI, controleert de volledigheid met Quality Guard en zet het resultaat via platformsynchronisatie door naar Shopify, WooCommerce, Magento 2, Lightspeed, CCV Shop en andere gekoppelde shops. De storefront leest daarna nette, gestructureerde velden uit de API van het platform. Verandert er iets in WISEPIM, dan zet auto-sync (als je die aanzet) het opgeslagen product door naar de gekoppelde shop, zodat de storefront niet op een handmatige export wacht.

Overweeg je een headless project, begin dan bij de data: op het gratis abonnement importeer je je catalogus en zie je welke velden ontbreken voordat er een regel front-end-code geschreven is.