Een CMS dat alles al in huis heeft, in plaats van dertig plugins die het moeten waarmaken

Waarom Umbraco, en geen WordPress

Het is de vraag die we het vaakst krijgen: waarom Umbraco, als WordPress gratis is en iedereen het gebruikt? Het eerlijke antwoord: WordPress begint goedkoop en wordt duur, en Umbraco begint serieus en blijft beheersbaar. Dat verschil zit hem niet in de core van beide systemen: het zit in alles wat je er omheen moet bouwen. Liever de feiten naast dit betoog? Bekijk Umbraco vs WordPress: de eerlijke vergelijking.

Umbraco heeft het al in huis

Wat je bij WordPress met plugins moet oplossen, is bij Umbraco onderdeel van het systeem: meertaligheid, eigen contenttypes en velden, mediabeheer, versiebeheer, previews, gebruikersrollen en rechten. Geen zoektocht naar de plugin die het net wel doet, geen abonnement per functie, geen dertig losse onderdelen die allemaal apart bijgewerkt moeten worden.

Je content model volgt jouw organisatie

In WordPress is alles in de basis een post of een pagina, en alles daarbuiten wordt met custom fields en plugins bijgebogen. In Umbraco modelleer je precies wat je hebt: een vacature is een vacature, een project is een project, een locatie is een locatie, met eigen velden, eigen validatie en een redactieomgeving die daarop is ingericht. Redacteuren vullen geen formulier in dat toevallig een pagina wordt; ze vullen hun eigen content in.

Meertaligheid is geen bijbouw

Meerdere talen zijn in Umbraco ingebouwd: een pagina bestaat in varianten per taal, met een eigen publicatiestatus en een eigen workflow. In WordPress is dat het domein van vertaalplugins, met alle koppelingen, licenties en upgrade-afhankelijkheden die daarbij horen. Precies op de plek waar het misgaat als er ooit iets gemigreerd moet worden.

Het plugin-risico

Hier zit de kern, en het is te meten. Securitybedrijf Patchstack telde over 2025 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem, 42% meer dan het jaar ervoor. De verdeling:

  • 91% zat in plugins.
  • 9% zat in thema's.
  • In WordPress zelf: 6 kwetsbaarheden, allemaal laag geprioriteerd.

En bij 46% was er op het moment van publiceren nog geen patch beschikbaar: de kwetsbaarheid was dan wel openbaar, de oplossing niet.

Het probleem is dus niet de code van WordPress. Het is de stapel eromheen. Elke plugin is in feite een extra leverancier in je website: met een eigen updateritme, een eigen kwaliteitsniveau en een eigen kans om morgen niet meer onderhouden te worden. Hoe meer plugins, hoe groter het aanvalsoppervlak, en hoe groter de kans dat een update van het ene onderdeel het andere sloopt.

Bron: Patchstack, State of WordPress Security in 2026 (cijfers over 2025).

Eerlijk is eerlijk: dat WordPress bovenaan staat komt er ook doordat het veruit het grootste platform is, met tienduizenden plugins en navenant veel onderzoekers die ernaar kijken. Umbraco kent ook packages, en die hebben ook onderhoud nodig. Het verschil zit in hoeveel je er nodig hebt.

Met Umbraco is dat oppervlak simpelweg kleiner. Er is minder nodig, dus er staat minder aan. En wat er wel bijkomt, bouwen we zelf, in code die wij onderhouden en meenemen naar de volgende versie.

Sinds Umbraco 14 kun je de site ook via een API laten bijwerken

Dit is de nieuwste reden om voor Umbraco te kiezen, en op dit moment misschien wel de leukste. Sinds Umbraco 14 draait de hele backoffice op een eigen Management API: elk scherm dat een redacteur gebruikt, praat onder water met die API. Dat is iets anders dan een API die er achteraf bij is gebouwd: wat een mens in de backoffice kan, kan een programma per definitie ook, want ze gebruiken dezelfde deur. Umbraco levert er een machineleesbare beschrijving bij (een OpenAPI-specificatie), zodat je niet hoeft te raden welke velden een pagina heeft.

Umbraco 15 maakte het bruikbaar voor koppelingen, met de API-user: een gebruiker zonder wachtwoord, die alleen namens een systeem inlogt. Zo'n API-user krijgt gewoon een rol toegewezen, net als een collega: deze secties, deze pagina's, deze rechten. Een koppeling die alleen vacatures mag bijwerken, kán ook alleen vacatures bijwerken.

