Sinds AI websites kan bouwen, gaat de discussie over één vraag: is WordPress nu achterhaald? De ene kant zegt ja, want je laat een website toch gewoon genereren. De andere kant zegt nee, want die AI-sites zijn rommel en je kunt er zelf niets aan veranderen.
Beide kanten slaan de plank mis. Ze behandelen “de website” als één ding, terwijl een gemiddelde WordPress-site uit twee heel verschillende lagen bestaat. AI raakt er maar één van.
Twee lagen die we op één hoop gooien
De eerste laag is het beheer van je inhoud. Teksten, foto’s, nieuwsberichten, vacatures, openingstijden. Dat wil je als organisatie zelf kunnen aanpassen, op elk moment, zonder iemand te bellen. Daar is een CMS voor, een contentmanagementsysteem, en WordPress is daar het bekendste voorbeeld van.
De tweede laag is de opbouw en vormgeving van je pagina’s. Welke secties staan in welke volgorde, hoe ziet een knop eruit, hoe gedraagt het menu zich op een telefoon. Die laag regel je in WordPress meestal met een pagebuilder, zoals Elementor, Divi of WPBakery.
Die twee lagen hebben een ander doel. De eerste is er zodat jij je eigen verhaal kunt bijhouden. De tweede is er omdat het schrijven van code voor een lay-out duur en traag was.
Waarom de pagebuilder ooit bestond
Een pagebuilder is een compromis. Wie een pagina wilde opbouwen zonder programmeur, kreeg een scherm met blokken die je kon slepen en instellen. Dat was een uitkomst, want een webbouwer inhuren voor elke nieuwe sectie of elke andere knopkleur was geen doen.
De prijs van dat compromis zie je pas later. Een pagebuilder moet elke denkbare lay-out aankunnen, dus levert hij veel meer code mee dan jouw pagina nodig heeft. Elk blok komt in meerdere lagen verpakt, en de stijlen en scripts van alle mogelijke widgets reizen mee, ook als je ze niet gebruikt. De opbouw van je pagina’s ligt bovendien opgeslagen in het eigen formaat van die ene pagebuilder, waardoor je er niet makkelijk meer vanaf komt.
Daar komt bij dat die vrijheid in de praktijk weinig wordt gebruikt. Meestal bouwt een webbureau de pagina’s in de pagebuilder, en past de opdrachtgever daarna alleen nog teksten en foto’s aan. Je betaalt dan de prijs van een systeem dat alles kan, voor iets wat een CMS ook doet.
Dat was een redelijke ruil zolang het alternatief duur was. Dat alternatief is niet meer duur.
Wat AI verandert
AI kan goed en snel code schrijven voor een lay-out. Een nieuwe sectie, een aangepaste knop, een ander menu op mobiel: dat beschrijf je in gewone taal, en de code staat er binnen minuten. Het argument waarom de pagebuilder bestond, “code schrijven is te duur”, valt daarmee weg.
Zie een pagebuilder als een tolk tussen jou en de code. Je kon zelf geen code schrijven, dus kreeg je knoppen en schuifjes die dat voor je deden. Nu je in gewone taal kunt zeggen wat je wilt, heb je die tolk niet meer nodig. En een tolk die alles moet kunnen vertalen, is altijd trager en omslachtiger dan iemand die gewoon je taal spreekt.
Het argument waarom een CMS bestaat, blijft precies overeind. Jij wilt nog steeds zelf je teksten aanpassen, zonder dat daar iemand tussen zit. AI verandert daar niets aan.
Daarom is de vraag “vervangt AI WordPress?” de verkeerde vraag. De functie die WordPress voor de meeste organisaties vervult, inhoud beheren, blijft nodig. Of je dat in WordPress doet of in een ander CMS, is een tweede keuze. Wat AI wel vervangt, is de pagebuilder: de laag waarmee je zonder programmeur een lay-out in elkaar klikte.
Hoe dat er in de praktijk uitziet
In de praktijk haal je de twee lagen uit elkaar. De opbouw en vormgeving staan in code, die AI schrijft en die een mens controleert voordat hij live gaat. De inhoud staat in een CMS, waar de organisatie zelf teksten, beelden en berichten aanpast.
Een voorbeeld is Ligthart Assurantiën. Op kantoor passen ze zelf de teksten en nieuwsberichten aan, en de nieuwsbrief vertrekt vanuit dezelfde omgeving. Aan de opbouw van de pagina’s komen ze niet: die staat in code en verandert alleen als dat bewust gebeurt.
Waarom dit beter werkt dan een pagebuilder
Schonere code. Code die voor jouw pagina is geschreven, bevat alleen wat jouw pagina nodig heeft. Minder code betekent een snellere site, en een structuur die zoekmachines en AI-systemen beter kunnen lezen. Een pagebuilder moet alles kunnen, en dat merk je aan wat hij meestuurt.
Makkelijker wijzigen. Stel dat alle knoppen op je site een andere stijl moeten krijgen. In een pagebuilder hangt het ervan af of alles vanaf dag één consequent via globale stijlen is opgezet; zo niet, dan pas je ze pagina voor pagina aan. In code bestaat die knop op één plek, en verandert hij na één aanpassing overal tegelijk. Met AI gaat dat bovendien snel, omdat je de wijziging in gewone taal beschrijft. DeepCalls is om precies die reden van WordPress naar een codebasis overgestapt: wijzigingen moesten eenvoudiger worden.
Minder onderdelen die kunnen breken. Een pagebuilder is zelf een plugin, en hij trekt vaak weer extra plugins voor formulieren, sliders en effecten mee. Elke plugin die je niet nodig hebt, is er één minder om bij te houden.
Wat dit betekent voor WordPress zelf
Haal je de pagebuilder weg, dan blijft er van WordPress vooral een CMS over met een enorm plugin-ecosysteem eromheen. Dat ecosysteem was altijd de kracht van WordPress: voor elke functie een plugin, zonder programmeur. Nu code schrijven niet meer duur is, weegt dat voordeel steeds minder zwaar. Een functie die je nodig hebt, laat je bouwen voor precies jouw site, in plaats van een plugin te installeren die voor duizenden sites tegelijk is gemaakt.
Tegelijk wordt datzelfde ecosysteem een groter risico. Volgens het jaarrapport van Patchstack werden in 2025 11.334 nieuwe kwetsbaarheden gevonden in het WordPress-ecosysteem, 42% meer dan een jaar eerder. Daarvan zat 91% in plugins en 9% in thema’s. In WordPress zelf werden er zes gevonden, allemaal met een lage prioriteit. WordPress zelf is dus niet het probleem, de stapel plugins eromheen wel.
En die stapel wordt sneller aangevallen dan ooit. Bij de kwetsbaarheden die op grote schaal werden misbruikt, zat er volgens Patchstack bij de helft minder dan vijf uur tussen de bekendmaking en massale aanvallen. Bij 46% van de kwetsbaarheden was er nog geen update beschikbaar op het moment dat ze openbaar werden. Patchstack schrijft er zelf bij dat aanvallers AI krijgen die “steeds beter in staat is om zelfstandig kwetsbaarheden te vinden en te misbruiken”. Dat is geen toekomstmuziek: Google liet in 2024 al zien dat zijn AI-agent Big Sleep zelfstandig een onbekend, misbruikbaar lek vond in SQLite, een van de meest gebruikte databases ter wereld.
Dezelfde technologie die het bouwen van een website goedkoper maakt, maakt het vinden van lekken in bestaande software goedkoper. Een site met twintig plugins van twintig verschillende makers heeft twintig plekken waar dat kan gebeuren, en jij bent afhankelijk van twintig partijen om op tijd een update uit te brengen. Een site die alleen bevat wat hij nodig heeft, heeft minder deuren om open te breken. Dat maakt hem niet onkwetsbaar, wel een stuk kleiner als doelwit.
De zorgen die vaak terugkomen
“Dan kan ik zelf niets meer aanpassen.” Je teksten, beelden en berichten pas je zelf aan in het CMS, net als nu. Wat verdwijnt, is het slepen met blokken om de lay-out te veranderen. Voor de meeste organisaties is dat eerder een opluchting dan een gemis: een pagina die niet per ongeluk uit elkaar kan vallen.
“Dan zit ik vast aan degene die de code schrijft.” Dat hangt af van de afspraken, niet van de techniek. Code en een export van je inhoud zijn over te dragen aan elke andere ontwikkelaar; spreek vooraf af dat je allebei krijgt als je vertrekt. Met een pagebuilder zit je eerder vaster: je pagina’s staan in het eigen formaat van die ene plugin.
“Een overstap kost me mijn plek in Google.” Die angst is begrijpelijk. Een slordige migratie, waarbij oude webadressen verdwijnen zonder doorverwijzing, kan je posities inderdaad kosten. Een zorgvuldige migratie hoeft dat niet te doen, ook niet op korte termijn.
Een voorbeeld: IBgids.nl verhuisde op 11 april 2026 van WordPress naar Astro, met doorverwijzingen voor de oude webadressen. Binnen enkele dagen gaf Google Search Console de hoogste dagwaarden van de hele periode, voor zowel klikken als vertoningen.
Zo’n snelle stijging is zeldzaam, en de lijn liep al op voor de overstap. Er veranderde tegelijk meer dan alleen de techniek, dus de grafiek bewijst niet dat Astro de enige oorzaak is. Wat hij wel laat zien: de overstap zelf heeft de zichtbaarheid niet laten zakken, ook niet in de eerste weken.
“Code die door AI is geschreven, is toch rommel?” Code die ongecontroleerd uit een generator komt, kan dat zeker zijn. Het verschil zit in de werkwijze: AI doet het schrijfwerk, een mens controleert elke wijziging voordat hij live gaat. AI maakt een website niet vanzelf sneller of beter, die controle doet dat.
“Alle AI-websites zien er hetzelfde uit.” Dat geldt voor sites die je in één klik laat genereren. Kies je het ontwerp zelf, op basis van je merk en je bezoekers, en laat je AI alleen de code schrijven, dan heb je dat probleem niet.
“Maar WordPress heeft voor alles een plugin.” Dat klopt, en dat is precies het probleem als je er twintig hebt. Met code bouw je alleen wat je nodig hebt. Een nieuwsbrief kan dan gewoon deel uitmaken van dezelfde omgeving als de website, in plaats van een losse plugin met eigen updates.
Wanneer een pagebuilder wél de goede keuze is
Een pagebuilder is niet slecht. Elementor en platformen als Webflow en Wix hebben inmiddels zelf AI-functies, en voor sommige situaties zijn ze prima:
- Je wilt de lay-out van je pagina’s zelf regelmatig en ingrijpend veranderen, niet alleen de teksten.
- Je bouwt en beheert de site volledig zelf, zonder partner voor de techniek.
- Je marketingteam zet wekelijks nieuwe campagnepagina’s in elkaar en heeft daar geen ontwikkelaar voor.
Herken je jezelf daarin, dan is een goed opgezette pagebuilder een verstandige keuze. Wil je vooral je inhoud actueel houden en een site die snel, veilig en makkelijk aan te passen is, dan heb je die laag niet meer nodig.
Waar je op moet letten
Kijk bij je eigen website naar wat je er werkelijk mee doet. Pas je vooral teksten, foto’s en berichten aan, dan heb je een goed CMS nodig en geen pagebuilder. Wil je zelf regelmatig de opbouw van je pagina’s veranderen, dan kan een pagebuilder nog steeds de juiste keuze zijn.
