Staging WordPress: perché non aggiorno mai i siti importanti “dal vivo”

C'è una cosa che faccio da anni e che i clienti non vedono mai, motivo per cui ogni tanto qualcuno la guarda con sospetto quando la trova nel preventivo. È una copia del sito, identica all'originale, che sta in un posto separato e che nessuno tranne me può aprire. Si chiama ambiente di prova, o in gergo staging, e serve a una cosa sola: fare i danni lì invece che sul sito vero.

La spiego sempre con la stessa immagine perché funziona. Se devi provare una vernice nuova su una parete di casa, non inizi dal muro del salotto davanti agli ospiti: prendi un angolo nascosto, provi, guardi come asciuga e poi decidi. Un sito web è la stessa cosa, con la differenza che il salotto è aperto ventiquattro ore su ventiquattro e i tuoi clienti ci passano dentro proprio mentre tu stai provando la vernice.

Questo articolo lo scrivo perché nella maggior parte dei siti che eredito non c'è niente del genere, e nella maggior parte dei preventivi che i miei clienti mi fanno vedere non è previsto. Il che significa che chiunque abbia lavorato su quei siti prima di me ha fatto modifiche e aggiornamenti direttamente sulla versione che vedono i visitatori, sperando bene. Il più delle volte va bene. Le volte che va male, va male nel momento peggiore, perché la legge dei guai informatici prevede che si rompano il venerdì pomeriggio.

Cosa è, concretamente, questa copia

Tecnicamente è un sito completo: tutti i file, tutto il contenuto del database, la stessa versione del software, gli stessi componenti aggiuntivi, la stessa configurazione. Sta su un indirizzo separato, spesso qualcosa che assomiglia al nome del sito con un prefisso davanti, ed è protetto da una password perché non deve finire nelle ricerche di Google né essere visto da chiunque passi di lì per caso.

La differenza fondamentale con il sito vero è che lì dentro posso fare qualsiasi cosa senza conseguenze. Aggiornare venti componenti tutti insieme e vedere cosa esplode. Cambiare il tema. Provare un modulo di pagamento nuovo. Cancellare cose per capire se servivano. Se il risultato è una pagina bianca, chiudo, ricreo la copia e ricomincio, e nessuno al mondo si è accorto di niente.

Quello che non è, e lo chiarisco perché la confusione è frequente: non è un backup. Il backup è una fotografia del passato che serve a tornare indietro dopo un disastro. La copia di prova è un laboratorio che serve a evitare il disastro. Le due cose convivono e servono a scopi diversi. Ho clienti che avevano ottimi backup e che comunque sono stati fermi mezza giornata, perché ripristinare un backup richiede tempo e nel frattempo il sito resta rotto.

Cosa ci provo sopra prima di toccare il sito vero

Nella pratica quotidiana, quello che passa dalla copia di prova prima di arrivare al sito pubblico è una lista abbastanza precisa. Te la scrivo così hai un'idea di quando ha senso chiederla a chi ti gestisce il sito.

• Aggiornamenti importanti del software di base e dei componenti principali, soprattutto quando cambiano di versione in modo sostanziale.
• Installazione di qualsiasi componente nuovo, anche se sembra innocuo, perché i conflitti nascono quasi sempre tra due cose che presi singolarmente funzionano.
• Modifiche al tema o al modo in cui sono costruite le pagine, che sono la cosa più visibile di tutte.
• Cambi di versione del linguaggio sul server, che è la tipica cosa che il fornitore di hosting ti annuncia con una mail che nessuno legge.
• Riorganizzazioni della struttura delle pagine, con i relativi reindirizzamenti da verificare uno per uno.
• Interventi sulla parte di negozio: metodi di pagamento, calcolo delle spedizioni, regole di sconto.
• Qualsiasi cosa tocchi i moduli di contatto, che è la parte che si rompe più spesso in silenzio.

L'ultimo punto merita una nota perché è quello che mi ha insegnato di più. Un modulo di contatto rotto non si vede: la pagina si apre, il modulo compare, la persona scrive, clicca invia e legge grazie del messaggio. Tutto perfetto, tranne che la mail non parte. Ho visto aziende accorgersene dopo tre settimane, contando i preventivi persi. Nella copia di prova, ogni volta che tocco qualcosa, mando un messaggio vero e controllo che arrivi. Sono due minuti che valgono oro.

Sul penultimo punto aggiungo una cosa che riguarda i negozi online. Le regole di calcolo delle spedizioni e degli sconti sono un campo minato, perché un errore lì non genera un messaggio di errore: genera ordini con il prezzo sbagliato. Provare sulla copia significa poter fare dieci ordini finti con combinazioni assurde, cinque prodotti pesanti verso le isole, un prodotto piccolo con il codice sconto, il ritiro in negozio, e vedere se i numeri tornano. Sul sito vero non potresti farlo senza sporcare i dati veri.

