Website onderhoud: welke updates zijn echt nodig?

Inleiding

Maandagochtend, koffie in de hand, en je website laadt niet. Of erger: een witte pagina met een cryptische PHP-foutmelding. Of een mailtje van je hostingpartij dat er verdachte bestanden zijn aangetroffen. Klinkt bekend? Dan ben je niet de enige. Achterstallig onderhoud aan een website is bijna altijd het gevolg van dezelfde drie dingen: geen tijd, geen prioriteit, en geen overzicht van wat er eigenlijk speelt onder de motorkap.

Dit artikel is geen uitputtende checklist met dertig vinkjes. Het is een prioritering. Welke website updates kun je écht niet uitstellen zonder dat je site eruit klapt, gehackt wordt of in Google wegzakt? Welke kunnen prima een paar weken wachten? En welke zijn nice-to-have?

Kortom: een kompas voor websitebeheer onder tijdsdruk. Zodat je weet waar je het eerste de mist in gaat als je niets doet, en waar je rustig adem kunt halen.

De updates die je echt niet kunt uitstellen

Er zijn drie soorten updates waarbij uitstel direct schade oplevert. Geen "we kijken er volgende sprint naar". Geen "ik wacht even tot het rustiger is". Gewoon doen, binnen 48 uur na release. Punt.

Beveiligingsupdates voor WordPress en kritieke plugins

Volgens het Wordfence Vulnerability Report komt het overgrote deel van de gehackte WordPress-sites binnen via één en dezelfde route: een verouderde plugin met een bekende kwetsbaarheid. Niet via geavanceerde zero-days, niet via brute-force aanvallen op je inlog, maar via lekken waarvoor de fix al weken of maanden beschikbaar is. De aanvaller scant simpelweg op websites die de patch nog niet hebben geïnstalleerd.

Wat er dan gebeurt is zelden subtiel. Defacement waarbij je homepage wordt vervangen door politieke leuzen of gokreclames. Malware-injecties die bezoekers doorsturen naar phishingsites. Verborgen SEO-spam waardoor Google je hele domein als onveilig markeert, met een rode waarschuwing voor elke bezoeker. Dat laatste vreet maanden aan rankings die je nooit volledig terugkrijgt.

Vuistregel: security-patches voor je CMS en actief gebruikte plugins installeer je binnen 48 uur. Geen uitzonderingen, ook niet als het uitkomt in een drukke week. Zet automatische updates aan voor minor security releases als je niet de discipline hebt om handmatig te checken.

Core security releases van je CMS

Wanneer WordPress, Drupal of een ander CMS een release uitbrengt met het label "security", betekent dat: er is een gat gedicht dat bekend is. Vanaf het moment dat de release publiek is, weten kwaadwillenden precies wat ze moeten zoeken. De window tussen release en actieve exploits in het wild is soms minder dan 24 uur.

Minor security releases zijn meestal backwards-compatible en breken zelden iets. Major versies (bijvoorbeeld van 6.4 naar 6.5) verdienen wel een staging-test, maar ook die mag je niet maandenlang voor je uitschuiven.

SSL-certificaten op tijd verlengen

Een verlopen SSL-certificaat is geen schoonheidsfoutje. Chrome, Firefox en Safari blokkeren bezoekers actief met een volledig scherm waarop staat dat de verbinding niet vertrouwd is. De doorklikratio na zo'n waarschuwing? Vrijwel nul. Voor een webshop betekent dat omzetverlies vanaf minuut één.

Veel hostingpartijen vernieuwen Let's Encrypt-certificaten automatisch, maar vertrouw daar niet blind op. Zet een herinnering 14 dagen voor de verloopdatum en controleer of de vernieuwing daadwerkelijk is doorgekomen. Een handmatige check van twee minuten voorkomt een paniekvolle middag.

Regelmatig, maar geen wekelijkse paniek

Onder de categorie "echt niet uitstellen" zit een tweede laag onderhoud die je niet wekelijks hoeft aan te raken, maar waar je ook geen half jaar overheen moet laten gaan. Maandelijks tot per kwartaal is voor de meeste sites een gezond ritme. Wat hoort daarin thuis?

Back-ups die je daadwerkelijk hebt getest

Iedereen maakt back-ups. Bijna niemand test of het terugzetten ook werkt. Dat verschil merk je pas op het moment dat je site plat ligt en je ontdekt dat de back-up corrupt is, alleen de database bevat zonder uploads, of stilletjes al drie maanden faalt. Zet één keer per kwartaal een back-up terug op een staging-omgeving. Werkt het? Mooi. Werkt het niet? Dan weet je dat nu, niet straks.

PHP-versie op de server

Je CMS draait op PHP, en PHP-versies hebben een end-of-life datum. Een blik op de officiële lijst met ondersteunde PHP-versies laat zien dat oudere releases geen security-patches meer krijgen. Draaien op PHP 7.4 of lager is dus een tikkende tijdbom: één gevonden kwetsbaarheid en er komt geen fix meer. Een PHP versie update is meestal een kwestie van een knop omzetten in je hostingpaneel, maar test eerst op staging of je plugins en thema meebewegen.

Thema-updates en plugin-opschoning

Thema updates zijn minder urgent dan plugin-patches, maar laat ze niet achterstevoren raken. Een thema dat drie major versies achterloopt is moeilijker te updaten dan eentje die je netjes hebt bijgehouden. En terwijl je toch in het admin-paneel zit: verwijder plugins die je niet meer gebruikt. Gedeactiveerd is niet hetzelfde als weg. Inactieve plugins bevatten nog steeds code die misbruikt kan worden.

