Una pubblicazione sbagliata di un sito statico di solito non sembra subito un incidente grave. Una pagina resta bianca. Il CSS non viene caricato. Un'immagine finisce in 404. Un PDF punta al file sbagliato. Una landing page va online con il testo non approvato.
Il rischio cresce quando il team prova a correggere la produzione mentre il link è già in giro.
Per un sito statico, la strada più sicura è spesso questa: ripristinare prima l'ultima versione funzionante, poi analizzare la pubblicazione rotta quando i visitatori non la stanno più vedendo.
Il rollback serve quando il link pubblico è davvero compromesso
Non ogni errore richiede un rollback. Un refuso minore può essere corretto con un nuovo caricamento.
Il ripristino diventa la prima opzione quando la versione pubblica attuale è chiaramente peggiore della precedente.
| Problema | Perché ripristinare aiuta |
|---|---|
| Pagina bianca | I visitatori tornano a vedere una versione funzionante mentre controlli la build. |
| CSS, immagini o font mancanti | La versione precedente ha percorsi degli asset già verificati. |
| Percorsi rotti | Deep link, QR code e URL di campagna possono tornare utilizzabili. |
| Testo di campagna sbagliato | L'offerta approvata torna online mentre correggi la nuova versione. |
| Export IA incompleto | Placeholder, link inventati o sezioni non finite spariscono dalla versione live. |
| PDF o download errato | Il link pubblico smette di puntare a un file sbagliato o assente. |
La regola è pratica: se la versione live danneggia accesso, fiducia, revisione cliente o conversione, prima torna a uno stato noto.
Perché i siti statici si prestano al ripristino
Un sito statico può essere visto come un insieme completo di file: HTML, CSS, JavaScript, immagini, font, PDF e altri asset.
Questo permette di pubblicare per versioni, invece di modificare una cartella live. Se ogni pubblicazione sovrascrive i file nello stesso posto, un errore può mescolare HTML vecchio, JavaScript nuovo, immagini mancanti e cache del browser. Con versioni di pubblicazione separate, ogni release rappresenta uno stato completo.
| Livello | Cosa dovrebbe conservare | Perché conta |
|---|---|---|
| Output di build | I file esatti di quella versione | Non devi ricostruire il sito precedente a memoria. |
| Record di pubblicazione | Quale versione era attiva e quando | Puoi scegliere uno stato già verificato. |
| Mappatura del dominio | Quale versione serve l'URL pubblico | Il recupero può essere un cambio di versione attiva. |
| Contesto | Chi ha pubblicato e cosa è cambiato | L'analisi inizia dopo aver contenuto il problema. |
Cloudflare Pages descrive i rollback come ritorno a un deployment di produzione precedente. Vercel usa Instant Rollback per riportare i domini di produzione a un deployment precedente. Netlify permette di pubblicare di nuovo un deploy precedente come produzione. Cambia l'interfaccia, ma il modello è simile: la versione precedente deve esistere ancora come destinazione pubblicabile.
Evita di ricostruire il vecchio sito durante l'incidente
Se il rollback significa cercare un vecchio ZIP, ricostruire in locale, caricare tutto di nuovo e sperare che coincida, non è un vero ripristino. È un redeploy d'emergenza.
Può funzionare, ma aggiunge rischio nel momento peggiore:
- Il codice vecchio può non corrispondere alla build pubblicata.
- Le dipendenze possono essere cambiate.
- Variabili e impostazioni di build possono non essere identiche.
- Qualcuno può scegliere la cartella sbagliata.
- Il nuovo caricamento può introdurre un altro stato rotto.
Il percorso più pulito è conservare le pubblicazioni riuscite e cambiare quale versione è attiva.
Una decisione breve, non un dibattito
Il rollback non dovrebbe diventare una discussione teorica. Bastano poche domande.
| Domanda | Se sì | Se no |
|---|---|---|
| Il sito live è rotto per visitatori reali? | Ripristina una versione stabile. | Può bastare una correzione in avanti. |
| È solo un piccolo testo? | Considera un upload corretto. | Continua a valutare l'impatto. |
| La versione precedente è stata verificata? | Usala come destinazione. | Cerca l'ultimo stato davvero approvato. |
| La modifica dipendeva da API o dati esterni? | Controlla compatibilità. | Il ripristino statico probabilmente basta. |
| C'è una campagna, un cliente o un lancio attivo? | Contieni prima l'impatto pubblico. | Hai più spazio per il debug. |
L'obiettivo non è dire che il rollback vince sempre. L'obiettivo è evitare che una versione rotta resti pubblica mentre il team improvvisa.
Cosa controllare subito dopo
Un ripristino non finisce quando l'interfaccia dice che è riuscito. Devi aprire il sito.
- Apri la pagina iniziale in una finestra privata.
- Controlla le pagine importanti e i deep link.
- Verifica CSS, JavaScript, immagini, font, PDF e download.
- Prova dominio personalizzato e link di anteprima se esistono entrambi.
- Conferma che HTTPS sia valido per l'hostname.
- Guarda visite recenti o log, se disponibili.
- Dì al team quale versione è attiva ora.
Se il problema è arrivato insieme a modifiche di dominio, controlla anche DNS e SSL. Ripristinare file non corregge un CNAME sbagliato o un certificato non ancora attivo. Per questa parte puoi usare il controllo DNS e lo SSL checker.
Cosa il rollback non risolve
Il rollback ripristina lo stato di consegna statica. Non riporta indietro automaticamente tutto ciò che sta intorno al sito.
| Dipendenza | Limite del ripristino |
|---|---|
| API esterne | La versione precedente può aspettarsi una risposta che è già cambiata. |
| Database | Ripristinare file statici non annulla migrazioni o dati scritti. |
| CMS o contenuti esterni | Una build vecchia può continuare a leggere contenuti nuovi. |
| Script di terze parti | Un problema del fornitore può colpire versione vecchia e nuova. |
| DNS o certificati | La configurazione del dominio segue un percorso separato. |
| Cache del browser | Alcuni visitatori possono mantenere asset per un po'. |
Questo confine è importante. Il rollback è forte per problemi di frontend, percorsi, asset e contenuti pubblicati. Non sostituisce un piano d'incidente per API, dati e servizi esterni.
Browser upload, Git e CLI: stessa idea
Un sito può arrivare online in modi diversi. La logica di recupero rimane simile.
Caricamento dal browser
È comune per cartelle HTML, export IA, portfolio, PDF, pagine singole e anteprime cliente. Il rischio è che la versione precedente esista solo nel computer di qualcuno.
Le pubblicazioni versionate aiutano perché lo stato precedente resta nel progetto.
Pubblicazione da Git
Git aiuta, ma un commit non coincide sempre con l'artefatto servito ai visitatori. Una build eseguita più tardi può produrre output diverso se cambiano dipendenze, variabili o impostazioni.
Per i siti statici, anche il deployment riuscito ha valore.
Pubblicazione via CLI
La CLI rende il processo più ripetibile. Non lo rende infallibile. Una build valida può comunque pubblicare un percorso rotto, un asset referenziato male o contenuti non approvati.
Come si inserisce DeployPages
DeployPages pubblica versioni statiche invece di costringerti a modificare una cartella live a mano.
Puoi iniziare con un caricamento dal browser per ottenere il primo link pubblico e mantenere lo stesso progetto quando il sito diventa più serio. Quando gli aggiornamenti contano, puoi usare ripristino di una versione precedente, statistiche, domini personalizzati, protezione con password e pubblicazione via CLI.
L'idea è semplice: ogni modifica importante dovrebbe lasciare una strada di ritorno. Se un nuovo caricamento rompe l'URL pubblico, il team non dovrebbe ricostruire il sito di ieri mentre i visitatori aspettano.
Playbook minimo per il prossimo lancio
| Passaggio | Responsabile | Fatto quando |
|---|---|---|
| Dare un nome alla versione | Chi pubblica | Il team sa cosa è cambiato. |
| Verificare l'anteprima | Reviewer | Pagina iniziale, percorsi, asset e mobile funzionano. |
| Tenere disponibile la versione precedente | Owner del progetto | Esiste uno stato stabile da ripristinare. |
| Pubblicare | Chi pubblica | L'URL pubblico serve la versione corretta. |
| Guardare i primi segnali | Owner | Statistiche, log e test manuali non mostrano errori evidenti. |
| Ripristinare se serve | Persona autorizzata | L'URL pubblico torna a uno stato verificato. |
| Fare debug dopo | Builder | La versione rotta viene corretta senza pressione live. |
È volutamente semplice. È quello che serve quando una pagina pubblica è rotta.
Quando il rollback diventa necessario
Per un'anteprima usa e getta, potrebbe non essere indispensabile.
Diventa importante quando:
- il sito usa già un dominio personalizzato;
- un cliente, recruiter, docente o pubblico di campagna ha già il link;
- più di una persona può pubblicare;
- un errore tocca reputazione, entrate, candidature o supporto;
- lavori con export IA o file ricevuti da altri;
- gli archivi ZIP manuali non sono più affidabili.
A quel punto il rollback non è un lusso. È ciò che permette di aggiornare senza trasformare ogni pubblicazione in una strada senza ritorno.