Aggiornamenti WordPress: farli senza rompere il sito nel 2026

Quella volta che un “Aggiorna tutto” mi è costato un weekend

Venerdì. 18:47. Novembre 2023.

Mi arriva un vocale su WhatsApp. Cliente con WooCommerce — 1.800 ordini al mese, mica noccioline — e in sottofondo sento il panico: “ho cliccato Aggiorna tutto e ora è tutto bianco”.

Apro il sito. Bianco. Apro wp-admin. Bianco pure quello. 500 secco.

Nessun backup decente degli ultimi 11 giorni. Aveva cliccato davvero su tutto: 23 plugin in un colpo solo, più il core da 6.3 a 6.4. Quale aveva rotto tutto? Boh. Impossibile saperlo così, alla cieca.

Ci ho messo — giuro — 7 ore spalmate tra sabato e domenica a rimetterlo in piedi. FTP, file per file, disattiva questo, riattiva quello, prova, ricarica. Il cliente? Due giorni di vendite perse. Circa 2.400 euro volatilizzati. E la mia domenica? Andata.

Da quel giorno ho una regola che non mollo più. Semplice, quasi stupida se vuoi: mai più “Aggiorna tutto”. Mai di venerdì. E mai senza una procedura scritta, punto.

È la stessa procedura che uso oggi su oltre 200 siti. Ed è esattamente quella che sta dietro alla mia assistenza WordPress. Te la racconto come la racconterei a un amico davanti a un caffè — senza filtri — perché qui la differenza non è tra “aggiornato” o “non aggiornato”. È tra stare online e rovinarti il weekend.

Perché gli aggiornamenti rompono il sito (e no, non è colpa di WordPress)

WordPress, da solo, è stabile. Te lo dico dopo anni che ci lavoro: il core regge.

Quello che spacca tutto è il contorno. Ogni sito è un incastro diverso — core + tema + 20 plugin + versione PHP + hosting che magari fa di testa sua. Aggiornare è come cambiare una ruota mentre l’auto è in corsa. Se sbagli ordine… salta.

I tre motivi che vedo sempre — sempre — in ordine di frequenza:

1. Plugin vs core. Il classico. Aggiorni a WordPress 7.0 e un plugin è rimasto fermo al 2021. Non regge PHP 8.3. Boom, fatal error. L’ho visto a febbraio con un page builder che non veniva aggiornato da tre anni. Il cliente nemmeno lo sapeva.

2. Tema fermo.ThemeForest, comprato nel 2019, mai più toccato. Richiama una funzione che non esiste più. Schermata bianca. Ne ho contati 14 solo nel 2024. Quattordici, dico.

3. PHP. Eh, il PHP… c’è chi è ancora inchiodato al 7.4 — nel 2026, ti rendi conto? — e chi invece salta di botto a 8.3 senza testare nulla. In entrambi i casi esplode metà roba. E a volte è l’hosting stesso che aggiorna di notte senza avvisarti. Bello, no?

E poi c’è il quarto motivo. Quello che nessuno dice ma è il più comune: la fretta. Aggiorni di venerdì sera, 5 minuti prima di cena, senza backup, senza staging. Otto siti su dieci che mi arrivano rotti sono così. Non è un bug. È fretta e basta.

Se il tuo sito è fermo da mesi e hai paura anche solo a cliccare “Aggiorna” — ti capisco, davvero. È normale. Proprio per questo esiste un servizio di assistenza WordPress professionale che fa tutto in staging, con backup veri. Così tu non rischi.

Il backup. Quello vero, non quello finto

Sembra banale, lo so. E invece no. Ti dico solo questo: il 60% dei backup che trovo quando arrivo su un sito nuovo… non si ripristina. Non parte proprio.

Perché?

• Sta sullo stesso server del sito. Se va giù l’hosting, ciao. Hai perso anche il backup. Complimenti.
• Non è mai stato aperto. Mai testato. Scopri che è vuoto quando ti serve. Mi è successo nel 2022: file da 4,2 GB, lo apro… cartella uploads vuota. Vuota!
• Manca il database. Ripristini i file e… dov’è il contenuto? Non c’è. Solo struttura.

