De term duikt op in een offerte van een bureau, in een gesprek met een developer of in een artikel over moderne webtechniek: headless WordPress. Het klinkt als iets dat je zou moeten willen, en tegelijk is volstrekt onduidelijk wat het betekent en of het voor jouw situatie relevant is. Het korte antwoord: headless WordPress betekent dat WordPress alleen nog de beheeromgeving en opslagplaats van je content is (het CMS), terwijl de zichtbare website zelf (de frontend) los daarvan wordt gebouwd met andere techniek. De “head” die eraf is, is de weergavekant van WordPress: je thema. En het eerlijke vervolg op dat antwoord: voor de meeste websites is dit niet de juiste keuze, voor een specifiek soort teams en projecten juist wel. We leggen uit hoe het werkt en waar die grens ligt.
Hoe headless werkt
Bij een traditionele WordPress-site doet één systeem alles: je schrijft content in het dashboard, en hetzelfde WordPress bouwt met je thema de pagina’s die bezoekers zien. Bij headless wordt dat geknipt. WordPress blijft de plek waar redacteuren inloggen en content beheren, maar levert die content vervolgens uit als kale data via de REST API (een gestandaardiseerde manier waarop software gegevens bij elkaar opvraagt) of GraphQL, een alternatieve querytaal daarvoor. Een apart gebouwde frontend, meestal in een JavaScript-framework zoals Next.js of Nuxt, haalt die data op en bepaalt volledig zelf hoe alles eruitziet. Die frontend draait vaak ook op andere hosting dan het WordPress-gedeelte.
Voor de redactie verandert er opvallend weinig: die werkt gewoon in het vertrouwde WordPress-dashboard. Voor alles daaromheen verandert vrijwel alles: thema’s en de meeste plugins die iets aan de voorkant doen (page builders, veel SEO-functionaliteit, formulieren) werken niet meer vanzelf, want er ís geen WordPress-voorkant meer. Al die functionaliteit moet in de frontend opnieuw gebouwd of gekoppeld worden.
Waarom teams hiervoor kiezen
De voordelen zijn reëel, en ze verklaren waarom grote mediasites en tech-gedreven bedrijven deze route kiezen. De frontend kan extreem snel zijn: pagina’s worden vaak vooraf opgebouwd en wereldwijd verspreid, waardoor laadtijden minimaal worden. Developers werken in moderne frameworks met hun eigen gereedschap, los van de beperkingen van het thema-systeem. Dezelfde content kan naar meerdere kanalen: één artikel in WordPress voedt de website, een app en een narrowcasting-scherm tegelijk. En de beveiliging verbetert structureel, omdat het WordPress-gedeelte volledig afgeschermd kan draaien terwijl bezoekers alleen de losse frontend zien.
De prijs die je ervoor betaalt
Tegenover die voordelen staat een fundamentele verandering in wie je site kan bouwen en onderhouden. Zonder developer geen headless site: elke aanpassing aan de voorkant is programmeerwerk, en de doe-het-zelf-kracht van WordPress (even een plugin installeren, even iets aanpassen in de customizer) ben je kwijt. Vertrouwde functionaliteit moet opnieuw geregeld worden, en juist de onopvallende dingen kosten daar tijd: de preview-knop bijvoorbeeld, waarmee een redacteur een concept bekijkt vóór publicatie, werkt bij headless niet vanzelf en moet apart worden ingericht. Je beheert voortaan twee omgevingen in plaats van één, met elk hun eigen hosting, updates en back-upstrategie; ook je back-upaanpak wordt daarmee tweeledig, zoals de principes uit onze complete gids over WordPress back-ups en migratie dan op beide omgevingen apart toegepast moeten worden. En de totale kosten liggen structureel hoger: meer bouwtijd, meer onderhoud, meer specialistische kennis.
Voor wie het wel en niet is
Onze mening is hier uitgesproken, omdat we de vraag geregeld krijgen van site-eigenaren die er niet mee geholpen zouden zijn. Headless past bij organisaties met een eigen developmentteam of een vast bureau, met hoge eisen aan snelheid en schaal, of met content die naar meerdere kanalen moet. Denk aan mediaplatformen, grote corporate sites en applicaties met een contentcomponent. Voor de bedrijfssite, de webshop, het blog en eigenlijk elke site die door de eigenaar zelf of een kleine redactie beheerd wordt, is traditioneel WordPress de betere keuze: sneller gebouwd, goedkoper onderhouden en zelf aan te passen. Een traag geworden WordPress-site is bovendien vrijwel altijd te versnellen met goede hosting, caching en optimalisatie; “we gaan headless voor de snelheid” is voor een gemiddelde site een onnodig zwaar middel.
Bij Surver: onze hosting draait op LiteSpeed-servers met NVMe SSD-opslag, en in de praktijk halen goed geoptimaliseerde traditionele WordPress-sites daarop laadtijden waarvoor je geen headless-verbouwing nodig hebt. Twijfel je of jouw snelheidsprobleem om architectuur of om optimalisatie vraagt, onze support kijkt zeven dagen per week eerlijk met je mee.
Als je het overweegt: de juiste volgorde
Denk je na dit alles nog steeds aan headless, dan is dat waarschijnlijk terecht, en dan is de volgorde: eerst de redactionele eisen scherp (welke content, welke workflows, hoe belangrijk is preview), dan de frontend-keuze door je developmentteam, en pas daarna de inrichting van WordPress als kale contentbron. Het WordPress-gedeelte zelf blijft daarbij gewoon een installatie die onderhoud, updates en beveiliging nodig heeft; alles daarover vind je in onze complete gids over WordPress-beheer. En ben je juist tot de conclusie gekomen dat een goede traditionele site je route is, dan begint die bij onze startgids voor het maken van een website met WordPress.