Le due volte in cui ho pagato per non averla

Parlo per esperienza diretta, comprese le esperienze in cui ho sbagliato io. La prima risale a diversi anni fa, su un sito piccolo di un cliente che seguivo da poco. Un aggiornamento che sembrava di routine, fatto al volo da un bar mentre aspettavo un appuntamento, perché tanto era una cosa da niente. Il componente aggiornato litigava con il tema e il sito è diventato una pagina di errore. Ho passato le due ore successive a sistemare da un telefono con una connessione ballerina, e nel frattempo il sito era giù. Nessun disastro economico, ma una figura che non volevo fare.

La seconda è più seria e riguarda un negozio online. Cambio di versione del linguaggio sul server, annunciato dal fornitore, necessario per la sicurezza, fatto direttamente sul sito pubblico perché il test sembrava superfluo. Il sito si apriva benissimo. Il modulo di fatturazione, invece, aveva smesso di generare i documenti perché usava una funzione che nella versione nuova non esisteva più. Non un errore visibile: semplicemente non faceva più il suo lavoro. Ce ne siamo accorti a fine mese, con una trentina di ordini da sistemare a mano e un commercialista non felicissimo.

Quella storia lì mi ha convinto definitivamente. Sul momento non era successo niente, il sito funzionava, tutti contenti. I guasti peggiori non sono quelli che ti mettono il sito bianco: quelli almeno li vedi subito. Sono quelli che lasciano tutto in piedi e rompono un pezzo che nessuno guarda ogni giorno.

Come la creo e come la riporto indietro

La procedura dipende un po' dal fornitore di hosting. I servizi migliori hanno una funzione apposta: un pulsante che crea la copia in qualche minuto, e un altro che riporta le modifiche sul sito vero. Dove questa funzione c'è, il lavoro è banale e non c'è nessuna scusa per non usarla. Dove non c'è, la copia si fa a mano ed è un lavoro di mezz'ora, quindi comunque poca roba rispetto al rischio che copre.

1. Copia completa di file e contenuti dal sito pubblico verso l'ambiente separato.
2. Blocco dell'accesso con password e blocco dell'indicizzazione da parte dei motori di ricerca.
3. Disattivazione di tutto quello che manda mail o comunica con l'esterno, per non far partire messaggi veri dai test.
4. Passaggio in modalità di prova dei sistemi di pagamento, se c'è un negozio.
5. Esecuzione delle modifiche o degli aggiornamenti, una cosa alla volta e annotando cosa si fa.
6. Controllo delle pagine chiave, dei moduli, del carrello e delle parti che dipendono da servizi esterni.
7. Riporto delle modifiche sul sito vero, preceduto da un backup fresco.
8. Nuovo controllo delle stesse cose sul sito pubblico, perché l'ambiente non è mai identico al cento per cento.

Il punto tre è quello che fa sudare freddo chi se lo dimentica. Una copia di prova di un negozio contiene tutti gli ordini veri e tutti gli indirizzi mail dei clienti veri. Se fai una prova sul modulo che manda le conferme d'ordine e ti sei scordato di bloccare l'invio, mandi mail vere a clienti veri parlando di ordini che non esistono. È successo, non a me per fortuna, ma l'ho visto. Da allora bloccare la posta in uscita è la prima cosa che faccio dopo aver creato la copia, prima ancora di guardare se il sito si apre.

Sul punto sette, il riporto delle modifiche, c'è una sottigliezza che vale la pena capire perché è la parte dove le cose si complicano. Se le modifiche riguardano solo file, tipo un aggiornamento o una modifica al tema, riportare è semplice. Se riguardano anche i contenuti, e nel frattempo sul sito vero sono arrivati ordini nuovi, commenti o articoli pubblicati, allora non puoi semplicemente sovrascrivere: cancelleresti quello che è successo nel frattempo. In quei casi la strada è rifare le modifiche sul sito vero seguendo l'elenco preciso di quello che hai fatto nella prova, che è il motivo per cui il punto cinque dice di annotare.

Quanto costa e quanto tempo richiede

Questa è la domanda che mi fanno subito e la risposta è meno drammatica di quanto si aspettino. Molti servizi di hosting decenti includono la funzione nel canone, senza costi aggiuntivi: è una cosa che si attiva e basta. Dove non è inclusa, mantenere un secondo spazio separato costa nell'ordine di pochi euro al mese, o si può creare solo quando serve e spegnere dopo, spendendo praticamente nulla.

L'ultima riga è quella su cui mi soffermo con i clienti quando fanno resistenza. Il costo di non averla non è distribuito: è concentrato in un giorno solo, e quel giorno costa molto. Mezza giornata di sito giù per un negozio che vende, o per un albergo in periodo di prenotazioni, vale molte volte il canone annuale di un ambiente di prova. È un'assicurazione con un premio ridicolo.

