Website opknappen of een nieuwe laten bouwen? Zo bepaal je het

Waarom design en leeftijd je hier niet verder helpen

De checklists die je tegenkomt bij het zoeken naar “website opknappen of nieuwe website” stellen bijna allemaal dezelfde vragen: ziet het ontwerp gedateerd, werkt de site goed op mobiel, hoe oud is hij eigenlijk. Dat zijn smaakoordelen. Wie de checklist schrijft, bepaalt meteen ook het antwoord, en dat antwoord is bij vrijwel elke partij die zo’n lijst publiceert: bouw iets nieuws. Een oordeel over hoe een site eruitziet is niet fout, maar het is ook nooit hard. Er is geen manier om “verouderd” te meten, en dus ook geen manier om het oordeel tegen te spreken.

Dit artikel doet iets anders. Vijf dingen die je vandaag zelf in je eigen site kunt nakijken, en die wél een uitkomst hebben. Geen mening over hoe je site voelt, maar feiten over hoe hij gebouwd is en waar hij op draait.

Twee dingen laat ik hier expliciet liggen. Waaróm een site traag is, los van deze vraag, is een verhaal met een eigen antwoord. En hoe je een herbouw uitvoert zonder je posities in Google te verliezen, is een volgend probleem, dat pas speelt zodra je al gekozen hebt. Dit stuk gaat alleen over de knop zelf: opknappen, of overstappen.

Kun je überhaupt bij je eigen site?

Voordat opknappen of overstappen een echte keuze is, moet er iets anders vaststaan. Zonder toegang tot je domeinbeheer, je hosting, een beheerdersaccount op de site en de broncode zelf, ligt opknappen niet eens op tafel — dan kun je namelijk niets aanpassen, bij wie dan ook.

Bij een .nl-domein is dat concreet te maken. Wil je overstappen naar een andere provider, dan gaat dat via een verhuistoken dat je huidige registrar afgeeft. Die registrar moet dat token binnen vijf dagen na je aanvraag overdragen. Vraag het op en blijft het stil, dan weet je in één keer hoeveel controle je eigenlijk had.

Dit is geen reden om te herbouwen. Het is wel een reden om dit eerst op orde te krijgen voordat je iets beslist — anders neem je een besluit over een site die op dit moment niet van jou is om over te beslissen.

Zit je tekst in je pagina’s, of in je pagebuilder?

De zwaarste kantelfactor is ook de minst zichtbare. Een pagebuilder — een plugin zoals Elementor, Divi of WPBakery waarmee je pagina’s opbouwt uit blokken en vakken, in plaats van gewone tekst te typen — bewaart wat je invoert niet als platte tekst. Elementor slaat de complete opbouw en inhoud van een pagina op als JSON in de post-metadata van WordPress: een los opslagvak naast het gewone contentveld, oorspronkelijk bedoeld voor extra gegevens bij een pagina, niet voor de hoofdtekst zelf.

Dat heeft gevolgen voor “we nemen gewoon mee wat we hebben”. Tekst die in een builder zit, verhuist niet mee als tekst. Wat je ook kiest, opknappen of overstappen, die inhoud moet opnieuw ingericht worden, omdat er geen contentveld is om zomaar te kopiëren.

Zelf nakijken kost een paar minuten. Open een pagina in de gewone WordPress-editor, niet de builder, en kijk of je eigen tekst daar terugkomt. Zie je alleen een leeg blok met een knop naar de builder, dan weet je genoeg.

Bestaan de plugins waar je op leunt nog?

De volgende vraag is niet hoeveel plugins je site heeft, maar of ze nog bestaan. Patchstack telde in 2025 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem. 91% daarvan zat in plugins en 9% in thema’s. Bij 46% van die meldingen was er op het moment van openbaarmaking nog geen fix beschikbaar.

Dat risico stopt niet zodra een maker een plugin loslaat. WordPress.org sluit een plugin wanneer er zes maanden geen nieuwe code voor gepubliceerd is, of wanneer de readme hem zelf als deprecated aanmerkt — afgeschreven, niet langer onderhouden. Een gesloten plugin is niet meer te downloaden of te installeren, ook niet als jij hem op dit moment nog gebruikt. De melding dat een plugin “hasn’t been tested with the latest 3 major releases” komt rechtstreeks uit de “Tested up to”-header die de maker zelf invult, en zegt dus vooral iets over hoe lang geleden diezelfde maker voor het laatst gekeken heeft.

