WordPress vs Next.js + AI: waarom de kloof blijft groeien

WordPress draait op ongeveer 43% van het web, en de meeste van die sites zijn traag, onveilig en duur in onderhoud. Dat is geen mening. Google's Core Web Vitals-data uit het HTTP Archive laat zien dat WordPress-sites consistent slechter presteren dan sites die met moderne frameworks zijn gebouwd.

We hebben op WordPress gebouwd. Veel bedrijven draaien er nog op. Maar de afstand tussen WordPress en wat moderne webdevelopment er in 2026 daadwerkelijk uitziet, is moeilijk te rechtvaardigen geworden -- zeker nu AI-agents taken afhandelen waarvoor je vroeger het plugin-ecosysteem van WordPress nodig had.

Als je een nieuwe site plant of een rebuild overweegt, zetten we architectuur, performance, beveiliging, kosten en de AI-invalshoek -- die deze hele discussie stilletjes heeft veranderd -- voor je op een rij.

WordPress' marktaandeel van 43% is echt. Het is ook misleidend.

Een flink deel van die sites bestaat uit verlaten blogs, geparkeerde domeinen en brochuresites van vijf pagina's die sinds 2019 niet meer zijn bijgewerkt. Filter op actief onderhouden bedrijfswebsites met echt verkeer en het aandeel van WordPress krimpt snel. Filter nogmaals op sites die alle drie de Core Web Vitals halen, en het krimpt nog sneller.

Het platform werd populair om goede redenen. In 2008, als je een website wilde zonder code te schrijven, was WordPress je beste optie. Themes, plugins, een visuele editor die goed genoeg werkte. Voor zijn tijd was het uitstekend.

Maar dat tijdperk eindigde. Het web bewoog richting componentgebaseerde architecturen, statische generatie, edge computing en API-first design. WordPress bewoog richting... Gutenberg-blocks. Die nog steeds trager zijn dan met de hand HTML typen, eerlijk gezegd.

De plugin-afhankelijkheidsval

Dit horen WordPress-fans niet graag. Een contactformulier nodig? Plugin. SEO-tools nodig? Plugin. Caching? Plugin. Beveiliging? Plugin. Image-optimalisatie? Plugin.

Elke plugin voegt databasequeries, HTTP-requests en potentiële beveiligingslekken toe. Een typische zakelijke WordPress-site draait 20-30 plugins. Dat zijn 20-30 onafhankelijke codebases van verschillende ontwikkelaars met verschillende beveiligingspraktijken en updateschema's. Sommige van die ontwikkelaars zijn allang met andere projecten verder.

We hebben WordPress-sites geaudit die 47 plugins draaiden. De site laadde in 8,3 seconden. De klant betaalde €200 per maand puur aan premium plugins.

WordPress is een monolithische PHP-applicatie die bij elke paginalading met een MySQL-database praat. Elke. Enkele. Pagina.

Wanneer iemand je homepage bezoekt, start WordPress PHP, queryt de database voor je theme-instellingen, queryt opnieuw voor je sidebar-widgets, queryt opnieuw voor je menu, queryt opnieuw voor je laatste posts, en assembleert dat allemaal tot HTML. Op shared hosting (waar de meeste WordPress-sites draaien) duurt dit 2-4 seconden voordat de browser ook maar begint te renderen.

Cachingplugins helpen. Maar het zijn pleisters. Je cachet de output van een traag systeem in plaats van een snel systeem te bouwen.

Waarom Gutenberg het niet oploste

WordPress' block-editor (Gutenberg) zou contentbewerking moderniseren. In de praktijk introduceerde het een React-gebaseerde editor bovenop een PHP-gebaseerde backend. De bewerkervaring verbeterde marginaal. De performance-overhead nam toe. En de leercurve voor custom block development is steiler dan vanaf nul componenten bouwen in Next.js.

Eerlijk gezegd: als je flink hebt geïnvesteerd in custom Gutenberg-blocks, wordt het migratiegesprek lastiger. Maar dat maakt de architectuur niet beter.