Performance-checks

Google neemt websitesnelheid mee in zijn ranking. De Core Web Vitals-documentatie op Search Central legt uit welke metrics meetellen: laadtijd, interactiviteit, visuele stabiliteit. Draai elk kwartaal een Lighthouse-rapport en kijk naar de Core Web Vitals in Google Search Console. Zakken je scores? Vaak ligt het aan een nieuwe plugin, een opgeblazen afbeelding, of een third-party script dat ongemerkt is binnengeslopen. Vroeg signaleren scheelt een dure refactor later.

Updates waar je bewust over kunt nadenken

En dan is er een derde categorie: updates waar de melding rood oplicht in je dashboard, maar waar niets ergs gebeurt als je een paar weken wacht. Sterker nog, vaak is wachten verstandiger dan meteen klikken.

Major version-upgrades van page builders en frameworks

Een sprong van Elementor 3 naar 4, of een nieuwe major release van je page builder of CSS-framework, is geen security-patch. Het is een herstructurering. De eerste twee tot vier weken na zo'n release zitten changelogs vol met "hotfix voor X", "regressie opgelost in Y". Wachten kost je niets en bespaart je een avond debuggen. Lees de release notes, scan support forums op klachten, en pas dan: testen op staging.

Feature-updates van plugins zonder security-impact

Een plugin die een nieuwe kleurenpicker toevoegt of een vernieuwde admin-interface uitrolt? Geen haast. Zeker niet als je custom CSS of hooks hebt geschreven die op de oude versie leunen. Plugin updates testen doe je sowieso niet rechtstreeks op productie, maar bij cosmetische releases mag je gerust een maand wachten tot de stof is neergedaald.

Content- en designtweaks

Het bijwerken van koppen, het verversen van foto's, het herzien van een landingspagina: belangrijk werk, geen onderhoud. Plan dit in een eigen ritme, los van je technische updates. Anders raakt alles vermengd en weet je achteraf niet meer of een conversiedaling kwam door de nieuwe heroafbeelding of door een plugin-update die dezelfde dag binnenkwam.

Vuistregel voor de twijfelgevallen

Bij elke niet-kritieke update stel je drie vragen. Lost dit een security-issue op? Verbetert het iets dat ik daadwerkelijk gebruik? Is de release langer dan twee weken geleden en stabiel bevonden? Drie keer nee betekent: laat staan. WordPress updates plannen werkt het best in vaste blokken, bijvoorbeeld elke tweede dinsdag van de maand, met een staging omgeving als verplichte tussenstop. Uitstel is hier geen slordigheid. Het is risicomanagement.

Wat achterstallig onderhoud je concreet kost

Tot nu toe ging het over wat je moet doen. Nu de andere kant: wat het kost als je het laat versloffen. Geen abstracte risico's, maar wat je daadwerkelijk op je bord krijgt.

Een gehackte WordPress-site herstellen kost gemiddeld twee tot vijf werkdagen voor een specialist. Reken op een rekening tussen de 1.500 en 5.000 euro voor schoonmaak, forensisch onderzoek en het opnieuw inrichten van beveiliging. Daar bovenop: dagen tot weken downtime, omzetverlies, en bij een SEO-spam-injectie een Google-waarschuwing die maanden nawerkt. Klanten die zo'n rode "Deze site is mogelijk gehackt"-melding zien, komen zelden terug.

Trage laadtijden kosten je twee keer. Eerst bij de bezoeker: bij een laadtijd van meer dan drie seconden haakt ongeveer de helft af voordat de pagina is geladen. Daarna bij Google: zakkende Core Web Vitals betekent zakkende posities. Een refactor om de snelheid weer op orde te krijgen kost al gauw 3.000 tot 10.000 euro, afhankelijk van de rommel die in de loop der jaren is opgestapeld.

Een verouderde PHP-versie leidt tot plugins die stoppen met werken, een site die ineens niet meer laadt na een server-update, en in het ergste geval een hosting-omgeving die geforceerd wordt geüpgraded zonder dat jouw code mee kan. Migratie achteraf kost dagen ontwikkeltijd.

Een ontbrekende back-up is de duurste van allemaal. Site opnieuw bouwen vanaf nul: weken werk, tien- tot vijftienduizend euro, en je content ben je kwijt.

Preventief onderhoud kost een fractie. De rekening komt altijd, alleen later en met rente.

Conclusie

Drie lagen, drie tempo's. Security-patches en core-updates van je CMS: binnen 48 uur, geen discussie. Back-ups testen, PHP-versie checken, thema's en performance monitoren: maandelijks tot per kwartaal in een vast ritme. Cosmetische plugin-releases en major version-upgrades: bewust uitstellen tot de eerste hotfixes binnen zijn.

Het echte probleem is zelden technisch. Het is planning. Wie WordPress onderhoud erbij doet tussen klantwerk en mailtjes door, schiet er onvermijdelijk doorheen. Op een dinsdagochtend ontdek je dan dat een plugin drie maanden uit de lucht is, of dat de back-up al een half jaar faalt. Twee opties: zelf een vaste agenda blokkeren en je eraan houden, of websitebeheer uitbesteden via een onderhoudscontract met iemand die het structureel oppakt.

Welke route je ook kiest, kies hem bewust. En als je sparren wilt over wat past bij jouw site: Mediajunkies denkt graag mee.