Aggiornamento WordPress: cosa fare prima e dopo, in che ordine e come tornare indietro

Un aggiornamento di WordPress tocca quattro cose che non si comportano allo stesso modo: il core, i plugin, i temi e le traduzioni. Alcune versioni WordPress le installa da solo, altre aspettano un tuo clic, e quale delle due dipende anche da quando è nato il sito.

Prima di decidere come aggiornare conviene sapere cosa sta già succedendo senza di te.

Questa guida segue l’ordine in cui si lavora. Si parte da quello che va fatto prima, con un backup già provato, la compatibilità letta dove WordPress la mostra e una copia di prova quando serve. Poi vengono l’ordine degli aggiornamenti e quello che WordPress fa da solo mentre aggiorna, compreso il ripristino automatico e i casi in cui non scatta. In fondo ci sono i controlli da fare dopo e il modo di tornare indietro quando qualcosa si rompe.

Una nota sulle fonti. Quello che segue l’ho verificato il 1° ottobre 2026 sulla documentazione ufficiale di WordPress e di WP-CLI e sul codice di WordPress 7.1.2. Gli aggiornamenti automatici e quelli manuali, il ripristino, i messaggi di errore e i tre blocchi di codice li ho eseguiti su un WordPress 7.1.2 in italiano, con un plugin di prova costruito apposta in due versioni, una sana e una che va in errore.

Dove la documentazione e il codice dicono cose diverse, lo trovi scritto.

Perché aggiornare presto, e perché non alla cieca

Le falle nei plugin e nei temi vengono sfruttate in fretta. Nel rapporto di Patchstack sul 2025, aggiornato a febbraio 2026, c’è il tempo che passa fra la pubblicazione di una vulnerabilità e il primo tentativo di sfruttarla, misurato su quelle più attaccate. Pesando ciascuna per quanto è stata attaccata, la mediana è di cinque ore. Il 45% era già sotto attacco entro un giorno, il 70% entro una settimana. Chi attacca non sceglie i siti uno per uno. Sono programmi automatici che provano la stessa falla su tutti i siti che trovano, come quelli che tentano di entrare dal login ogni giorno, e per loro un sito piccolo vale quanto uno grande.

Patchstack vende protezioni che bloccano gli attacchi prima che arrivi la correzione, e dai suoi dati conclude che sugli aggiornamenti dei plugin non si può contare come unica difesa. Nel 46% dei casi lo sviluppatore non aveva ancora pubblicato una correzione quando la falla è diventata pubblica. Per chi aggiorna il dato dice due cose. Le correzioni di sicurezza si installano appena escono, e bisogna sapere quali sono.

A dirti quali sono serve un plugin che ti avvisa quando una versione installata è vulnerabile, e Wordfence (9.0.2) e Patchstack (2.3.7) lo fanno anche nella versione gratuita. In quella di Wordfence, però, le regole del firewall e le firme arrivano con 30 giorni di ritardo.

Dall’altra parte, un aggiornamento cambia codice su cui contano il tema e gli altri plugin. Le versioni minori di WordPress contengono correzioni di bug e di sicurezza. Le major cambiano l’editor, le API e a volte i requisiti di PHP, ed è lì che un plugin rimasto indietro può smettere di funzionare.

Per questo conviene trattarle in modo diverso, con le correzioni che arrivano da sole e le novità provate prima.

Che aggiornamento hai davanti, e cosa WordPress installa da solo

La prima cosa da sapere è cosa si aggiorna già da solo sul tuo sito, perché la risposta cambia da un sito all’altro.

Il core, e la frase da leggere in Bacheca > Aggiornamenti

In Bacheca > Aggiornamenti, sopra il pulsante, una frase dice come è impostato il tuo sito. Su un’installazione nata dalla 5.6 in poi, se nessuno l’ha cambiata, la frase è “Questo sito viene aggiornato automaticamente con ogni nuova versione di WordPress.”, seguita dal link “Passa agli aggiornamenti automatici solo per le versioni di manutenzione e sicurezza.” Sui siti più vecchi si legge invece “Questo sito viene mantenuto automaticamente aggiornato solo con le versioni di manutenzione e sicurezza di WordPress.”, e il link fa il contrario.