Loop je eigen plugins langs, dan gaat het niet om het totale aantal. Het gaat om of er één onvervangbare bij zit — degene die een kernfunctie van je site draagt — waar niemand meer onderhoud op pleegt.

Draait je site nog op software die support krijgt?

PHP 8.0 en 8.1 zijn end of life: het punt waarop de makers stoppen met alle updates, ook beveiligingsfixes.

WordPress adviseert zelf PHP 8.3 of hoger, samen met MariaDB 10.11+ of MySQL 8.0+, als veilige basis.

Waarom dit iets is om nu te checken en niet later: hosters trekken de PHP-versie op hun servers door, meestal zonder dat jij daar veel over te zeggen hebt.

Gelden de toegankelijkheidsregels voor jou?

Sinds de European Accessibility Act moeten onder meer webwinkels digitaal toegankelijk zijn. Die regels gelden voor je als je meer dan 10 mensen in dienst hebt, of meer dan 2 miljoen euro omzet draait.

Dat werkt in twee richtingen. Kom je boven een van die twee grenzen uit en zit je vast aan een thema of builder waarvan je de markup — de onderliggende HTML-structuur — niet zelf kunt aanpassen, dan is dat een factor die richting herbouw kantelt. Blijf je onder allebei, dan gelden de regels niet voor jou, en dan is het ook geen argument dat een bureau bij jou mag gebruiken om je richting nieuwbouw te duwen.

De proef: doe eerst de kleinste reparatie die je kunt terugdraaien

De vijf checks hierboven geven je feiten, geen garantie. Wil je zekerheid, dan hoef je niet te gokken op een inschatting: kies één afgebakende ingreep die je echt nodig hebt, zet die op een kopie van je site, en kijk wat er gebeurt.

Wat je daarbij meet is niet het resultaat, maar de weerstand. Lukt de ingreep zonder dat er ergens anders iets breekt? Of moet je drie andere dingen omzeilen om die ene wijziging aan de praat te krijgen? Dat laatste is een signaal op zichzelf, los van wat de vijf checks al opleverden.

Zie deze proef als bevestiging, niet als eerste stap. Je doet hem na de checks, niet in plaats daarvan.

Wanneer opknappen de kleinere en de betere keuze blijft

Het antwoord op deze vijf checks is vaker “opknappen” dan de meeste checklists je laten geloven. Een bouwer die bij elk gesprek uitkomt op nieuwbouw, heeft een probleem dat niet van jou is.

Ik heb zelf sites gebouwd waarbij een CMS — het systeem waarmee je zonder developer teksten en pagina’s aanpast — bewust ontbreekt, omdat de eigenaar er zelden iets aan wijzigt. Zo is er een parketbedrijf waarvan de site bewust zonder CMS is gebouwd, met ruimte voor voor-en-na-fotografie in plaats van een beheersysteem dat toch nooit gebruikt zou worden. Dezelfde overweging speelde bij een pastorale praktijk met een persoonlijke site zonder CMS: geen builder om in de gaten te houden, geen plugins, geen versies om te controleren, omdat er simpelweg niets is dat continu bijgehouden moet worden. In beide gevallen was de kleinere oplossing de juiste, niet de grootste die te verkopen was.

Er zijn ook situaties waarin nieuwbouw wél de juiste keuze is. Bij een vastgoedplatform met een losgekoppelde frontend en een koppeling met het bestaande CRM was dat zo. De site is headless gebouwd: de frontend, wat de bezoeker ziet, staat los van het systeem waarin de content wordt beheerd. Daar kwam een eigen beheersysteem bij en een koppeling naar het CRM waarin het aanbod al werd bijgehouden. Geen van de vijf checks had dat kunnen oplossen binnen de bestaande opzet — de content kwam uit een ander systeem, niet uit WordPress-pagina’s die je kunt herinrichten.

Welke kant voor jou geldt, hangt af van wat je bij de vijf checks tegenkomt, niet van hoe je site eruitziet of hoe oud hij is. Wil je die checks samen doorlopen voor jouw situatie, stuur me een appje via het contactformulier en dan kijken we samen waar het op uitkomt.