Stel je voor: je WordPress-site draait prima, maar je frontend-team wil werken met React of Next.js. Of je hebt een app die dezelfde content moet tonen als je website. Dan komt het concept headless WordPress al snel om de hoek kijken. Het klinkt modern en aantrekkelijk - maar is het ook de juiste keuze voor jouw situatie?
In de eerdere artikelen van deze serie hebben we uitgebreid stilgestaan bij WordPress performance-optimalisatie, caching-strategieën en server-tuning. Al die technieken gaan uit van een traditionele WordPress-architectuur. Maar wat als je die architectuur fundamenteel verandert?
Wat is headless WordPress precies?
Bij een traditionele WordPress-installatie zijn de backend (contentbeheer, database, plugins) en de frontend (thema, templates, HTML-output) onlosmakelijk met elkaar verbonden. Elke pagina wordt door PHP gerenderd via het thema-systeem.
Bij headless WordPress ontkoppel je die twee lagen. WordPress fungeert dan puur als content management system - je beheert artikelen, pagina's en media via het vertrouwde dashboard. Maar de daadwerkelijke website die bezoekers zien, draait als een aparte applicatie.
Die frontend-applicatie haalt content op via een API:
- WordPress REST API - standaard ingebouwd sinds WordPress 4.7
- WP GraphQL - een populaire plugin die een GraphQL-endpoint toevoegt
De frontend kan gebouwd zijn in elk framework: Next.js, Nuxt, Astro, SvelteKit of zelfs een mobiele app. WordPress levert alleen de data, de presentatie is volledig losgetrokken.
Waarom kiezen teams voor headless?
Er zijn een aantal legitieme redenen waarom headless WordPress aantrekkelijk is. Laten we de belangrijkste bekijken.
Performance en schaalbaarheid
Met een headless setup kun je je frontend als statische site genereren (Static Site Generation). Dat levert razendsnelle laadtijden op - geen PHP-executie, geen database-queries bij elke pageview. In combinatie met een CDN zoals Cloudflare krijg je een nagenoeg onverwoestbare frontend.
Dat gezegd hebbende: zoals we in het artikel over full page caching hebben laten zien, kun je met NGINX-caching vergelijkbare resultaten bereiken zonder je hele architectuur om te gooien.
Flexibiliteit in frontend-technologie
Je frontend-team kan werken met moderne tools en frameworks. React, Vue of Svelte - de keuze is vrij. Dit is vooral waardevol als:
- Je developers hebt die sterker zijn in JavaScript dan in PHP
- Je een designsystem wilt delen tussen website en applicatie
- Je dezelfde content op meerdere kanalen wilt tonen (web, app, kiosk)
Betere beveiliging
Omdat WordPress niet direct aan het publieke internet hangt, verkleint headless het aanvalsoppervlak. Je WordPress-installatie draait achter een firewall en is alleen bereikbaar voor contentbeheerders. De statische frontend heeft geen database, geen PHP en geen login-pagina om aan te vallen.
Multi-channel contentdistributie
Eén WordPress-backend kan content leveren aan je website, mobiele app, digital signage en nieuwsbrief tegelijk. De REST API of GraphQL maakt het mogelijk om dezelfde content overal te hergebruiken zonder duplicatie.
Wanneer is headless WordPress géén goed idee?
Hier wordt het interessant - want headless wordt regelmatig gekozen om de verkeerde redenen. In veel gevallen is de traditionele architectuur een betere keuze.
Je site is "gewoon" een website
Heb je een bedrijfswebsite met een blog, wat landingspagina's en een contactformulier? Dan is headless overkill. De complexiteit die je toevoegt weegt niet op tegen de voordelen. Een goed geoptimaliseerde traditionele WordPress-site - met de technieken uit onze performance-serie - levert uitstekende resultaten.
Je team heeft geen JavaScript-expertise
Headless verplaatst complexiteit van PHP naar JavaScript. Je hebt developers nodig die overweg kunnen met React/Next.js, API-integratie, build-pipelines en deployment. Als je team vooral PHP-ervaring heeft, introduceer je een flinke leercurve.
Je bent afhankelijk van WordPress-plugins
Veel plugins werken niet of beperkt in een headless setup. Denk aan:
- Formulierenplugins (Contact Form 7, Gravity Forms) - je moet de frontend-rendering zelf bouwen
- Page builders (Elementor, WPBakery) - compleet onbruikbaar zonder de PHP-themelaag
- SEO-plugins (Yoast, Rank Math) - de meeste functionaliteit werkt niet aan de frontendzijde
- WooCommerce - technisch mogelijk maar enorm complex als headless
- Preview-functionaliteit - vereist custom werk om content-previews te tonen
Budget en doorlooptijd zijn beperkt
Een headless implementatie kost doorgaans twee tot drie keer zoveel als een traditionele WordPress-site. Je bouwt immers twee applicaties: de WordPress-backend én een complete frontend. Onderhoud wordt ook duurder omdat je twee systemen up-to-date moet houden.
De technische architectuur van headless WordPress
Laten we concreet kijken hoe een headless WordPress-stack eruitziet.
Backend: WordPress als API
Je WordPress-installatie draait op een server met PHP en MySQL - precies zoals beschreven in onze artikelen over database-optimalisatie en PHP-FPM tuning. Het verschil is dat je geen thema nodig hebt voor publieke output.
Wat je wél nodig hebt:
- WP GraphQL of de standaard REST API als data-endpoint
- Custom post types en ACF (Advanced Custom Fields) voor gestructureerde content
- Een headless-ready thema dat de frontend-rendering uitschakelt
- CORS-configuratie zodat je frontend de API mag aanspreken
Frontend: het JavaScript-framework
De populairste keuze is Next.js in combinatie met React. Alternatieven zijn Nuxt (Vue) en Astro voor meer statische sites.
Je frontend haalt bij elke build - of bij elke request, afhankelijk van je rendering-strategie - content op via de API:
- SSG (Static Site Generation) - pagina's worden bij de build gegenereerd. Supersnel, maar content-updates vereisen een nieuwe build.
- SSR (Server-Side Rendering) - pagina's worden per request gerenderd. Altijd actueel, maar trager dan statisch.
- ISR (Incremental Static Regeneration) - het beste van beide werelden. Statische pagina's die op de achtergrond worden vernieuwd. Next.js biedt hier uitstekende ondersteuning voor.
Deployment en hosting
Je hebt nu twee deployment-pipelines:
- WordPress - draait op een traditionele LAMP/LEMP-stack of managed hosting
- Frontend - draait op Vercel, Netlify, Cloudflare Pages of een eigen server
Dit betekent ook twee sets monitoring, twee sets updates en twee potentiële punten van falen. De multi-server setup die we eerder bespraken wordt hier nog relevanter.
Headless WordPress stap voor stap opzetten
Wil je ermee experimenteren? Dit zijn de basisstappen.
1. WordPress voorbereiden
Installeer WordPress op je server en configureer de REST API of installeer WP GraphQL. Zorg dat je API-endpoints correct werken door ze te testen in je browser of met een tool als Postman.
2. Content structureren
Maak gebruik van custom post types en custom fields (via ACF of de ingebouwde custom fields) om je content goed te structureren. Hoe beter de structuur in WordPress, hoe makkelijker je frontend de data kan consumeren.
3. Frontend project opzetten
Maak een nieuw Next.js-project aan en schrijf de logica om data op te halen van je WordPress API. Begin simpel: haal een lijst artikelen op en render ze.
4. Routing en templates bouwen
Bouw je paginatemplates in React-componenten. Je hebt aparte templates nodig voor blogposts, pagina's, archieven en eventueel custom post types.
5. Preview-functionaliteit implementeren
Dit is een van de lastigste onderdelen. Content-editors willen hun wijzigingen kunnen bekijken vóór publicatie. In Next.js kun je Draft Mode gebruiken om previews van ongepubliceerde content te tonen.
6. Build en deployment inrichten
Configureer een CI/CD-pipeline die je frontend automatisch herbouwt wanneer content in WordPress wordt gepubliceerd of gewijzigd. Een webhook vanuit WordPress naar je build-platform is hiervoor de standaardoplossing.
Vergelijking: headless vs. traditioneel WordPress
| Aspect | Traditioneel | Headless |
|---|---|---|
| Setup-complexiteit | Laag | Hoog |
| Performance (out of the box) | Gemiddeld | Hoog (met SSG) |
| Performance (geoptimaliseerd) | Hoog | Hoog |
| Plugin-compatibiliteit | Volledig | Beperkt |
| Frontend-flexibiliteit | Beperkt tot PHP | Onbeperkt |
| Onderhoudskosten | Lager | Hoger |
| Content preview | Ingebouwd | Custom werk |
| Multi-channel | Niet zonder extra werk | Native |
| Team-vereisten | PHP/WordPress | PHP + JavaScript |
Alternatieven voor volledig headless
Niet overtuigd van een volledige headless-aanpak, maar wil je wél meer flexibiliteit? Er zijn tussenoplossingen.
Progressief headless
Gebruik WordPress traditioneel voor het grootste deel van je site, maar bouw specifieke onderdelen (bijvoorbeeld een interactief dashboard of een productconfigurator) als losse React-componenten die via de API communiceren.
WordPress met een modern thema-framework
Frameworks zoals Sage (Roots) of Flavor brengen moderne development-workflows naar WordPress-thema's: Webpack/Vite, component-based templating en Tailwind CSS. Je behoudt de voordelen van het WordPress-ecosysteem met een modernere developer experience.
Andere CMS-opties
Als je vanaf nul begint en headless je aanspreekt, overweeg dan of WordPress überhaupt het juiste CMS is. Platformen als Sanity, Strapi of Contentful zijn van de grond af ontworpen als headless CMS en bieden een soepelere API-ervaring.
Checklist: is headless WordPress iets voor jou?
Beantwoord deze vragen eerlijk:
- Moet je dezelfde content op meerdere platforms tonen? → Headless wordt interessant
- Heb je een team met JavaScript-ervaring? → Essentieel voor headless
- Gebruik je page builders of veel frontend-plugins? → Blijf bij traditioneel
- Is performance je hoofdmotivatie? → Probeer eerst caching en server-optimalisatie
- Heb je budget voor dubbel onderhoud? → Headless vereist dit
- Wil je maximale frontend-vrijheid? → Headless levert dit
Veelgestelde vragen
Wat is headless WordPress?
Headless WordPress betekent dat je WordPress alleen als backend (CMS) gebruikt voor contentbeheer, terwijl de frontend een losstaande applicatie is die via de REST API of WP GraphQL data ophaalt. De traditionele PHP-themelaag verdwijnt volledig.
Is headless WordPress sneller dan traditioneel WordPress?
De frontend kan sneller zijn doordat je statische pagina's genereert of een geoptimaliseerd JavaScript-framework gebruikt. Maar de winst hangt af van je implementatie. Met goede caching en server-tuning kan een traditionele WordPress-site vergelijkbare snelheden halen.
Welke frameworks worden gebruikt voor een headless WordPress-frontend?
De meest gebruikte frameworks zijn Next.js (React), Nuxt (Vue) en Astro. Next.js is het populairst in combinatie met WordPress dankzij goede SSR- en SSG-ondersteuning en een actieve community.
Kan ik mijn bestaande WordPress-site omzetten naar headless?
Ja, maar het is een ingrijpend traject. Je moet een compleet nieuwe frontend bouwen, alle dynamische functionaliteit (formulieren, zoeken, previews) opnieuw implementeren en je deployment-pipeline aanpassen. Reken op een aanzienlijke investering in tijd en budget.