De REST API als ontsnappingsroute

Met de REST API van WordPress kun je het inzetten als headless CMS, dat content voedt aan een aparte frontend. Sommige teams doen dat. Maar dan onderhoud je WordPress (met alle beveiligingsbagage van dien) puur als content-editinginterface. Voor die specifieke taak zijn betere opties: Sanity, Strapi of zelfs een simpele JSON-bestandsstructuur die AI-agents kunnen beheren. Voor bedrijven die volledige controle over hun contentworkflows willen, ruimt custom CMS-development de afwegingen van zowel WordPress als third-party SaaS-platforms uit de weg.

Next.js kiest een smallere benadering, en die afweging betaalt zich uit.

In plaats van een monolithische applicatie bouwt Next.js je site bij compileren. Pagina's worden statische HTML-bestanden, geserveerd vanaf een CDN. Geen databasequeries. Geen PHP-uitvoering. Geen server-side rendering bij elke request (tenzij je dat specifiek nodig hebt voor dynamische content).

Pagina's laden in minder dan 1 seconde. Vaak onder de 500 milliseconden. Niet vanwege caching-trucs, maar omdat er minder werk is op het moment van de request.

Statische generatie vs server-side rendering

Next.js geeft je drie renderstrategieën:

Static Generation (SSG) bouwt pagina's bij deploy. Goed voor marketingsites, blogs, productpagina's. De HTML bestaat al voordat iemand bezoekt.

Incremental Static Regeneration (ISR) bouwt specifieke pagina's op de achtergrond opnieuw, terwijl de gecachete versie geserveerd wordt. Werkt goed voor content die dagelijks verandert maar geen realtime updates nodig heeft.

Server-Side Rendering (SSR) genereert pagina's bij elke request. Dit gebruik je voor gebruikersdashboards of gepersonaliseerde ervaringen waar de content per bezoeker verschilt.

WordPress geeft je één optie: alles bij elke request genereren en hopen dat je cachingplugin de rest opvangt. Daarom draaien hoogpresterende websites tegenwoordig vrijwel altijd op moderne frameworks.

Componentgebaseerde architectuur

Elk onderdeel van een Next.js-site is een herbruikbaar component. Een prijstabel, een testimonialcarousel, een contactformulier. Eens bouwen, overal hergebruiken. Moet je je CTA-knop op 47 pagina's updaten? Eén component aanpassen.

WordPress-themes verspreiden templatelogica over tientallen PHP-bestanden. Shortcodes, template parts, hooks, filters. Het werkt, maar het is alsof je meubilair in elkaar zet met instructies in drie verschillende talen.

De meeste WordPress vs Next.js-vergelijkingen slaan dit deel volledig over.

Twee jaar geleden was het argument voor WordPress simpel: sneller op te zetten, lagere technische drempel, enorm plugin-ecosysteem. In 2026 handelen AI-agents developmenttaken af waar je vroeger weken aan kwijt was. Het snelheidsvoordeel dat WordPress ooit had, is grotendeels verdampt.

Een AI-codingagent kan in uren een complete Next.js-site neerzetten met routing, styling, SEO en contentbeheer. Geen template. Een werkende site met custom componenten afgestemd op je eisen.

Wat AI-agents écht doen in webdevelopment

Vergeet de hype over AI die "developers vervangt". Dat gebeurt niet. Dit is wat agents vandaag wél doen:

• Componentcode genereren en verfijnen op basis van designvereisten
• Content schrijven, optimaliseren en vertalen naar meerdere talen
• Toegankelijkheidsaudits draaien en problemen automatisch oplossen
• Images, bundle sizes en performance optimaliseren
• Repetitief werk afhandelen: meta tags, sitemap-updates, structured data
• Layoutproblemen en cross-browserinconsistenties debuggen

In een WordPress-workflow zou je hiervoor 6-8 verschillende plugins installeren (en voor de meeste betalen). Met Next.js en AI-agents is het onderdeel van het developmentproces.

