Cosa succede se non aggiorni WordPress

Non aggiornare WordPress espone il sito a vulnerabilità pubbliche che i bot possono sfruttare in poche ore dalla loro divulgazione. Il danno non è immediato: si accumula in silenzio per settimane o mesi prima di diventare visibile. La progressione tipica: vulnerabilità aperte nelle prime settimane, lentezza ed errori di compatibilità nel secondo e terzo mese, danno SEO e reputazionale tra il quarto e il sesto mese. Oltre i sei mesi il recupero diventa costoso, mediamente 5-10 volte più di una manutenzione preventiva. I rischi di un WordPress non aggiornato non riguardano se il problema emergerà, ma quando.

Perché rimandare gli aggiornamenti WordPress costa più di quanto pensi

Le notifiche di aggiornamento nella dashboard WordPress sono facili da ignorare. Il sito funziona, i clienti arrivano, non c’è nessun segnale che qualcosa non vada. Rimandare sembra una scelta ragionevole: gli aggiornamenti possono rompere cose. In realtà, senza manutenzione WordPress regolare, aspettare il momento giusto significa solo accumulare rischi.

Il problema è che mentre aspetti il momento giusto, aggiornare WordPress smette di essere una scelta e diventa un’urgenza. Le vulnerabilità scoperte nei plugin e nel core di WordPress vengono pubblicate in database accessibili a tutti, inclusi i bot che scansionano milioni di siti automaticamente. Il tuo sito non viene ignorato perché è piccolo o poco visitato. Viene ignorato finché non smette di esserlo, e i numeri mostrano quanto velocemente può succedere.

Secondo il report State of WordPress Security in 2026 di Patchstack, nel 2025 sono state scoperte 11.334 nuove vulnerabilità nell’ecosistema WordPress, il 42% in più rispetto all’anno precedente, il 91% concentrate in plugin di terze parti. Il dato più critico riguarda i tempi: per le vulnerabilità più sfruttate, il tempo mediano tra la divulgazione e il primo attacco è di 5 ore. Il 20% viene sfruttata entro 6 ore dalla scoperta, il 45% entro 24 ore. Non aggiornare non è una scelta neutrale: la finestra per intervenire prima che l’exploit venga automatizzato si misura ormai in ore, non in giorni.

Il sito funziona normalmente, ma questo non significa che sia al sicuro

Questa è la trappola principale: un sito WordPress non aggiornato può sembrare perfettamente funzionante per settimane o mesi. Le pagine si caricano, i form funzionano, Google indicizza. Nel frattempo:

• Le vulnerabilità sono pubbliche. Quando viene scoperta una falla in un plugin popolare, viene pubblicata in database come WPScan e CVE. Chiunque, inclusi i bot automatici, sa quali versioni sono vulnerabili e può verificarlo in pochi secondi sul tuo sito.
• Il codice invecchia rispetto all’ambiente. WordPress, PHP, il browser del visitatore e le API dei servizi terzi si aggiornano continuamente. Un plugin scritto per PHP 7.4 su WordPress 5.x può funzionare in modo imprevedibile su PHP 8.2 e WordPress 6.x; i problemi non sempre sono evidenti.
• Il danno si accumula senza segnali. Malware iniettato discretamente, spam SEO inserito nelle pagine, traffico deviato verso siti terzi: gli attacchi più sofisticati evitano di essere visibili perché la longevità dell’accesso vale più del danno immediato.

L’errore più comune: “se il sito si vede, allora va bene”. I rischi di un WordPress non aggiornato sono spesso invisibili: un sito può essere online, indicizzato e apparentemente funzionante mentre è già compromesso.

La progressione del danno silenzioso

Il danno di un sito WordPress non aggiornato non è uniforme nel tempo. Segue una progressione prevedibile in cui ogni fase aggiunge un livello di problema al precedente.

Settimane 1-4: la vulnerabilità è pubblica, il tuo sito resta esposto

Ogni aggiornamento di plugin o core WordPress corregge vulnerabilità che vengono contestualmente rese pubbliche nel changelog e nei database CVE. Dal momento in cui un aggiornamento viene rilasciato, chiunque può vedere cosa corregge, e quindi cosa è vulnerabile nelle versioni precedenti.

In questa fase il sito funziona normalmente, ma la sicurezza è già indebolita: i bot automatici scansionano e catalogano i siti con vulnerabilità plugin WordPress attive, individuandoli prima che il proprietario se ne accorga.

Il periodo di massima esposizione si è ristretto drasticamente: se un tempo si parlava di settimane, oggi la maggior parte degli attacchi automatici avviene entro le prime 24 ore dalla divulgazione di una vulnerabilità. Questo non significa che il rischio sparisca dopo un giorno: i siti individuati nelle prime 24 ore vengono colpiti quasi subito, mentre quelli non ancora scansionati restano esposti per tutte le settimane successive, finché un bot non li intercetta.

