Ik heb de afgelopen drie jaar commerce-frontends gebouwd en herbouwd voor merken met een jaaromzet van $2M tot $200M. Als ik één ding heb geleerd, is het dat de "beste" headless commerce-architectuur niet in een vacuüm bestaat. Die bestaat in de context van je team, je budget, de complexiteit van je catalogus, en — eerlijk gezegd — hoeveel pijn je bereid bent te verdragen tijdens de transitie.

Het gesprek over headless commerce is sinds de initiële hype aanzienlijk gerijpt. We zijn voorbij het punt waarop het ontkoppelen van je frontend van je backend een radicaal idee is. In 2026 gaan de echte vragen over welk ontkoppelingspatroon, hoeveel composability je werkelijk nodig hebt, en of de MACH-puristenbenadering de operationele overhead voor jouw specifieke situatie waard is.

Dit is mijn poging om de architectuurpatronen uit te zetten die ik in productie heb zien slagen (en falen), met eerlijke beoordelingen van de betrokken afwegingen.

Inhoudsopgave

Headless Commerce-architectuurpatronen in 2026: Een diepgaande analyse

Het architectuurspectrum: Monoliet tot volledig MACH

Voordat we in specifieke patronen duiken, moeten we het spectrum vaststellen. Commerce-architectuur is niet binair — het is niet "headless" versus "niet headless." Het is een gradiënt.

Aan het ene uiteinde heb je de traditionele monoliet: Shopify met een Liquid-thema, Magento met zijn ingebouwde frontend, WooCommerce. Alles zit samen. Aan het andere uiteinde heb je een volledig composable MACH-stack waarbij elke mogelijkheid — commerce-engine, CMS, zoeken, betalingen, OMS — een aparte service is die via API's verbonden is.

De meeste teams in 2026 landen ergens in het midden, en dat is volkomen prima.

Wat MACH eigenlijk betekent

MACH staat voor Microservices, API-first, Cloud-native, en Headless. De MACH Alliance (ja, het is een echte organisatie met ledenschap en abonnementsgelden) certificeert leveranciers die aan deze criteria voldoen. Leden zijn onder meer commercetools, Contentful, Algolia en anderen.

De filosofie is gezond: best-of-breed-services, losjes gekoppeld, onafhankelijk deployable. De realiteit is meer genuanceerd. Het runnen van een echte MACH-stack betekent dat je team verantwoordelijk is voor de lijm tussen 5-15 verschillende services. Dat is een aanzienlijke operationele last.

Patroon 1: API-first monoliet met ontkoppelde frontend

Dit is waar de meeste teams mee moeten beginnen. Je houdt je bestaande commerce-platform (Shopify, BigCommerce, Medusa) als backend en bouwt een custom frontend die er via API's mee communiceert.

Hoe het werkt

