Blog
Een architectuurkeuze, geen upgrade.
Wanneer headless Drupal echte problemen oplost, en wanneer het enkel werk toevoegt zonder meerwaarde.
Headless Drupal is een architectuurkeuze, geen upgrade.
Je haalt de frontend uit Drupal en bouwt die apart, Drupal levert de content als gestructureerde data.
Dat lost echte problemen op, maar het voegt werk toe dat pas na de oplevering zichtbaar wordt.
Dit artikel bekijkt de afweging van jouw kant: wat vraagt het van je organisatie, wat krijg je terug en wanneer is het antwoord nee.
Wat de opzet technisch inhoudt en hoe ik zo'n traject uitvoer, staat op headless en decoupled Drupal.
Wat headless verandert aan je project
Headless verplaatst het renderen van je pagina's van Drupal naar een aparte applicatie.
Drupal blijft het contentmodel, de rechten en de redactieomgeving en levert de content via JSON:API in de core of via de GraphQL-module.
De frontend wordt een eigen project in Next.js, Nuxt of Astro, met eigen repository en releaseritme.
Alles wat Drupal meelevert, van metatags tot formulieren, zoek en taalroutering, bouw je daar opnieuw.
Je koopt vrijheid in de presentatielaag en betaalt met werk dat Drupal anders voor je deed.
Wat headless extra van je vraagt
De kosten van headless zitten in het beheer, niet in de bouw.
Vier posten komen altijd terug.
Twee codebases in plaats van een
Elke wijziging aan een contenttype raakt twee projecten.
Een veld toevoegen is in Drupal vijf minuten werk, maar de frontend moet het ook ophalen, renderen en testen.
Ook je versiebeheer verdubbelt: Drupal 11 is de stabiele lijn op 11.4.x, Drupal 12 komt uit in de week van 7 december 2026 en je frontend-framework heeft eigen majeure versies.
Preview werkt niet meer vanzelf
Preview is de post die het vaakst vergeten wordt.
In een klassieke Drupal-site ziet een redacteur een ongepubliceerde revisie meteen in de echte opmaak.
Headless vraagt daarvoor een eigen route, een beveiligd token en een omgeving die snel genoeg herbouwt.
Hetzelfde geldt voor layout: elk blok dat je redactie plaatst is een component die iemand bouwt.
Hosting en deployment verdubbelen
Je hebt twee omgevingen die apart draaien en samen moeten werken.
Drupal met PHP en een database, de frontend met Node of een buildstap, plus een cachelaag en cache-invalidatie zodra content wijzigt.
Daar komen twee deployment-pijplijnen bij en bij elk incident de vraag: zit het probleem in de backend, in de frontend of ertussen.
Kennis in je team, ook over drie jaar
Headless vraagt twee specialismen, of iemand die beide echt beheerst.
Een Drupal-profiel dat het contentmodel en de API-laag correct opzet en een frontendprofiel dat een JavaScript-framework in productie houdt.
De architectuur verandert mijn tarieven niet, maar wel het aantal uren en het aantal rollen.
Wat zulke profielen op de Belgische markt kosten lees je in wat een freelance Drupal developer kost, mijn eigen uur- en dagtarief staat op tarieven.
Voor een frontendprofiel hangt het tarief af van de markt voor JavaScript-specialisten, dus vraag dat apart uit.
Wat je ervoor terugkrijgt
De baten zijn reeel, maar smaller dan de verhalen suggereren.
De sterkste is content die je meer dan een keer publiceert: gaan dezelfde artikels, producten of locaties naar een website, een app en een partner, dan is een API-first backend de logische vorm.
De tweede is een bestaand designsysteem in React of Vue, want dat opnieuw bouwen in Twig is zonde van het werk.
De derde is teamstructuur, want twee repositories laten een frontendteam en een backendteam onafhankelijk releasen.
De snelheidsmythe
Snelheid is het argument dat het vaakst valt en dat het minst hard is.
Een klassieke Drupal-site met correcte caching, geoptimaliseerde afbeeldingen en weinig JavaScript haalt in de praktijk vergelijkbare resultaten.
Een JavaScript-framework voegt juist code toe die de bezoeker moet downloaden en uitvoeren, dus de winst hangt af van hoe de frontend gebouwd is en niet van de architectuur zelf.
Is je site vandaag traag, dan zit de oorzaak meestal in die frontend en niet in Drupal, dus meet voor je verbouwt: waarom je PageSpeed-score niet je snelheid is legt uit wat je dan wel moet meten en Core Web Vitals voor Drupal laat zien waar de winst echt zit.
Wil je dat werk uitbesteden in plaats van verbouwen, dan kan dat via technische SEO en frontend performance.
Zeven situaties met een duidelijk antwoord
Zo beantwoord ik de vraag in een intake.
Meestal beslist een van deze situaties.
| Situatie | Antwoord | Waarom |
|---|---|---|
| Een website, redactie in Drupal, geen andere kanalen | Nee | Dubbel beheer zonder tweede afnemer van je content |
| Dezelfde content naar website, app en partners | Ja | Content die je meermaals publiceert hoort achter een API |
| Designsysteem in React of Vue, met eigen frontendteam | Ja | Je hergebruikt componenten, teams blijven onafhankelijk |
| De site is traag en headless moet dat oplossen | Nee | Meet eerst waar de tijd verloren gaat |
| Marketing stelt zelf pagina's samen en wil preview | Meestal nee | Layoutvrijheid en preview kosten het meeste bouwwerk |
| Applicatie met ingelogde gebruikers, Drupal levert data | Ja | Drupal is hier echt backend, de interface een apart product |
| Je zit op Drupal 10 en moet voor 9 december 2026 migreren | Nee, niet nu | Twee ingrepen in een beweging maakt het onnodig risicovol |
Die laatste verdient uitleg.
Drupal 10 bereikt end of life op 9 december 2026 en 10.6.0 is de laatste minor release, dus veel organisaties hebben nu een harde deadline.
Wat die datum concreet van je vraagt staat in Drupal 10 loopt op 9 december 2026 uit support.
Doe je de migratie en een nieuwe frontend in een beweging, dan weet je bij een afwijking niet welke ingreep hem veroorzaakt.
Eerst naar een ondersteunde versie, daarna de architectuurvraag: Drupal migratie en upgrade.
De middenweg die vaker klopt
Tussen volledig headless en volledig klassiek zit een variant die in de meeste projecten beter uitpakt.
Drupal rendeert de pagina's en alleen de onderdelen die echt een rijke interface nodig hebben, een configurator, een kaart, een filterbare zoekmodule, worden componenten die de API aanspreken.
Je houdt preview, layoutbeheer en meertaligheid uit de core.
Frontendvrijheid alleen waar het nodig is, in plaats van overal.
Die tussenvorm is wat ik bedoel met decoupled Drupal en het is het voorstel dat ik het vaakst doe.
Toegankelijkheid verschuift naar jouw kant
In een headless opzet ben je zelf verantwoordelijk voor alle semantiek.
Drupal core levert in de klassieke opzet correcte HTML en een basis voor schermlezers en dat is precies waarom Drupal toegankelijker is dan de meeste CMSen.
Bouw je de frontend opnieuw, dan begin je bij nul: koppen, labels, zichtbare focus, statusmeldingen en routewissels zet je met de hand goed en je toetst ze zelf aan de vier principes van WCAG.
De European Accessibility Act, richtlijn 2019/882, is van toepassing sinds 28 juni 2025, met WCAG 2.2 niveau AA en EN 301 549 als normen.
Twijfel je of die regels jou raken, dan check je eerst of de European Accessibility Act voor jouw website geldt.
Zo ja, dan is dit een harde post in je begroting en geen sluitpost en moet elke release van je eigen frontend langs de toegankelijkheidstests die je zelf uitvoert.
Hoe ik dat aanpak staat op digitale toegankelijkheid.
Terugdraaien kan, gratis is het niet
Een architectuurkeuze die je niet kan herzien is een risico, dus stel die vraag voor je begint.
Het goede nieuws: Drupal blijft in een headless opzet een volwaardige Drupal-site.
Het contentmodel, de rechten, de revisies en je redactieomgeving staan er nog, dus je kan later opnieuw een Drupal-thema de weergave laten doen.
Wat je niet terugkrijgt is de investering in de frontend en alles wat je daar opnieuw bouwde: componenten, routes, formulieren en de toegankelijkheid die erin zit.
Omgekeerd is de stap kleiner.
Bouw je nu klassiek en blijkt over twee jaar dat een tweede kanaal echt nodig is, dan levert diezelfde site de content via JSON:API zonder dat je het contentmodel omgooit.
Dat verschil in risico is een argument om klassiek te beginnen zolang je twijfelt.
Wie onderhoudt de frontend over drie jaar
Dit is de vraag die in intakes het minst gesteld wordt en achteraf het duurst uitpakt.
Een Drupal-site kan je bij vrijwel elke Drupal-partij in beheer geven.
Een zelfgebouwde frontend in een JavaScript-framework is specifieker en degene die hem bouwde kent hem het best.
Vraag je dus af wie de securityupdates van dat framework doet, wie de buildpijplijn repareert als die na een versiesprong faalt en wie de componenten kent zodra je redactie iets nieuws wil.
Zit die rol niet intern, dan leg je hem contractueel vast, bijvoorbeeld via een afspraak voor Drupal onderhoud en support of door een freelance Drupal developer in te huren voor een vast aantal dagen.
Een headless opzet zonder benoemde eigenaar van de frontend veroudert sneller dan een klassieke site, simpelweg omdat er meer onderdelen zijn die aandacht vragen.
Drie vragen die de keuze beslissen
- Hoeveel kanalen consumeren dezelfde content vandaag en welke staan binnen twee jaar gepland?
- Wie onderhoudt de frontend over drie jaar en kan je die rol vervangen?
- Wat moet de redactie zelf kunnen: teksten bijwerken, of pagina's samenstellen met preview?
Een tweede echt kanaal, een team dat de frontend draagt en een redactie die alleen content beheert, maken headless verdedigbaar.
Ontbreekt er een, dan is een goed gebouwde klassieke Drupal-site het eerlijke antwoord.
Twijfel je over de architectuur?
Leg me je situatie voor via contact: welke kanalen, welk team, welke deadline.
Ik bekijk je aanvraag en geef je een eerlijk advies, ook als dat advies is dat je geen headless nodig hebt.
Veelgestelde vragen
Is headless Drupal sneller dan een klassieke Drupal-site?
Niet automatisch en vaak niet.
Een klassieke Drupal-site met correcte caching, moderne afbeeldingsformaten en beperkte JavaScript haalt vergelijkbare resultaten.
Een JavaScript-framework voegt juist code toe die de bezoeker moet downloaden en uitvoeren, dus de winst hangt af van hoe de frontend gebouwd is en niet van de architectuur zelf.
Wat gebeurt er met preview en layoutbeheer als je headless gaat?
Die twee bouw je opnieuw.
In een klassieke Drupal-site ziet een redacteur een ongepubliceerde revisie meteen in de echte opmaak en headless vraagt daarvoor een eigen route, een beveiligd token en een omgeving die snel genoeg herbouwt.
Hetzelfde geldt voor layout: elk blok dat je redactie plaatst is een component die iemand bouwt.
Stelt je marketingteam zelf pagina's samen, dan is dit meestal het argument om niet volledig headless te gaan.
Wie onderhoudt de frontend van een headless site?
Iemand met kennis van het framework waarin die frontend gebouwd is en dat is een smallere groep dan de Drupal-markt.
Reken op securityupdates van dat framework, een buildpijplijn die na een versiesprong opnieuw moet werken en componenten die iemand moet kennen zodra je redactie iets nieuws wil.
Zit die rol niet in je team, leg hem dan contractueel vast voor je begint, want een frontend zonder eigenaar veroudert snel.
Kan een headless site voldoen aan WCAG 2.2 AA?
Ja, maar je bouwt de toegankelijkheid volledig zelf.
De semantiek die Drupal core meelevert verdwijnt zodra je de frontend opnieuw opbouwt: koppen, labels, zichtbare focus, statusmeldingen en routewissels zet je met de hand goed.
Reken er ook op dat je elke release van die frontend zelf test, want er is geen themalaag meer die het basiswerk voor je doet.
Kun je een headless frontend later terugdraaien?
Ja, want Drupal blijft in een headless opzet een volwaardige Drupal-site.
Het contentmodel, de rechten en de revisies staan er nog, dus je kan later opnieuw een Drupal-thema voor de weergave gebruiken.
Wat je kwijt bent is de investering in de frontend, dus die keuze is omkeerbaar maar niet gratis.
Moet ik eerst migreren of eerst headless bouwen?
Eerst migreren.
Drupal 10 bereikt end of life op 9 december 2026, dus een ondersteunde versie is de prioriteit.
Doe je de migratie en een nieuwe frontend in een beweging, dan weet je bij een afwijking niet welke van de twee ingrepen hem veroorzaakt.
Breng je site eerst naar een ondersteunde versie en beantwoord de architectuurvraag daarna, met een werkend vertrekpunt.
Een vraag over dit onderwerp?
Beschrijf kort je situatie, dan laat ik weten wat er speelt en wat het zou kosten. Zonder offertetraject.
