De meeste ondernemers denken dat WordPress onderhoud betekent dat je af en toe inlogt en op die blauwe update-knop drukt. Ze hebben geen ongelijk. Alleen is dat misschien tien procent van het werk, en het zijn juist die andere negentig procent waar sites stilletjes kapot gaan.
Ik krijg deze vraag af en toe: heb ik hier echt iemand voor nodig, of kan ik dat gewoon zelf? Het eerlijke antwoord is dat je het inderdaad prima zelf kunt. De vraag die ik liever eerst beantwoord zie, is of je weet waar je aan begint. Want het aantal mensen dat pas achteraf ontdekt hoe groot het eigenlijk is, is verbazend hoog. En dat leermoment wil ik je graag besparen.
TL;DR
- Updates zijn het zichtbare deel van WordPress onderhoud. Het is misschien 10% van het werk.
- Patchstack registreerde in 2024 7.966 nieuwe WordPress kwetsbaarheden, een stijging van 34% ten opzichte van 2023. 96% daarvan zat in plugins.
- Een derde van die kwetsbaarheden had geen patch op het moment van openbaarmaking, en voor 43% was zelfs geen login nodig om ze te misbruiken.
- Het echte werk zit onder de waterlijn: PHP-lifecycle, plugin-triage, geteste restores, beveiliging op serverniveau en incident response op een zondagavond.
- Zelf doen werkt als je de kennis, de discipline en de tijd hebt. Mis je er één van, dan wordt de goedkope optie stilletjes de dure.
Het deel dat je ziet: op update klikken
Updates draaien is het werk dat iedereen voor zich ziet als je "WordPress onderhoud" zegt. En het is echt werk. WordPress levert gemiddeld drie grote releases per jaar, plus een gestage stroom aan minor- en security-updates daartussenin. Het 2026 release-schema van het core team staat weer op drie majors, nadat 2025 even een terugval naar twee had. Een site met twintig plugins en een thema komt al snel op tientallen update-meldingen per maand.
Het moeilijke is niet op die knop drukken. Het moeilijke is weten welke updates je vertrouwt en welke je twee keer moet bekijken. Niet elke plugin-update is gelijk. De ene is cosmetisch. De andere herschrijft hoe de plugin met de database praat. Wordfence documenteerde dat CVE-2025-3102, een authentication bypass in SureTriggers met meer dan 100.000 installaties, binnen enkele uren na openbaarmaking in april 2025 actief werd misbruikt. Een week wachten met een kritieke plugin-update is allang geen veilige keuze meer. Een week wachten met een cosmetische update en 'm eerst testen juist wel.
Kun je dat onderscheid niet maken uit een changelog, dan verandert updates draaien van een taak van tien minuten in óf "alles maar klikken en hopen" óf "niks aanraken tot iets breekt." Allebei zijn faalmodes die prima lijken tot het moment dat ze het niet zijn.
Het deel dat je niet ziet
Hier woont de ijsberg.
Plugins zijn het hele aanvalsoppervlak. Het State of WordPress Security 2025 rapport van Patchstack registreerde in 2024 7.966 nieuwe WordPress kwetsbaarheden, een stijging van 34% ten opzichte van 2023. 96% kwam uit plugins. Zes kwamen uit WordPress core. Geen typefout: zes, in een heel jaar. Een derde van die kwetsbaarheden had geen patch op het moment van publicatie. En 1.614 plugins en thema's zijn in 2024 uit de officiële wordpress.org directory gehaald vanwege onopgeloste security-issues. Draai je twintig plugins, dan is de kans dat er op elk willekeurig moment eentje in een wachtrij van onopgeloste kwetsbaarheden zit, niet klein. Ik schreef apart over waarom plugins het grootste security-risico van WordPress zijn als je het hele plaatje wil.
Plugin-onderhoud is niet "effe op update klikken." Het is "mag ik eigenlijk nog wel op deze plugin vertrouwen?" Dat is een triage-vaardigheid, en die vraagt dat je meer leest dan alleen het versienummer.
PHP heeft een lifecycle en WordPress gaat ervan uit dat je 'm kent. PHP 8.1 heeft op 31 december 2025 zijn end of life bereikt. Geen patches meer, punt uit. WordPress beveelt op dit moment PHP 8.3 of hoger aan, en het absolute minimum is PHP 7.2, waarvan de requirements-pagina zelf aangeeft dat die "voorbij end of life en een security-risico" is. PHP upgraden zonder eerst je plugins te checken is precies het soort klus dat van een dinsdagmiddag een brandoefening maakt. De praktische kant daarvan werkte ik uit in PHP 8.1 end of life: is je WordPress site klaar voor PHP 8.4?.
Een backup is pas een backup als je 'm hebt teruggezet. Het 2024 Data Protection Trends Report van Veeam vond dat slechts 58% van de servers de recovery-SLA haalde bij de laatste grote restore-test. Dat is enterprise-data, met een IT-team erachter. Een WordPress-eigenaar die nog nooit op "restore" heeft geklikt, staat er vrijwel zeker slechter voor. De meeste mensen vertellen je met droge ogen dat ze backups hebben. Bijna niemand kan je vertellen wanneer ze er voor het laatst eentje daadwerkelijk hebben teruggezet, en dat is de enige test die telt.
Een security-plugin is geen web application firewall. Een plugin zoals Wordfence draait ín WordPress. Als een aanvaller het punt heeft bereikt waarop Wordfence het verzoek kan inspecteren, zit hij al in PHP, en in de praktijk zit hij al in WordPress. Een echte WAF filtert verkeer voordat het WordPress überhaupt bereikt. Die twee worden constant door elkaar gehaald, en die verwarring kost mensen geld, dus schreef ik een apart stuk over wat een WAF nou precies wél en niet doet voor WordPress.
Staging, rollback en incident response. WordPress 6.6 introduceerde een automatische rollback voor plugin-updates die een fatale PHP-fout veroorzaken op de voorpagina. Dat is nuttig. Het vangt geen kapotte layouts op, geen kapotte checkouts, geen kapotte admin en ook geen plugin die stilletjes je contactformulier niet meer laat afvuren. Wil je updates testen zonder risico, dan heb je een echte staging-omgeving nodig. En als er dan op zondagavond om elf uur tóch iets breekt, is de nuttige vraag niet meer "bestaat er een tool voor." De vraag is of je weet wat je in de eerstvolgende twintig minuten moet doen.
Wanneer zelf doen wél houdbaar is
Ik probeer niemand zelf doen uit het hoofd te praten. Voor heel veel sites is het gewoon de beste keuze. Drie voorwaarden, maar alle drie tellen.
Kennis. Kun je een plugin-changelog lezen en inschatten of een update risicovol is, dan zit je goed. Zijn termen als "PHP-versie", "staging" en "serverniveau-WAF" dingen die je eerst moet googelen voordat je ermee kunt werken, dan is de ijsberg onder water groter dan je dacht. En je gaat 'm raken, één plugin-update per keer.
Discipline. Onderhoud is een wekelijks ritme, geen "als ik er een keer aan denk"-klus. Dertig minuten per week, elke week, in je agenda. Gaat er een maand voorbij zonder dat je bent ingelogd, dan ben je geen onderhoud aan het doen. Dan ben je aan het wachten tot er iets breekt, zodat iemand anders de beslissing voor je neemt.
Tijd als er iets breekt. Als een plugin-update je checkout sloopt, ben jij degene die het oplost. Dat betekent concreet vaak een avond of een weekend, wat je ook had gepland. Wees eerlijk of je die tijd echt hebt, of dat het tijd is die je zou doorbrengen met ruzie maken tegen je site terwijl je partner roept dat het eten koud wordt.
Check je ze alle drie, dan is zelf doen prima, zeker voor een portfoliosite, een eenvoudige bedrijfspagina met een contactformulier of een blog dat niet aan omzet gekoppeld is. Installeer Wordfence (de gratis versie is al degelijk), zet UpdraftPlus of iets vergelijkbaars op een schema dat naar een externe opslag schrijft, en test minstens één keer per kwartaal of je backup daadwerkelijk terug te zetten is. Die kwartaaltest is de goedkoopste verzekering in dit hele lijstje, en de eerste die mensen overslaan.
Waar zelf doen stilletjes strandt
Het patroon dat ik het vaakst zie is niet "zelf doen werkt niet." Het is "zelf doen werkt tot het eerste moment dat er een oordeel nodig is." Een plugin-kwetsbaarheid komt naar buiten en je weet niet of jouw site geraakt is. Een PHP-upgrade sloopt een thema dat al jaren niet is onderhouden. Je hebt wel een backup, maar niemand heeft ooit een restore gedraaid, en de database-dump blijkt corrupt. Een contactformulier stopt stilletjes met e-mail afleveren en je komt er pas drie weken later achter, als een klant vraagt waarom er nooit iemand heeft teruggebeld.
Dat zijn geen uitzonderlijke gebeurtenissen. Ik heb eerder beschreven wat een WordPress hack in de praktijk eigenlijk inhoudt, en geen van de incidenten die ik ken kwam van exotische aanvallers. Ze kwamen allemaal voort uit bekende plugin-kwetsbaarheden waarvoor de patch al beschikbaar was en niemand 'm had toegepast. Dat is de faalmodus van zelf doen zonder het discipline-deel: je bent nog steeds de laatste verdedigingslinie, maar die linie hangt op het feit dat jij consequent blijft inchecken. En consequent inchecken is nou precies het ding dat de meeste mensen na maand drie stoppen te doen.
De rekensom kantelt snel als je site direct aan je omzet vastzit. WooCommerce, afspraken inboeken, leadgeneratie, een contactformulier waar een echt bedrijf op draait. Op dat moment gaat uitbesteden eigenlijk niet meer over de kennisvraag. Het gaat over iemand hebben wiens dagtaak het is om het probleem op te merken voordat jij het ziet. Dat iemand kan jij zijn, als je de tijd hebt en die tijd ook beschermt. Meestal kan dat niet als het al het tiende ding is op een lijst van dingen die allemaal al branden.
De echte vraag
"Moet ik WordPress onderhoud zelf doen of uitbesteden?" is niet de goede manier om het te framen. De bruikbare vraag is of je een eerlijk beeld hebt van de omvang en een plan voor de delen onder de waterlijn. Wil je de kostenkant van dezelfde afweging, dan heb ik die apart uitgewerkt in een companion artikel over wat WordPress onderhoud nou écht kost.
Lees je dit lijstje en herken je drie punten waar je al een tijdje niet meer over hebt nagedacht, dan heb je daarmee eigenlijk al antwoord gegeven. Het is niet dat je het niet kunt. Het is dat de versie van "zelf doen" die de meeste mensen voor zich zien, niet de versie is die de site daadwerkelijk veilig houdt. En het gat tussen die twee is precies waar de meeste incidenten gebeuren.