Se il link manca, una costante in wp-config.php o un plugin hanno già deciso al posto tuo.

La documentazione ufficiale, su questo punto, si contraddice. Updating WordPress, aggiornata l’ultima volta a settembre 2024, dice ancora che per le major bisogna cliccare “Update Now”. Upgrading WordPress, la guida per gli amministratori, e il codice dicono invece che dalla 5.6 le installazioni nuove le ricevono da sole.

Fa fede la frase della tua bacheca.

La guida alla manutenzione lascia automatiche le minori del core e manuale tutto il resto, major comprese. Su un sito installato con la 5.6 o una versione successiva vuol dire cliccare quel link. La stessa scelta si può fissare nel wp-config.php, dove vince su quello che imposti in bacheca, con la riga define( 'WP_AUTO_UPDATE_CORE', 'minor' );.

Prima di una major conviene sapere cosa contiene. Per l’ultima uscita c’è una guida che spiega se conviene passare subito alla 7.1 e cosa può rompersi. Se stai saltando più versioni in una volta, quello che si accumula sta in un posto solo, la tabella di cosa è cambiato in ogni versione, dalla 6.0 in poi.

Quando le major da saltare sono più di due, la guida ufficiale suggerisce di valutare un passaggio alla volta, per ridurre il rischio di conflitti e di danni al database.

Plugin e temi

Per plugin e temi l’aggiornamento automatico è spento finché non lo accendi, e dalla 5.5 si accende uno per uno. In Plugin installati c’è la colonna “Aggiornamenti automatici” con il link “Abilita gli aggiornamenti automatici”; per i temi lo stesso link sta nella scheda del tema, in Aspetto > Temi. Secondo la documentazione sugli aggiornamenti automatici, WordPress fa il giro due volte al giorno e alla fine manda un’email con quello che ha aggiornato e quello che non è riuscito ad aggiornare.

C’è un’eccezione che non decidi tu. Quando una falla è grave, WordPress.org può spingere la versione corretta di un plugin su tutti i siti che lo usano, anche dove il suo aggiornamento automatico è spento. La blocca solo chi ha spento gli automatismi nel codice del sito, con un filtro o con la costante che li disattiva tutti, e perdere quella spinta è uno dei motivi per cui spegnerli in blocco è una cattiva idea.

Per decidere quali plugin lasciare in automatico la stessa guida usa un criterio semplice. In automatico vanno quelli che non toccano né il sito pubblico né i pagamenti, a mano tutti gli altri.

Un’avvertenza. Gli aggiornamenti automatici partono con WP-Cron, il sistema con cui WordPress esegue i compiti programmati. Se WP-Cron è spento e nessun cron di sistema lo sostituisce, non parte nemmeno l’aggiornamento, e Salute del sito lo segnala fra gli eventi programmati.

Come si gestisce WP-Cron, e come si spegne un automatismo quando c’è una ragione per farlo, hanno due guide in calendario.

Da dove arriva l’aggiornamento

L’aggiornamento di un plugin della directory ufficiale, oggi, passa da due filtri prima di arrivare al tuo sito. Dal 5 giugno 2026 ogni nuova versione di plugin e temi aspetta, al momento 6 ore, prima di essere distribuita, anche a chi aggiorna con un clic dalla bacheca. Dal 9 settembre 2026, durante l’attesa, una revisione automatica analizza le modifiche dei plugin e blocca le versioni ad alto rischio. Lo ha spiegato il team dei plugin di WordPress.org annunciando la revisione.

I plugin commerciali seguono un’altra strada. Si aggiornano dal server del fornitore, con la licenza, e quei controlli non li riguardano. È la distinzione da tenere a mente quando ti chiedi da dove può arrivare un problema, compreso il caso peggiore, quando è l’aggiornamento stesso a portare il codice malevolo.

Prima di aggiornare: backup, compatibilità e staging

Le prime due servono sempre, la terza quando l’aggiornamento è grosso.

Un backup che hai già provato a ripristinare

