Stop met WordPress-spaghetti

WordPress is geen slechte keuze, maar het groeit tegen je

WordPress heeft een reden waarom het op veertig procent van het web draait. Het is flexibel, de community is groot, en voor een klein budget krijg je snel een werkende site. Maar die flexibiliteit heeft een prijs: alles is gebaseerd op plugins, themes en een database die niet ontworpen zijn om samen te werken.

In het begin valt dat niet op. Je installeert een contact-formulier-plugin, een SEO-plugin, een caching-plugin, een backup-plugin. Prima. Maar zodra je site groeit en je meer functionaliteit toevoegt, meer plugins activeert en meer themes aanpast, ontstaat er een web van afhankelijkheden dat niemand meer volledig overziet. Jijzelf ook niet.

Ik noem dat WordPress-spaghetti. Niet als kritiek op de tool, maar als beschrijving van een patroon dat ik keer op keer zie bij MKB-sites die vijf jaar oud zijn: twintig, dertig, soms tachtig plugins. Themes aangepast door drie verschillende ontwikkelaars. Een update-schema dat niemand meer bijhoudt want de site breekt dan.

Wat er in de praktijk fout gaat bij WordPress op schaal

De problemen die ik het meest tegenkom bij WordPress-sites die te lang zijn doorgegroeid:

• ▸Plugin-conflicten: twee plugins die dezelfde jQuery-versie vereisen maar dan conflicteren. Een update van WooCommerce die de betaalpagina breekt. Een Elementor-update die custom CSS overschrijft.
• ▸Security-kwetsbaarheden: WordPress is het meest aangevallen CMS ter wereld. Elke niet-bijgewerkte plugin is een potentiële aanvalsvector. Ik kom regelmatig sites tegen die drie versies achterlopen op kritische patches.
• ▸Performance-problemen: Elementor en Divi laden megabytes aan CSS en JavaScript voor elke pagina, ook als je die bouwer alleen voor de homepagina gebruikt. Een LCP van vier seconden is geen uitzondering. Het is de norm.
• ▸Licentiekosten die oplopen: premium plugins kosten €50–€300 per jaar, per plugin. Een site met tien premium plugins betaalt jaarlijks meer aan licenties dan aan hosting.
• ▸Ontwikkelaarsschaarste: WordPress-ontwikkelaars zijn er genoeg, maar een goede developer die ook weet hoe performance, security en custom post-types samenhangen, is schaars en duur.
• ▸Lock-in door page-builders: een site gebouwd in Elementor of Beaver Builder is praktisch niet overdraagbaar naar een andere aanpak zonder alles opnieuw te bouwen.

Dit is geen theorie. Dit zijn de bevindingen die ik tegenkom in de audit die ik altijd doe voordat ik aan een migratie begin. De meeste klanten zijn verrast door de omvang, niet door het bestaan.

Hoe ik jouw content en URLs migreer

De technische kern van een WordPress-migratie is de content-export en de redirect-mapping. WordPress heeft een REST API die ik gebruik om alle posts, pagina’s, custom post types, media en taxonomieën gestructureerd te exporteren. Dat geeft me een JSON-dump die ik vervolgens kan transformeren naar MDX-bestanden of een headless CMS.

Naast de content bouw ik een volledige URL-map. Ik crawl jouw bestaande site, vergelijk die met de Google Search Console-data, en bouw een redirect-tabel die elke geïndexeerde URL koppelt aan de nieuwe URL-structuur. Die tabel wordt 301-redirect voor 301-redirect geïmplementeerd voordat de nieuwe site live gaat.

• ▸WP REST API-export: alle posts, pagina’s, custom post types en media worden geëxporteerd via de standaard WordPress REST-endpoints. Geen handmatig kopiëren.
• ▸Content-transformatie: de ruwe WordPress-HTML wordt omgezet naar schone MDX of CMS-invoer, zonder shortcodes, zonder Elementor-markup, zonder verborgen stijlen.
• ▸Redirect-mapping: elke URL die in Google geïndexeerd staat, krijgt een 301-redirect naar de equivalente nieuwe URL. Inclusief pagina-2-varianten en categorie-URLs.
• ▸Sitemap-inzending: na livegang stuur ik de nieuwe sitemap.xml naar Google Search Console en monitor ik de crawl-statistieken.