Wat dat oplevert, merkten we onlangs zelf. Er kwam een verzoek om de vacatures op onze eigen site te vernieuwen, aangeleverd als Word-bestand. Geen redacteur die vier pagina's overtypt: het document erin, via de API-user eroverheen, en de vacatures stonden in de juiste opmaak op de site. Dat is precies waarom dit zo prettig is: veel mensen vinden werken in een CMS ingewikkeld, hoe goed de backoffice ook is. Je levert aan wat je toch al had, en het komt goed terecht. We schreven het hele verhaal uit in Umbraco bijwerken zonder de backoffice in te gaan.

Met één belangrijke veiligheidsklep: schrijven via de API is niet hetzelfde als publiceren. Werkt een koppeling een pagina bij die al live staat, dan bewaart Umbraco dat als openstaande wijziging; bezoekers blijven de oude versie zien tot een mens op publiceren drukt. De machine doet het typewerk, de redactie houdt het laatste woord.

Ook hier hoort een eerlijke kanttekening bij: WordPress heeft ook een API, al sinds versie 4.7 uit 2016, met sinds 5.6 ingebouwde applicatiewachtwoorden. Wie beweert dat het niet kan, heeft niet gekeken. Het verschil zit in hoe ver die API reikt. Berichten, pagina's, media en gebruikers zitten erin, maar juist de dingen die een site eigen maken vallen erbuiten of moeten apart worden aangezet: custom velden (ACF) staan standaard uit in de API, eigen contenttypes moeten expliciet worden vrijgegeven, en een pagina die met een page builder als Elementor is opgebouwd zit als één dichtgetimmerd blok in de database. Een koppeling loopt dus vast op precies het punt waar een site eigen wordt. Daar komt bij dat een WordPress-applicatiewachtwoord altijd de volledige rechten van zijn gebruiker erft, inperken tot één contenttype kan niet.

Wanneer WordPress prima is

Voor een blog of een eenvoudige site van een paar pagina's is WordPress een uitstekende keuze, en dat zeggen we ook gewoon. Het kantelt zodra er structuur bij komt: meerdere talen, meerdere contenttypes, redactieteams met verschillende rollen, koppelingen met andere systemen, of eisen op het gebied van security en compliance. Dat is precies het punt waarop de plugin-stapel begint te wringen, en waar Umbraco nog niet eens warmgelopen is.

Twijfel je waar jouw site staat? Laat het ons weten via het formulier hieronder: we denken graag mee, ook als het antwoord "blijf voorlopig waar je bent" is.

Contactgegevens

Adres

Neem contact op

Postbus

Benieuwd wat dit voor jouw site betekent? Laat je gegevens achter en vertel kort waar je tegenaan loopt, dan nemen we contact met je op. We reageren doorgaans binnen één werkdag.

 

Liever direct contact? Bel of mail ons gerust.

Veelgestelde vragen over Umbraco versus WordPress

De core van WordPress is het probleem niet: de plugin-stapel eromheen wel. Van de 11.334 nieuwe kwetsbaarheden die Patchstack over 2025 telde, zat 91% in plugins. Umbraco heeft veel van die functionaliteit ingebouwd, waardoor je minder afhankelijkheden nodig hebt en het aanvalsoppervlak kleiner is.

In aanschaf lijkt WordPress goedkoper, maar de kosten verschuiven naar plugin-abonnementen, koppelwerk en onderhoud aan een stapel losse onderdelen. WordPress begint goedkoop en wordt duur; Umbraco begint serieus en blijft beheersbaar. Vergelijk dus de totale kosten over een paar jaar, niet de licentieprijs op dag één.

Voor een blog of een eenvoudige site van een paar pagina's is WordPress een uitstekende keuze. Het kantelt zodra er structuur bij komt: meerdere talen, meerdere contenttypes, redactieteams met verschillende rollen, koppelingen met andere systemen of eisen aan security en compliance.

Dat kan, al is het eerder een herbouw dan een één-op-één-migratie: het contentmodel wordt in Umbraco opnieuw opgezet en de content gaat over. Of die stap de moeite waard is, hangt af van waar je site staat: we denken graag mee, ook als het antwoord is: blijf voorlopig waar je bent.

Ja. Sinds Umbraco 14 draait de backoffice op een Management API, en sinds Umbraco 15 kun je daarvoor een API-user aanmaken: een account zonder wachtwoord dat namens een systeem inlogt, met dezelfde fijnmazige rechten als een redacteur. Wij gebruiken dat zelf om content bij te werken vanuit aangeleverde documenten. Belangrijk: schrijven via de API zet niets direct live, op een gepubliceerde pagina landt de wijziging als openstaande wijziging, tot een redacteur publiceert.