La mia regola — quella che applico su ogni sito in assistenza continuativa — è noiosa, lo ammetto. Ma funziona, ed è noiosa apposta:

1. Backup completo, file + database. Ogni volta. Non “quando mi ricordo”. Ogni volta che tocco qualcosa.
2. Copia remota, cifrata, fuori dal server. Fuori. Come lo faccio l’ho scritto qui passo-passo: backup criptato su server remoto. Due minuti in più, ti salva due giorni di madonne.
3. Verifica. Scaricalo. Aprilo. Guarda dentro il .sql, scorri due righe. Se è vuoto lo vedi subito, non quando è tardi.

I comandi che uso io da terminale — senza plugin, senza fronzoli, quelli che non tradiscono mai:

wp db export backup_$(date +%F).sql
wp db size --tables
tar -czf files_$(date +%F).tar.gz wp-content --exclude=wp-content/cache

Non hai SSH? Usa pure quello che ti dà l’hosting, ok. Ma poi — ti prego — scarica il file e aprilo sul tuo PC. Se non lo apri, non è un backup. È una speranza. E le speranze non ripristinano siti, i file sì.

Lo staging: l’unico posto dove puoi permetterti di sbagliare

Aggiornare direttamente in produzione? Guarda, è come provare il paracadute saltando dall’aereo. Magari va bene. Ma se va male…

Oggi quasi tutti gli hosting decenti hanno lo staging in un clic. Se il tuo non ce l’ha — mah. Fatti una domanda, ecco.

Come lavoro io in staging? Te lo dico papale:

Clono produzione → staging. Stesso PHP, stessi plugin, stesso tema. Identico, non “simile”. Poi aggiorno UNA cosa alla volta. Una. Ricarico. Controllo. Poi la successiva. Mai “Aggiorna tutto”.

Il mio errore — 2021, non lo dimentico — 23 plugin insieme. “Ma tanto sono minori, che vuoi che sia”. Ecco, uno di quelli “minori” aveva una dipendenza JS e mi ha segato il carrello di brutto. Da allora? Uno alla volta. Sembra lento? È 4 volte più veloce che riparare un sito bianco alle 23 di sabato con il cliente che ti scrive ogni 5 minuti.

E se proprio non hai staging — almeno fai così: backup + modalità manutenzione + un plugin alla volta, testa, poi il prossimo. Non c’è scorciatoia furba. Davvero, non cercarla.

La sequenza che uso io — su 200+ siti, da due anni, sempre uguale

Non è teoria da blog. È la sequenza che mi ha evitato l’80% dei rollback. Nell’ordine, così com’è. Non cambiarla.

1. Controllo preliminare (5 minuti, cronometro alla mano)

wp core verify-checksums
wp plugin verify-checksums --all
wp plugin list --status=active --field=name
php -v

Se verify-checksums ti dice che dei file del core sono modificati… fermati. Subito. Qualcuno ha toccato roba, o peggio: c’è codice iniettato. A novembre ho pulito un sito con 47 backdoor — il primo segnale è stato proprio il checksum fallito. L’ho raccontato nella guida su WordPress hackerato.

2. Core — solo se serve davvero, non per sport

Non aggiorno a ogni minor se il sito è sotto promo e sta vendendo. Ma le patch di sicurezza? Sempre. Subito, senza se e senza ma. Dalla 6.4 in poi WordPress spinge forte su PHP 8.2+, quindi prima guardo se il tema regge. Altrimenti sono guai.

3. Tema — occhio ai premium fermi lì da anni

Tema premium? Verifica che l’autore abbia scritto nero su bianco “compatibile con WP 7.0”. Se l’ultimo update è del 2020… lascia perdere, prima testiamo in staging. Ho visto temi andare in fatal per una funzione rimossa da anni. Un classico, purtroppo.

4. Plugin — uno alla volta, senza fretta (lo ripeto apposta)

Parto dai critici: cache, sicurezza, SEO, page builder. Poi gli altri, i secondari. Dopo ognuno — ognuno eh, non ogni tre:

