Waarom updates op uw website niet optioneel zijn

Dat maakt het de makkelijkste post om uit te stellen. Eerst even dat andere, en volgende maand kijken we opnieuw. Een jaar later blijkt dat “volgende maand” twaalf keer is voorbijgegaan.

Wat er in die twaalf maanden gebeurt, ziet u niet. Hieronder staat wat het is, en waarom het opruimen ervan altijd duurder uitvalt dan het bijhouden had gekost.

Dit is het misverstand waar het mee begint. “Update” klinkt als een nieuwe functie waar u niet op zat te wachten, en dus als iets wat kan wachten.

Het grootste deel van de updates op een website is iets anders: het dichten van een gat dat iemand gevonden heeft. En hier zit het onprettige deel. Zodra zo'n lek gedicht is, wordt het ook openbaar gemaakt. Dat hoort zo, want anders kan niemand controleren of hij kwetsbaar is. Maar het betekent ook dat op het moment dat de reparatie beschikbaar komt, het probleem bekend is bij iedereen die ernaar zoekt.

Vanaf dat moment is uw site niet veiliger geworden door het bestaan van de update. Hij is onveiliger geworden doordat u hem niet geïnstalleerd heeft.

Ondernemers zeggen vaak: bij ons valt niets te halen, waarom zou iemand ons aanvallen?

Omdat er niemand naar u kijkt. Het overgrote deel van wat er misgaat, gaat automatisch. Software zoekt het hele internet af naar sites met een bekend lek, zonder enig idee of daar een bakkerij, een advocatenkantoor of een hobbyblog achter zit. Wie er een open heeft staan, is aan de beurt.

En het gaat meestal ook niet om uw gegevens, maar om uw server. Die is bruikbaar om spam mee te versturen, om reclame voor iemand anders op te zetten, of om anderen mee aan te vallen. Een kleine site is daarvoor net zo geschikt als een grote, en vaak makkelijker binnen te komen.

Niet het lek zelf. Dat merkt u nooit. U merkt de gevolgen, en die komen in willekeurige volgorde:

Uw site staat vol links naar iets waar u niets mee te maken wilt hebben, vaak op pagina's die u zelf niet ziet omdat ze speciaal voor zoekmachines zijn neergezet. Google plaatst een waarschuwing voor uw bezoekers, en die haalt hij er niet meteen af als het is opgelost. Uw site doet het niet meer, op een moment dat u er niet op zat te wachten. Of uw mail komt bij klanten in de spammap terecht, omdat uw server ondertussen op een lijst is beland.

Het herstel is daarbij zelden het dure deel. Het dure deel is uitzoeken hoe iemand binnenkwam, want een back-up terugzetten zonder dat antwoord betekent meestal dat u er een week later weer staat.

Om te laten zien hoe stil dit soort dingen kapotgaan, hier een voorbeeld waar we zelf niet beter van worden.

Wij bouwen sinds 2000 websites voor anderen en hadden aan onze eigen site nooit veel aandacht besteed. In augustus 2026 zijn we hem voor het eerst serieus gaan doormeten, en daar kwam meteen iets uit: dijkers.com serveerde zijn certificaat niet compleet uit. Er ging alleen ons eigen certificaat de deur uit, zonder de tussenliggende schakel van de uitgever die aantoont dat het geldig is.

De meeste browsers vullen die schakel zelf aan, dus geen bezoeker heeft er ooit iets van gemerkt en er stond nergens een waarschuwing. Een strenge controle kapte er wel op af. Hoe lang het er al zat, weten we niet, en dat is precies het punt: niemand keek.

Dezelfde dag opgelost. Dat voorbeeld draagt wat ons betreft deze hele pagina. Het gaat zelden om een aanval die u ziet aankomen; het gaat om dingen die maanden stilstaan omdat er geen moment is waarop iemand kijkt.

Dit is het punt dat het vaakst verrast, en het geldt voor elke site die op iets van techniek draait.

Bijhouden is een kleine, saaie handeling. Inhalen is dat niet. Loopt u een paar versies achter, dan kunt u meestal niet in één sprong bij de laatste komen: er zit een volgorde in, er zijn onderdelen die onderweg veranderd zijn, en er is geen testomgeving waarop u kunt controleren wat er stukgaat. Wat als bijwerken begon, wordt dan een project.

Bij maatwerkapplicaties komt daar een vaste klok bij. Laravel, het fundament waar wij op bouwen, brengt elk jaar een nieuwe hoofdversie uit en ondersteunt een versie een beperkte tijd met beveiligingsupdates. Loopt u een paar jaar achter, dan krijgt u geen reparaties meer voor lekken die wél bekend zijn. Zie Laravel-applicatie onderhoud.

Het moment waarop het urgent wordt, is trouwens meestal niet een lek maar een mail van de hoster: uw PHP-versie wordt uitgefaseerd, per datum. Dan is er ineens een deadline, en dan blijkt hoeveel er ondertussen is blijven liggen.

Er zit weinig spannends in, en dat is precies het idee.

Bij de sites die wij in beheer hebben, lopen de updates mee met de pakketten zelf: brengt de maker van een onderdeel een nieuwe versie uit, dan wordt uw site bijgewerkt. Er is dus geen vaste dag in de maand waarop het gebeurt, maar ook geen achterstand die zich opbouwt.

Daarnaast schrijven we elke nacht een back-up weg, buiten de site zelf om, verzorgen we het SSL-certificaat en het DNS-beheer, en loopt er bewaking mee op de sites die wij beheren. Dat laatste is het verschil tussen “wij zagen het” en “u belde ons”. Wat wij bouwen draait op onze eigen servers, met een uptime van 99,9%; als er iets is, hebben wij de hele keten in handen in plaats van drie partijen die naar elkaar wijzen.

Een back-up waarvan niemand ooit heeft gecontroleerd of hij terug te zetten is, telt overigens niet mee. Dat is een aanname, geen vangnet.

Er is een goedkopere manier om dit probleem kleiner te maken dan meer onderhoud kopen, en dat is minder hebben om te onderhouden.

Elke plugin die ooit geïnstalleerd is, draait mee en moet bijgehouden worden. Ook die ene die na twee weken niet meer gebruikt werd. Een site zonder beheersysteem heeft simpelweg minder plekken waar iets kan lekken: wat er niet in zit, kan ook niet stukgaan.

Dat is geen theorie. Voor de woonwijk Vroondaal in Den Haag hebben we een besmette WordPress-site opgeschoond en daarna plat opgeleverd: dezelfde site voor de bezoeker, maar zonder beheersysteem, page builder of plugins eronder. Samen met een nieuwe ronde over de afbeeldingen ging de laadtijd op de telefoon van 9,6 naar 2,2 seconde. Dat verhaal staat uitgeschreven bij website beveiliging.

Of dat voor u de goede kant op is, hangt af van hoe vaak u zelf iets wilt wijzigen. Verandert er twee keer per jaar iets, dan is een platte site een reële optie. Wilt u wekelijks nieuws plaatsen, dan wint een beheersysteem het en is het zaak het aantal onderdelen klein te houden. Die afweging staat uitgebreider op website beveiliging.

Niet elk achterstallig onderhoud is met onderhoud op te lossen, en dat zeggen we liever vooraf.