Mese 2-3: errori di compatibilità che vengono scambiati per problemi di hosting o casi isolati

L’ecosistema WordPress si aggiorna continuamente anche intorno al tuo sito: il server aggiorna PHP, i browser cambiano come interpretano certi script, le API di servizi terzi (pagamenti, form, newsletter) cambiano le proprie versioni. Un sito fermo accumula incompatibilità crescenti.

I segnali tipici di questa fase:

• Errori sporadici su pagine specifiche che prima funzionavano
• Lentezza crescente senza cause apparenti, spesso causata da query non ottimizzate che peggiorano con le versioni più vecchie
• Form che smettono di inviare email o gateway di pagamento che restituiscono errori
• Avvisi deprecation nei log PHP: il codice vecchio usa funzioni che le versioni nuove di PHP non supportano più

In questa fase il proprietario del sito nota qualcosa ma spesso attribuisce i problemi a cause esterne: “il server è lento”, “è un problema temporaneo”. Raramente collega i sintomi ai problemi legati agli aggiornamenti WordPress rimasti indietro.

Mese 4-6: il danno lo vede Google prima che a te

Se il sito è stato compromesso silenziosamente, in questa fase i segnali diventano visibili a Google prima che al proprietario. I motori di ricerca scansionano il sito e trovano: link a siti spam inseriti nel codice, redirect nascosti verso pagine esterne, contenuto generato automaticamente in lingue straniere.

Le conseguenze:

• Calo del traffico organico. Google riduce la visibilità dei siti compromessi o con comportamenti anomali; in alcuni casi si tratta di una vera e propria penalizzazione SEO manuale. Il calo può essere graduale, difficile da collegare alla causa reale senza un’analisi approfondita.
• Blacklist del dominio. Se il sito viene usato per inviare spam SEO o distribuire malware, il dominio finisce nelle blacklist degli antivirus e dei filtri email. Le email del dominio iniziano ad arrivare nello spam dei destinatari.
• Avviso del browser. Google Safe Browsing segnala i siti compromessi con un avviso rosso prima dell’accesso. È il danno reputazionale più visibile, e quello più difficile da recuperare velocemente.

Arrivati a questo punto il recupero è possibile ma non è più semplice. C’è però una fase successiva in cui i costi cambiano natura completamente.

Oltre 6 mesi: il recupero non è più un intervento veloce ma un progetto di settimane che costa più della manutenzione che lo avrebbe evitato

Un sito WordPress obsoleto, o sito WordPress vecchio, con mesi di aggiornamenti non eseguiti accumula un debito tecnico che non si risolve con un click su “Aggiorna tutto”. I plugin con versioni molto distanti da quella attuale possono rompere funzionalità quando aggiornati d’improvviso. Il tema può non essere più compatibile con il core aggiornato. Il database può avere tabelle corrotte o strutture obsolete.

Il recupero in questa fase richiede:

• Analisi approfondita dello stato attuale: versioni, compatibilità, vulnerabilità attive
• Aggiornamenti incrementali in ambiente di staging: non si aggiorna tutto in produzione
• Pulizia del database e verifica dell’integrità del codice
• Scansione malware e rimozione di codice iniettato se il sito è stato compromesso
• Ripristino del posizionamento SEO se il sito è stato penalizzato o inserito in blacklist

Il costo di questo intervento supera sistematicamente il costo di una manutenzione WordPress ordinaria fatta nel tempo. Non è una questione di ore, ma di settimane.

Quattro aree di danno, e quanto costano

Il dato che quasi nessuno considera: il costo di recupero da una compromissione è mediamente 5-10 volte superiore al costo di una manutenzione preventiva annuale. Non è un calcolo ipotetico, è la differenza tra gestire il problema prima e gestirlo dopo che è esploso.

Se riconosci uno di questi scenari sul tuo sito, la strada più diretta per evitare che queste cifre diventino reali è affidare la gestione degli aggiornamenti a un professionista.

Come si recupera un posizionamento perso dopo una compromissione

Ecco cosa comporta in pratica, che il recupero lo segua un tecnico o tu stesso: il ripristino SEO dopo un attacco non è automatico nemmeno dopo la bonifica tecnica, e richiede una verifica sistematica su più fronti:

• Ogni redirect va controllato uno per uno: un 301 verso una pagina pertinente conserva parte del valore acquisito, uno verso una pagina pubblicitaria o la home aggrava il danno agli occhi di Google.
• File di configurazione. Canonical, tag noindex, robots.txt e sitemap vanno rivisti: durante la compromissione vengono spesso alterati senza segnali visibili, e continuano a disorientare Google anche dopo la pulizia.
• Revisione Google Safe Browsing. Se il dominio è finito in blacklist, l’avviso rosso non sparisce da solo: va richiesta esplicitamente la revisione una volta completata la bonifica.
• Search Console. Resta lo strumento per individuare URL spam ancora indicizzati settimane dopo la pulizia.

