WordPress-updates zijn essentieel zodat een website veilig blijft, maar ze zijn ook een grote bron van zorg voor webagentschappen. We vroegen Sébastien Cavaillé, Product Marketing Manager bij OVHcloud, om uit te leggen hoe Smart Automatic Updates ontworpen is om dit dilemma op te lossen.
Elke agency die WordPress-websites beheert, kent de spanning tussen de noodzaak van updates en niet de tijd of de middelen hebben om ze uit te voeren. Aan de ene kant kunnen updates niet wachten: volgens het laatste jaarverslag van WordPress-beveiligingsspecialist Patchstack werden er in 2025 11.334 nieuwe kwetsbaarheden geregistreerd, waarvan 91% in plug-ins, 9% in thema's en slechts zes in de WordPress-kern. En aanvallers handelen snel: ongeveer de helft van de kwetsbaarheden met een grote impact wordt binnen 24 uur na openbaarmaking misbruikt. Een verouderde plug-in is een van de vaakst voorkomende ingangen voor een aanvaller, en hoe langer een update wordt uitgesteld, hoe langer een site kwetsbaar blijft.
Maar aan de andere kant brengt elke update een risico met zich mee: een incompatibele plug-in, een thema dat niet langer goed wordt weergegeven, een pagina die plotseling een foutmelding geeft. Om dat risico niet blindelings te nemen, controleren veel bureaus elke site handmatig. Dat kost behoorlijk veel tijd wanneer er tientallen of zelfs honderden sites te managen zijn. En wanneer de tijd dringt, worden updates uitgesteld, soms wel weken of maanden.
Om deze impasse te doorbreken, hebben de teams van OVHcloud Smart Automatic Updates ontwikkeld, een functie die inbegrepen is in Managed Hosting voor WordPress. Om dit probleem beter te begrijpen, spraken we met Sébastien, die aan het project heeft gewerkt.
Waar kwam het idee voor het project vandaan?
Dat kwam rechtstreeks van onze klanten. Op ons platform voor shared hosting hosten we ongeveer 6 miljoen websites en 80 % daarvan draait op WordPress. Dat geeft ons veel feedback, en één behoefte bleef terugkomen: mensen weten dat ze hun sites up-to-date moeten houden, maar velen hebben een update meegemaakt die misging en ze hebben niet de tijd om elke site handmatig te controleren.
Traditionele automatische updates lossen het beveiligingsprobleem op, maar ze creëren een ander probleem, omdat je er vaak pas achter komt dat een site kapot is wanneer een klant belt. We wilden automatisering die controleert alvorens actie te ondernemen.
Eén verhaal in het bijzonder is ons bijgebleven. Een freelance webdeveloper runde een eenmanszaak en managede in zijn eentje tientallen WordPress-websites voor zijn klanten. Er werd een kwetsbaarheid bekendgemaakt in een plug-in die op veel van die sites werd gebruikt en hij had simpelweg geen tijd om ze allemaal bij te werken voordat een aanvaller hem voor was. Binnen korte tijd waren 36 van de websites van zijn klanten gehackt en werden bezoekers doorgestuurd naar kwaadaardige websites.
Het opschonen van de sites was nog tot daaraan toe. Het moeilijkste was om zijn klanten onder ogen te komen. Ieder van hen vertrouwde hem om voor hun website te zorgen, en ieder van hen kwam erachter dat hun bezoekers naar gevaarlijke pagina's waren gestuurd. Voor een freelancer wiens bedrijf afhankelijk is van reputatie en mond-tot-mondreclame, duurt het herstellen van dat soort geloofwaardigheidsschade veel langer dan het herstellen van de sites zelf.
Sindsdien heeft hij de sites van zijn klanten verplaatst naar Managed Hosting voor WordPress en ons de taak gegeven om ze up-to-date te houden. Zijn verhaal is precies het soort situatie dat we wilden voorkomen: niet omdat hij iets verkeerd deed, maar omdat niemand handmatig tientallen websites, elke week weer opnieuw, up-to-date kan houden.
Hoe worden WordPress-updates getest?
Het principe is om een update nooit direct op de live site te testen.
Wat zijn de vier testfasen?
Elke dag controleren we of er nieuwe updates beschikbaar zijn. Elke update wordt vervolgens in vier fasen getest.
Eerst maken we een snapshot van de site zoals deze op dit moment werkt. Een crawler begint vanaf de homepage en volgt de links recursief: als de homepage linkt naar pagina A, die linkt naar pagina B, die linkt naar pagina C, dan wordt pagina C ook geanalyseerd. We analyseren tot 50 pagina's per site. Voor elke pagina registreren we de HTTP-statuscode die de server retourneert, wat laat zien of de pagina normaal laadt of een foutmelding geeft, samen met een schermafbeelding van de volledige pagina in een resolutie van 1920×1080.
Vervolgens klonen we de site naar een geïsoleerde testomgeving. Op die kloon, en alleen op die kloon, passen we de updates toe voor WordPress, de thema's en de plug-ins.
Als derde stap analyseren we de kloon op precies dezelfde manier als de oorspronkelijke site, met dezelfde pagina's, dezelfde HTTP-statuscodes en dezelfde schermafbeeldingen.
Ten slotte vergelijken we de twee. Die vergelijking bepaalt of de update kan worden toegepast op de productieomgeving.
Wanneer is een update valide?
Er moet aan drie voorwaarden zijn voldaan:
- De HTTP-statuscodes zijn identiek. Als een pagina die voorheen werkte nu een foutmelding geeft, wordt de update geblokkeerd.
- De schermafbeeldingen komen overeen, met een kleine tolerantie voor visuele verschillen.
- Elke update van een thema of een plug-in is zonder fouten geïnstalleerd.
De visuele vergelijking is opzettelijk zeer strikt. Een pixel wordt als verschillend beschouwd zodra een van de rood-, groen- of blauwwaarden met slechts één eenheid verandert. Er is helemaal geen kleurtolerantie. Wat we wel tolereren is een klein percentage gewijzigde pixels: tot 5% van de pagina. De drempelwaarde meet dus hoeveel van de pagina is veranderd, niet hoeveel elke pixel is veranderd.
Voordat we elke schermafbeelding maken, wachten we ook een paar seconden om animaties tijdens het laden en soortgelijke effecten te laten voltooien.
Hoe voorkom je een vals alarm?
Veel sites hebben carrousels, animaties of content die voortdurend verandert. Dat was een van de interessantere problemen die we moesten oplossen. Bij de allereerste tests waren we verrast door het aantal updates dat als mislukt werd gemarkeerd, ook al zag er niets stuk uit toen we de sites handmatig controleerden. Toen we de screenshots nader bekeken, waren de boosdoeners bijna altijd dezelfde: sliders op de homepage die naar de volgende afbeelding waren gegaan, aftellende timers op evenementensites, widgets met "laatste berichten" of ingesloten social media-feeds die tussen twee opnames door waren ververst. De updates waren in orde; de pagina's veranderden simpelweg vanzelf.
De oplossing was om van elke pagina meerdere screenshots te maken met tussenpozen van een paar seconden. Als de pagina uit zichzelf verandert tussen twee screenshots, markeert het systeem deze als dynamisch en sluit het deze uit van de visuele vergelijking. Deze pagina's worden echter nog steeds gecontroleerd: hun HTTP-statuscodes worden nog steeds vergeleken, dus een dynamische pagina die een foutmelding begint te geven, zal de update nog steeds blokkeren. Zodra we die stap hadden toegevoegd, namen de valse alarmen drastisch af en konden we de visuele vergelijking weer vertrouwen.
Hoe ver gaat de analyse?
We hebben ons gericht op wat het belangrijkst is: de pagina's die je bezoekers daadwerkelijk zien. In de praktijk dekt dat de kern van de meeste websites: de homepage, de belangrijkste secties en de essentiële pagina's waar bezoekers doorheen bewegen.
Pagina's die niet vanaf de homepage te bereiken zijn, zelfs niet indirect, maken geen deel uit van de analyse. Dat is opzettelijk: als er geen link naar een pagina leidt, kunnen bezoekers deze ook niet bereiken als ze door de website struinen, dus dat is niet de plek waar ze last zouden ondervinden van een defecte update.
Dezelfde logica geldt voor gebieden achter een inlogscherm, zoals klantaccounts of het beheerdersdashboard. Elke site regelt authenticatie op zijn eigen manier, dus we hebben ervoor gekozen ons te concentreren op de openbare pagina's, waar we betrouwbare, consistente controles op grote schaal kunnen uitvoeren.
Het idee is niet om de expertise van een webbureau te vervangen, maar om de repetitieve controles over te nemen die zij anders handmatig zouden doen, site na site. Dat maakt tijd vrij voor het werk dat alleen zij kunnen doen.
Wanneer een test slaagt of faalt
Wat gebeurt er als de validatie mislukt?
Er gebeurt niets op de live site en dat is precies de bedoeling. Als niet aan een criterium wordt voldaan, worden de updates niet toegepast. De site blijft precies zo werken als voorheen.
De klant ontvangt vervolgens een e-mail waarin wordt uitgelegd waarom de validatie is mislukt. Er zijn vier mogelijke oorzaken:
- Plug-ins of thema's konden niet volledig worden bijgewerkt op de testsite.
- De homepage gaf een 4xx-foutmelding of was onbereikbaar, waardoor de test niet kon worden uitgevoerd.
- De HTTP-responsen verschilden tussen de originele site en de kloon.
- De screenshots verschilden tussen de twee.
De e-mail geeft ook toegang tot de gekloonde site, waar de updates zijn toegepast. Het webagentschap kan het probleem zien, het direct op de kloon oplossen en vervolgens zelf de productie-update starten zodra alles in orde is.
We waren stellig op dit punt: automatisering neemt het repetitieve werk uit handen, maar neemt nooit namens het bureau een riskante beslissing. Bij twijfel blijft een mens de controle houden.
Hoe gaat een gevalideerde update live?
Zodra de update is gevalideerd, wordt deze kort daarna toegepast op de productieomgeving en wordt de klant op de hoogte gesteld.
Er is geen automatische rollback als zodanig, aangezien de update al is getest voordat deze live ging. Maar als er achteraf toch een probleem optreedt, kan de klant met één klik een back-up terugzetten vanuit het OVHcloud Control Panel. Back-ups worden per site gemaakt in plaats van voor het hele hostingpakket, zodat een webbureau de site van één klant kan herstellen zonder de andere sites aan te raken.
Kun je plug-ins uitsluiten van updates?
Nee, en dat is een bewuste keuze. Wanneer iemand een plug-in wil uitsluiten, is dat meestal omdat die persoon bang is dat een update de site zal beschadigen. Ervoor zorgen dat dit niet gebeurt, is precies onze taak.
Sommige gevallen vereisen een speciale aanpak, en dat regelen we. Neem WooCommerce: als een site zowel WooCommerce als een premium WooCommerce-extensie gebruikt waarvan de licentie verlopen is, ontvangt de premium extensie geen updates meer. Als je dan alleen WooCommerce zou updaten, houdt dat het risico in dat de site niet meer werkt, omdat een recente versie van WooCommerce niet compatibel is met een verouderde versie van de extensie. In die situatie updaten we WooCommerce niet. Wanneer Smart Automatic Updates andere soortgelijke gevallen tegenkomt, handelen wij die ook af.
Hoe zit het met premium plug-ins en thema's?
De regel is simpel: als je in je WordPress-beheerdersdashboard op “Update” kunt klikken voor een plug-in of thema, dan updaten we deze. Als dat niet kan, bijvoorbeeld omdat een licentie is verlopen, dan doen we dat niet. In dat geval laten we de klant in het OVHcloud Control Panel weten dat de plug-in moet worden bijgewerkt, zodat de update niet over het hoofd wordt gezien.
Wat verandert er voor bureaus?
Ik zou zeggen drie dingen.
Ten eerste, beveiliging. Updates stapelen zich niet langer op omdat niemand tijd heeft gehad om ze te controleren. Elke site wordt regelmatig bijgewerkt, waardoor de periode waarin een bekende kwetsbaarheid open blijft, wordt verkort.
Ten tweede, minder zorgen. Het bureau hoeft zich niet langer af te vragen of een update een site heeft beschadigd. Of de update is gevalideerd en toegepast, of de productieomgeving is ongewijzigd gebleven en zij hebben precies te horen gekregen waarom. En mocht er ooit iets misgaan, dan kan de site van elke klant afzonderlijk met één klik worden hersteld, zonder dat dit invloed heeft op de andere.
Ten derde, tijdsbesparing. Eén bureau vertelde ons dat het onderhoud van hun sites rond de 30 % van hun tijd in beslag neemt. Smart Automatic Updates neemt de repetitieve controles over, zodat bureaus meer van die tijd kunnen besteden aan wat de meeste waarde toevoegt voor hun klanten.
Smart Automatic Updates is inbegrepen in al onze Managed Hosting voor WordPress-abonnementen, dus elke WordPress-update wordt getest voordat deze de sites van je klanten bereikt. Lees meer over hoe wij bureaus en freelancers ondersteunen bij het beheren van hun WordPress-websites, of lees waarom we managed WordPress hosting op deze manier hebben gebouwd.
De documentatie voor Managed Hosting voor WordPress behandelt de installatie en het updateproces in meer detail.