WordPress plugin updates wanneer wel of niet doen

Verouderde plugins zijn de grootste inbraakroute op WordPress-sites. Dat blijkt al jaren uit de overzichten van Wordfence en uit de meldingen op de WordPress security blog. Toch zie ik bij vrijwel elke nieuwe klant minstens drie plugins die maandenlang niet zijn bijgewerkt. De reden is bijna altijd dezelfde. Eén keer ging er iets mis na een update, en sindsdien durft niemand meer op die knop te drukken.

Dat is begrijpelijk. Maar het is ook de verkeerde reactie. Een verouderde plugin is een open deur. De vraag is dus niet “moet ik updaten”, maar “hoe doe ik het veilig”. En soms: “wanneer wacht ik bewust een paar dagen”.

In dit artikel deel ik de regels die ik bij mijn klantsites gebruik. Vier regels per plugin-type. Geen one-size-fits-all, wel concrete checklists.

Waarom niet elke update gelijk is

Er zit veel verschil tussen “WordPress core 6.5.2 patcht een beveiligingslek” en “een page-builder krijgt een major versie met breaking changes”. Beide verschijnen in hetzelfde scherm. Beide klinken als “Update beschikbaar”. Dat is misleidend.

Een major-update kan je site breken. Een security-patch lost een acuut risico op. Een onderhoudsrelease vult kleine bugs aan. Wie alles in één klik bijwerkt, behandelt drie verschillende dingen alsof ze hetzelfde zijn.

In mijn ervaring werkt iets simpels het beste. Snelle updates voor security-patches. Voorzichtige updates voor major-versies. Een paar dagen wachten op een nieuwe release van een page-builder of payment-plugin, tot de eerste bug-reports binnen zijn op het WordPress.org-forum.

Vier soorten plugin updates en het ritme per type

Ik werk met vier categorieën. Per categorie een ander ritme.

Security-patches: meteen, dezelfde dag

Een security-patch lost een actief lek op. Hackers scannen het internet binnen uren na een release op sites die nog niet zijn bijgewerkt. Hier wachten is gevaarlijk.

Bij security-only releases doe ik geen volledige staging-test. Ik maak een verse back-up, voer de update door en check daarna of de site nog werkt. Tien minuten werk, vrijwel altijd zonder problemen omdat security-patches bewust geen functies wijzigen.

Bekend voorbeeld uit 2025: een patch voor LiteSpeed Cache. Binnen zes uur na release deden hackers actief misbruik. Sites met automatische security-updates aan waren op tijd. Sites die handmatig werden bijgewerkt en niet onderhouden waren, kwamen er slechter af.

Minor-updates: binnen een week

Minor-updates (bijvoorbeeld 5.3.1 naar 5.3.2) bevatten bug-fixes en kleine verbeteringen. Risico op breekschade is laag. Ik doe ze meestal binnen een week, in een gepland onderhoudsblok.

Ritme: back-up maken, op staging testen, doorvoeren naar live, kort testen op functionaliteit. Twintig minuten per plugin voor een gemiddelde site.

Major-updates: een week wachten, dan testen

Major-updates (5.3 naar 6.0) kunnen breaking changes bevatten. Zelfs als de plugin-maker het tegendeel beweert. Dit is waar de meeste sites stukgaan.

Mijn regel: een week wachten na release. In die week verschijnen de eerste bug-reports op WordPress.org en in de developer-communities. Daarna een staging-test van minstens een uur, met focus op de pagina’s die de plugin direct raakt.

Drie typen major-update die ik in 2025 fout heb zien gaan:

• Een page-builder die de globale styling brak op enkele sites
• Een WooCommerce-major die checkout-velden wijzigde waardoor een betaalkoppeling stopte
• Een SEO-plugin die op één site de schema-markup voor producten brak

In alle gevallen kwam dat boven via bug-reports op WordPress.org. Wie meteen had geüpdatet, had pas drie dagen later doorgehad dat er iets stuk was.

Onderhoudsreleases zonder duidelijke changelog: altijd staging

Sommige plugins krijgen een update zonder duidelijke uitleg in de changelog. “Various improvements” staat er dan. Dat zegt mij weinig.

Bij dit soort updates doe ik altijd een staging-test, ongeacht of het minor of major lijkt. Geen zekerheid wat er wijzigt betekent geen automatische update.

Wanneer je beter even wacht

Naast plugin-type spelen ook timing en context. Vier situaties waarin ik bewust pauzeer.

Vlak voor een drukke periode. Heb je een webshop die in de aanloop naar Black Friday of een vakantieperiode op volle toeren draait? Stop dan met niet-kritieke updates één tot twee weken vooraf. Een gebroken checkout op de drukste dag van het jaar is duurder dan twee weken een verouderde plugin.

Direct na een grote eigen wijziging. Heb je gisteren een nieuwe template uitgerold of een payment-koppeling gewijzigd? Wacht een week met andere updates. Als er iets stuk gaat, weet je dan welke wijziging de oorzaak is.

Bij een plugin met slechte reviews op de nieuwe versie. Soms verschijnt op WordPress.org binnen 48 uur een rij van 1-sterren-reviews. “Broke my site.” “Lost all my settings.” Dat is een waarschuwingssignaal. Wacht tot er een patch komt.

