1 L’ambiente di Staging

L’ambiente di staging è uno spazio che permette di effettuare modifiche, aggiornamenti e test del proprio sito web prima di metterlo online. Se si ha questa necessità è possibile creare un ambiente di staging su cui lavorare utilizzando Softaculous sui piani Hosting WordPress e tutti gli altri con cPanel. E’ possibile effettuare una copia di staging anche tramite wp-cli seguendo questa guida.

Serve per evitare che modifiche o nuovi rilasci causino problemi agli utenti finali. È uno spazio separato, non visibile al pubblico, che riproduce il più fedelmente possibile tutte le condizioni dell’ambiente reale: stessa versione di PHP, stesso database, stessa configurazione del server, stessi moduli e dipendenze.

Questo consente di verificare il comportamento dell’app in un contesto realistico ma sicuro, isolato da quello vero. Si usa per testare codice nuovo, aggiornamenti, integrazioni con servizi esterni o anche semplici modifiche grafiche. Se qualcosa va storto in staging, non si rompe nulla nel sito online. È un passaggio fondamentale per chi lavora in modo professionale, perché aiuta a prevenire bug, conflitti o errori che in produzione potrebbero causare disservizi, perdite di dati o malfunzionamenti. Lo staging è utile anche per simulare carichi di lavoro reali, per esempio testando le performance del sistema in condizioni simili a quelle di produzione.

Alcuni utenti lo usano anche per demo interne o per far approvare modifiche al cliente prima di pubblicarle. In certi casi, il database di produzione viene copiato nello staging per poter lavorare su dati veri, magari con nomi e email oscurati. Questo aumenta la precisione dei test, soprattutto quando si tratta di funzioni complesse che dipendono da uno stato preciso del sistema. L’ambiente di staging si differenzia sia da quello di sviluppo che da quello di test automatico.

Lo sviluppo è spesso locale, sul PC del programmatore, e ha configurazioni personalizzate. I test automatici, come quelli unitari o di integrazione, servono per controllare il comportamento del codice in modo isolato e ripetibile. Lo staging invece mette tutto insieme, come succede nella realtà, ed è quindi più adatto a test finali prima del rilascio. Non si tratta solo di un’abitudine consigliata, ma di un vero strumento di lavoro, specie quando si lavora in gruppo o su progetti strutturati. Permette a più persone di collaborare senza rischiare di toccare il sito vero, e consente di creare una procedura di rilascio ordinata.

Una volta finiti i test in staging, e solo dopo aver verificato che tutto funzioni come previsto, il codice può essere spostato in produzione. In alcuni casi questo avviene in modo manuale, in altri con sistemi automatizzati di deploy. L’importante è che lo staging funga da zona cuscinetto, dove le modifiche vengono esaminate e confermate prima di diventare visibili agli utenti. È quindi uno strumento semplice ma indispensabile per garantire qualità, stabilità e sicurezza nel rilascio del software. Chi lavora senza staging rischia di introdurre errori direttamente nel sito live, con tutte le conseguenze che ne derivano. Anche in progetti piccoli, usare uno staging riduce i problemi e permette di lavorare con maggiore tranquillità. Non è un ambiente pensato solo per i grandi team, ma per chiunque voglia mantenere il controllo su quello che viene pubblicato online.

1.1 Cosa controllare prima di creare un ambiente di staging

Prima di duplicare il sito è opportuno verificare che sull’account hosting sia disponibile spazio sufficiente. Lo staging crea infatti una seconda installazione che comprende i file e un database separato. Lo spazio necessario dipende quindi dalle dimensioni del sito da copiare.

È inoltre consigliabile disporre di un backup recente del sito di produzione. Lo staging non sostituisce il backup: sono due strumenti con finalità differenti. Il primo serve a provare modifiche in un ambiente separato, mentre il secondo permette di recuperare dati e file qualora si verifichi un problema.

Prima di effettuare modifiche importanti o aggiornamenti è quindi opportuno conservare una copia recuperabile del sito. Sul blog è disponibile anche una guida dedicata agli aggiornamenti di WordPress, con le verifiche da effettuare prima di intervenire su core, plugin e temi.

