Inzichten
Headless WordPress met Next.js: wanneer is het de moeite waard?
Ik krijg deze vraag geregeld van bureaus: onze klant wil een snellere, modernere website, moeten we van WordPress af? Meestal niet. Maar er zijn een paar situaties waarin headless WordPress met een Next.js-frontend een aantoonbaar beter resultaat geeft dan het klassieke thema-gebaseerde model. Dit is de afweging zoals ik hem in de praktijk maak.
Wat headless eigenlijk betekent
Bij een headless opzet blijft WordPress de plek waar redacteuren content invoeren — via het vertrouwde beheerpaneel, met dezelfde ACF-velden als altijd — maar de website die bezoekers zien wordt niet langer door een WordPress-thema gerenderd. In plaats daarvan haalt een losstaande Next.js-applicatie de content op via de WordPress REST API of WPGraphQL, en rendert die zelf, server-side.
Het CMS en de frontend worden dus twee losse applicaties die met elkaar praten via een API, in plaats van één samengesmolten geheel.
Wanneer het de moeite waard is
De winst is het grootst bij content-zware sites met veel verkeer waar laadtijd direct impact heeft op conversie: vergelijkingssites, marketplaces, sites met veel organisch zoekverkeer waar elke 100ms telt. Ook wanneer je dezelfde WordPress-content op meerdere platforms wilt tonen (website, app, interne tools) is headless logisch, omdat de content dan al als API beschikbaar is.
Een derde situatie: je hebt al een sterk Next.js-team of -codebase (bijvoorbeeld een bestaand platform) en wilt WordPress alleen als contentbron gebruiken, zonder het hele platform in WordPress zelf te bouwen.
Wanneer je beter bij WordPress blijft
Voor de meeste marketingsites, brochurewebsites en zelfs de meeste webshops is klassiek WordPress met maatwerk ACF-blocks (geen page builder) simpelweg de pragmatischere keuze. Je verliest met headless de ingebouwde previews, de WYSIWYG-ervaring voor redacteuren en een deel van het plugin-ecosysteem (SEO-plugins, formulierbouwers) dat uitgaat van een klassiek gerenderd thema.
Headless verdubbelt bovendien effectief het aantal systemen dat onderhouden moet worden: een WordPress-backend én een Next.js-frontend, elk met eigen deploys, dependencies en beveiligingsupdates. Die extra complexiteit moet je terugverdienen met snelheid of flexibiliteit die je er ook echt voor nodig hebt.
Een tussenweg: goed geoptimaliseerd klassiek WordPress
Voordat je voor headless kiest, is het de moeite waard om te checken of het snelheidsprobleem eigenlijk wordt veroorzaakt door een page builder (Elementor, WPBakery) en niet door WordPress zelf. Maatwerk ACF-blocks met semantische HTML en goede caching halen vaak al 80% van de performance-winst van headless, zonder de extra systeemcomplexiteit.
Veelgestelde vragen
Goede Vragen
Verwachtingen scherp voordat we starten, met een eerlijk proces en heldere antwoorden.
Ja. Ik begin vaak met de pagina's die het meeste verkeer of het meeste conversierisico hebben, en migreer de rest in fases, zodat redacteuren steeds hetzelfde beheerpaneel blijven gebruiken.
Dat hangt sterk af van het aantal templates en custom functionaliteit, maar reken op een vergelijkbare investering als een volledige maatwerk-rebuild — headless is geen kleine toevoeging, het is een nieuwe frontend.
Contact
Zeg Hallo
Heb je een project in gedachten? Vertel me er iets over, dan reageer ik binnen een dag.