Sul tempo: creare la copia richiede minuti, provare richiede da mezz'ora a un paio d'ore secondo la complessità, riportare richiede altri minuti. Il lavoro vero è il controllo, non la copia. E il controllo è esattamente la parte che salta chi lavora dal vivo, perché sul sito pubblico non puoi permetterti di provare le cose che potrebbero rompersi.

La versione locale sul computer: quando basta

Esiste una variante che uso spesso nella fase di costruzione di un sito nuovo: la copia gira direttamente sul mio computer, senza server e senza internet. È comodissima per lavorare veloce, per scrivere codice e per provare cose radicali, perché non devo caricare niente e posso rompere tutto senza conseguenze.

Il limite però c'è ed è importante: il mio computer non è il server del cliente. Versioni diverse, configurazioni diverse, limiti di memoria diversi, un sistema operativo diverso. Una cosa che funziona benissimo in locale può comportarsi in modo diverso sul server vero, e quando succede impazzisci a capire perché. Per questo, quando devo provare un aggiornamento o una modifica su un sito già online, la copia la faccio sempre sul server, in un ambiente che assomigli il più possibile a quello reale. La versione locale è per costruire, quella sul server è per verificare.

C'è un caso intermedio che uso volentieri sui progetti più lunghi: due ambienti separati, uno dove sviluppo e faccio casino liberamente, e uno che serve al cliente per guardare il lavoro in corso e dire cosa gli piace. Tenere separate le due cose evita la situazione classica in cui il cliente apre l'anteprima proprio nel momento in cui sto smontando mezza pagina e si spaventa.

Gli errori che vedo fare anche a chi ce l'ha

Avere l'ambiente di prova non basta, bisogna usarlo bene. Gli sbagli che vedo più spesso sono sempre gli stessi e hanno tutti la stessa radice: la copia viene creata una volta e poi dimenticata.

Il primo è la copia vecchia di sei mesi. Se il sito vero nel frattempo è cambiato, le prove che fai sulla copia non ti dicono più niente di utile: stai verificando un sito che non esiste. La regola è semplice, la copia si rigenera prima di ogni sessione di lavoro, non si tiene in eterno.

Il secondo è la copia raggiungibile da chiunque. Se non è protetta da password, prima o poi Google la trova e inizia a mostrare nei risultati una versione doppia del tuo sito, con conseguenze spiacevoli sul posizionamento e figure imbarazzanti se dentro ci sono contenuti non ancora pubblicati. Ho trovato copie di prova indicizzate con dentro listini riservati e pagine di clienti che non erano ancora clienti.

Il terzo, il più pericoloso, è la copia dimenticata e mai aggiornata che resta online per anni. Diventa un sito con software vecchio e buchi di sicurezza, sullo stesso server dove sta il sito vero. È una porta aperta sul retro, e chi entra da lì ha buone probabilità di arrivare anche al resto. Quando faccio un controllo su un sito nuovo che prendo in carico, una delle prime cose che cerco sono proprio le copie abbandonate: ne trovo più spesso di quanto vorrei.

Quando invece se ne può fare a meno

Per onestà devo dire anche questo, perché non voglio far passare l'idea che serva sempre. Se il tuo sito è un piccolo sito vetrina di cinque pagine, senza negozio, senza area riservata, con due componenti aggiuntivi in tutto, e il tuo hosting fa backup automatici quotidiani che sai ripristinare con un clic, allora aggiornare direttamente con un backup fresco alle spalle è un rischio accettabile.

Il discorso cambia completamente quando il sito porta soldi ogni giorno, quando c'è un negozio, quando ci sono integrazioni con sistemi esterni, quando ci sono aree riservate, o semplicemente quando il numero di componenti aggiuntivi supera la decina. Lì la probabilità che due cose litighino cresce in fretta, e la copia di prova smette di essere un lusso.

C'è poi un criterio che non è tecnico e che uso volentieri: quanto ti costerebbe una mattinata di sito giù? Se la risposta è un fastidio, puoi rischiare. Se la risposta è una cifra che ti fa storcere la bocca, non c'è discussione. È lo stesso ragionamento che si fa per qualsiasi assicurazione, e curiosamente sui siti web la gente lo fa molto meno di quanto lo faccia sulle cose fisiche.

Le domande che mi fanno più spesso

Le domande che ricevo quando spiego questa voce del preventivo.

Il mio hosting dice che fa i backup: non è la stessa cosa?