Durante la creazione dello staging bisogna inoltre scegliere dove collocare la nuova installazione. Softaculous permette di indicare il dominio e la directory da utilizzare per la copia. La documentazione ufficiale prevede, ad esempio, la possibilità di creare lo staging all’interno di una sottodirectory. La posizione scelta deve essere differente da quella dell’installazione principale.

1.2 Staging e sito online sono due installazioni distinte

Dopo la creazione dello staging si avranno due installazioni separate: quella di produzione, utilizzata dagli utenti, e quella destinata ai test.

Questo aspetto è importante perché una modifica effettuata successivamente sul sito online non deve essere considerata automaticamente presente nello staging. Allo stesso modo, ciò che viene modificato nello staging non viene pubblicato sul sito principale fino a quando non viene eseguita una specifica operazione di Push to Live.

Più tempo passa tra la creazione dello staging e la pubblicazione delle modifiche, maggiore può essere la differenza tra le due installazioni. Prima del passaggio finale è quindi opportuno verificare sempre quale versione di file e database si sta per trasferire.

1.3 Come creare la copia del sito sullo staging

Dopo aver effettuato l’accesso a cPanel (utilizzando link e dati presenti nell’e-mail di attivazione del servizio hosting ricevuta in fase di acquisto) cliccare su WordPress Manager by Softaculous (nel caso in cui non dovesse essere visibile è possibile cercarlo utilizzando la barra di ricerca di cPanel in alto a destra).

Cliccare quindi su Tutte le installazioni nel menu in alto a destra (la quinta icona contando da sinistra, quella a forma di scatola).

A questo punto sarà possibile scegliere per quale installazione creare l’ambiente di staging e poi, per avviare la configurazione, basterà cliccare su Create Staging (seconda icona contando da sinistra nella sezione Opzioni vicino al nome dell’installazione).

In questa schermata finale sarà possibile compilare tutti i dettagli relativi all’ambiente di staging che si sta creando, come ad esempio l’URL di installazione (con la possibilità di indicare un sottodominio o una sottocartella) ed il nome del database da associare.

Una volta compilati tutti i campi cliccare su Create Staging in basso per avviare la procedura.

1.4 Proteggere lo staging e impedirne l’indicizzazione

Una copia di staging non deve essere considerata automaticamente privata solo perché viene utilizzata per i test. Se l’installazione dispone di un URL raggiungibile da Internet e non sono presenti ulteriori limitazioni, il sito può essere tecnicamente accessibile dall’esterno.

È quindi opportuno distinguere l’accessibilità dall’indicizzazione. Impedire l’indicizzazione serve a chiedere ai motori di ricerca di non inserire quelle pagine nei propri risultati, ma non equivale a impedire l’accesso al sito.

Quando lo staging contiene dati o funzionalità che non devono essere raggiungibili pubblicamente, è preferibile aggiungere anche una protezione dell’accesso. Una possibilità è utilizzare un’autenticazione HTTP, se disponibile nella configurazione utilizzata.

Nella guida dedicata alla creazione dello staging WordPress con WP-CLI viene mostrato anche come disabilitare l’indicizzazione di WordPress e come aggiungere una protezione tramite autenticazione HTTP.

1.5 Controllare email e servizi esterni nello staging

La copia di staging deriva dal sito di produzione e può quindi conservare configurazioni relative a plugin e servizi esterni. Prima di iniziare i test è opportuno verificare quali integrazioni sono attive.

Particolare attenzione va prestata ai sistemi che inviano email, alle newsletter, ai webhook, alle API esterne, ai CRM, ai sistemi di pagamento e agli altri servizi che comunicano con infrastrutture esterne al sito.

Un modulo di contatto provato nello staging, per esempio, potrebbe utilizzare le stesse impostazioni SMTP presenti sul sito originale. Allo stesso modo, un plugin potrebbe continuare a comunicare con un servizio esterno utilizzando le credenziali copiate dalla produzione.

Non bisogna quindi dare per scontato che la creazione dello staging renda innocue tutte le integrazioni presenti nell’installazione. Prima di effettuare test è opportuno controllarle e, quando previsto dal servizio utilizzato, configurare eventuali modalità di test o disabilitare temporaneamente le comunicazioni che non devono partire dallo staging.

1.6 Cosa verificare nello staging prima della pubblicazione

