Update fatti in fretta sono la prima causa di siti rotti per giorni. Lavoriamo con un process disciplinato: staging, test funzionale, deploy con rollback automatico se qualcosa va storto.
Inclusi in Manutenzione (da 79€/mese), spot da 99€
Il problema reale
Il cliente clicca 'aggiorna tutto' dalla bacheca, qualcosa va storto, il sito è offline. Niente backup, niente staging, niente idea di cosa abbia rotto cosa. Recovery panico, ore o giorni di down.
Update fatto direttamente in produzione
Click su 'aggiorna' dalla bacheca, plugin incompatibile col PHP attuale, sito che torna errore 500. Il cliente non sa quale dei tre plugin aggiornati abbia rotto il sito.
Niente backup pre-update
Il cliente assume che l'hosting faccia backup automatico (spesso non è vero), o che i backup esistenti siano utilizzabili (spesso non lo sono). Recovery diventa un terno al lotto.
Plugin con dipendenze nascoste
Plugin A richiede versione 3.x di plugin B. Aggiornando B alla 4.0 si rompe A. Niente in WordPress segnala questa dipendenza prima dell'update.
Update saltati per anni
Cliente che ha paura di toccare i plugin perché 'l'ultima volta si è rotto tutto'. Risultato: 2 anni di vulnerabilità accumulate, attaccanti che scansionano e trovano CVE noti.
Il nostro metodo
Aggiornare WordPress non è 'cliccare aggiorna'. È un process: pre-check, backup, staging, test, deploy, verify. Niente di tutto questo è opzionale, perché ogni passaggio saltato è un rischio. La regola è: se non sai come tornare indietro, non andare avanti.
Prima di qualsiasi update, leggiamo i changelog. Breaking changes nel core? Plugin che richiedono PHP 8.x mentre il server è 7.4? Dipendenze incrociate? Ogni rischio noto va valutato prima dell'update, non dopo.
Backup completo file + database, verificato (non solo creato) prima di toccare qualsiasi cosa. Se il backup è corrotto, l'update si ferma. Niente eccezioni.
Se esiste staging, l'update va lì per primo. Test funzionale: login, frontend, ricerca, checkout, form. Solo se tutto è verde, si deploya in produzione. Lo staging non è un lusso, è il modo per non avere sorprese.
In produzione, deploy fatto in modo che il rollback sia immediato (snapshot pre-deploy, branch git, ecc.). Se nei primi 15 minuti dopo il deploy qualcosa non va, si rolla back senza pensarci.
Il sito risponde 200 sulla home? OK ma non basta. Login admin funziona? Form di contatto invia? Checkout completa un ordine di test? Ricerca interna ritorna risultati? Solo dopo questa lista, l'update è chiuso.
Come si svolge
Lettura changelog, verifica compatibilità PHP/MySQL, identificazione dipendenze fra plugin, individuazione rischi noti.
Backup completo file e database, verificato (test estrazione campione). Se il backup è corrotto, l'update si ferma.
Sincronizzazione staging col live, applicazione degli update, test funzionale. Se qualcosa rompe, rollback su staging e analisi.
Replica controllata su produzione: stesse versioni, stessa sequenza. Snapshot pre-deploy armato per rollback immediato.
Verifica login admin, frontend, form, checkout (se WooCommerce), ricerca, performance baseline. Confronto con stato pre-update.
Riassunto di cosa è stato aggiornato, eventuali note operative (es. plugin X richiede ora reCAPTCHA v3), prossimi update raccomandati.
Cosa ricevi
Core, plugin, temi alle versioni attuali, con verifica funzionale completata. Documentato cosa è stato aggiornato.
Snapshot del sito pre-update conservato per 30 giorni, disponibile per ripristino se serve.
Documento per il cliente: cosa è stato aggiornato, cosa è cambiato in user-experience (se rilevante), eventuali piccole differenze visive da notare.
Plugin che vanno valutati per sostituzione (abbandonati o pesanti), piani di update futuri (es. quando passare a PHP 8.3).
FAQ
Risposte concrete sulle modalità di lavoro, garanzie reali e limiti tecnici di questo servizio.
Pronto a partire?
Apri la chat con Bob o richiedi un'analisi tecnica iniziale. Mappiamo lo stato del tuo stack e ti diciamo cosa va aggiornato e in che ordine.
Servizi correlati
Strategia 3-2-1 applicata, test mensile di ripristino, documentazione recovery. Avere backup non basta: serve sapere che funzionano.
Scopri il servizioPartner tecnico per agenzie che gestiscono portafogli WordPress. SLA dedicati, audit periodici, escalation tecnica white-label.
Scopri il servizio