Gli aggiornamenti WordPress sono essenziali per mantenere un sito web sicuro, ma costituiscono anche una delle principali fonti di preoccupazione per le agenzie web. Abbiamo chiesto a Sébastien Cavaillé, Product Marketing Manager di OVHcloud, di spiegare come Smart Automatic Updates è stato progettato per risolvere questo dilemma.
Qualunque agenzia che gestisce siti WordPress conosce le difficoltà tra la necessità di installare gli aggiornamenti e la mancanza di tempo o risorse per eseguirli. Da un lato, gli aggiornamenti non possono aspettare: secondo l'ultimo rapporto annuale di Patchstack, specialista nella sicurezza di WordPress, nel 2025 sono state registrate 11.334 nuove vulnerabilità, il 91% delle quali riguardava i plugin, il 9% i temi e soltanto 6 il core di WordPress. Gli aggressori si muovono inoltre rapidamente: circa la metà delle vulnerabilità ad alto impatto viene sfruttata entro 24 ore dalla divulgazione. Un plugin non aggiornato è uno dei punti di accesso più comuni per gli attacchi, perciò più si ritarda un aggiornamento più a lungo un sito rimane esposto.
D'altra parte, ogni aggiornamento comporta un rischio: un plugin incompatibile, un tema che non viene più visualizzato correttamente, una pagina che restituisce improvvisamente un errore. Per evitare brutte sorprese, molte agenzie effettuano controlli manuali su ogni sito. Un’attività che richiede molto tempo quando si gestiscono decine o addirittura centinaia di siti. E quando il tempo non è sufficiente gli aggiornamenti vengono posticipati, a volte per settimane o mesi.
Per superare questo stallo, i team di OVHcloud hanno sviluppato Smart Automatic Updates, una funzionalità inclusa nel servizio Managed Hosting for WordPress. Per capire meglio questo problema, abbiamo parlato con Sébastien, che ha lavorato al progetto.
Da dove nasce l'idea del progetto?
È venuta direttamente dai nostri clienti. Nella nostra piattaforma di hosting condiviso ospitiamo circa 6 milioni di siti web, di cui l’80% è basato su WordPress. Questo ci permette di raccogliere molti feedback e una particolare esigenza emergeva frequentemente: tutti conoscono l’importanza di mantenere i siti aggiornati, ma molti hanno vissuto esperienze negative e non hanno il tempo di controllare ogni sito manualmente.
Gli aggiornamenti automatici tradizionali risolvono il problema della sicurezza, ma ne creano un altro perché spesso ci si accorge che un sito non funziona solo quando un cliente chiama per segnalarlo. Volevamo quindi un'automazione che effettuasse controlli prima degli interventi.
Una storia, in particolare, ci ha colpito. Uno sviluppatore web freelance gestiva da solo la propria agenzia e decine di siti WordPress per i suoi clienti. Quando è stata resa nota una vulnerabilità in un plugin utilizzato in molti di essi, semplicemente non ha avuto il tempo di aggiornarli tutti prima che un hacker la sfruttasse. In breve tempo, 36 dei siti dei suoi clienti sono stati compromessi e hanno iniziato a reindirizzare i visitatori verso siti malevoli.
Ripulire i siti era una cosa, affrontare i clienti tutt’altra. Ognuno di loro gli aveva affidato la gestione del proprio sito web e aveva poi scoperto che i visitatori erano stati reindirizzati a pagine pericolose. Per un libero professionista con un’attività basata sulla reputazione e il passaparola, riparare un danno alla propria credibilità richiede molto più tempo che un ripristino.
Da allora, ha migrato i siti dei clienti su Managed Hosting for WordPress affidandoci il compito di mantenerli aggiornati. La sua storia rappresenta esattamente il tipo di situazione che vogliamo evitare: non perché lui avesse commesso errori, ma perché è impossibile aggiornare manualmente decine di siti, settimana dopo settimana.
Come vengono testati gli aggiornamenti di WordPress?
Il principio è non testare mai un aggiornamento direttamente sul sito online.
Quali sono le quattro fasi di test?
Ogni giorno verifichiamo la disponibilità di nuovi aggiornamenti e ognuno viene successivamente testato in quattro fasi.
La prima fase consiste nel creare uno snapshot dello stato attuale del sito. Un crawler parte dalla homepage e segue i link in modo ricorsivo: se la homepage rimanda alla pagina A, che rimanda alla pagina B, che a sua volta rimanda alla pagina C, allora anche la pagina C viene analizzata. Arriviamo ad analizzare fino a 50 pagine per sito. Per ciascuna registriamo il codice di stato HTTP restituito dal server, che indica se la pagina si carica normalmente o genera un errore, ed effettuiamo uno screenshot dell’intera pagina con risoluzione 1920×1080.
Nella seconda fase, cloniamo il sito in un ambiente di test isolato. Su questa copia, ed esclusivamente su di essa, applichiamo gli aggiornamenti di WordPress, dei temi e dei plugin.
Nel terzo step, analizziamo il clone esattamente come il sito originale verificando le stesse pagine, gli stessi codici di stato HTTP e gli stessi screenshot.
Nella quarta e ultima fase, compariamo i risultati. Questo confronto determina se l'aggiornamento può essere applicato al sito in produzione.
Quando un aggiornamento viene considerato valido?
Devono essere soddisfatte tre condizioni:
- I codici di stato HTTP sono identici: se una pagina che prima funzionava ora restituisce un errore, l'aggiornamento viene bloccato.
- Gli screenshot corrispondono, con una piccola tolleranza per le differenze visive.
- Ogni aggiornamento di temi e plugin viene installato senza errori.
Di default il confronto visivo è molto rigoroso. Un pixel viene considerato diverso appena uno dei suoi valori di rosso, verde o blu cambia anche di una singola unità. Non è prevista alcuna tolleranza per la variazione di colore. Viene invece accettata una piccola percentuale di pixel modificati: fino al 5% della pagina. La soglia misura quindi quanto può cambiare la pagina, non quanto può variare ogni singolo pixel.
Prima di acquisire ogni screenshot attendiamo inoltre qualche secondo per consentire il completamente delle animazioni di caricamento e degli effetti simili.
Come si evitano i falsi allarmi?
Molti siti includono caroselli, animazioni o contenuti che cambiano continuamente. Questo è stato uno dei problemi più interessanti da risolvere. Durante i primi test siamo rimasti sorpresi dal numero di aggiornamenti segnalati come non riusciti, anche se dai controlli manuali non risultava esserci nessun malfunzionamento. Analizzando gli screenshot, abbiamo notato che le cause erano quasi sempre le stesse: slider nella homepage passati all'immagine successiva, timer per il conto alla rovescia sui siti di eventi, widget con gli ultimi post pubblicati e feed di social media incorporati che si erano aggiornati tra le due acquisizioni. Gli aggiornamenti erano corretti: semplicemente, erano le pagine a cambiare.
La soluzione è stata acquisire più schermate di ogni pagina a pochi secondi di distanza. Se una pagina cambia da sola tra due screenshot, il sistema la riconosce come dinamica e la esclude dal confronto visivo. Questo non significa però che non venga controllata: i codici di stato HTTP vengono comunque comparati e di conseguenza se una pagina dinamica inizia a restituire un errore blocca comunque l'aggiornamento. Dopo l’aggiunta di questo step, i falsi allarmi sono diminuiti in modo significativo e abbiamo potuto fare nuovamente affidamento sul confronto visivo.
Fin dove arriva l'analisi?
Ci siamo concentrati su ciò che conta di più: le pagine effettivamente consultate dai visitatori. Nella pratica, questo include il core della maggior parte dei siti web: homepage, sezioni principali e pagine chiave del percorso di navigazione.
Le pagine non raggiungibili dalla homepage, nemmeno indirettamente, non rientrano nell'analisi. È una scelta intenzionale: se nessun link porta a una pagina, i visitatori non possono raggiungerla navigando nel sito e, di conseguenza, un aggiornamento non riuscito non avrebbe un impatto sulla loro esperienza.
La stessa logica si applica alle aree protette da login, come l’account cliente o il pannello di amministrazione. Ogni sito gestisce l'autenticazione in modo diverso, quindi abbiamo scelto di concentrarci sulle pagine pubbliche, dove possiamo eseguire controlli affidabili e coerenti su larga scala.
L’obiettivo non è sostituire le competenze di un’agenzia, ma occuparci dei controlli ripetitivi che altrimenti dovrebbero essere eseguiti manualmente sito dopo sito. In questo modo l’agenzia ha più tempo da dedicare alle attività che solo lei è in grado di svolgere.
Quando un test viene superato o fallisce
Cosa succede se la validazione fallisce?
Sul sito online non succede nulla, ed è proprio questo il punto. Se anche solo un criterio non viene rispettato, gli aggiornamenti non vengono applicati e il sito continua a funzionare esattamente come prima.
Il cliente riceve quindi un'email che spiega perché la validazione non è andata a buon fine. Le possibili cause sono quattro:
- i plugin o i temi non sono stati aggiornati completamente sul sito di test
- la homepage ha restituito un errore 4xx o non era raggiungibile, impedendo l’esecuzione del test
- le risposte HTTP sono diverse tra il sito originale e il clone
- i due screenshot sono diversi tra loro
L'email contiene anche l'accesso alla copia del sito su cui sono state applicate le modifiche. L'agenzia può individuare il problema, risolverlo direttamente sul clone e poi avviare l'aggiornamento in produzione una volta che tutto è in ordine.
Su questo punto siamo categorici: l'automazione si occupa delle attività ripetitive, ma non prende mai decisioni rischiose per conto dell'agenzia. In caso di dubbio, è sempre una persona ad avere il controllo.
Come viene pubblicato un aggiornamento validato?
Una volta convalidato, l’aggiornamento viene applicato nell’ambiente di produzione poco dopo e il cliente riceve una notifica.
Non è previsto un vero e proprio rollback automatico, perché l'aggiornamento è già stato testato prima del rilascio. Se dovesse verificarsi un problema in un secondo momento, il cliente può ripristinare un backup con un solo clic dallo Spazio Cliente OVHcloud. I backup sono effettuati per ogni singolo sito e non per l'intero piano di hosting. In questo modo un'agenzia può ripristinare il sito di un cliente senza intervenire anche sugli altri.
È possibile escludere i plugin dagli aggiornamenti?
No, ed è una scelta intenzionale. Quando qualcuno vuole escludere un plugin, solitamente è perché teme che un aggiornamento possa compromettere il sito. Il nostro compito è proprio assicurarci che questo non accada.
Alcune situazioni richiedono una gestione specifica, di cui ci occupiamo direttamente. Prendiamo l’esempio di WooCommerce: se un sito utilizza sia WooCommerce sia una sua estensione premium la cui licenza è scaduta, quest’ultima non riceve più aggiornamenti. Aggiornare solo WooCommerce rischierebbe di compromettere il funzionamento del sito, perché le versioni più recenti di WooCommerce non sono compatibili con una versione obsoleta dell'estensione. In questo caso, non aggiorniamo WooCommerce. Ogni volta che Smart Automatic Updates individua altri casi dello stesso tipo, li gestiamo allo stesso modo.
E per i plugin e i temi premium?
La regola è semplice: l’aggiornamento viene eseguito se nel tuo pannello di amministrazione WordPress è possibile cliccare su “Aggiorna” per un plugin o un tema. Se l’opzione non è disponibile, ad esempio perché la licenza è scaduta, l’operazione non viene effettuata. In questo caso informiamo il cliente, tramite lo Spazio Cliente OVHcloud, che il plugin deve essere aggiornato, in modo che l'intervento non venga trascurato.
Cosa cambia per le agenzie?
Direi tre cose.
Prima di tutto, la sicurezza. Gli aggiornamenti non restano più in sospeso perché manca il tempo per controllarli. Ogni sito viene aggiornato regolarmente, riducendo così il periodo di esposizione alle vulnerabilità conosciute.
In secondo luogo, la tranquillità. L'agenzia non deve più chiedersi se un aggiornamento abbia compromesso un sito: o l’aggiornamento è stato convalidato e applicato, oppure l’ambiente di produzione è rimasto invariato ed è stata informata chiaramente dei motivi. In caso di problemi, il sito di ogni cliente può essere ripristinato singolarmente con un solo clic, senza impatto sugli altri.
Infine, il risparmio di tempo. Un'agenzia ci ha riferito che dedica fino al 30% del proprio tempo alla manutenzione dei siti. Smart Automatic Updates si occupa dei controlli ripetitivi, consentendo di concentrarsi sulle attività con maggior valore per i clienti.
La funzionalità Smart Automatic Updates è inclusa in tutti i nostri piani Managed Hosting for WordPress, in modo che ogni aggiornamento di WordPress venga testato prima di raggiungere i siti dei tuoi clienti. Scopri come supportiamo agenzie e liberi professionisti nella gestione dei loro siti WordPress e leggi perché abbiamo sviluppato il nostro servizio di hosting WordPress gestito in questo modo.
La documentazione su Managed Hosting for WordPress descrive in modo più dettagliato la configurazione e il processo di aggiornamento.