• Ricarico home, una pagina interna, wp-admin. Tre ricariche, 20 secondi.
• Guardo i log: tail -n 50 wp-content/debug.log (se hai il debug attivo, sennò attivalo al volo, non fa male)
• Se c’è WooCommerce — ordine di test da 1€. Sempre. Ci metti 30 secondi e ti evita resi e bestemmie il giorno dopo.

5. Pulisci? Sì, ma con la testa, non con la mannaia

Dopo gli update il database si gonfia — transient scaduti, autoload… Ma per favore, non usare plugin “pulisci tutto” a caso. L’ho fatto nel 2019. Una volta sola. Ho cancellato le impostazioni della cache e il sito è andato in loop per un’ora. Mai più, ho imparato.

Ora pulisco solo quello che conosco, a mano. E poi controllo la velocità — un update può raddoppiare le query senza che te ne accorga. Le 12 cause vere di lentezza le ho messe qui, nero su bianco: sito WordPress lento. Se il TTFB passa da 320ms a 1,4s… ecco il colpevole, è lì.

6. Backup post-aggiornamento — quello che tutti dimenticano

Tutto ok? Verificato? Funziona? Bene. Ora rifai il backup. Subito. Così se domani qualcosa va storto, torni al “dopo update buono”, non al “prima”. Sembra una cavolata? Ti salva la vita, credimi.

I 9 errori che vedo ogni settimana — e quanto ti costano (in euro veri)

Te li elenco secchi, senza giri. Sono quelli che mi portano più lavoro in assistenza WordPress. E sono tutti — tutti — evitabili.

1. Aggiornare di venerdì sera. Il classico dei classici. Va giù sabato, lo scopri lunedì. Un cliente perse 4.200€ in un weekend del 2022. Non farlo. Mai di venerdì.

2. “Aggiorna tutto” e chiudi il tab. Se si rompe, quale è stato? Non lo saprai mai. E il rollback diventa un rebus infinito.

3. Backup mai testato. Quando serve, scopri che è vuoto. Ho dovuto ricostruire a mano un blog di 600 articoli. 600. A mano.

4. Plugin nulled, craccati. Risparmi 49€, ti porti dentro una backdoor che dorme mesi — poi si sveglia. Ne ho tolte 47 da un solo sito. 47! Ne ho parlato qui: plugin piratati e sicurezza.

5. PHP ignorato. Restare al 7.4 nel 2026 è girare con gomme lisce sulla neve. Ma saltare a 8.3 senza testare? Peggio ancora.

6. “Funziona, quindi è a posto”. Il malware sa stare zitto, è furbo. Ho trovato backdoor ferme 14 mesi, si sono riattivate proprio dopo un update che ha risvegliato un plugin dormiente. Silenziose, subdole.

7. Niente manutenzione. Aggiorni mentre uno sta pagando… carrello in errore, cliente perso. Due minuti di modalità manutenzione ti evitano il danno. Due minuti.

8. Changelog non letto. “Fix sicurezza” = aggiorna subito, di corsa. “Rifattorizzato template” = testa in staging, con calma, con caffè.

9. 35 plugin di cui 12 inutili. Ogni plugin è un debito che paghi. Su un sito ne ho tolti 19 (da 47!) e il tempo di risposta è passato da 1,8s a 420ms. Meno roba, meno rotture. Punto e basta.

Quando ha senso fare da solo — e quando invece chiamarmi

Te lo dico dritto, senza venderti fumo. Perché ci vivo, su sta roba, ogni giorno.

Sito vetrina, 10 pagine? Fallo da solo, davvero. La procedura sopra la impari in un pomeriggio, ti basta un backup decente. Non hai bisogno di me, e te lo dico onestamente.

Ma se il sito è il tuo lavoro — e-commerce, prenotazioni, lead che pagano le ads — cambia tutto. Ogni ora offline costa, ogni update sbagliato è un rischio che non puoi permetterti. E tu non hai il riflesso che ho io: io in 30 secondi capisco se è un conflitto cache/page builder perché l’ho già visto 40 volte. Tu no, ed è normalissimo.