Lo staging è utile solo se le modifiche vengono effettivamente verificate prima del passaggio in produzione. Non è sufficiente controllare che la homepage venga caricata correttamente.

Prima del Push to Live è opportuno verificare almeno:

• il caricamento delle pagine principali;
• il funzionamento dell’area amministrativa di WordPress;
• il corretto funzionamento del tema e delle relative personalizzazioni;
• il funzionamento dei plugin interessati dalle modifiche;
• eventuali moduli e funzionalità interattive;
• la visualizzazione da desktop e dispositivi mobili;
• la presenza di errori PHP o JavaScript introdotti dalle modifiche;
• le funzionalità personalizzate aggiunte tramite plugin, tema o codice.

Se lo staging è stato creato per verificare un aggiornamento di WordPress, di un tema o di un plugin, il controllo deve concentrarsi anche sulle funzioni direttamente interessate dall’aggiornamento e sulle eventuali dipendenze tra i diversi componenti.

1.7 Come pubblicare un ambiente di staging con Softaculous

Per pubblicare l’ambiente di staging creato cliccare, sempre dalla schermata vista in precedenza contenente tutte le installazioni, su Push to Live (seconda icona da sinistra nella sezione Opzioni dell’installazione relativa all’ambiente di staging).

Nella schermata successiva sarà sufficiente cliccare nuovamente su Push to Live per avviare la procedura di pubblicazione utilizzando le impostazioni di default o delle impostazioni personalizzate cliccando prima su Customize.

1.7.1 Push to Live: differenza tra Default e Customize

Prima di avviare il Push to Live è importante controllare cosa verrà trasferito dallo staging alla produzione.

Softaculous mette a disposizione le modalità Default e Customize. La modalità personalizzata permette di intervenire sulle opzioni relative alla sovrascrittura dei file e al trasferimento del database.

Se viene selezionata l’opzione per sovrascrivere i file, i file interessati presenti sul sito live vengono sovrascritti durante il Push to Live.

Un’attenzione ancora maggiore va prestata all’opzione relativa al database completo. Secondo la documentazione ufficiale Softaculous aggiornata a febbraio 2026, abilitando il trasferimento completo del database, il database di destinazione viene cancellato e sostituito con quello trasferito durante l’operazione.

Per questo motivo non conviene confermare automaticamente un Push to Live senza avere prima verificato le opzioni selezionate. La scelta dipende dal tipo di modifica effettuata nello staging e da ciò che deve essere effettivamente riportato sul sito di produzione.

1.8 Creare un backup prima del Push to Live

Prima di trasferire lo staging in produzione è consigliabile creare un backup recente del sito live. Il backup deve comprendere almeno i file e il database necessari a ripristinare il sito nello stato precedente alla pubblicazione.

Questa precauzione è particolarmente importante perché il Push to Live può comportare la sovrascrittura dei file e modifiche al database della produzione. Avere una copia precedente all’operazione permette di disporre di un punto di ripristino qualora il risultato non sia quello previsto.

Sui servizi cPanel che dispongono dello strumento è possibile consultare anche la guida VHosting dedicata a come gestire i backup con JetBackup.

Il backup va considerato separatamente dallo staging: una copia utilizzata per eseguire test non è, di per sé, una strategia di ripristino del sito di produzione.

1.9 Cosa controllare dopo il Push to Live

Il completamento della procedura di Softaculous non conclude le verifiche. Dopo il Push to Live è opportuno aprire il sito di produzione e controllare che le modifiche previste siano effettivamente presenti e che le funzionalità già esistenti continuino a funzionare.

Conviene controllare le pagine interessate dalla modifica, l’accesso all’amministrazione WordPress, i moduli, il tema, i plugin coinvolti e le eventuali funzionalità personalizzate.

Se sul sito sono presenti sistemi di cache, dopo una modifica può inoltre essere necessario svuotare la cache secondo le modalità previste dalla configurazione utilizzata, in modo da evitare che vengano visualizzate versioni precedenti delle pagine.

Solo dopo queste verifiche il passaggio dallo staging alla produzione può essere considerato completato. Se l’ambiente di staging non serve più, può essere rimosso dopo essersi assicurati che non contenga modifiche o dati ancora necessari. Se invece viene mantenuto per test futuri, va trattato come una seconda installazione WordPress: deve essere protetto e mantenuto aggiornato.