Wat er echt gebeurt als je WordPress een jaar niet bijwerkt

Je website staat er nog. Pagina’s laden, contactformulier werkt, Google vindt je. Alles lijkt prima. Maar onder de motorkap is het inmiddels een rommeltje dat vroeg of laat zichtbaar wordt – en dat moment kiest altijd een slecht moment.

Geen dramaverhaal hier. Gewoon wat Arjan in de praktijk tegenkomt als hij bij een nieuwe klant onder de motorkap kijkt.

Maand één tot drie: niks aan de hand, schijnbaar

WordPress brengt gemiddeld vier tot vijf grote updates per jaar uit. Plugins komen daar bovenop, met soms meerdere updates per week. In de eerste maanden merk je weinig als je die laat zitten. Geen foutmeldingen, geen geklaag van bezoekers.

Wat je niet ziet: de beveiligingslekken die ondertussen publiek bekend worden. Zodra een kwetsbaarheid in een plugin wordt gepubliceerd – en die worden netjes bijgehouden op sites als WPScan – weten kwaadwillenden precies waar ze op moeten zoeken. Ze scannen niet handmatig. Ze gebruiken geautomatiseerde tools die duizenden sites per uur afstruinen.

Jij hoeft niet beroemd te zijn. Je hoeft alleen een verouderde versie van Contact Form 7 of WooCommerce te draaien.

Maand vier tot zes: de eerste echte problemen

Rond deze periode begint de incompatibiliteit te spelen. WordPress-core heeft een update gehad. Je thema niet. Of andersom. Plugins verwachten een nieuwere versie van PHP dan je server draait.

Het resultaat is niet altijd een harde fout. Soms is het subtieler: een knop die niet meer werkt, een formulier dat de inzendingen niet meer doorstuurt, een afbeelding die niet meer laadt op mobiel. Dingen die je pas opmerkt als een klant er iets over zegt – of als je zelf toevallig op je eigen site klikt.

Drie van de tien keer dat Arjan gebeld wordt met "mijn website doet raar" blijkt het een compatibiliteitsprobleem door verouderde software. Dat is geen getal uit een rapport, dat is gewoon wat er binnenkomt.

Wat er met je SEO gebeurt

Google meet laadsnelheid, en verouderde plugins zijn een bekende oorzaak van tragere sites. Niet dramatisch in één keer, maar sluipend. Een pagina die in januari in 1,8 seconden laadde, doet er in september 3,1 seconden over. Dat klinkt als weinig, maar Google’s eigen data laat zien dat de kans op een bounce bij drie seconden laadtijd 32% hoger ligt dan bij één seconde.

Daarnaast: als je site op een gegeven moment gehackt wordt en Google dat detecteert, verdwijn je uit de zoekresultaten. Niet naar pagina twee. Weg. Terugkomen kost weken, soms maanden.

Maand zeven tot twaalf: het wordt serieus

Na een jaar zonder updates is de kans op een actief beveiligingsprobleem fors. Arjan ziet dit bij nieuwe klanten die binnenkomen met een "kapotte" site: spam-links verborgen in de footer, een doorverwijzing naar een goksite op mobiel, of een beheerdersaccount dat er ineens bij staat.

Hackers zijn zelden geïnteresseerd in jouw gegevens specifiek. Ze willen je server gebruiken voor spam, je bezoekers doorsturen naar hun rommel, of je site als springplank gebruiken voor andere aanvallen. Je bent een middel, geen doel.

Schoonmaken van een gehackte WordPress-site kost gemiddeld drie tot zes uur werk, afhankelijk van hoe ver de infectie is gegaan. Als er geen recente back-up is – en die is er zelden bij bedrijven die ook hun updates niet bijhouden – is het soms sneller om opnieuw te beginnen.

Wat "even bijwerken" in de praktijk inhoudt

Hier zit een nuance die de meeste how-to’s overslaan: updates uitvoeren is niet altijd klikken op "alles bijwerken" en klaar. Dat werkt bij een eenvoudige site met een standaard thema en vijf plugins. Bij een maatwerk-site met twintig plugins en aangepaste functionaliteit is dat vragen om problemen.

De volgorde matters. PHP-versie eerst controleren, dan core, dan plugins, dan thema. Altijd met een back-up die je ook daadwerkelijk hebt getest. En na de update even doorlopen of de kritieke pagina’s nog werken: homepage, contactpagina, eventueel de webshop.

Voor een gemiddelde WordPress-site is dit werk van een halfuur per maand. Voor een complexe webshop met maatwerk kan dat twee uur zijn. Als je dat zelf doet, is het prima te doen. Als je er liever niet mee bezig wilt zijn, is het ook gewoon uit te besteden – bij Webplace4u is dat onderdeel van het onderhoudspakket, zonder dat je je er verder druk over hoeft te maken.

Wat je vandaag kunt controleren

Log in op je WordPress-dashboard. Linksboven zie je een getal in een rood bolletje als er updates klaarstaan. Staat daar 12 of hoger? Dan weet je genoeg.

Check daarna wanneer je laatste back-up is gemaakt. Niet of er een back-up-plugin staat, maar wanneer die voor het laatste een succesvolle back-up heeft gedraaid. Dat zijn twee verschillende dingen.

En als je PHP-versie wil checken: ga naar Tools > Site Health in je dashboard. Daar staat het gewoon. Draai je nog PHP 7.4? Dan is het echt tijd. Die versie heeft al twee jaar geen beveiligingsupdates meer.