No, e la confusione è comprensibile perché sembrano due modi di proteggersi. Il backup serve a tornare indietro dopo che il danno è successo: il sito è rotto, tu ripristini la versione di ieri e torni al punto di partenza. Il che significa che comunque il sito è stato rotto per un po', che hai perso quello che era successo nel frattempo, ordini compresi, e che il problema che volevi risolvere è ancora lì da risolvere. La copia di prova serve prima: ti dice che quell'aggiornamento romperebbe il carrello, così tu non lo fai e cerchi un'altra strada. Servono entrambe, e in questo ordine: il backup è la rete sotto il trapezio, la copia di prova è il fatto di avere provato il numero prima dello spettacolo.

Posso crearla da solo se non sono tecnico?

Se il tuo hosting ha la funzione integrata, sì, è davvero un pulsante e non c'è modo di combinare disastri creandola. Quello che ti consiglio di non fare da solo, se non sei pratico, è l'operazione inversa: riportare le modifiche dalla copia al sito vero. Quella è la fase delicata, perché a seconda di come è configurata può sovrascrivere contenuti recenti del sito pubblico, e se nel frattempo sono arrivati ordini o hai pubblicato un articolo rischi di cancellarli. La regola prudente per chi non è tecnico è: crea la copia liberamente, guardaci dentro, provaci quello che vuoi, ma per il passaggio finale fatti aiutare. Oppure, se le modifiche sono poche, rifalle a mano sul sito vero seguendo quello che hai verificato nella prova.

Quanto spesso dovrei usarla?

Il criterio che uso è per tipo di intervento, non per calendario. Ogni volta che si tocca qualcosa di strutturale, la copia entra in gioco: aggiornamenti importanti, componenti nuovi, modifiche al tema, cambi di configurazione del server, interventi sul negozio. Le cose di normale amministrazione, come pubblicare un articolo, cambiare una foto, correggere un testo o aggiornare un prezzo, si fanno tranquillamente sul sito vero: sono operazioni che il sistema è fatto per gestire e che non rompono niente. Nella pratica, su un sito aziendale che seguo con manutenzione regolare, la copia viene usata una volta al mese circa, in occasione della sessione di aggiornamenti, e poi ogni volta che c'è un lavoro fuori ordinaria amministrazione.

Perché non basta aggiornare un componente alla volta e controllare?

È una strategia che riduce il rischio e infatti la uso anche io dentro la copia, quindi non è sbagliata come idea. Il problema è che sul sito pubblico ti protegge solo a metà. Primo, perché alcuni guasti non si vedono subito: aggiorni, guardi la pagina, sembra tutto a posto, e il pezzo rotto è il modulo di contatto o la fattura automatica. Secondo, perché quando il problema si manifesta il danno è già online e i visitatori lo stanno vedendo. Terzo, perché alcuni aggiornamenti non si possono annullare facilmente: una volta che la struttura dei dati è cambiata, tornare alla versione precedente richiede un ripristino completo. Fare la stessa identica cosa dentro la copia costa uguale in tempo e ti toglie tutti e tre i problemi.

Google può vedere la copia e penalizzarmi?

Può vederla se è lasciata aperta, e va evitato, anche se la parola penalizzazione è un po' forte per quello che succede davvero. Il rischio concreto è che il motore di ricerca trovi due versioni identiche dello stesso sito e si trovi a dover scegliere quale mostrare, con il risultato che a volte compare l'indirizzo sbagliato nei risultati. Aggiungi che dentro la copia spesso ci sono bozze, prezzi in prova o pagine di lavori non ancora annunciati, e capisci perché non è una cosa da lasciare al caso. La protezione è banale: password di accesso a livello di server, così nemmeno i motori di ricerca entrano, più l'impostazione che chiede di non indicizzare. Sono due spunte. Il problema esiste solo per chi non le mette.

Serve anche per i siti non fatti con WordPress?

Sì, il principio è identico e vale per qualsiasi sito che non sia un semplice insieme di pagine statiche. Anzi, in alcuni ambienti la separazione tra ambiente di prova e ambiente pubblico è così scontata che nessuno si sognerebbe di lavorare diversamente. Il motivo per cui nel mondo WordPress se ne parla di più è che è un sistema fatto di tanti pezzi scritti da persone diverse che si aggiornano in modo indipendente, quindi la probabilità che due pezzi litighino è strutturalmente più alta. Ma anche un sito costruito su misura ha bisogno di un posto dove provare le modifiche prima di pubblicarle. Se hai un sito fatto da qualcuno e non esiste un ambiente del genere, è una domanda legittima da fare.

La sintesi è che questa è una di quelle voci di preventivo che sembrano un dettaglio tecnico e invece sono una scelta di rischio. Non rende il sito più bello, non lo fa vendere di più, non si vede da nessuna parte. Serve solo a fare in modo che il giorno in cui qualcosa va storto, quel qualcosa vada storto in un posto dove non lo vede nessuno e dove si può sistemare con calma. Nella mia esperienza è la differenza principale tra chi lavora sui siti con metodo e chi ci lavora incrociando le dita.