WordPress zonder kop - waarom eigenlijk?
WordPress is nooit ontworpen als een headless CMS. Dit heeft de afgelopen jaren herhaaldelijk tot wrijvingspunten geleid: Wie een moderne frontend (Next.js, Astro, Nuxt) wilde opzetten op WordPress moest het doen met een REST API die uitbreidbaar was maar structureel beperkt. Aangepaste blokken in de editor zagen eruit als ondoorzichtige HTML-blokken van de frontend. Server-side componenten - de hotspot van moderne frontend frameworks - waren nauwelijks haalbaar met WordPress.
Dit verandert met WordPress 7.0. De REST API is herzien, block SSR wordt voor het eerst officieel ondersteund en nieuwe eindpunten leveren gestructureerde blokgegevens in plaats van vooraf gerenderde HTML. Dit betekent dat headless WordPress niet langer een compromis is, maar een echte architectuuroptie.
Bij Werbesofa gebruiken we headless setups voor specifieke klantvereisten - meestal voor klanten met complexe frontend-eisen, hoge prestatieverwachtingen of meerdere frontends (website + mobiele app + marketingmicrosites) die allemaal toegang hebben tot dezelfde contentbasis. Dit artikel vat samen wat WP 7.0 voor zulke opstellingen kan betekenen.
De herziene REST API
De WordPress REST API bestaat al jaren. Wat verandert er in 7.0: De endpoints zijn beter gestructureerd, presteren beter en brengen blokgegevens in een vorm die een moderne frontend direct kan renderen. In plaats van een post endpoint dat de gerenderde HTML terugstuurde (en dus elke frontend logica dwong om de HTML te post-processen), levert WP 7.0 optioneel blok JSON.
Block JSON is de structuur waarin WordPress blokken intern opslaat. Elke instantie van een blok is een object met een bloktype, attributen en geneste kindblokken. Een frontend kan deze structuur ontvangen en implementeren met zijn eigen rendercomponenten - meestal React componenten in een Next.js project.
Dit lost een lang bestaand headless probleem op: als een aangepast blok werd onderhouden in de editor, moest de frontend dit voorheen opnieuw parsen vanuit de HTML of opvragen via aparte endpoints. Met block JSON is er een 1:1 representatie van de inhoud van de editor in de frontend. Editor en frontend blijven structureel gesynchroniseerd.
Blok SSR - wat het concreet betekent
Rendering serverzijde blokkeren is de tweede grote vernieuwing. WordPress 7.0 kan niet langer de inhoud volledig renderen bij het afleveren van een bericht, maar kan blokken die aan de serverkant moeten worden gerenderd (bijvoorbeeld in Next.js) in de frontend markeren. Hierdoor kun je blokken bouwen die er hetzelfde uitzien in de editor, maar een modern React server component gedrag hebben in de frontend.
Praktijkvoorbeeld: Een custom blok van een Werbesofa voor „actueel nieuws“ toont een placeholderlijst met schemagegevens in de editor. Aan de voorkant wordt het blok gerenderd op de Next.js server, haalt het huidige nieuws op via de WordPress API en levert de voltooide HTML af aan de browser. Caching, incrementele statische regeneratie, dynamische inhoud - moderne frontend tooling zorgt voor alles.
Voorheen moest je of het nieuws ophalen in de block rendering in de WordPress PHP laag (traag, moeilijk te cachen) of het afhandelen in de frontend (complex, foutgevoelig). WP 7.0 Block-SSR dicht de kloof.
Frontend frameworks in detail
Volgende.js is de populairste keuze voor headless WordPress projecten. Vercel en WP Engine bieden speciale hostingstacks met cachinglagen en build hooks. Met WordPress 7.0 is de integratie veel soepeler: Vercel heeft een officiële WP-7 connector die blok JSON direct in Next.js servercomponenten mapt.
Astro is geschikt voor klanten met veel statische inhoud en weinig interactiviteit. Astro sites met WordPress als CMS backend kunnen extreem performant zijn omdat ze standaard minimale JavaScript leveren.
Nuxt 4 (gebaseerd op Vue) heeft vergelijkbare mogelijkheden als Next.js. Iedereen die Vue in zijn team heeft, zal er goed mee overweg kunnen. De WordPress integratie verloopt niet zo soepel als bij Next.js, maar het werkt wel.
SvelteKit is een optie voor zeer lichte, snelle frontends. Hier moet je meer zelf integreren, maar heb je zeer slanke bundels.
Wanneer is headless de moeite waard?
Headless is niet voor elke klant zinvol. De installatie is aanzienlijk complexer dan bij een klassieke WordPress-installatie. Hosting is duurder (twee systemen: WordPress + frontend server). Onderhoud vereist frontend en backend expertise.
Headless is zinvol voor: hoge prestatie-eisen die verder gaan dan wat klassieke WordPress kan leveren; meerdere frontends die dezelfde inhoud consumeren (website + app); app-achtige interacties in de frontend; zeer grote klanten met duidelijk gescheiden teams (zie ook Prestatievergelijking) voor inhoud en UI.
Niet bruikbaar voor: kleine tot middelgrote websites van klanten met beheersbare prestatie-eisen; klanten zonder front-end ontwikkelaars; redactionele opstellingen waarin de voorbeeldfunctie van de editor een centrale rol speelt (headless opstellingen hebben vaak beperkte voorbeeldopties).
Prestaties en kostenbalans
Een headless architectuur kan indrukwekkende prestaties leveren. LCP waarden onder de seconde, INP constant onder de 100 ms, perfecte lighthouse scores - dit is haalbaar met een goede headless implementatie. Cachinglagen kunnen extreem agressief werken omdat de frontend statische builds produceert.
De kosten zijn echter hoger. Frontend hosting (Vercel, Netlify, eigen servers) komt bovenop WordPress hosting. Er moet rekening worden gehouden met bouwtijden - een volledige build kan enkele minuten duren voor grote websites van klanten. We raden incrementele statische regeneratie (ISR) aan als de klant veel publiceert.
Bij Werbesofa berekenen we dat een typische headless setup één tot anderhalf keer meer hostinginspanning vergt dan een klassieke WordPress site. Aan de andere kant bespaar je op plugins omdat veel functionaliteit direct aan de voorkant wordt opgelost.
Praktijk voor Werbesofa: geselecteerde klanten hebben de stap genomen
Drie klanten in onze klantenportefeuille zijn de afgelopen twaalf maanden overgestapt op headless. In alle drie de gevallen was de aanleiding een specifiek probleem - meestal de prestaties met zeer veel klantenverkeer of de wens om parallel aan de website een mobiele app te exploiteren (typische vereiste voor klanten met wie moderne webontwikkeling is veelgevraagd). De migratie was een project van enkele weken, maar het was de moeite waard voor de klanten.
De leercurve: Headless is een architecturale beslissing, geen plugin keuze. Als je deze stap wilt zetten, moet je bekend zijn met frontend frameworks, cachingstrategieën, build pipelines en CDN-configuratie. We begeleiden dergelijke projecten graag - maar raden klanten die onzeker zijn aan om eerst een klassieke WordPress setup te optimaliseren voordat ze headless gaan.
Als je overweegt of headless de juiste architectuur is voor je eigen website, kun je ons een Eerste consult informeren. We bekijken de vereisten en vertellen je eerlijk of headless geschikt is of dat een klassieke opstelling volstaat. In de meeste gevallen is de klassieke opstelling voldoende.
Migratiepad: van klassieke setup naar headless
Iedereen die overweegt om over te stappen van een klassieke WordPress setup naar headless, moet de migratie plannen als een project dat meerdere weken in beslag neemt. We verdelen dergelijke migraties in vier fasen: Audit en architectuurbeslissing, frontend setup, parallelle testfase, cut-over. Elke fase heeft zijn eigen risico's en zijn eigen succescriteria.
Fase 1 (audit): Twee tot drie weken. Inventarisatie van alle bestaande inhoud, aangepaste blokken, plugins en front-end gedrag. Welke functionaliteit is bedrijfskritisch? Welke kan zonder verlies worden overgezet naar een moderne frontend? Welke is plugin-afhankelijk en moet opnieuw worden gebouwd? Aan het einde van deze fase moet een beslissing worden genomen: Headless is de moeite waard, of klassieke optimalisatie is beter.
Fase 2 (front-end ontwikkeling): Vier tot acht weken. Opzetten van het geselecteerde frontend framework (meestal Next.js), verbinding maken met de WordPress REST API, implementatie van de Aangepaste blok renderer, SEO instellen met server-side rendering, tracking-integratie, caching-strategie. Deze fase is het meest complex - en degene met het grootste aandeel front-end ontwikkelwerk.
Fase 3 (testfase): Twee tot vier weken. De nieuwe headless frontend draait op een subdomein parallel aan het bestaande systeem. Klanten testen redactionele workflows, prestaties worden gemeten, edge cases worden doorlopen - wat gebeurt er met verwijderde inhoud, wat gebeurt er met permalink wijzigingen, wat gebeurt er met grote updates van de WordPress API. De migratie gaat pas de laatste fase in als alles werkt.
Fase 4 (cut-over): Enkele uren tot een dag. DNS-omschakeling van de oude site naar de nieuwe headless front-end. Houd vooral de eerste 48 uur goed in de gaten. Met een goede voorbereiding is de cut-over niet spectaculair - met een slechte voorbereiding begint hier het drama. We raden aan om de cut-over buiten de belangrijkste salesperiodes en met een duidelijk rollback plan uit te voeren.
Conclusie over migratie: Headless is haalbaar, maar geen weekendproject. Wie deze stap neemt, moet een partner inschakelen die ervaring heeft met beide werelden - WordPress backend en moderne frontend. Wij hebben verschillende van dit soort migraties begeleid en helpen klanten om het risico goed in te schatten.
Tool stack: wat we gebruiken voor headless projecten
Voor geïnteresseerde klanten of collega's in de industrie: Onze typische tool stack voor headless WordPress projecten bestaat uit verschillende componenten. Backend: WordPress 7.0 met geselecteerde plugins (ACF Pro voor gestructureerde inhoudsvelden, WPGraphQL voor GraphQL API, RankMath voor SEO metadata). Frontend: Next.js 15 met App Router en React Server Componenten.
Hosting: WordPress op onze eigen Hetzner-servers in het datacenter van Falkenstein. Next.js frontend op Vercel (voor ISR en edge caching) of op eigen servers (voor klanten met speciale datalokalisatie-eisen). CDN: bunny.net voor statische assets, Cloudflare voor DNS en initiële edge caching.
Bouw pijplijn: GitHub Actions die automatisch revalidate calls naar Vercel sturen wanneer content wordt bijgewerkt in WordPress. Incrementele build met ISR - nieuwe posts zijn live in minder dan een minuut zonder dat de hele site opnieuw gebouwd hoeft te worden. Previewmechanisme: Editor previewmodus in Next.js, die de ongepubliceerde versie rechtstreeks uit WordPress haalt.
Headless is een architecturale beslissing met gevolgen op lange termijn. Als je eenmaal bent overgestapt, kom je zelden meer terug - de frontend development expertise die in de setup ging zitten, wil je niet opgeven. Omgekeerd heeft iemand die tevreden is met een klassieke WordPress setup geen reden om extra moeite te doen. Headless is geen statussymbool, maar een hulpmiddel voor specifieke eisen. We geven eerlijk advies - zelfs als dat betekent dat Headless niet geschikt is voor de klant in kwestie.
Voor klanten van Werbesofa geldt: iedereen die geïnteresseerd is in Headless kan een kort architectuurgesprek met ons afspreken. We bekijken de huidige vereisten, controleren de roadmap voor de middellange termijn en geven duidelijk aan of Headless het juiste antwoord is of dat klassieke WordPress met gerichte optimalisatie volstaat. Dit advies maakt deel uit van onze adviesdiensten en is gratis voor bestaande klanten.