Un backup completo comprende i file (core, plugin, temi, caricamenti e wp-config.php) e il database. Va conservato in più copie, e non tutte sul server del sito. La guida ufficiale ai backup ne consiglia almeno da tre a cinque recenti, in posti diversi, per esempio una sul server, una in un servizio cloud e una sul tuo computer. La parte che si salta è la prova. Fra i passi dell’aggiornamento manuale, la documentazione di WordPress chiede di verificare che i backup appena fatti ci siano e siano utilizzabili, e lo definisce essenziale. Che il file esista non dice niente su cosa contiene: lo dice un ripristino fatto su una copia, almeno una volta.

Con WP-CLI e uno spazio esterno come S3, la procedura per salvarlo, ripristinarlo da riga di comando e cronometrare quanto ci vuole è in un articolo a parte.

Con un plugin, la versione gratuita di UpdraftPlus (1.26.8) salva su Google Drive, Dropbox, Amazon S3 e altre destinazioni; il backup automatico subito prima di ogni aggiornamento è una funzione della versione Premium. Anche l’hosting fa i suoi backup, ma la stessa guida ufficiale avverte che chiederne una copia richiede tempo. Per un aggiornamento serve un backup che puoi ripristinare tu, subito, fatto un minuto prima di cominciare.

La compatibilità, dove WordPress la mostra già

Prima di aprire siti esterni conviene guardare Bacheca > Aggiornamenti. Per ogni plugin da aggiornare c’è una riga del tipo “Compatibilità con WordPress 7.1.2: sì (secondo l’autore)” oppure “non verificata”, e quando è in sospeso anche un aggiornamento del core le righe diventano due, una per la versione installata e una per quella in arrivo. Il dato viene dal campo “Testato fino alla versione” che l’autore dichiara, quindi “non verificata” vuol dire che non l’ha provato.

Due controlli la bacheca li fa da sola, in momenti diversi. Se l’aggiornamento richiede una versione di PHP più recente della tua, il plugin non si può selezionare e la riga dice “Questo aggiornamento non funziona con la tua versione di PHP.”

Se invece richiede una versione di WordPress più recente, la schermata non avvisa. L’ho provato con un plugin che dichiarava WordPress 99.0. La casella c’era, l’aggiornamento è partito e solo allora è arrivato “C’è stato un errore durante l’aggiornamento di Prova aggiornamento: La tua versione di WordPress è 7.1.2, ma la nuova versione del plugin richiede la 99.0.”, con il plugin lasciato alla versione di prima.

In quel caso si aggiorna prima il core.

Sulla scheda del plugin in it.wordpress.org le stesse informazioni stanno nel riquadro a lato (Versione WordPress, Testato fino alla versione, Versione PHP), con un segnale in più. Quando un plugin non è stato provato con le ultime tre major, in cima alla pagina compare l’avviso “Questo plugin non è stato testato con le ultime 3 versioni principali (major releases) di WordPress”.

Il changelog si legge invece senza uscire dalla bacheca, dal link “Visualizza i dettagli della versione” accanto a ogni aggiornamento, ed è lì che capisci se si tratta di una correzione di sicurezza da installare subito o di una novità che può aspettare.

Fra i prerequisiti c’è anche l’ambiente. La versione di PHP ancora supportata, gli aggiornamenti minori automatici e i plugin inutilizzati da disinstallare sono i primi tre controlli della checklist di sicurezza.

Un’ultima verifica riguarda il tema. L’aggiornamento sostituisce l’intera cartella, quindi se hai modificato i suoi file direttamente le modifiche spariscono. Prima di procedere spostale in un child theme.

Uno staging che non ti tradisca

Uno staging è una copia del sito dove provi l’aggiornamento prima di farlo su quello vero. Serve per le major, per i plugin grossi o che toccano pagamenti ed editor, e per i salti di più versioni. Per una minore del core o per la correzione di un plugin semplice è più lavoro che protezione.

Si prepara in tre modi. Se il pannello del tuo hosting ha una funzione di staging, è la strada più corta. Con un plugin, la versione gratuita di WP STAGING (4.15.1) clona il sito in una sottocartella, visibile solo agli amministratori e fuori dai motori di ricerca; riportare le modifiche sul sito vivo è una funzione della versione Pro. A mano si copiano file e database su un sottodominio e si dice a WordPress il suo nuovo indirizzo, con due righe nel wp-config.php della copia.