Bij een plugin die je over een paar maanden vervangt. Heb je al besloten dat je over twee maanden van page-builder switcht? Dan investeer ik niet in een major-update van de oude. Wel de security-patches, niet de feature-updates.

Een veilige testroutine voor elke update

Voor sites die ik onderhoud doe ik elke major plugin-update via deze vijf stappen. Voor wie het zelf wil doen, hier de stappen leesbaar uitgeschreven.

Stap 1: Back-up controleren

Een back-up van vannacht is niet genoeg. Ik maak handmatig een verse back-up via UpdraftPlus net voor de update. Bestanden plus database. Op een externe locatie, niet op dezelfde server.

Test of de back-up echt werkt door een test-restore op een staging-omgeving te draaien. Een back-up die nooit getest is, is geen back-up.

Stap 2: Lijst van wat de plugin raakt

Welke pagina’s gebruiken deze plugin? Welke functionaliteit hangt eraan? Schrijf het op. Een page-builder raakt bijna elke pagina. Een payment-plugin raakt alleen de checkout. Een SEO-plugin raakt de meta-tags en sitemap.

Zonder die lijst weet je niet wat je moet testen.

Stap 3: Update op staging

Een staging-omgeving is een kopie van je live-site op een aparte URL. Hosters zoals SiteGround, Kinsta en Cloudways hebben hier knoppen voor. Bij anderen kan ik er een opzetten via WP Staging.

Voer de update door op staging. Loop daarna de lijst uit stap 2 langs. Werkt elke pagina, elke functie? Zien de stijlen er nog goed uit? Werkt de mobiele versie?

Stap 4: Doorvoeren naar live

Als staging schoon is, doe ik de update op live. Ik vermijd bewust drukke momenten: niet op vrijdag tegen 17:00, niet vlak voor een evenement van de klant.

Direct na de update een tweede check van de belangrijkste pagina’s. Werkt er iets niet, dan terug naar back-up. Met UpdraftPlus duurt dat ongeveer tien minuten.

Stap 5: Monitor 24 uur

Sommige problemen komen niet direct aan het licht. Een trage pagina onder load. Een fout in een formulier dat niet vaak gebruikt wordt. Een SEO-impact die pas zichtbaar wordt in de logs. Houd uptime-monitoring (zoals Uptime Robot) en de site een dag in het oog.

Meer over deze maandelijkse onderhoudsroutine staat in mijn artikel over website-onderhoud in Zeeland.

Wat ik bewust niet aanraad

Eerlijk over grenzen hoort bij goed werk. Drie dingen die ik niet aanraad, ook al doen anderen het wel.

Auto-updates voor alle plugins. Sommige hosters en plugins bieden dit aan. Voor security-patches prima. Voor major-versies een groot risico. Ik zet auto-updates alleen aan voor specifieke plugins waarvan ik weet dat ze betrouwbaar releasen (bijvoorbeeld de security-patches van bekende security-plugins). De rest blijft handmatig.

Plugins direct na release updaten zonder reviews te lezen. De eerste 48 uur na release is in mijn ervaring de meest risicovolle periode. Wachten kost weinig. Te vroeg updaten kost soms een dag werk.

Wachten tot er meer dan tien updates klaar staan. Als alles tegelijk wordt bijgewerkt en er gaat iets stuk, weet je niet welke plugin het was. Houd het maandelijkse ritme aan, zodat updates in kleinere series gaan.

Andere CMS’en: dezelfde logica

Deze regels zijn geschreven met WordPress in het hoofd. Voor andere systemen werkt de logica vergelijkbaar, alleen heten de onderdelen anders.

Joomla en Drupal kennen extensies en modules met dezelfde update-cyclus. Major-versies daar zijn vaak ingrijpender dan in WordPress. Voor Shopify werkt het anders: Shopify host zelf en doet veel basis-updates. Daar gaat het meer om app-updates en theme-updates die je zelf in de gaten houdt.

Voor maatwerk in Laravel of React zijn updates een ander verhaal. Daar werk ik per project, want de onderhoudsbehoefte verschilt te veel.

Wanneer je het beter aan een specialist overlaat

Niet elke ondernemer wil dit zelf doen. Dat is een prima keuze. Een paar tekenen dat je het beter laat overnemen.

Je hebt meer dan twintig plugins op je site. De combinaties maken risico’s groter dan je in een blogartikel kunt vangen.

Je site draait een webshop met betalingen. Daar gaat veel relaties mis bij updates. De impact van een dag stilstand is groter dan een paar maanden onderhoud.

Je hebt zelf één keer een site gebroken bij een update en je vertrouwt het proces niet meer. Begrijpelijk. Iemand anders die het routinematig doet, voorkomt herhaling.

Je hebt geen tijd om elke maand een uur aan dit soort werk te besteden. Voor 58 euro per maand neem ik dit over via een onderhoudscontract. Direct contact met degene die het werk uitvoert, geen tussenlaag.

Heb je vragen over een specifieke plugin-update of een lopende situatie op je site? Stuur een bericht met je URL, ik reageer binnen 4 uur op werkdagen. Meer artikelen staan in de categorie website onderhoud.