[Custom Frontend (Next.js/Astro)] 
        ↓ (GraphQL/REST API's)
[Commerce Platform API's]
        ↓
[Commerce Platform Backend]
  - Productcatalogus
  - Winkelwagen/Checkout
  - Orderbeheer
  - Klantenaccounts

De frontend is ontkoppeld. De backend blijft een enkel platform dat de meeste commerce-logica afhandelt. Je kunt een headless CMS toevoegen voor inhoud, maar de commerce-engine blijft monolithisch.

Wanneer dit patroon werkt

  • Teams met 1-3 frontend-ontwikkelaars
  • Merken met minder dan $50M jaaromzet
  • Catalogi met minder dan 10.000 SKU's
  • Als je prestatieverbeteringen nodig hebt zonder alles opnieuw in te richten

Real-world voorbeeld

We hebben onlangs de storefront van een DTC-merk gebaseerd op Shopify herbouwd met behulp van Next.js en de Storefront API. Hun Liquid-thema scoorde 35 op mobile Lighthouse. De Next.js-frontend haalde 92 op dag één. Dezelfde Shopify-backend, dezelfde apps, dezelfde workflows voor het operationele team. Het enige dat veranderde was de klantenervaring.

De bouw duurde 8 weken met twee ontwikkelaars. Een volledig MACH-migratie zou 6+ maanden geduurd hebben.

Patroon 2: Composable Commerce (waar MACH)

Dit is de architectuur waar conferentie-sprekers van houden om over te praten. Elke mogelijkheid is een aparte, best-of-breed-service.

De stack ziet er zo uit

[Custom Frontend (Next.js)]
        ↓
[API Orchestration Layer / BFF]
    ↓         ↓         ↓         ↓
[commercetools] [Contentful] [Algolia] [Stripe]
[Commerce]      [Inhoud]     [Zoeken]  [Betalingen]
    ↓
[Fluent Commerce / Manhattan]
[Orderbeheer]
    ↓
[Klaviyo / Braze]
[Marketing Automation]

Het Backend-for-Frontend (BFF) patroon

In een echte composable-stack heb je bijna altijd een BFF-laag nodig. Dit is een dunne API die tussen je frontend en alle backend-services zit. Het verwerkt:

  • Het samenvoegen van gegevens uit meerdere services tot enkele antwoorden
  • Authenticatie en sessiebeheer
  • Caching-strategieën
  • Snelheidsbeperking en circuit breaking
// Voorbeeld BFF-route in Next.js API-route
export async function GET(request: Request) {
  const { slug } = params;
  
  // Parallelle verzoeken naar meerdere services
  const [product, content, reviews, inventory] = await Promise.all([
    commercetools.getProductBySlug(slug),
    contentful.getProductContent(slug),
    yotpo.getReviews(slug),
    inventory.getAvailability(slug),
  ]);
  
  // Samenvoegen in unified product-antwoord
  return Response.json({
    ...product,
    editorial: content,
    reviews: reviews.items,
    availability: inventory.status,
  });
}

Wanneer dit patroon verstandig is

  • Enterprise-merken ($100M+ omzet)
  • Complexe multi-regio-, multi-valutavereisten
  • Teams met 5+ dedicated engineers
  • Als je werkelijk voorbij de beperkingen van je platform bent gegroeid
  • B2B-commerce met complexe prijsstelling/cataloguslogica

De eerlijke nadelen

Laat me direct zijn: ik heb meer composable commerce-projecten zien mislukken dan slagen. Niet omdat de architectuur slecht is, maar omdat teams de integratiewerk onderschatten.

commercetools alleen kost $40.000-$200.000/jaar afhankelijk van GMV. Voeg Contentful ($3.000-$30.000/jaar), Algolia ($1.000-$10.000/jaar voor commerce) toe, en je kijkt tegen $80.000-$300.000 jaarlijkse SaaS-kosten voordat je een enkele regel code hebt geschreven. Dan is er nog de 4-8 maanden buildtijd.

Je moet erg eerlijk zijn over of de flexibiliteit het voor je bedrijf waard is.

Headless Commerce-architectuurpatronen in 2026: Een diepgaande analyse - architectuur

Patroon 3: Hybrid Headless (de pragmatische middenweg)

Dit is het patroon dat ik meestal aanbeveel, en het is waar de industrie in 2026 naartoe gaat. Je neemt een capabel commerce-platform, ontkoppelt de frontend, en voegt selectief best-of-breed-services alleen toe waar het platform tekortkoming.

Architectuur

[Custom Frontend (Next.js / Astro)]
        ↓
[Commerce Platform API's]
  - Producten, Winkelwagen, Checkout, Bestellingen
        +
[Headless CMS] → Redactionele inhoud, landingspagina's
        +
[Zoekservice] → Alleen als platform-zoeken ontoereikend is

De sleutelgedachte: je hoeft niet alles te vervangen. Shopify's checkout is uitstekend — waarom herbouwen? BigCommerce's catalogusbeheer is solide — behoud het. Maar misschien zijn hun CMS-mogelijkheden zwak, dus je haalt Sanity of Contentful voor die specifieke behoefte.

De composability-strategie

Hier is hoe ik denk over welke mogelijkheden je kunt extraheren:

Mogelijkheid Behoud in platform Extraheer wanneer...
Productcatalogus < 50K SKU's, eenvoudige varianten Complexe B2B-prijsstelling, multi-regio-catalogi
Winkelwagen & Checkout Bijna altijd Custom checkout-flows, multi-vendor-marktplaats
Inhoud/CMS Zelden Bijna altijd — platform CMS-tools zijn zwak
Zoeken < 5K producten Gefacetteerd zoeken, AI-aanbevelingen, merchandising
Betalingen Platform verwerkt het Multi-PSP, complexe abonnementen
OMS < 1K bestellingen/dag Multi-warehouse, complexe fulfillment-logica

Dit is de benadering die we in de meeste van onze headless CMS-ontwikkelingsprojecten gebruiken — extraheer eerst contentbeheer, evalueer dan wat nog meer moet worden ontkoppeld.

Patroon 4: Platform-native headless

Verschillende commerce-platforms bieden nu hun eigen headless-frontend-frameworks. Het meest opmerkelijke is Shopify Hydrogen.

Shopify Hydrogen

Hydrogen is Shopify's React-framework gebouwd op Remix (nu React Router v7). Het is speciaal ontworpen voor Shopify's Storefront API en bevat:

  • Ingebouwde cart- en checkout-hooks
  • Geoptimaliseerde data-fetching voor Shopify's GraphQL API
  • Server-side rendering met Oxygen (Shopify's hosting)
  • Voorgebouwde commerce-componenten
// Hydrogen-productpagina-voorbeeld
import { useLoaderData } from '@remix-run/react';
import { json } from '@shopify/remix-oxygen';

export async function loader({ params, context }) {
  const { product } = await context.storefront.query(PRODUCT_QUERY, {
    variables: { handle: params.handle },
  });
  return json({ product });
}

export default function Product() {
  const { product } = useLoaderData();
  // render product...
}

De afweging

Hydrogen bindt je vast aan Shopify's ecosysteem. Dat is prima als Shopify je langetermijnplatform is. Maar als je ooit wilt migreren, herschrijf je je hele frontend — de Hydrogen-specifieke hooks en datapatronen zijn niet overdraagbaar.

Voor teams die volledig op Shopify inzetten en het snelste pad naar een custom storefront willen, is Hydrogen een legitieme keuze. Weet gewoon waarvoor je je inschrijft.

Keuzes voor frontend-frameworks voor commerce

Je keuze voor frontend-framework is belangrijker dan mensen denken, vooral voor commerce waar Core Web Vitals direct van invloed zijn op conversietarieven.

Next.js

Nog steeds de dominante keuze voor headless commerce in 2026. De App Router is stabiel, Server Components zijn werkelijk nuttig voor commerce (denk aan productpagina's die volledig server-rendered kunnen zijn met nul client-side JavaScript voor de initiële paint).

Next.js 15's Partial Prerendering (PPR) is bijzonder interessant voor commerce. Je kunt statisch productinfo genereren terwijl je dynamische elementen streamt, zoals voorraadstatus en gepersonaliseerde aanbevelingen.

// Next.js 15 PPR voor een productpagina
import { Suspense } from 'react';

export default async function ProductPage({ params }) {
  const product = await getProduct(params.slug); // Statisch
  
  return (
    <div>
      <ProductInfo product={product} /> {/* Statische schil */}
      <Suspense fallback={<PriceSkeleton />}>
        <DynamicPricing productId={product.id} /> {/* Gestreamed */}
      </Suspense>
      <Suspense fallback={<ReviewsSkeleton />}>
        <Reviews productId={product.id} /> {/* Gestreamed */}
      </Suspense>
    </div>
  );
}

We hebben veel Next.js-ontwikkeling voor commerce-clients gedaan, en PPR is een echte stap vooruit geweest om prestaties met personalisatie in evenwicht te brengen.

Astro

Astro's island-architectuur maakt het aantrekkelijk voor content-zware commerce-sites — denk aan editorial-merken, inspiratiegaleries, catalogi met veel storytelling. Het verstuurt dramatisch minder JavaScript dan Next.js standaard.

Voor een productlijstpagina met 50 producten? Astro verstuurt misschien 15KB JS. Next.js zou 80-120KB kunnen versturen. Dat verschil zie je terug in Time to Interactive, vooral op mobiel.

De beperking: Astro is minder volwassen voor zeer interactieve commerce-ervaringen. Complexe winkelwagenklapmenu's, productconfigurators en real-time voorraadbijwerking vereisen client-side islands, en op een bepaald moment vecht je tegen het framework. Maar voor de juiste use case kan Astro-ontwikkeling de betere keuze zijn.

Framework-vergelijking voor commerce

Factor Next.js Astro Hydrogen Nuxt
Bundelgrootte (typische PLP) 80-120KB 15-40KB 90-130KB 70-100KB
SSR-prestatie Uitstekend Uitstekend Goed (Oxygen) Zeer goed
Commerce-ecosysteem Enorm Groeiend Alleen Shopify Matig
Leercurve Matig Laag Matig-Hoog Matig
ISR/Revalidatie Ingebouwd Via adapters Beperkt Ingebouwd
Leveranciersvergrendeling Geen Geen Hoog (Shopify) Geen
Ideaal voor Volledig uitgerust winkels Content-zware catalogi Shopify-native builds Vue-ecosysteem-teams

Backend-platformvergelijking: leveranciers die in 2026 tellen

Laten we het hebben over de commerce-engines zelf. Ik zal specifiek zijn over prijzen, beperkingen en wie elk platform werkelijk dient.

Shopify (Plus)

Prijzen: Standaardabonnementen $39-$399/mnd. Plus begint bij $2.300/mnd (omhoog van $2.000 in 2024) met 0,25% transactietarief op betaalgateways van derden.

Storefront API: GraphQL-gebaseerd, goed gedocumenteerd, redelijk compleet. Ontbreekt enkele B2B-functies. Snelheidslimieten kunnen lastig zijn op schaal (50 verzoeken/seconde op Plus).

Beste voor: DTC-merken, mode, schoonheid, voeding & drank. Als je bedrijfsmodel "verkoopproducten aan consumenten online" is, is Shopify om een reden de standaardkeuze.

Eerlijke beperkingen: De limiet van 100 varianten per product doet nog steeds pijn. Metavelden zijn beter dan ze waren, maar nog steeds onhandig voor complexe productgegevens. Extensions-ecosysteem (Functions, Checkout Extensions) is krachtig maar merkgebonden.

BigCommerce

Prijzen: Standaardabonnementen $39-$399/mnd. Enterprise is custom maar meestal $1.000-$5.000/mnd. Geen transactiekosten op enig abonnement.

API's: Zowel REST als GraphQL. Hun GraphQL Storefront API is dramatisch verbeterd. Native multi-storefront is werkelijk nuttig — één backend, meerdere headless-frontends voor verschillende regio's of merken.

Beste voor: Multi-storefront-bedrijven, B2B/B2C-hybrid, merken die meer catalogusflexibiliteit willen dan Shopify biedt.

Eerlijke beperkingen: Kleiner app-ecosysteem dan Shopify. De admin-interface voelt gedateerd vergeleken met Shopify. Ontwikkelaarsgemeenschap is aanzienlijk kleiner.

Medusa.js

Prijzen: Open-source (MIT-licentie). Medusa Cloud-prijzen beginnen rond $50/mnd voor hosting, schalen naar gebruik. Zelf hosten op Railway of AWS is haalbaar.

Architectuur: Node.js/TypeScript, modulair van ontwerp. Je kunt elke module (winkelwagen, betaling, fulfillment) vervangen of uitbreiden met custom logica.

// Voorbeeld van aangepaste prijsmodule Medusa
import { PricingModuleService } from '@medusajs/medusa/pricing';

class CustomPricingService extends PricingModuleService {
  async calculatePrice(productId: string, context: PricingContext) {
    // Je aangepaste B2B-prijsstelling
    const tierDiscount = await this.getTierDiscount(context.customerId);
    const basePrice = await super.calculatePrice(productId, context);
    return basePrice * (1 - tierDiscount);
  }
}

Beste voor: Developer-geleide teams die volledige controle willen, startups die zakelijke SaaS niet kunnen betalen, complexe B2B-scenario's, multi-tenant marktplaatsen.

Eerlijke beperkingen: Je bent verantwoordelijk voor alles — hosting, schaling, beveiligingspatches, PCI-naleving (bij directe betalingsverwerking). Het ecosysteem van voorgebouwde integraties is veel kleiner dan Shopify's. Medusa v2 was een aanzienlijke herschrijving en enkele v1-bronnen zijn verouderd.

commercetools

Prijzen: Begint rond $40.000/jaar voor kleine implementaties. Enterprise-deals meestal $100.000-$300.000/jaar gebaseerd op GMV en API-aanroepvolume.

Architectuur: Echte microservices, event-driven, ongelooflijk flexibele API's. Hun Composable Commerce-aanbieding verdeelt zich in onafhankelijk deployable-pakketten.

Beste voor: Enterprise ($100M+ GMV), complexe multi-marktoperaties, B2B met geavanceerde prijsmodellen.

Eerlijke beperkingen: Duur. Steile leercurve. Je zult een systeemintegrator of een zeer ervaren intern team nodig hebben. De admin-interface is functioneel maar niet mooi — de meeste teams bouwen custom admin-tools.

Leverancierssnelle vergelijking

Platform Startprijs API-stijl Zelf te hosten B2B-ondersteuning Checkout-aanpassingen
Shopify Plus $2.300/mnd GraphQL Nee Basis Extensions API
BigCommerce ~$1.000/mnd GraphQL + REST Nee Goed Stencil + API's
Medusa.js Gratis (OSS) REST + komende GQL Ja Uitstekend Volledige controle
commercetools ~$40K/jr GraphQL + REST Nee Uitstekend Volledige controle
Saleor Gratis (OSS) GraphQL Ja Goed Volledige controle

Besluitvormingskader: Je architectuur kiezen

Hier is het kader waarmee ik cliënten door loop als ze contact opnemen met ons over headless commerce-projecten.

Stap 1: Beoordeel je beperkingen

Wees eerlijk over deze:

  • Teamgrootte: Heb je dedicated engineers, of is dit een eenmalige bouw die marketing zal onderhouden?
  • Budget: Zowel buildbudget als lopende operationele kosten
  • Tijdlijn: Wanneer moet dit live gaan?
  • Technische schuld tolerantie: Hoeveel complexiteit kan je organisatie absorberen?

Stap 2: Koppel aan een architectuurpatroon

Als je hebt... Overweeg...
1-2 devs, $50K-$150K budget, 2-3 maanden tijdlijn Patroon 1: Ontkoppelde frontend op bestaand platform
3-5 devs, $150K-$500K budget, 4-6 maanden tijdlijn Patroon 3: Hybrid headless
5+ devs, $500K+ budget, 6-12 maanden tijdlijn Patroon 2: Volledig composable (als het bedrijf het echt eist)
Volledig op Shopify, 1-3 devs Patroon 4: Hydrogen

Stap 3: Valideer met een proof of concept

Verbind jezelf niet aan een architectuur gebaseerd op een slideshow. Bouw een proof of concept die bevat:

  1. Een productlijstpagina met filtering
  2. Een productdetailpagina met variantselectie
  3. Toevoegen aan winkelwagen en winkelwagenbeheer
  4. De checkout-flow (minstens de eerste stap)

Dit zal 80% van de integratieuitdagingen blootleggen waarmee je geconfronteerd wordt. Budget 2-3 weken voor de POC.

Prestatiegegevens en real-world data

Hier zijn gegevens van werkelijke commerce-builds die we in de afgelopen 12 maanden hebben geleverd:

Metriek Shopify Liquid thema Next.js + Shopify API Astro + Medusa Hydrogen + Oxygen
LCP (p75, mobiel) 3,8s 1,6s 1,2s 1,9s
FID/INP (p75) 180ms 95ms 45ms 110ms
CLS 0,15 0,03 0,02 0,05
JS-bundelgrootte (initieel) 320KB 105KB 28KB 118KB
Buildtijd (1000 producten) N/A 4,2min 3,1min 3,8min
Time to First Byte 800ms 120ms (Edge) 90ms (Edge) 150ms

Deze cijfers vertellen een duidelijk verhaal: het ontkoppelen van de frontend verbetert consistent de prestatie. Maar de mate van verbetering varieert, en Astro's minimale-JS-benadering wint op pure prestatiesmetrieken.

Google's eigen gegevens uit 2025 suggereren dat elke 100ms-verbetering in LCP correleren met ongeveer een 1,3%-toename in conversietarief voor commerce-sites. Die prestatiewinsten zijn echt geld.

Veel gestelde vragen

Is headless commerce het waard voor kleine bedrijven? Dat hangt af van wat "klein" betekent. Als je een Shopify-winkel bent die $500K/jaar doet met een team van drie, is een headless-frontend waarschijnlijk overkill. De prestatiewinsten zijn leuk, maar de onderhoudslast is niet gerechtvaardigd. Als je $5M+ doet en je conversietarief belangrijk genoeg is om in custom UX te investeren, dan heeft een ontkoppelde frontend (Patroon 1) zin. Ga niet volledig composable tot je duidelijk voorbij $50M bent.

Wat zijn de gemiddelde kosten voor het bouwen van een headless commerce-site in 2026? Voor een Patroon 1-build (ontkoppelde frontend op Shopify/BigCommerce), verwacht $50.000-$150.000 voor de initiële build met een bureau of ervaren freelancers. Patroon 3 (hybrid) kost $150.000-$400.000. Volledig composable (Patroon 2) begint bij $300.000 en kan gemakkelijk $1M overschrijden voor enterprise-implementaties. Lopende kosten tellen 15-25% van de initiële build jaarlijks op voor onderhoud, hosting en SaaS-fees. Bekijk onze prijspagina voor specifieker inzicht.

Moet ik Hydrogen of Next.js gebruiken voor een Shopify headless-winkel? Als je 100% vastbesloten bent om Shopify op lange termijn te gebruiken en je team JavaScript kent, krijg je met Hydrogen sneller naar productie met minder custom integratiecode. Als je framework-flexibiliteit wilt, de mogelijkheid om later commerce-platforms te wisselen, of je moet zwaar integreren met niet-Shopify-services (een headless CMS, custom zoeken, enz.), is Next.js de veiliger gok. De meeste teams waarmee ik werk kiezen Next.js omdat het ecosysteem groter is en de vaardigheden meer overdraagbaar zijn.

Hoe verhoudt Medusa.js zich tot Shopify voor headless commerce? Medusa geeft je volledige controle en nul platformkosten — maar je bent verantwoordelijk voor alles wat Shopify voor je verwerkt: hosting, schaling, beveiliging, PCI-naleving (bij directe betalingsverwerking), uptime. Medusa v2 is technisch werkelijk indrukwekkend, met een modulaire architectuur die schoner is dan de meeste open-source commerce-platforms. Kies Medusa als je sterke backend-engineers hebt en diepe aanpassing nodig. Kies Shopify als je je louter op de frontend-ervaring wilt richten en Shopify de infrastructuur voor je laat afhandelen.

Wat is de MACH Alliance en is certificering belangrijk? De MACH Alliance is een branchegroep die leveranciers certificeert die aan Microservices, API-first, Cloud-native, en Headless-criteria voldoen. Leden zijn onder meer commercetools, Contentful, Algolia en ongeveer 100 andere leveranciers. Is certificering belangrijk? Het is een nuttig signaal dat een leverancier API-first-architectuur serieus neemt, maar het garandeert niet de kwaliteit of geschiktheid. Enkele uitstekende tools (zoals Medusa, Sanity, of Astro) zijn niet MACH-gecertificeerd, en dat maakt ze niet tot slechtere keuzes.

Kan ik stap voor stap naar headless migreren in plaats van alles tegelijk? Absoluut, en dit is wat ik aanbeveel. Begin door één oppervlak los te koppelen — misschien je productlijstpagina's of je blog/contentpagina's. Behoud checkout op het bestaande platform. Meet de impact. Breid dan uit. Shopify's Storefront API ondersteunt dit patroon goed: je kunt een headless PLP runnen die linkt naar een Shopify-gehoste checkout. Deze incrementele benadering vermindert het projectrisico en laat je ROI bewijzen voordat je je aan een volledige herbouw verbindt.

Wat is de grootste fout die teams maken met headless commerce? Te veel engineeren. Ik heb teams gezien die 6 maanden besteedden aan het bouwen van een volledig composable MACH-stack terwijl alles wat ze nodig hadden een custom Next.js-frontend op Shopify was. Begin met de eenvoudigste architectuur die je werkelijke problemen oplost. Je kunt mogelijkheden later altijd extraheren in aparte services. Je kunt bijna nooit een architectuur die al te complex is vereenvoudigen zonder een pijnlijke herschrijving.

Hoe gaan headless commerce-sites om met SEO vergeleken met traditionele platforms? Met server-side rendering (wat Next.js, Astro en Hydrogen allemaal ondersteunen) kunnen headless-sites werkelijk beter SEO hebben dan traditionele platforms. Je hebt volledige controle over metatags, gestructureerde gegevens, URL-structuur en paginasnelheid — allemaal factoren die direct van invloed zijn op rankings. De sleutel is ervoor zorgen dat je goede SSR/SSG implementeert en niet op client-side rendering vertrouwt voor inhoud die geïndexeerd moet worden. We hebben gezien dat headless-herbouwen het organische verkeer met 20-40% verhogen puur vanwege Core Web Vitals-verbeteringen en beter technisch SEO-beheer.