// Nel wp-config.php della copia, sopra la riga "Finito, interrompere le modifiche!"
define( 'WP_HOME', 'https://staging.tuosito.it' );
define( 'WP_SITEURL', 'https://staging.tuosito.it' );

Nei siti installati dal pacchetto inglese la riga di riferimento è “That’s all, stop editing!”.

Le due costanti vincono sul database, che resta com’è. Nella prova home_url() restituiva l’indirizzo della copia, mentre nel database restava quello del sito vero. I link scritti dentro gli articoli, però, puntano ancora al sito vero. Per una copia completa gli indirizzi vanno sostituiti in tutto il database, e lì la trappola sono i dati serializzati, spiegata nella guida su come cambiare gli indirizzi senza rompere i dati serializzati.

Una copia di prova può tradirti in tre modi. Può finire nei motori di ricerca, se nessuno la protegge, e la soluzione più solida è una password chiesta dal server, la stessa che serve per tenere la copia fuori dai motori di ricerca e dagli estranei.

Può mandare email vere, perché ha gli stessi utenti, ordini e plugin del sito. WooCommerce Subscriptions, per esempio, quando si accorge che l’indirizzo è cambiato smette di incassare i rinnovi in automatico e di mandare le sue email, ma la sua documentazione avverte che quelle di WordPress, di WooCommerce e degli altri plugin possono partire lo stesso.

Infine usa le chiavi del sito vero per parlare con i servizi esterni, dai pagamenti alle newsletter.

Quando la prova è andata bene, l’aggiornamento si rifà sul sito vero. Copiare il database dello staging sopra quello del sito cancellerebbe tutto quello che è arrivato nel frattempo, dagli ordini ai commenti. Tutto quello che una copia eredita dal sito vero, e come si spegne prima di aprirla, l’ho messo in fila in una guida a parte.

Durante l’aggiornamento: in che ordine, e cosa fa WordPress

L’ordine giusto

Quando aggiorna da solo, WordPress segue un ordine fisso: prima i plugin, poi i temi, poi il core e per ultime le traduzioni. Sta scritto nel codice dell’aggiornamento automatico, e a mano conviene seguire la stessa logica. Così il core nuovo trova ogni plugin alla sua versione più recente, la più probabile a essere stata provata con lui, e se l’autore l’ha provata lo dice la riga sulla compatibilità.

Le traduzioni vengono dopo i componenti che traducono.

La bacheca introduce due eccezioni, e te le segnala lei. Se il core nuovo richiede un PHP più recente del tuo, l’aggiornamento non parte (“Non puoi eseguire l’aggiornamento perché WordPress 7.1.2 richiede la versione di PHP 7.4 o superiore”), e allora PHP si aggiorna per primo, dal pannello dell’hosting, dopo aver controllato che plugin e tema lo reggano. Se un plugin chiede una versione di WordPress più recente della tua, il suo aggiornamento si fa dopo quello del core.

Uno alla volta o tutti insieme? Per le correzioni di routine il pulsante che li aggiorna in gruppo va bene, purché dopo controlli il sito. Per una major, per un plugin che cambia versione principale o che tocca pagamenti ed editor, meglio uno alla volta, con un’occhiata al sito fra l’uno e l’altro.

Se qualcosa si rompe, sai già quale è stato.

Con WP-CLI

Con l’accesso SSH la stessa sequenza si fa da riga di comando, con un’anteprima prima di toccare qualcosa. I comandi sono quelli della documentazione di WP-CLI. Li ho eseguiti uno per uno su un sito di prova che aveva in sospeso un aggiornamento del core, uno di un plugin e uno di un tema.

# Cosa c'è da aggiornare, e cosa si aggiorna già da solo
wp core check-update
wp plugin list --update=available
wp plugin auto-updates status --all

# Anteprima: cosa verrebbe aggiornato, senza toccare niente
wp plugin update --all --dry-run
wp theme update --all --dry-run

