Moet je WordPress verlaten? Een besluitvormingskader voor ontwikkelaars
Ik heb mijn 47e WordPress-site vorige week van WordPress gemigreerd. De beslissingsregel die nooit in de steek heeft gelaten: als je meer tijd besteedt aan het bestrijden van WordPress dan aan het bouwen van features, vertrek dan.
Dat klinkt reductief, ik weet het. Maar na jaren van bouwen op WordPress — en jaren van het verwijderen van projecten ervan — heb ik de vraag "moet ik blijven of moet ik gaan" versmald tot iets meer gestructureerds. Een framework van vijf vragen dat je een eerlijk, kwantificeerbaar antwoord geeft. Geen vibes. Geen tribale loyaliteit aan PHP of React. Gewoon een checklist die aansluit op echte pijnpunten.
Laat ik je erlangs leiden, en dan praten we over waar je heen gaat, wat het kost, en de fouten die je migratie verpesten als je niet voorzichtig bent.
Inhoudsopgave
- Het framework van 5 vragen: moet je WordPress verlaten?
- Je antwoorden beoordelen
- Waar je naar toe gaat (per use case)
- Migratietijdlijn en kosten (echte getallen)
- De 3 fouten die WordPress-migraties verpesten
- Veelgestelde vragen
Het framework van 5 vragen: moet je WordPress verlaten?
Ik heb dit framework gebruikt met klanten, met mijn eigen projecten en met dev-teams die hun stack evalueren. Vijf ja-nee-vragen. Elk raakt een specifieke categorie WordPress-pijn — plugin-bloat, kosten, beveiliging, prestaties en snelheid.
1. Heb je meer dan 20 actieve plugins?
Twintig is het getal. Niet omdat daar iets magisch aan is, maar omdat dat het moment is waarop WordPress stopt met een CMS te zijn en begint een Frankenstein-monster te zijn, bij elkaar gehouden door add_filter-hooks en gebeden.
Elke plugin is een afhankelijkheid die je niet controleert. Elke plugin-update is een potentiële breekwijziging. En in 2026 heeft het WordPress-plugin-ecosysteem een beveiligingsprobleem dat moeilijk te negeren is: Patchstack meldde meer dan 11.300 plugin-CVE's in 2025 alleen al, een stijging van 42% ten opzichte van het voorgaande jaar. Meer plugins betekent meer aanvalsoppervlak.
Tel je actieve plugins nu meteen. Ik wacht wel.
Als je op 30+ zit, voer je vrijwel zeker plugins uit die functionaliteit dupliceren, met elkaar conflicteren, of alleen bestaan omdat WordPress iets niet native doet dat moderne frameworks uit de doos afhandelen — dingen zoals beeldoptimalisering, caching, SEO-metatags of formulierverwerking.
2. Betaal je meer dan €100 per maand voor beheerde hosting?
WordPress is "gratis" software die op de een of andere manier een fortuin kost om goed te hosten. Als je op WP Engine, Kinsta of Flywheel zit, betaal je waarschijnlijk €30-€115 per maand voor één site. Schaal dat op naar 5-10 sites en je kijkt naar €300-€600 per maand.
Ondertussen een statisch gegenereerde site op Vercel of Netlify? De gratis tier handelt de meeste marketing-sites af. Zelfs een headless CMS + Next.js-setup op Vercel Pro is €20 per maand. Dat is geen apple-to-apple-vergelijking (WordPress bevat een database, admin-UI, enz.), maar dat is precies het punt — je betaalt voor infrastructuur die je misschien niet nodig hebt.
Als je hostingrekening je laat winnen, is dat een signaal.
3. Ben je gehackt of had je downtime in de afgelopen 12 maanden?
Dit is een binaire vraag en het doet meer ertoe dan de meeste developers willen toegeven. WordPress gebruikt ~40% van het web, wat het maakt tot het grootste doelwit voor geautomatiseerde aanvallen. Brute-force-loginpogingen, SQL-injectie via verouderde plugins, malware geïnjecteerd via nulde thema's — ik heb het allemaal gezien.
Als je bent gehackt, ken je de procedure: Sucuri-scan, databaseopschoning, wachtwoordrotaties, paniek van de klant. Als je downtime hebt gehad omdat een plugin-update je site om 2 uur 's nachts verwoestte, ken je dat gevoel ook.
Moderne statische sites en server-rendered apps zonder openbare admin-panel hebben eenvoudig niet dit aanvalsoppervlak. Er is geen /wp-admin om brute-force aan te vallen. Er is geen xmlrpc.php om uit te buiten. Het beveiligingsmodel is fundamenteel anders.
4. Mislukken je Core Web Vitals op mobiel?
Google's Core Web Vitals zijn standaard geworden voor SEO in 2026. En WordPress-sites kampen hier voortdurend mee. Een HTTP Archive-analyse uit 2025 toonde aan dat ongeveer 71% van WordPress-origins de beoordeling van mobiele CWV niet haalde — vergeleken met aanzienlijk betere slagingspercentages voor sites gebouwd op frameworks zoals Next.js en Astro.
De schuldige? Render-blocking CSS van thema's en plugins. Niet-geoptimaliseerde afbeeldingen die zonder moderne formaten worden geleverd. Excessieve DOM-grootte van page builders. JavaScript dat niet nodig was. Je kunt caching-plugins naar het probleem gooien, maar je behandelt symptomen, niet oorzaken.
Voer je site uit via PageSpeed Insights. Als je mobiele LCP hoger is dan 2,5 seconden en je CLS faalt, is WordPress zelf mogelijk het knelpunt.
5. Wil je team features sneller leveren dan WP toestaat?
Dit is de vraag die het meest uitmaakt voor engineering-teams. WordPress's ontwikkelingsmodel — PHP-templates, de loop, hooks en filters, de Gutenberg block API — is een specifieke manier van bouwen. Het is niet slecht. Maar het is langzaam vergeleken met component-gebaseerde ontwikkeling met React, Vue of Svelte.
Als je team meer tijd besteedt aan:
- Worstelen met de Block Editor's React-but-not-really-architectuur
- Schrijven van aangepaste PHP om themabeperkingen heen te werken
- Debuggen van plugin-conflicten na updates
- Wachten op volledige page-cache-ongeldigmaking
...dan eigenlijk features bouwen die je gebruikers willen, dan is dat je antwoord.
Moderne frameworks laten je sneller leveren. Dat is geen mening — het is fysica. Component-gebaseerde architecturen met hot module reloading, TypeScript en API-gestuurde content verslaan de WordPress-ontwikkelingslus op iteratiesnelheid elke keer.
Je antwoorden beoordelen
Hier is je beslissingsmatrix. Opzettelijk eenvoudig:
| Ja-antwoorden | Aanbeveling | Rationale |
|---|---|---|
| 0-1 | Blijf op WordPress | Je problemen zijn te beheren. Optimaliseer wat je hebt. |
| 2 | Blijf, maar plan | Begin met het prototypen van alternatieven. Je nadert het kantelpunt. |
| 3 | Begin met migratie | De pijn is echt en verdwijnt niet vanzelf. Begin met het plannen van je vertrek. |
| 4-5 | Vertrek nu | WordPress kost je actief tijd, geld en beveiliging. Prioriteer migratie. |
Ik heb dit op waarschijnlijk 60+ projecten toegepast. Het heeft me nooit een false positive gegeven. De klanten die 3+ scoorden en op WordPress bleven? Ze kwamen 6-12 maanden later terug, en de migratie was tegen die tijd harder en duurder geworden.
Waar je naar toe gaat (per use case)
Dit is het moment waarop de meeste "verlaat WordPress"-artikelen instorten. Ze zeggen je Next.js voor alles te gebruiken, of ze zullen 15 CMS-opties opsommen zonder je te vertellen welke op je situatie past. Laat me specifiek zijn.
Marketing-sites en blogs
Aanbevolen stack: Astro + een headless CMS (Sanity, Storyblok of Contentful)
Astro werd eigenlijk ontworpen om WordPress te vervangen voor inhoudssites. Het verzend standaard nul JavaScript, genereert statische HTML en ondersteunt gedeeltelijke hydratatie voor interactieve componenten. Je Lighthouse-scores gaan van "teleurstellend" naar "perfect" in één nacht.
We bouwen veel van deze op Social Animal — onze Astro-ontwikkelingscapaciteiten zijn sterk gericht op precies dit migratiepad. Combineer Astro met Sanity Studio en je content-editors krijgen een beter ontwerpervaring dan WordPress ze ooit gaf.
E-commerce
Aanbevolen stack: Next.js + Shopify (headless) of Medusa.js
Als je WooCommerce gebruikt, ken je de pijn al. WooCommerce is krachtig maar fragiel onder belasting, langzaam zonder serieuze cache-infrastructuur, en duur om aan te passen. De Storefront API van Shopify met een Next.js-frontend geeft je winkelwagen-functionaliteit, checkout en inventarisbeheer zonder je eigen database te draaien.
Voor teams die volledige controle willen en zelf-hosting willen, is Medusa.js aanzienlijk gerijpt in 2026 en de moeite waard om te evalueren.
Webapplicaties (dashboards, portals, SaaS)
Aanbevolen stack: Next.js (App Router) + headless CMS voor inhoudsgedeelten + je eigen API
Als je WordPress hebt gehackt in een applicatie met custom post types, ACF en REST API-endpoints... stop. WordPress was nooit bedoeld om een applicatie-framework te zijn. Next.js met server-componenten, server-acties en middleware geeft je een echte applicatie-architectuur.
Inhoudsrijke editoriale sites
Aanbevolen stack: Next.js of Astro + Sanity of Strapi
Editoriale teams hebben nodig: gestructureerde inhoudsmodellering, draft-previews en collaboratief bewerken. Dit is waar een headless CMS schittert. Sanity's real-time samenwerking is jaren vooruit op de Gutenberg-editor van WordPress. Strapi geeft je een zelf-gehoste optie met een schoon admin-paneel.
| Use Case | Aanbevolen Frontend | Aanbevolen CMS | Hosting | Geschatte maandelijkse kosten |
|---|---|---|---|---|
| Marketing-site / blog | Astro | Sanity of Contentful | Vercel / Netlify | €0-€20 |
| E-commerce | Next.js | Shopify Storefront API | Vercel | €29-€79 (Shopify) + €20 (Vercel) |
| Webapplicatie | Next.js | Sanity (voor inhoud) | Vercel / AWS | €20-€100 |
| Editoraal / publiceren | Next.js of Astro | Sanity of Strapi | Vercel | €0-€99 |
Vergelijk dat met je huidige WordPress-hostingrekening. Voor de meeste teams dalen de infrastructuurkosten met 30-60%.
Migratietijdlijn en kosten (echte getallen)
Ik ga je de getallen geven die niemand wil publiceren omdat ze bang zijn klanten af te schrikken. Deze zijn gebaseerd op echte migraties die we hebben gedaan en waargenomen in 2025-2026.
Kleine site (onder 50 pagina's, eenvoudige blog)
- Tijdlijn: 3-5 weken
- Kosten: €5.000-€12.000 (bureau) / 40-80 uur (in-house)
- Belangrijkste taken: Content-export en herstructurering, template-rebuilds in Astro/Next.js, CMS-setup, redirect-mapping, DNS-omschakeling
- Moeilijkste deel: Content extraheren uit page-builder-shortcodes. Als je inhoud vol zit met
[vc_row]of Elementor JSON-blobs, budget extra tijd in voor content-opschoning.
Middelgrote site (50-200 pagina's, meerdere inhoudstypen)
- Tijdlijn: 6-10 weken
- Kosten: €15.000-€35.000 (bureau) / 120-250 uur (in-house)
- Belangrijkste taken: Alles hierboven, plus inhoudsmodellering in de headless CMS, aangepaste component-ontwikkeling, formuliersmigraties, herbedrading van derde-partij-integraties (analytics, e-mailmarketing, CRM)
- Moeilijkste deel: Het herbouwen van aangepaste ACF-veldgroepen en relaties in een nieuw inhoudsmodel. Dit is waar de meeste tijdlijn-schattingen uit de rails gaan.
Grote site (200+ pagina's, e-commerce, aangepaste functionaliteit)
- Tijdlijn: 12-20 weken
- Kosten: €40.000-€80.000+ (bureau) / 400-800+ uur (in-house)
- Belangrijkste taken: Volledige content-audit, gefaseerde migratiestrategie, data-migratiescripts, e-commerce-platform-migratie, migratie van gebruikersaccounts, SEO-behoud (redirects, sitemap, structured data)
- Moeilijkste deel: SEO niet breken. Grote sites hebben jarenlang backlinks, geïndexeerde pagina's en search authority opgebouwd. Één foute redirect-map kan je organisch verkeer maanden naar beneden doen.
Deze getallen lijken misschien hoog, maar vergelijk ze met de totale eigendomskosten van het blijven op WordPress voor nog eens 3 jaar: beheerde hosting (€100-€300/mnd × 36 = €3.600-€10.800), premium-plugin-licenties (€500-€2.000/jaar × 3 = €1.500-€6.000), reactie op beveiligingsincidenten (€2.000-€10.000 per incident) en ontwikkelaar-tijd besteed aan onderhoud in plaats van features.
Als je specifieke getallen voor je project wil bespreken, legt onze prijspagina uit hoe we dit aanpakken, en je kunt altijd rechtstreeks contact opnemen.
De 3 fouten die WordPress-migraties verpesten
Ik heb deze gezien migraties compleet verpesten. Niet "veroorzaken vertraging" — ze compleet verpesten. Als in: het team geeft het op en gaat terug naar WordPress, nadat ze maanden en tientallen duizenden euros hebben verspild.
Fout 1: Content migreren zonder het te herstructureren
De grootste fout is migratie als een copy-paste-klus behandelen. Je exporteert je WordPress-berichten en pagina's, importeert ze in een nieuwe CMS en bouwt dezelfde templates opnieuw. Dit geeft je dezelfde rommelige content-architectuur in een glimmend doosje.
Het hele doel van migratie is herstructurering. WordPress stimuleert een platte inhoudsmodel: berichten, pagina's en custom post types met ACF-velden eraan gebolt. Een headless CMS laat je juiste inhoudsmodellen definiëren met getypeerde velden, referenties en validatie.
Besteed de tijd om je inhoud te auditen voordat je één regel code schrijft. Welke inhoudstypen heb je echt nodig? Welke velden doen ertoe? Welke pagina's kunnen worden geconsolideerd of verwijderd? Ik heb 200-pagina's WordPress-sites zien worden teruggebracht tot 60 pagina's goed-gestructureerde inhoud tijdens migratie — zonder enig waardeverlies.
Fout 2: De redirect-map negeren
WordPress-URL's volgen een specifiek patroon (/2024/03/post-title/, /category/uncategorized/, enz.). Je nieuwe site heeft andere URL-patronen. Elke oude URL moet naar zijn nieuwe equivalent omleiden, of je verliest de SEO-waarde die deze pagina's hebben opgebouwd.
Dit is vervelend, ondankbaar werk. Het is ook de meest kritieke technische taak in de hele migratie. Gebruik een crawl-tool zoals Screaming Frog om elke geïndexeerde URL te exporteren, zet elk ervan om naar zijn nieuwe bestemming en implementeer 301-redirects.
// next.config.js — voorbeeld redirect-mapping
const nextConfig = {
async redirects() {
return [
{
source: '/2024/03/old-post-slug/',
destination: '/blog/new-post-slug',
permanent: true,
},
{
source: '/category/:slug',
destination: '/topics/:slug',
permanent: true,
},
// ... mogelijk honderden van deze
];
},
};
Voor grote sites wil je deze programmatisch genereren vanuit je content-export in plaats van ze handmatig in te kaarten.
Fout 3: Editors geen CMS geven voordat je live gaat
Developers houden van migraties. Content-editors haten ze. Je neemt het gereedschap weg dat ze kennen (WordPress) en geeft ze iets onbekends. Als je je editors niet vroeg betrokken hebt — hen trainen over de nieuwe CMS, hun feedback over de content-authoring-workflow krijgen, ervoor zorgen dat ze kunnen publiceren zonder hulp van developers — zullen ze rebelleren.
Ik heb een migratie twee weken voor de lancering zien worden geannuleerd omdat het marketingteam zei "we kunnen niet met dit werken." Het dev-team had een mooie Astro-site met Sanity Studio gebouwd, maar niemand had de editors laten zien hoe Sanity werkt totdat de week van lancering.
Haal je content-team in week 2, niet week 10. Laat ze test-inhoud in de nieuwe CMS maken. Luister naar hun klachten. Pas de studio-configuratie aan. Dit bepaalt of adoptie slaagt of faalt.
Veelgestelde vragen
Hoe weet ik dat het tijd is om WordPress te verlaten?
Gebruik het framework van vijf vragen hierboven. Als je "ja" antwoordt op drie of meer vragen — meer dan 20 plugins, hosting boven €100/maand, beveiligingsincidenten, falende Core Web Vitals of je team kan niet snel genoeg features leveren — is het tijd. Het framework gaat niet over WordPress haten. Het gaat om eerlijk beoordelen of het platform je helpt of tegenhoudt. Twee of minder? WordPress is waarschijnlijk nog prima voor je behoeften, en je zou je moeten concentreren op het optimaliseren van wat je hebt.
Wat is het goedkoopste WordPress-alternatief?
Astro met een gratis-tier headless CMS (Sanity's gratis plan ondersteunt 3 gebruikers, Contentful's gratis plan ondersteunt 5 gebruikers) gedeployed op Netlify of de gratis tier van Vercel. Totale kosten: €0/maand. Serieus. Voor een marketing-site of blog is deze stack productieklaar en draait beter dan een €100/maand-managed WordPress-setup. De vangst: je hebt een developer nodig die comfortabel is met Astro en je gekozen CMS — maar als je dit artikel leest, ben je dat waarschijnlijk.
Hoe lang duurt het om van WordPress af te migreren?
Voor een typische kleine site (onder 50 pagina's), rekening houden met 3-5 weken. Middelgrote sites met 50-200 pagina's en meerdere inhoudstypen lopen 6-10 weken. Grote sites met e-commerce of complexe aangepaste functionaliteit kunnen 12-20 weken duren. De grootste variabele is niet code — het is inhoud. Als je inhoud schoon en goed gestructureerd is, gaat migratie snel. Als het gevangen zit in page-builder-shortcodes en diep geneste ACF-veldgroepen, budget extra tijd in voor extractie en herstructurering.
Verlies ik SEO als ik van WordPress migreer?
Dat kan, maar je hoeft niet. De kritieke stap is het implementeren van een volledige 301-redirect-map van elke oude URL naar zijn nieuwe equivalent. Je moet ook je meta-titels, -beschrijvingen en structured data behouden (schema-markup). Crawl je bestaande site met Screaming Frog vóór migratie, exporteer alle geïndexeerde URL's en verifieer dat elke redirect na lancering werkt. De meeste goed uitgevoerde migraties zien een temporaire 2-4 week fluctuatie in rankings, gevolgd door verbetering dankzij betere Core Web Vitals.
Kan ik WordPress als headless CMS gebruiken in plaats van volledig te migreren?
Ja, en dit is een geldige tussenstap. De REST API van WordPress (of WPGraphQL) laat je WordPress als content-backend gebruiken terwijl je een modern frontend in Next.js of Astro bouwt. Dit geeft je editors de mogelijkheid om de WordPress-admin die ze kennen te gebruiken, terwijl je dev-team een sneller frontend bouwt. De minpunten: je onderhoudt nog steeds een WordPress-installatie (met al zijn beveiligings- en update-overhead), en de REST API kan langzaam zijn zonder caching. Ik zou dit als tussenstap aanbevelen, niet als bestemming.
Wat gebeurt er met mijn WordPress-plugins als ik migreer?
Ze verdwijnen — en dat is precies het doel. De meeste plugins bestaan om gaten in WordPress te vullen (SEO, caching, formulieren, beeldoptimalisering, beveiliging). In een moderne stack worden deze afgehandeld door het framework of build-tools. Next.js heeft ingebouwde beeldoptimalisering. Astro verzend nul JS standaard. Contactformulieren kunnen services als Formspree of Resend gebruiken. Analytics gaan naar Plausible of Vercel Analytics. Je moet je plugin-lijst auditen en elk ervan naar zijn vervanging in de nieuwe stack in kaarten.
Moet ik alles tegelijk migreren of in fasen?
Voor sites onder 100 pagina's, migreren alles tegelijk. De coördinatieoverhead van twee systemen tegelijk niet waard. Voor grote sites (200+ pagina's), overweeg een gefaseerde aanpak: migreer eerst de marketing-pagina's en blog, hou complexe gedeelten (e-commerce, gebruikersportals) tijdelijk op WordPress, en gebruik reverse proxy-regels om beide vanuit dezelfde domein te serveren. Dit verkleint risico maar vergroot architectonische complexiteit.
Heb ik een bureau nodig om van WordPress af te migreren, of kan ik dit zelf doen?
Hangt af van de site. Een developer comfortabel met Next.js of Astro kan een eenvoudige blog in een paar weekenden migreren. Maar voor sites met complexe inhoudsmodellen, e-commerce, aangepaste functionaliteit of hoge SEO-inzet, werken met een team dat dit eerder heeft gedaan bespaart echte tijd en geld. We hebben tientallen van deze migraties gedaan — de patronen zijn voorspelbaar en de vallen zijn goed bekend. Bekijk onze capabiliteiten of neem rechtstreeks contact op als je je specifieke situatie wil bespreken.