Security: het stille risico van een verouderde WordPress-site

WordPress-beveiliging is een actieve bezigheid, geen eenmalige instelling. Elke dag worden er nieuwe kwetsbaarheden ontdekt in plugins en themes. Als je een plugin niet bijwerkt omdat je bang bent dat de site breekt, sta je de deur open voor geautomatiseerde aanvallen die WordPress-installaties massaal scannen op bekende kwetsbaarheden.

Ik heb klanten gehad die ontdekten dat hun WordPress-site al maanden deel uitmaakte van een spamnetwerk. De site werkte gewoon, maar de server stuurde duizenden spam-mails per dag. In een ander geval was er een redirect geïnjecteerd die mobiele bezoekers doorstuurde naar een phishing-pagina. Beide incidenten waren het gevolg van een niet-bijgewerkte plugin.

Next.js heeft dit probleem structureel niet. Er is geen database die rechtstreeks aangesproken kan worden via een SQL-injectie. Er is geen plugin-architectuur met achterdeurtjes. De aanvalsoppervlakte is minimaal: statische bestanden, een API-endpoint als dat nodig is, en een beheerde hosting-omgeving. Na de migratie hoef je niet meer dagelijks te controleren of er een plugin-update klaarstaat die je site kan breken.

Wat ik anders doe dan een WordPress-bureau

De meeste WordPress-bureaus lossen een WordPress-probleem op met een WordPress-oplossing: een betere caching-plugin, een ander theme, meer servergeheugen. Dat werkt op de korte termijn, maar het lost het structurele probleem niet op. Plugins zijn niet het probleem. Het systeem van afhankelijkheden is het probleem.

Ik werk niet met WordPress als output. Ik gebruik WordPress als startpunt: ik lees jouw data via de REST API, exporteer jouw content, en bouw een nieuwe omgeving in Next.js die geen van de WordPress-aannames heeft. Geen database die vatbaar is voor SQL-injectie. Geen plugin-updates die de site kunnen breken. Geen maandelijkse licenties voor formulier-plugins.

Wat ik meeneem: jouw content, jouw URLs, jouw SEO-positie en jouw design-intentie. Wat ik achterlaat: de technische schuld, de plugin-hel en de security-risico’s. Het resultaat is een site die jij volledig begrijpt, die door mij beheerd kan worden, en die niet afhankelijk is van de roadmap van een third-party plugin-ontwikkelaar.

Beheer en CMS na de migratie

Een veelgehoorde zorg: ‘Maar ik wil zelf mijn content kunnen aanpassen.’ Dat kan. En beter dan in WordPress. Afhankelijk van de hoeveelheid content en hoe vaak je die aanpast, kies ik voor:

• ▸een eigen CMS: een Git-gebaseerd CMS dat direct in de repository schrijft. Geen aparte database, geen aparte server. Jij bewerkt content in een overzichtelijke UI, ik zie de wijziging als een Git-commit.
• ▸een eigen CMS: een headless CMS met een volledig configureerbare redactie-interface. Geschikt als je meerdere redacteuren hebt of als de content-structuur complex is.
• ▸MDX-bestanden: voor eenvoudige sites met weinig content-updates werkt een directe MDX-structuur ook. Je bewerkt Markdown-bestanden, ik deploy automatisch via een CI/CD-pipeline.
• ▸Geen CMS: voor brochure-sites waarbij de content zelden wijzigt, is een CMS overbodig. Ik lever de pagina’s als statische bestanden en je vraagt me als er iets moet veranderen.

In alle gevallen heb je volledige toegang tot je eigen data. Er is geen WordPress-admin waarvoor je een apart wachtwoord beheert, geen database die apart beveiligd moet worden, en geen plugin die jouw content in een eigen formaat opslaat dat moeilijk te exporteren is.

Lees verder