Di solito mi chiamano quando:

• hanno già rotto una volta e non vogliono riviverlo (trauma, comprensibile, ci sono passato anch’io dall’altra parte)
• non sanno cos’è uno staging o un checksum — e non hanno voglia di impararlo, giustamente
• hanno un tema premium vecchio e hanno paura anche solo a toccarlo
• hanno ereditato un sito da un ex fornitore: 47 plugin, zero documentazione, zero spiegazioni. Il classico pacco.

In quei casi delegare costa meno di un giorno fermo. Non lo dico per vendere — lo dico con i numeri, quelli veri: un intervento di assistenza WordPress per aggiornamenti e ripristino sta tra 80 e 250€. Un weekend offline di un e-commerce medio? Tra 1.000 e 5.000. Fai due conti e dimmi tu.

Come lavoro quando seguo un sito in continuativa

Niente pacchetti finti bronze/silver/gold uguali per tutti. Ogni sito ha una storia diversa, dai. Ma il metodo è sempre lo stesso, quello non cambia:

1. Monitoraggio 24/7 su file e login. Se qualcuno tocca wp-config.php alle 3 di notte, lo so alle 8, non tra due settimane quando è troppo tardi.
2. Backup giornaliero testato, due destinazioni. Uno locale, uno remoto cifrato. Come da guida backup, testato davvero, non “finto”.
3. Aggiornamenti in staging, mai di venerdì. Uno alla volta, verificati. No fretta, no scorciatoie.
4. Report mensile in italiano normale. Cosa ho fatto, cosa ho trovato, cosa conviene fare. Senza fuffa tecnica incomprensibile che non capisce nessuno.

È lo stesso approccio che racconto nella pagina sull’importanza di avere un supporto WordPress: paghi meno se mi chiami prima, non dopo che è esploso tutto. E se devi ancora partire, partire da una creazione fatta bene — hosting giusto, plugin essenziali — ti evita metà dei casini futuri. Te lo assicuro, l’ho visto 100 volte.

Checklist — stampala, tienila aperta quando aggiorni

Nell’ordine, senza saltare pezzi — davvero, non saltarne uno:

1. Backup completo + aprilo, verifica che non sia vuoto (guardaci dentro)
2. Metti in manutenzione (anche 2 minuti, bastano e avanzano)
3. Checksum + versione PHP (i due comandi sopra)
4. Aggiorna: core → tema → plugin (uno alla volta! lo ripeto)
5. Ricarica home, pagina interna, wp-admin, checkout se c’è
6. Guarda log + performance (TTFB sotto 600ms con cache, sennò indaga)
7. Backup post-aggiornamento (quello che tutti dimenticano)
8. Togli manutenzione, controlla da mobile — sì, dal telefono vero

Se al punto 5 vedi bianco o 500 — fermati. Non insistere. Non cliccare di nuovo “aggiorna” sperando che si sistemi da solo (non succede mai). Ripristina il backup di prima e analizziamo in staging quale plugin è il colpevole. Il comando che ti salva la vita in quel momento:

wp plugin deactivate --all
wp plugin activate --all --exclude=plugin-sospetto

Niente SSH? Via FTP rinomina wp-content/plugins/nome-plugin in nome-plugin-off e ricarica. Torna su nel 90% dei casi, te lo dico per esperienza.

Conclusione — aggiornare è obbligatorio, rompere è facoltativo

WordPress va aggiornato. Non è un consiglio da blogger per fare contenuto, è sicurezza. Punto. Ma tra “aggiornato” e “rotto” c’è una procedura. Quella sopra è la mia — testata su 200+ siti, con errori pagati prima io, così non li paghi tu.

Puoi impararla e farla da solo. Oppure fare come i miei clienti in assistenza WordPress continuativa: mi lasci la rogna, tu pensi al tuo lavoro, io penso al resto. Entrambe le strade vanno benissimo, davvero.

L’unica sbagliata è la terza: non aggiornare mai sperando che “tanto non succede niente”. Succede. Eccome se succede. E quando succede, costa sempre — sempre — più di un aggiornamento fatto bene. Fidati.