Verouderde plugins zijn veruit de meest voorkomende oorzaak van gehackte WordPress-sites: zodra een lek bekend wordt, scannen bots binnen dagen het hele internet af naar sites die nog niet zijn bijgewerkt. Toch stellen veel site-eigenaren updates uit, uit angst dat er iets breekt — en dat is geen onzin, want dat gebeurt soms echt. De oplossing is niet "nooit updaten" en ook niet "alles blind automatisch", maar een simpele routine: back-up vooraf, updates in kleine stapjes, site checken, en staging voor de grote klappen. In dit artikel leg ik uit hoe je dat praktisch aanpakt.
Waarom updaten geen keuze is
WordPress zelf, je thema en je plugins zijn software — en in software zitten fouten. Zodra een beveiligingslek in een populaire plugin wordt ontdekt en gepubliceerd, gebeuren er twee dingen tegelijk: de maker brengt een gepatchte versie uit, en aanvallers lezen precies dezelfde publicatie. Binnen enkele dagen, soms zelfs uren, draaien er geautomatiseerde scans die elke WordPress-site op internet aftasten op die ene kwetsbare versie. Dat is geen gerichte aanval op jouw bedrijf; het is een sleepnet. Jouw site is interessant omdat hij bestaat, niet omdat hij van jou is.
Dat verklaart ook waarom "mijn site is te klein om gehackt te worden" niet opgaat. Een gehackte site wordt gebruikt om spam te versturen, malware te verspreiden of bezoekers door te sturen naar dubieuze webshops. Daar is elke site geschikt voor, hoe klein ook.
Bij vrijwel elke gehackte site die ik opruim, is het beeld hetzelfde: ergens draait een plugin die maanden — soms jaren — niet is bijgewerkt, terwijl het lek allang publiek bekend was. De hack zelf is dan geen pech, maar het voorspelbare gevolg van uitgesteld onderhoud.
Waarom mensen updates uitstellen (en waarom dat begrijpelijk is)
De angst dat een update je site breekt, is terecht. Een plugin-update kan botsen met je thema, twee plugins kunnen elkaar in de weg zitten, en een grote WordPress-versie kan verouderde code onderuit halen. Wie ooit na een update een wit scherm heeft gezien, klikt de volgende keer minder makkelijk op "alles bijwerken".
Maar de conclusie "dan update ik maar niet" lost het verkeerde probleem op. Je ruilt een klein, beheersbaar risico (een update die iets breekt en die je met een back-up terugdraait) in voor een groot, onbeheersbaar risico (een hack die je site, je mail-reputatie en je Google-positie beschadigt). De juiste conclusie is: updaten, maar slim — zodat een mislukte update een ongemak van tien minuten is in plaats van een ramp.
Automatische updates: wat wel en wat niet
Automatische updates zijn een prima gereedschap, zolang je weet waar je ze inzet.
Wel automatisch:
- Minor core-updates (bijvoorbeeld 6.8.1 naar 6.8.2). Dit zijn beveiligings- en bugfixes, WordPress doet dit standaard al, en het risico is minimaal. Laat dit aan staan.
- Vertrouwde, actief onderhouden plugins. Denk aan plugins van grote makers met miljoenen installaties en een goede staat van dienst. Beveiligingsplugins en anti-spamplugins zijn logische kandidaten: juist daar wil je patches direct binnen hebben.
Liever niet automatisch:
- Major core-updates (6.x naar 7.0). Die veranderen te veel om onbewaakt te laten lopen.
- Je thema en page builder. Daar zit je vormgeving in; een verrassing daar zie je meteen op elke pagina.
- Plugins waar je site functioneel van afhangt, zoals WooCommerce op een webshop of een boekingsplugin. Die update je op een moment dat jij erbij bent en direct kunt testen.
Waar je bij automatische updates op let: zorg dat je een melding krijgt wanneer er iets is bijgewerkt, en kijk daarna even naar je site. "Automatisch" betekent niet "onzichtbaar". En besef dat automatische updates alleen bijwerken — ze controleren niet of je site daarna nog goed werkt. Die controle blijft mensenwerk.
Eerst een back-up, dan pas updaten
De belangrijkste regel van dit hele artikel: maak vóór elke update-ronde een back-up. Niet omdat updates meestal misgaan — dat doen ze niet — maar omdat een back-up het verschil is tussen "even terugzetten" en "in paniek een specialist bellen".
Een goede back-up voldoet aan drie eisen:
- Extern bewaard. Een back-up die in dezelfde hostingomgeving staat als je site, gaat mee verloren bij een hack of servercrash. Bewaar hem op een andere locatie: externe opslag, een andere server, of de back-upvoorziening van je host — als die buiten je eigen account staat.
- Meerdere dagen terug. Eén back-up van vannacht is niet genoeg. Een hack of fout wordt vaak pas na dagen opgemerkt; dan wil je terug kunnen naar een moment vóór het probleem. Zeven dagen historie is een goed minimum.
- Getest. Een back-up die nooit is teruggezet, is een hoop bestanden waarvan je hóópt dat ze werken. Zet hem minstens één keer terug op een testlocatie, zodat je weet dat het kan — en hoe lang het duurt.
Controleer ook of je back-up compleet is: zowel de bestanden (thema, plugins, uploads) als de database. Alleen bestanden of alleen de database is een halve site.
Staging: een oefenkopie van je site
Een staging-omgeving is een exacte kopie van je site op een aparte plek, onzichtbaar voor bezoekers. Daar voer je een update eerst uit, kijk je of alles nog werkt, en pas als het goed gaat doe je hetzelfde op de echte site.
Wanneer loont staging?
- Bij major core-updates van WordPress.
- Bij een PHP-versie-upgrade (daarover hieronder meer).
- Bij thema-updates of grote sprongen in een page builder.
- Bij webshops en andere sites waar omzet vanaf hangt. Een uur downtime op een brochuresite is vervelend; op een webshop kost het direct geld.
Voor de wekelijkse ronde kleine plugin-updates is staging meestal overdreven — daar volstaat een verse back-up. Maar voor alles wat groot of spannend is, is een oefenkopie de goedkoopste verzekering die er bestaat. Veel hostingpakketten hebben een staging-functie ingebouwd; vraag ernaar als je hem niet kunt vinden.
Updates in de praktijk: de volgorde
Zo ziet een verstandige update-ronde eruit:
- Back-up maken (of controleren dat de automatische back-up van vannacht gelukt is).
- Plugins updaten, één voor één of in kleine groepjes. Niet alles in één klik. Werk je in groepjes, houd ze dan logisch bij elkaar — bijvoorbeeld eerst de kleine hulpplugins, daarna de grote. Gaat er dan iets mis, dan weet je waar je moet zoeken.
- Site checken na elke stap. Open de homepage, een paar belangrijke pagina's, en test wat kritisch is: het contactformulier, de winkelwagen, het afrekenproces. Doe dat in een venster waarin je niet bent ingelogd — sommige fouten zie je als beheerder niet.
- Thema en core als laatste, met dezelfde controle erna.
- Iets kapot? Terugdraaien naar de back-up, uitzoeken welke update de boosdoener was, en die apart oppakken — eventueel op staging.
Voor de sites die ik in beheer heb, draai ik wekelijkse update-rondes volgens precies dit recept: back-up vooraf, updates in stapjes, controle achteraf. Niet omdat het spannend werk is, maar omdat de twee uitersten — "alles automatisch en nooit meer omkijken" en "nooit updaten want het werkt toch" — allebei aantoonbaar misgaan. De middenweg is saai, en saai is hier precies goed.
PHP-updates: apart behandelen
PHP is de programmeertaal waar WordPress op draait, en ook die krijgt nieuwe versies. Een nieuwere PHP-versie is sneller en veiliger, maar oude plugins en thema's kunnen erop stuklopen. Behandel een PHP-upgrade daarom nooit als "nog even een vinkje" tijdens een gewone update-ronde.
De aanpak: eerst al je plugins en je thema up-to-date brengen, dan de nieuwe PHP-versie op staging (of desnoods kort op de live site, op een rustig moment en met de oude versie als directe terugvaloptie) proberen, en pas definitief overschakelen als alles werkt. Loop daarna de foutlogs even na — PHP-problemen zijn niet altijd meteen zichtbaar op de site zelf.
Abandoned plugins: het stille risico
Sommige plugins krijgen geen updates meer omdat de maker ermee gestopt is. Zo'n verlaten plugin lijkt onschuldig — hij werkt immers nog — maar wordt elk jaar riskanter: gevonden lekken worden nooit meer gedicht.
Zo herken je ze:
- Laatste update langer dan een jaar geleden in de WordPress-pluginrepository.
- "Niet getest met jouw versie van WordPress" als waarschuwing bij de plugin.
- Onbeantwoorde supportvragen die zich opstapelen.
- De plugin is uit de repository verwijderd — vaak juist vanwege een beveiligingsprobleem.
Kom je zo'n plugin tegen, zoek dan een onderhouden alternatief en plan de vervanging. En loop meteen je pluginlijst na op spullen die je helemaal niet meer gebruikt: elke plugin die je verwijdert, is een stuk aanvalsoppervlak minder. Deactiveren is niet genoeg — de code staat dan nog steeds op je server. Echt verwijderen dus.
Maak er een routine van
Veilig updaten is geen kunst, het is een gewoonte: een vast wekelijks moment, back-up vooraf, stapje voor stapje, even checken, klaar. De eerste paar keer voelt het omslachtig; daarna is het een kwartier werk dat je een hoop narigheid bespaart.