WordPress AI-plugins vs native AI-integratie

WordPress heeft AI-plugins. Inmiddels waarschijnlijk 200. De meeste zijn ChatGPT-wrappers die middelmatige blogposts genereren. Sommige bieden "AI-gedreven SEO-optimalisatie" wat neerkomt op het herschrijven van je metabeschrijving.

Dat is bolt-on AI. Het begrijpt niets van je site-architectuur, je componentstructuur of je contentstrategie. Het verwerkt enkel tekst.

AI-agents in een Next.js-workflow werken anders. De agent heeft toegang tot je hele codebase, je contentstructuur, je stylingsysteem. Hij maakt wijzigingen die architectonisch samenhangen, niet alleen tekstueel zijn aangepast.

Performancevergelijkingen zonder concrete cijfers zijn waardeloos. Hier zijn echte benchmarks gebaseerd op productiesites.

Deze cijfers komen uit Google PageSpeed Insights en data van het Chrome UX Report en vergelijken zakelijke websites (geen persoonlijke blogs) met vergelijkbare contentcomplexiteit.

Het TTFB-verschil is het meest onthullend. WordPress heeft 1,4 seconden nodig om alleen al de HTML te genereren. Een statisch gegenereerde Next.js-pagina wordt al in 80 milliseconden vanaf het CDN-edgenode dichtst bij de gebruiker geserveerd.

Google is hier duidelijk over: Core Web Vitals zijn een ranking-signaal. Sites die deze benchmarks niet halen, zakken in zoekresultaten. Als je websitesnelheid onder 2 seconden zakt, verlies je al bezoekers en posities.

We hebben WordPress-sites gezien met premium caching, CDN-integratie en image-optimalisatie die alsnog niet door Core Web Vitals kwamen. Het architectuurplafond is reëel.

WordPress is verantwoordelijk voor naar schatting 90% van alle CMS-gerelateerde beveiligingsincidenten. Dat cijfer, uit Sucuri's jaarlijkse rapport over gehackte websites, is in jaren niet verbeterd.

Het aanvalsoppervlak is enorm. Een draaiend PHP-proces, een MySQL-database die queries accepteert, een adminpaneel toegankelijk via /wp-admin, XML-RPC-endpoints, REST API-endpoints, en de code van elke plugin draait met dezelfde rechten als WordPress core.

Een statische Next.js-site heeft geen server-side runtime, geen database, geen adminpaneel om te brute-forcen, geen plugins die code uitvoeren. Je kunt geen site hacken die alleen uit HTML-bestanden op een CDN bestaat. Er is niets om te misbruiken.

Veelvoorkomende WordPress-aanvalsvectoren

Brute force-aanvallen op wp-login.php, SQL-injectie via kwetsbare plugins, cross-site scripting via verouderde themes, privilege escalation via plugin-kwetsbaarheden. Geen theorie. Het gebeurt dagelijks.

Elke plugin die je installeert is een potentiële toegangspoort. Plugin-ontwikkelaars volgen niet altijd security best practices. Sommigen slaan API-keys in plaintext op. Sommigen sanitizen geen gebruikersinvoer. Sommigen zijn al twee jaar niet bijgewerkt maar hebben nog 100.000 actieve installaties.

De onderhoudsbelasting

WordPress veilig houden is een fulltime baan. Core-updates, plugin-updates, theme-updates, PHP-versie-updates, databasebackups, security monitoring. Mis er één en je staat bloot.

Met een statische site op Vercel of vergelijkbaar is je beveiligingsmodel: "er is niets om aan te vallen". Dat is geen luiheid. Dat is de hele essentie.

De kostenvergelijking WordPress vs Next.js verrast de meeste ondernemers. WordPress lijkt vooraf goedkoper. Over 3 jaar is dat meestal niet zo.