# Plugin e temi uno alla volta, controllando il sito dopo ciascuno
wp plugin update nome-del-plugin
wp theme update nome-del-tema

# Poi il core e il suo database, per ultime le traduzioni
wp core update
wp core update-db
wp language core update
wp language plugin update --all
wp language theme update --all

# Alla fine, i file del core confrontati con quelli ufficiali
wp core verify-checksums

L’opzione --dry-run elenca senza installare. wp core update-db fa l’aggiornamento del database che altrimenti WordPress chiede alla prima visita della bacheca, e se il database è già a posto lo dice e si ferma. L’ultimo comando confronta i file del core con quelli pubblicati su WordPress.org, e un file diverso va guardato, perché non è quello che è stato pubblicato.

Cosa succede mentre aggiorna

Durante l’aggiornamento WordPress mette il sito in manutenzione da solo, con un file .maintenance nella cartella principale, e lo toglie alla fine. Chi visita il sito in quei secondi riceve un codice 503 e una pagina con scritto “Briefly unavailable for scheduled maintenance. Check back in a minute.”, in inglese anche su un sito in italiano, perché il messaggio viene stampato prima che WordPress legga la lingua dal database.

Esce in italiano (“Momentaneamente non disponibile per manutenzione. Riprova fra un minuto.”) quando la lingua è nota prima, come nelle installazioni fatte con il pacchetto italiano di it.wordpress.org. Non c’è niente da attivare o da spegnere.

Dalla 6.3, prima di sostituire un plugin o un tema, WordPress sposta la versione installata in wp-content/upgrade-temp-backup e la rimette al suo posto se l’installazione fallisce, per esempio per un errore nella copia dei file o perché è finito il tempo concesso a PHP. Se l’installazione riesce, la copia viene cancellata. Non serve quindi a tornare indietro da una versione installata bene che poi non funziona, e la nota per sviluppatori della 6.3 rimanda quel controllo a una fase successiva, per i soli aggiornamenti automatici.

Per quel caso i comportamenti sono due, a seconda di chi aggiorna. Quando aggiorni tu, con “Aggiorna ora” in Plugin installati o con “Aggiorna plugin” in Bacheca > Aggiornamenti, WordPress non controlla niente. Nella prova ho aggiornato un plugin attivo a una versione che va in errore fatale: la bacheca ha risposto che l’aggiornamento era riuscito, il plugin è rimasto attivo e la home ha cominciato a rispondere con un errore 500.

Negli aggiornamenti automatici, dalla 6.6, il controllo c’è. Dopo aver aggiornato un plugin attivo, WordPress apre la home del sito con una richiesta a sé stesso e, se trova un errore fatale, rimette la versione precedente e lo scrive nell’email. Il meccanismo è descritto nella proposta con cui è entrato nel core, e guarda solo gli errori fatali, solo la home e solo i plugin attivi. L’ho provato in quattro casi.

Il terzo caso succede quando il server non riesce a raggiungere sé stesso, una condizione che Salute del sito controlla nella voce sulle richieste di loopback. Il quarto quando qualcosa davanti a WordPress, un firewall o una password chiesta dal server, risponde al suo posto. WordPress non vede l’errore, e nell’email scrive che non è richiesta alcuna altra operazione. In entrambi i casi l’avviso affidabile resta guardare il sito.

La stessa proposta scrive che un plugin aggiornato a mano che va in errore non viene riattivato. Vale solo per la procedura senza JavaScript, che la bacheca usa quando JavaScript è spento e che disattiva il plugin prima di aggiornarlo. Con i pulsanti di tutti i giorni il plugin resta attivo, come nella prova.

Per il core una protezione simile esiste dalla 3.7: se la copia dei file di un aggiornamento automatico non va a buon fine, WordPress prova a reinstallare la versione di prima.

Se WordPress ti chiede le credenziali FTP

Se al momento di aggiornare WordPress chiede le credenziali FTP, quella finestra è la diagnosi di un problema diverso. Significa che l’utente con cui gira PHP non è il proprietario dei file del sito, o non può scriverci, e finché resta così ogni aggiornamento dal backend passerà da lì. Gli aggiornamenti automatici, in quella situazione, non partono proprio, e Salute del sito lo scrive: “L’installazione di WordPress richiede le credenziali di accesso FTP per eseguire gli aggiornamenti.”