Un errore comune è eliminare le pagine che hanno perso traffico invece di ripristinarle: spesso conservano ancora URL, link interni e struttura che vale la pena recuperare piuttosto che ricostruire da zero.

Il danno tecnico e reputazionale non è l’unico rischio da considerare: per chi tratta dati di clienti c’è anche un profilo di responsabilità legale.

Per aziende che trattano dati di clienti

Studi professionali, e-commerce, aziende con CRM: l’art. 32 del GDPR richiede misure di sicurezza tecniche e organizzative adeguate, tenendo conto dello stato dell’arte, per proteggere i dati trattati. Un sito con vulnerabilità note e pubblicamente documentate, mai corrette, rende difficile sostenere di aver rispettato l’obbligo in caso di controllo o violazione dei dati.

Lo stesso principio di responsabilità vale, con un rischio economico ancora più diretto, per chi gestisce un e-commerce.

Il caso WooCommerce: gli aggiornamenti non sono opzionali

Per un e-commerce WooCommerce, rimandare gli aggiornamenti WordPress ha conseguenze dirette sulle transazioni. Gli aggiornamenti WooCommerce non sono opzionali come potrebbero sembrare. WooCommerce gestisce ordini, pagamenti, stock, email transazionali e spesso integrazioni con corrieri e gestionali. Una versione non aggiornata può:

• Interrompere il processo di checkout. I gateway di pagamento (Stripe, PayPal, Nexi) aggiornano le proprie API e deprecano le versioni vecchie. Un plugin WooCommerce non aggiornato può smettere di comunicare con il gateway senza preavviso.
• Creare incongruenze nello stock. Plugin di magazzino e spedizione non compatibili tra loro dopo aggiornamenti parziali possono generare ordini per prodotti esauriti o errori nella gestione delle spedizioni.
• Violare le normative PCI DSS. I siti e-commerce che gestiscono pagamenti devono mantenere il software aggiornato come requisito di conformità. Un sito non aggiornato può non essere conforme, con implicazioni legali in caso di violazione dei dati.

Per un e-commerce, la differenza tra un aggiornamento gestito e uno improvvisato si misura in ordini persi durante il checkout. Se gestisci un negozio WooCommerce, vale la pena affidare gli aggiornamenti a un tecnico che li testa prima di metterli in produzione.

Per WooCommerce il backup automatico WordPress non è opzionale, è il prerequisito di qualsiasi aggiornamento. Un backup recente del database prima di ogni ciclo di aggiornamenti è la differenza tra un problema risolvibile e uno catastrofico.

Sapere cosa succede se non aggiorni è metà del problema. L’altra metà è capire come farlo senza che l’aggiornamento stesso rompa qualcosa, che è esattamente la preoccupazione che porta molti a rimandare.

Chi gestisce gli aggiornamenti per te

La ragione principale per cui gli aggiornamenti vengono rimandati non è negligenza, è la preoccupazione concreta che un aggiornamento possa rompere qualcosa. È una preoccupazione legittima: un plugin aggiornato può essere incompatibile con il tema, un aggiornamento del core può cambiare il comportamento di funzionalità personalizzate.

La soluzione non è non aggiornare. È aggiornare in modo controllato: backup prima dell’intervento, test in staging quando il sito è critico, verifica funzionale dopo ogni ciclo. In quale di queste quattro fasi si trova il tuo sito, in questo momento? Questo è esattamente quello che verifica una manutenzione WordPress professionale prima ancora di intervenire: non un click su “Aggiorna tutto” in produzione, ma un processo che riduce il rischio senza eliminare la manutenzione.

La guida su come aggiornare WordPress in sicurezza copre la procedura completa passo per passo.

In sintesi

Non aggiornare WordPress non è una scelta neutrale. I rischi di un WordPress non aggiornato si accumulano in silenzio seguendo una progressione prevedibile: vulnerabilità aperte nelle prime settimane, incompatibilità e lentezza nei mesi successivi, danno SEO e reputazionale tra il quarto e il sesto mese. Oltre i sei mesi il recupero diventa un intervento strutturato che costa sistematicamente più della manutenzione preventiva che lo avrebbe evitato.

La preoccupazione che un aggiornamento possa rompere qualcosa è legittima, ed è esattamente per questo che gli aggiornamenti WordPress vanno gestiti con un processo, non ignorati o eseguiti alla cieca. Backup prima, test quando il sito è critico, verifica dopo.

Per WooCommerce le conseguenze di un sito WordPress obsoleto sono ancora più dirette: gateway di pagamento che smettono di funzionare, stock non allineato, conformità PCI DSS a rischio. Non è una questione tecnica, è una questione operativa.