De initiële bouwkosten liggen hoger voor Next.js. Geen discussie. Maar het hosten van een statische site is in feite gratis (de free tier van Vercel dekt de meeste zakelijke sites). Geen premium plugins. Geen security monitoring service. Geen iemand betalen om malware op te ruimen en backups terug te zetten na een breach.

Content-updates verdienen aparte aandacht. Op WordPress heb je iemand nodig die het CMS begrijpt of betaal je een bureau voor elke wijziging. Met een AI-augmented Next.js-workflow kunnen contentwijzigingen geautomatiseerd worden. Onze contentpijplijn genereert, optimaliseert en publiceert content in 11 talen zonder dat iemand een bestand aanraakt.

De verborgen kosten van goedkope websites raken WordPress-gebruikers hard. Die WordPress-site van €3.000 gebouwd door een freelancer? Reken nog €10.000+ extra over drie jaar om hem draaiende, veilig en acceptabel performant te houden.

We zouden geloofwaardigheid verliezen als we beweerden dat WordPress nooit de juiste keuze is. In een aantal situaties werkt het prima:

Simpele persoonlijke blogs. Schrijf je over tuinieren of reizen en geef je niet om performancescores? Dan voldoet WordPress met een lichtgewicht theme. Je publiek leest content, het beoordeelt je TTFB niet.

Krap budget, geen technische middelen. Een soloondernemer die volgende week iets online nodig heeft en in totaal €500 te besteden heeft? WordPress.com (gehost) doet het werk.

Bestaand team met diepe WordPress-expertise. Heeft je bedrijf 3 WordPress-developers en nul JavaScript-developers? Dan brengt omscholing eigen kosten met zich mee.

WooCommerce-afhankelijke bedrijven. Loopt je omzet via WooCommerce met complexe productconfiguraties? Dan is de hele e-commercestack migreren een groot project. Wel waard om te plannen, niet om te overhaasten.

Maar elk van deze scenario's heeft een houdbaarheidsdatum. De persoonlijke blog groeit uit tot een bedrijf. Het budget breidt uit. Het team neemt nieuwe developers aan die React kennen. De WooCommerce-site heeft features nodig die het platform niet ondersteunt.

WordPress werkt als startpunt. Het is steeds moeilijker te rechtvaardigen als permanente keuze.

Bij automatisering wordt deze vergelijking scheef.

WordPress' AI-mogelijkheden

WordPress AI-plugins kunnen blogpostconcepten genereren, SEO-verbeteringen voorstellen (op veldniveau, niet structureel), basale image alt-teksten maken en chatbotwidgets aanbieden. Bruikbaar, maar beperkt.

Je kunt geen WordPress AI-plugin de navigatie van je site laten herstructureren, je pagina-architectuur laten optimaliseren of je theme laten refactoren voor performance. De plugin kan het onderliggende systeem niet zien of aanpassen. Hij raakt alleen contentvelden aan.

Agent-workflows in moderne development

Een AI-agent in een Next.js-workflow opereert op een ander niveau. Hij leest en wijzigt de daadwerkelijke codebase. Hij begrijpt componenthiërarchie, stylingsystemen, routinglogica en contentstructuur.

Echte voorbeelden uit productieworkflows:

• Schrijf een artikel: agent doet research, schrijft, optimaliseert voor SEO, genereert images, converteert naar JSON, lokaliseert naar 11 talen, publiceert. Eén commando.
• Herontwerp een sectie: agent leest het huidige component, stelt alternatieven voor op basis van conversiedata, implementeert de gekozen optie en test over breakpoints.
• Performance fixen: agent audit de build, vindt bottlenecks, past fixes toe, verifieert met Lighthouse.

Dit doen we nu allemaal. Zo werkt AI-first development in de praktijk. WordPress kan dit niveau van automatisering niet ondersteunen, omdat de codebase niet is gestructureerd voor programmatische aanpassing.

Het samengestelde effect