Si risolve una volta sola, sistemando proprietario e permessi dei file.

I controlli da fare dopo

Subito dopo l’aggiornamento, in quest’ordine.

• Svuota le cache, quella del plugin, quella del server e quella della CDN se ce l’hai. La procedura ufficiale lo chiede a lavoro finito, perché altrimenti i visitatori, e tu con loro, continuano a vedere la versione di prima.
• Guarda il sito da visitatore, in una finestra anonima. Un plugin in errore fatale mostra ai visitatori “Si è verificato un errore critico sul tuo sito web.” e, finché nessuno apre la bacheca o la pagina di login, non parte nessuna email.
• Prova le funzioni che portano contatti o vendite, come un modulo, il carrello con il pagamento e il login.
• Controlla in Plugin installati che i plugin attivi prima lo siano ancora.
• Leggi le email che WordPress ha mandato, sia l’esito degli aggiornamenti automatici sia, se c’è, quella intitolata “ha un problema tecnico”.
• Apri Strumenti > Salute del sito e guarda le voci sugli aggiornamenti in background, sulle richieste di loopback e sugli eventi programmati. Se un aggiornamento automatico del core è finito con un errore critico lo trovi scritto lì, e gli aggiornamenti automatici restano spenti finché non aggiorni a mano con “Aggiorna ora”.
• Se hai WP-CLI, oltre al confronto dei file del core con cui chiude il blocco di prima, lancia wp plugin verify-checksums --all per i plugin della directory. Salta i plugin commerciali e non può accorgersi di una versione malevola pubblicata nel repository, che per il confronto è l’originale. Sono i limiti del confronto dei file, spiegati nella guida sugli attacchi alla catena di fornitura.
• Guarda il log degli errori PHP, se lo tieni attivo. Un avviso che prima non c’era viene dall’aggiornamento, e il percorso del file nella riga dice di chi è.

Se, già che ci sei, vuoi fare ordine fra revisioni, transient e dati lasciati da plugin che non ci sono più, come farlo senza rompere niente è in come ripulire un sito WordPress.

Se qualcosa si rompe, come si torna indietro

Dopo un aggiornamento i guasti più comuni si riconoscono da tre messaggi e da un sintomo, e per ognuno c’è una strada.

“Briefly unavailable for scheduled maintenance”, o il suo equivalente in italiano. Un aggiornamento si è interrotto e ha lasciato il file .maintenance. Dopo dieci minuti WordPress lo ignora da solo e il sito riparte, ma l’aggiornamento può essere rimasto a metà. La documentazione ufficiale dice di cancellare il file via FTP e, se l’aggiornamento con un clic continua a non riuscire, di farlo a mano.

“Attualmente è in corso un altro aggiornamento.” WordPress blocca un secondo aggiornamento del core mentre ne gira uno, per quindici minuti. Passato quel tempo il blocco si libera da solo al tentativo successivo. Se non puoi aspettare, con WP-CLI si controlla e si toglie, dopo aver verificato che nessun aggiornamento stia girando (nel blocco più sotto).

“Si è verificato un errore critico sul tuo sito web.” Un plugin o il tema vanno in errore fatale. Da una pagina vista da un visitatore non parte nessuna email. Parte quando l’errore avviene sulla pagina di login o in bacheca, e allora l’amministratore riceve “Il tuo sito […] ha un problema tecnico”, con un link per entrare in modalità di recupero valido un giorno.

In modalità di recupero il componente rotto è messo in pausa solo per te: puoi entrare in bacheca, disattivarlo o rimettere la versione di prima, mentre per tutti gli altri il sito resta in errore finché non lo sistemi.

Un plugin funziona male dopo l’aggiornamento. Si torna alla versione precedente, il tempo di aspettare la correzione. Per i plugin della directory, la scheda su it.wordpress.org ha una “Visualizzazione avanzata” con le versioni precedenti da scaricare, e la directory stessa avverte che non sono raccomandate in produzione. Con WP-CLI basta un comando, che funziona anche quando il plugin impedisce a WordPress di partire.

# Rimettere la versione precedente di un plugin del repository.
# --skip-plugins serve quando è proprio quel plugin a impedire a WordPress di partire.
wp plugin install nome-del-plugin --version=1.2.3 --force --skip-plugins=nome-del-plugin

# "Attualmente è in corso un altro aggiornamento": il blocco del core dura 15 minuti.
# Prima di cancellarlo, controlla che nessun aggiornamento stia girando davvero.
wp option get core_updater.lock
wp option delete core_updater.lock

Nella prova, con un plugin reso volutamente rotto, WP-CLI senza --skip-plugins si fermava con lo stesso errore critico del sito. Con l’opzione ha reinstallato la versione precedente e il sito è tornato a rispondere.

Per un tema della directory il comando è lo stesso, con theme al posto di plugin e --skip-themes al posto di --skip-plugins. Nella prova il tema attivo è tornato alla versione precedente ed è rimasto attivo.

Per plugin e temi commerciali dipende dal fornitore.

Per il core la documentazione ufficiale sconsiglia di tornare indietro, perché le versioni nuove contengono spesso correzioni di sicurezza e la struttura del database cambia da una versione all’altra. Se serve comunque, si fa con il backup, ripristinando insieme tutti i file e il database.

Per gli errori che non nascono da un aggiornamento, come si diagnostica un errore ha una guida in calendario.

Se gestisci più siti

Con più siti lo stesso giro va fatto ovunque, e servono strumenti che lo facciano da un posto solo. Il primo è WP-CLI. Con gli alias, che la guida di WP-CLI ai comandi da remoto insegna a registrare con l’accesso SSH di ciascun sito, lo stesso comando parte su tutti insieme con @all, per esempio wp @all plugin list --update=available. Nella prova ha risposto sito per sito, con il nome dell’alias sopra ogni elenco. Poi ci sono i pannelli che controllano molti siti insieme, di due tipi. MainWP (6.2.1) lo installi tu, su un WordPress tuo, ed è open source. ManageWP è un servizio esterno, gratuito per gli aggiornamenti su un numero illimitato di siti. La funzione che prima di ogni aggiornamento crea un punto di ripristino, controlla il sito e torna indietro se qualcosa va storto si chiama Safe Updates, e richiede il suo backup a pagamento (condizioni lette il 1° ottobre 2026).

C’è poi un dettaglio che può cambiare la scelta. Quando un autore pubblica un aggiornamento con il rilascio graduale, WordPress.org chiede ai siti di aspettare 24 ore prima di installarlo da soli. I siti con WordPress 6.6 o successivo lo rispettano; degli strumenti esterni, scrive il team dei plugin, non si sa se lo facciano.

Domande frequenti

Da qui in avanti

Un aggiornamento fatto bene si riconosce da quello che non succede. Nessun visitatore vede un errore prima di te, nessun plugin resta a metà, nessuna email passa inosservata.

Ci si arriva con un backup provato, con la compatibilità letta prima, con l’ordine che usa WordPress e con il giro di controlli dopo. Se vuoi che gli aggiornamenti stiano dentro una routine, insieme ai backup e ai controlli periodici, parti da un piano di manutenzione.

Una versione precedente di questo articolo conteneva tre indicazioni sbagliate, corrette qui sopra. Presentava Wordfence come un plugin che blocca gli aggiornamenti dei plugin con vulnerabilità note, mentre segnala i plugin vulnerabili e sugli aggiornamenti non interviene. Indicava come automatiche solo le versioni minori del core, mentre sui siti installati dalla 5.6 in poi lo sono di default anche le major. Consigliava infine di disattivare i plugin di cache prima di aggiornare, mentre la procedura ufficiale chiede di svuotare la cache dopo.

Se preferisci che lo faccia io

Seguire gli aggiornamenti di un sito, con la prova sulla copia, l’ordine giusto, i controlli dopo e un backup pronto se qualcosa va storto, è il lavoro che descrivo nella pagina su come seguo gli aggiornamenti dei siti che mi affidano. Se vuoi che me ne occupi io, contattami e raccontami com’è messo il tuo sito.