Elke geautomatiseerde taak bespaart tijd. Over maanden stapelen die uren zich op. Content waar voorheen 3 dagen aan researchen, schrijven, vertalen en publiceren in zat, kost nu uren. Bugfixes die de volle aandacht van een developer vroegen, worden door agents afgehandeld terwijl de developer aan features werkt.

WordPress-plugins geven je incrementele efficiëntie. AI-agents veranderen de workflow volledig. De kloof zal niet sluiten, want hij is architectonisch.

Migratie klinkt eng, en eerlijk gezegd zijn een aantal van die zorgen terecht. Maar inmiddels hebben teams het vaak genoeg gedaan dat het proces voorspelbaar is.

Contentmigratie

WordPress slaat content op in een MySQL-database. Exporteren naar JSON of Markdown is rechttoe rechtaan met WP-CLI of custom exportscripts. Posts, pagina's, categorieën, tags en mediarefenties verhuizen schoon mee. De lastige delen: shortcode-afhankelijke content (vraagt meestal handmatige cleanup) en custom post types met complexe metavelden.

Voor de meeste zakelijke sites met 20-100 pagina's neemt contentmigratie 1-2 dagen in beslag.

Designhercreatie

Je WordPress-theme verhuist niet naar Next.js. Je design wel. Een vakkundig developmentteam maakt je visuele design opnieuw als React-componenten -- meestal met verbeteringen onderweg. Moderne CSS-frameworks (Tailwind bijvoorbeeld) maken het stylingproces sneller dan worstelen met WordPress theme-customization.

Functionaliteit in kaart brengen

Elke plugin wordt vervangen door ingebouwde frameworkfeatures of speciaal gebouwde code. Contactformulier? 30 regels code. SEO meta tags? Ingebouwd in het framework. Analytics? Eén script-tag. Image-optimalisatie? Automatisch met de Next.js Image-component.

De grootste mentale verschuiving: beseffen hoe weinig custom code er nodig is om te vervangen wat 15-20 plugins vereiste.

Tijdlijn en budget

Een typische WordPress-naar-Next.js-migratie voor een mid-sized zakelijke site duurt 4-8 weken met een toegewijd team. Het is een echte investering. Maar geen terugkerende. Eenmaal gemigreerd dalen de onderhoudskosten dramatisch.

Je website-structuur plannen vóór migratie maakt het hele proces sneller en voorkomt verrassingen.

Sla de ideologie over. Focus op jouw situatie.

Blijf op WordPress als:

• Je site werkt, Core Web Vitals haalt en je team het goed onderhoudt
• Je zware WooCommerce-afhankelijkheden hebt die niet eenvoudig te vervangen zijn
• Je budget op dit moment geen rebuild ondersteunt
• Je geen toegang hebt tot JavaScript/React-developmentmiddelen

Ga over op Next.js + AI als:

• Je site Core Web Vitals niet haalt en performance-inspanningen tegen muren blijven aanlopen
• Je echt geld uitgeeft aan premium plugins en securitydiensten
• Je AI-agents structureel betrokken wilt hebben bij content, development en automatisering
• Je toch al een redesign plant (migratie tijdens redesign is de meest kostenefficiënte route)
• Je concurrenten zijn overgestapt op moderne stacks en dat is terug te zien in zoekposities

De tussenoptie:

• Gebruik WordPress als headless CMS met een Next.js-frontend. Je behoudt de bewerkomgeving die je team kent en krijgt de moderne frontendperformance. Het is een compromis, en zoals de meeste compromissen: niemand is er dol op. Maar het werkt als brug.

In tientallen projecten hebben we teams deze switch zien maken zonder spijt. De performancewinst en automatiseringsmogelijkheden stapelen zich op in de loop van de tijd. Bekijk hoe het proces werkt op onze pagina voor webdevelopmentdiensten.

De kloof tussen WordPress en moderne frameworks sluit niet. Elke maand brengt nieuwe AI-mogelijkheden die frameworks zoals Next.js native opnemen, terwijl WordPress wacht tot iemand er een plugin voor schrijft.