10 migliori pratiche di staging di WordPress che prevengono disastri sul sito live

Aggiorni un plugin sul tuo sito live perché richiede solo 30 secondi. Poi la tua homepage diventa bianca.

È successo quasi a ogni proprietario di sito WordPress a un certo punto.

Un rapido aggiornamento, una piccola modifica, un momento "andrà tutto bene" che non è andato bene. E ora ti ritrovi a fissare uno schermo bianco con visitatori reali che cercano di raggiungere il tuo sito.

Questo è il problema che un sito di staging risolve. È una copia privata del tuo sito live dove testi le modifiche prima che arrivino alla produzione. Se qualcosa si rompe sullo staging, nessuno lo vede tranne te.

La maggior parte degli utenti WordPress occasionali sa che lo staging esiste. La maggior parte lo salta perché sembra un lavoro extra.

Capisco. Ma dopo aver visto il checkout di WooCommerce bloccarsi a metà vendita a causa di un conflitto di plugin che avrebbe richiesto due minuti per essere individuato sullo staging, ho smesso di considerarlo opzionale.

In questo post, ti mostrerò cos'è un sito di staging, quando ne hai bisogno, come impostarne uno velocemente e le pratiche che rendono lo staging degno di essere fatto in primo luogo.

Ecco i punti chiave:

• Lo staging non serve per ogni modifica. Modifiche minori come refusi, aggiornamenti di prezzi e nuovi post non richiedono un flusso di lavoro di staging.
• Testare contro una copia del tuo sito vecchia di una settimana produce risultati inaffidabili. Aggiornare lo staging prima di ogni ciclo di modifiche risolve completamente questo problema.
• Spingere l'intero database dallo staging alla produzione distrugge i contenuti live. Ordini, invii di moduli e registrazioni utenti arrivati in produzione mentre lavoravi sullo staging vengono sovrascritti. Spingi il codice, non il database.
• Un sito di staging non bloccato danneggia la SEO del tuo sito live. La protezione tramite password e le impostazioni noindex sono non negoziabili.
• La modalità di debug sullo staging mostra errori che sono nascosti in produzione. Avvisi e notifiche PHP che esistono silenziosamente sul tuo sito live appariranno qui per primi.
• Aggiornare un plugin alla volta è l'unico modo affidabile per tracciare un conflitto. Gli aggiornamenti in blocco rendono impossibile identificare quale modifica ha causato un problema.
• Il backup pre-push è ciò che rende recuperabile un'implementazione errata.
• Vecchi ambienti di staging diventano rischi per la sicurezza. Eliminali quando hai finito.

Indice

Lo staging non è un backup. Se il tuo sito live si blocca, non puoi ripristinare dallo staging.

Servono a scopi diversi: i backup sono il tuo strumento di recupero; lo staging è il tuo ambiente di test.

Lo staging non è nemmeno la stessa cosa di un ambiente di sviluppo locale. Un ambiente locale viene eseguito sul tuo computer, offline, disconnesso dalle reali condizioni del server.

Lo staging viene eseguito su un server effettivo con un URL reale, quindi riflette come il tuo sito si comporta effettivamente in produzione.

Se vuoi fare una ricostruzione completa o iniziare un sito da zero, strumenti locali come XAMPP, WAMP o MAMP hanno senso. Per testare aggiornamenti e modifiche rispetto al comportamento reale del server, lo staging è l'opzione più affidabile.

E lo staging non è un secondo sito permanente. È un ambiente di lavoro temporaneo. Fai modifiche, le testi, invii ciò che funziona e reimposti o aggiorni quando inizi il ciclo successivo.

Quando usare un sito di staging (e quando saltarlo)

Ogni post sullo staging ti dirà di usarlo per tutto. Non è realistico e seguire quel consiglio porta a un affaticamento del processo, dove alla fine smetti di usare lo staging del tutto, comprese le modifiche che ne hanno effettivamente bisogno.

Ecco una prospettiva più onesta.

Modifiche che giustificano lo staging

Queste sono le situazioni in cui qualcosa che va storto su un sito live ha conseguenze reali: vendite perse, moduli non funzionanti, utenti bloccati o una homepage che non si carica.

Il costo in termini di tempo dello staging è nulla rispetto al costo di recupero se una di queste cose va storta.

• Aggiornamenti del core di WordPress, in particolare le release di versioni principali
• Aggiornamenti di plugin o temi, in particolare WooCommerce, page builder e plugin di sicurezza
• Qualsiasi modifica alla tua versione PHP o alla configurazione del server
• Aggiunta di un nuovo plugin che influisce sul checkout, sui moduli o sulla funzionalità dell'intero sito
• Codice personalizzato o modifiche CSS che toccano template o file del tema
• Riprogettazioni complete o modifiche significative al layout

Modifiche che non richiedono lo staging

Lo staging ha un costo aggiuntivo. Creare un clone, apportare una modifica e ripubblicarla: è eccessivo per modifiche che non comportano rischi reali.

• Correggere un refuso o aggiornare un prezzo
• Pubblicare un nuovo post del blog o aggiungere un prodotto
• Sostituire una voce di menu o regolare un widget
• Aggiornamenti minori di immagini senza dipendenze di codice

Se qualcosa in questo elenco dovesse in qualche modo rompere il tuo sito, la correzione richiederebbe meno tempo di quanto avrebbe richiesto l'impostazione dello staging. Risparmia il processo per quando vale la pena farlo.

Come impostare un sito di staging WordPress

Se il tuo host offre lo staging integrato, quello è un punto di partenza ragionevole. WP Engine, Kinsta e SiteGround lo includono nei loro pannelli di controllo.

Se il tuo host non lo offre (o vuoi qualcosa che funzioni allo stesso modo indipendentemente da dove è ospitato il tuo sito), Duplicator Pro è quello che uso.

Trasforma qualsiasi backup completo del sito in un sito di staging in pochi clic. Non avrai bisogno di un account di hosting separato, FTP o lavoro manuale sul database.

Si inizia creando un backup completo del tuo sito.

Quindi, vai su Staging » Crea il tuo primo sito di staging.

Scegli il backup che hai creato come modello per il sito di staging. Assicurati anche di scegliere uno schema di colori amministrativi univoco in modo che la tua dashboard di staging abbia sempre un aspetto diverso.

Duplicator installerà il backup come un sito di staging completamente nuovo. Qualsiasi modifica apportata qui non influenzerà il tuo sito web reale.

Anche il percorso manuale è un'opzione: configura un sottodominio o una sottodirectory, trasferisci i file tramite FTP, duplica il database in phpMyAdmin, aggiorna le credenziali di wp-config.php e sincronizza gli URL nella tabella wp_options. Funziona, ma ci sono molti passaggi in cui si può sbagliare.

Per ulteriori metodi di staging, leggi il nostro post su come creare un sito di staging WordPress.

10 migliori pratiche di staging WordPress che ogni proprietario di sito dovrebbe seguire

La configurazione dello staging è la parte facile. Ecco alcune best practice per lo staging di WordPress per evitare errori comuni:

• Inizia sempre con un backup recente. Il tuo punto di ripristino se la configurazione dello staging va storta o una modifica inviata danneggia il sito live.
• Database privato, bloccato all'indicizzazione, separato. Tre impostazioni distinte che impediscono ciascuna una diversa categoria di danni.
• Rispecchia il tuo ambiente di produzione. La versione di PHP, il tipo di server, i livelli di caching e le regole del firewall dovrebbero corrispondere alla produzione, altrimenti i risultati dei tuoi test non saranno attendibili.
• Abilita la modalità di debug. Mostra gli errori PHP sullo staging che sono nascosti sul tuo sito live per impostazione predefinita.
• Un aggiornamento alla volta. L'unico modo per risalire a un conflitto fino alla modifica specifica che lo ha causato.
• Staging come gate di QA finale. Un test completo che copre navigazione, moduli, checkout, mobile e velocità della pagina prima che qualcosa vada in produzione.
• Codice alla produzione, non al database. L'invio dell'intero database sovrascrive il contenuto live arrivato mentre stavi lavorando sullo staging.
• Aggiorna prima di ogni ciclo. Uno staging obsoleto fornisce risultati inaffidabili. Scarica dalla produzione prima di ogni nuovo lotto di modifiche.
• Esegui il backup della produzione prima di inviare. Eseguito immediatamente prima del deployment, non il giorno prima.
• Pulizia regolare. Elimina gli ambienti di staging vecchi quando hai finito con loro per evitare confusione e lacune di sicurezza.

1. Inizia sempre con un backup fresco

Prima di creare un ambiente di staging, esegui un backup completo del tuo sito di produzione. Se la configurazione dello staging va storta, hai un punto di ripristino pulito.

Ancora più importante, quel backup diventa la tua opzione di ripristino se invii modifiche che danneggiano qualcosa sul sito live.

Se hai creato un sito di staging con Duplicator, avrai già un backup recente del tuo sito. È il primo passo dello staging!

Mentre crei il backup, ti consiglio di inviare almeno una copia nel cloud. Duplicator Cloud ti offre una dashboard di ripristino off-site nel caso in cui succeda qualcosa al tuo sito reale.

2. Mantieni lo staging privato, blocca l'indicizzazione e usa un database separato

Inizia con la protezione tramite password. Il tuo URL di staging non dovrebbe mai essere accessibile pubblicamente, punto.

Chiunque vi atterri vede una versione incompiuta, potenzialmente non funzionante, del tuo sito. La maggior parte degli host e dei plugin di staging gestisce questo automaticamente, ma verificalo tu stesso anziché dare per scontato.

Bloccare i motori di ricerca è un passaggio separato e altrettanto importante. Vai su Impostazioni » Lettura nella dashboard di staging di WordPress e seleziona Scoraggia i motori di ricerca dall'indicizzare questo sito.

Duplicator dovrebbe farlo automaticamente, ma non guasta controllare.

Un sito di staging non bloccato può essere indicizzato. Google non sempre distingue tra staging e produzione se l'URL è accessibile, e il danno SEO dovuto ai contenuti duplicati può influire sulle classifiche del tuo sito live per mesi.

La regola del database è diversa ma altrettanto importante. Non condividere mai un database tra il tuo sito live e quello di staging.

Un database condiviso significa che un'azione di staging come un salvataggio accidentale o una modifica di configurazione può sovrascrivere dati di produzione reali. Potresti perdere ordini, invii di moduli, account utente o contenuti pubblicati.

Mantieni i database completamente separati. La maggior parte delle configurazioni di staging gestisce questo per impostazione predefinita, ma se stai facendo una configurazione manuale, questa è l'unica cosa che vale la pena ricontrollare prima di iniziare.

3. Rispecchia il tuo ambiente di produzione il più fedelmente possibile

L'intero scopo dello staging è testare cosa accadrà sul tuo sito live. Se lo staging non corrisponde alla produzione, i risultati del test non hanno molto significato.

La versione PHP è la discrepanza più comune. Se il tuo ambiente di staging esegue PHP 8.1 e la produzione esegue PHP 8.3, un plugin che funziona bene sullo staging potrebbe generare errori sul sito live.

Verifica che entrambi gli ambienti eseguano la stessa versione prima di testare qualsiasi cosa. Potrebbe essere necessario aggiornare la versione PHP di un sito.

Se stai usando Duplicator per creare siti di staging, creane uno nuovo prima di un nuovo ciclo di test. Un ambiente vecchio non sarà una copia accurata del tuo sito web.

Elimina il vecchio sito di staging, genera una copia fresca del tuo sito web e usala per creare un nuovo sito di staging.

La stessa logica si applica al tuo web server. Apache e Nginx gestiscono determinate configurazioni in modo diverso. Se gli ambienti sono diversi, potresti ottenere bug che sono veramente difficili da tracciare.

Anche i livelli di caching contano, specialmente per i test di performance. Se la produzione utilizza Redis o Memcached e lo staging no, qualsiasi benchmark di velocità delle pagine eseguito sullo staging non rifletterà le condizioni reali.

Rispecchia la configurazione della cache, così come le regole del tuo firewall e della sicurezza. Un plugin di sicurezza o una regola WAF attivi sulla produzione ma non sullo staging possono causare conflitti che scoprirai solo dopo aver eseguito il push.

Più la corrispondenza è stretta, più puoi fidarti di ciò che lo staging ti dice.

4. Abilita la modalità di debug sullo staging

WordPress nasconde gli errori PHP sulla produzione per impostazione predefinita. Questa è la scelta giusta per un sito live perché non vuoi che i visitatori vedano messaggi di errore grezzi. Ma significa anche che i problemi possono esistere sul tuo sito senza alcun segno visibile.

Lo staging è dove li fai emergere, e puoi farlo con il debug di WordPress.

Aggiungi define('WP_DEBUG', true); al tuo file wp-config.php nell'ambiente di staging. Questo abilita la segnalazione degli errori e visualizza avvisi e notifiche PHP che altrimenti rimarrebbero nascosti.

Se un aggiornamento di un plugin introduce un avviso di deprecazione o una funzione del tema genera un errore, lo vedrai sullo staging prima che raggiunga il tuo sito live.

Vale la pena abilitare anche WP_DEBUG_LOG insieme ad esso. Questo scrive gli errori in un file debug.log nella tua cartella wp-content, in modo da avere un registro da consultare invece di affidarsi alla cattura degli errori in tempo reale.

Mantieni la modalità di debug disattivata in produzione. Le impostazioni sono solo per lo staging.

5. Aggiorna una cosa alla volta

Quando hai sei aggiornamenti di plugin in attesa, potresti voler selezionare tutto e aggiornare tutto in una volta. È più veloce, ma se qualcosa si rompe dopo un aggiornamento di massa, non hai idea di quale plugin ne sia stato la causa.

Aggiorna individualmente. Dopo ognuno, esegui un controllo rapido.

Carica la homepage, naviga attraverso un paio di pagine e assicurati che nulla di ovvio si sia rotto. Quindi aggiorna il successivo.

Aggiunge qualche minuto al processo, ma ti dà una mappa chiara di ciò che è cambiato quando qualcosa va storto.

Questo vale anche per gli aggiornamenti del core di WordPress. Se stai aggiornando il core e diversi plugin nella stessa sessione, aggiorna prima il core, testalo, quindi procedi con i plugin uno per uno.

Un conflitto tra un aggiornamento importante del core e un plugin specifico è molto più facile da diagnosticare quando non hai modificato più cose contemporaneamente.

6. Usa lo staging come tuo gate di controllo qualità finale prima di ogni push

Lo staging non è solo un luogo per sperimentare le modifiche. È l'ultimo controllo obbligatorio prima che qualsiasi cosa tocchi il tuo sito live.

Prima di applicare qualsiasi modifica, esegui un passaggio di test completo. Ciò significa più che controllare la pagina che hai appena aggiornato.

Ecco alcune azioni chiave da intraprendere:

• Naviga attraverso la tua navigazione principale sia su desktop che su mobile.
• Invia tutti i moduli che il sito utilizza, inclusi i moduli di contatto, le iscrizioni alla newsletter e qualsiasi cosa che venga inviata a un servizio di terze parti.
• Se stai utilizzando WooCommerce, esegui il flusso completo di checkout: aggiungi al carrello, checkout, pagamento.
• Controlla la velocità di caricamento della tua pagina con Google PageSpeed Insights e confrontala con il tuo valore di riferimento.
• Esamina le pagine che la tua modifica avrebbe dovuto influenzare e alcune pagine che non avrebbe dovuto toccare affatto.

I conflitti non si manifestano sempre dove ti aspetti. Un aggiornamento di un plugin che influisce sul tuo checkout potrebbe non rompere visivamente la pagina di checkout, ma potrebbe silenziosamente rompere le email di conferma dell'ordine.

Dieci minuti di clic approfonditi catturano ciò che un controllo rapido di cinque secondi perde.

7. Sposta il codice, non l'intero database

Quando sposti le modifiche dallo staging alla produzione, sposta il codice: temi, plugin, script personalizzati e modifiche alla configurazione. Non spingere l'intero database a meno che tu non abbia un motivo specifico e comprenda appieno cosa stai sovrascrivendo.

Mentre stavi lavorando sullo staging, il tuo sito live ha continuato a funzionare. Sono arrivati nuovi ordini. I moduli di contatto sono stati inviati. Gli utenti si sono registrati. I commenti del blog sono stati pubblicati.

Se sposti un intero database dallo staging alla produzione, sovrascrivi tutto questo.

La regola è: il codice fluisce dallo staging alla produzione; i contenuti rimangono sulla produzione.

Se hai apportato modifiche ai contenuti sullo staging che devono andare in produzione, migra manualmente quei pezzi piuttosto che eseguire il push dell'intero database.

Se il tuo host o plugin di staging supporta il push selettivo, usalo. Ti consente di eseguire il push di file o tabelle specifici senza toccare nient'altro. Quel livello di controllo vale molto quando il tuo sito live ha utenti attivi o transazioni in corso.

Per Duplicator, puoi creare un backup personalizzato del sito di staging che non includa il database.

Scaricalo, quindi caricalo sul tuo sito di produzione.

Tuttavia, assicurati di avere un piano di disaster recovery in atto ed evita di eseguire il push delle modifiche durante le finestre di traffico intenso. Potrebbe essere necessario eseguire il debug degli errori o ripristinare un backup se qualcosa va storto sulla produzione.

8. Aggiorna lo staging prima di ogni ciclo di modifiche

Un ambiente di staging vecchio di settimane o mesi non è un ambiente di test affidabile. È un'istantanea di come appariva il tuo sito al momento della sua creazione, che potrebbe avere molto poco in comune con il tuo sito di oggi.

Le versioni dei plugin sullo staging potrebbero essere in ritardo rispetto alla produzione. Le strutture dei contenuti potrebbero essere cambiate. Le impostazioni che hai aggiornato sul sito live potrebbero non esistere sullo staging.

Quando esegui test su una copia obsoleta, i risultati riflettono condizioni che non esistono più.

Estrai una copia fresca dalla produzione prima di ogni nuovo lotto di modifiche. Questa è l'unica abitudine che elimina la maggior parte degli errori di staging. Significa che ogni test che esegui è contro una versione attuale e accurata del tuo sito.

Se stai usando Duplicator Pro, aggiornare lo staging è veloce come l'installazione originale: esegui un nuovo backup, trasformalo in un ambiente di staging e hai finito.

9. Esegui un backup di produzione prima di fare il push

Anche dopo un lavoro di staging attento e approfondito, un push può ancora andare storto. Il comportamento della cache del server, un plugin che reagisce in modo diverso nell'ambiente live, una configurazione che funziona sullo staging ma entra in conflitto in produzione: queste cose accadono e non sono sempre prevedibili.

La risposta è avere sempre un punto di ripristino pronto prima di eseguire il push.

Esegui un nuovo backup completo del tuo ambiente di produzione immediatamente prima di distribuire qualsiasi cosa dallo staging. In questo modo, se qualcosa si rompe sul sito live, ripristini quel backup e torni alla normalità in pochi minuti.

Senza di esso, stai eseguendo il debug di un sito live interrotto in tempo reale o cercando di rimettere insieme le cose manualmente.

Tratto questo come un passaggio non negoziabile. Lo staging può andare perfettamente e il push può comunque sorprenderti. Il backup è ciò che lo rende recuperabile piuttosto che catastrofico.

Duplicator è l'unico plugin di backup con URL di disaster recovery che funzionano anche se WordPress è inattivo. Dopo aver creato un backup completo del sito, impostalo come punto di disaster recovery.

Quindi, copia l'URL di ripristino e salvalo in un posto sicuro.

Se il push va storto, incolla questo link in una finestra del browser e ripristina istantaneamente il tuo sito al suo stato normale.

10. Elimina i vecchi ambienti di staging

Gli ambienti di staging possono accumularsi rapidamente. Ne crei uno per una riprogettazione, finisci il progetto e vai avanti. Sei mesi dopo ci sono tre vecchi cloni di staging sul tuo server o account, nessuno etichettato chiaramente, tutti obsoleti.

Ci si sono due problemi. Primo, confusione: quando torni per fare altro lavoro, non sempre chiaro quale ambiente sia quello corrente o in quale stato siano.

Secondo, sicurezza: un vecchio sito di staging che non viene pi attivamente gestito pu rimanere non aggiornato e, se non protetto da password, una porta sempre aperta.

Prendi l'abitudine di eliminare gli ambienti di staging quando hai finito. Puoi gestire tutti i tuoi siti di staging da un'unica posizione nel cruscotto di Duplicator.

Quando inizii un nuovo round di lavoro, crea un clone fresco dalla produzione invece di recuperarne uno vecchio. Mantiene le cose pulite e ti assicura di sapere sempre esattamente con cosa stai lavorando.

Staging fatto bene: una checklist prima di fare il push in produzione

Prima di distribuire qualsiasi c cosa da staging a produzione, controlla questa lista. Richiede cinque minuti e, posso dirlo per esperienza, ha prevenuto pi di qualche giorno no.

• Lo staging stato aggiornato da produzione prima di questo round di test
• Tutte le modifiche sono state fatte su staging, non direttamente su produzione
• WP_DEBUG stato abilitato su staging e non sono state trovate errori
• Ogni aggiornamento stato applicato individualmente, non tutto in una volta
• Test completo del sito: navegazione, moduli, checkout, layout mobile, velocit pagina
• Lo staging protetto da password e bloccato indicizzazione motori di ricerca
• Vengono pushate solo modifiche al codice, non il database completo
• Un nuovo backup completo del sito di produzione stato creato immediatamente prima del push
• Conosci i passaggi esatti per ripristinare quel backup se il push rompe qualcosa

Quest'ultimo punto quello che la gente salta. Creare un backup e sapere come ripristinarlo sono due cose diverse.

Se non hai mai eseguito un ripristino da Duplicator Pro prima, testalo prima su un ambiente di staging cos non lo stai capendo sotto pressione su un sito vivo rotto.

Domande frequenti (FAQ)

Lo staging non ti rallenterà. Riprendersi da un sito live interrotto lo farà.

Lo staging ha la reputazione di essere quella cosa che dovresti fare ma non riesci mai a fare. Sembra un sovraccarico. Uno strato in più tra te e la modifica che vuoi apportare.

La maggior parte degli utenti occasionali di WordPress lo tratta in questo modo, e la maggior parte di loro ha anche avuto il proprio sito live interrotto nel momento peggiore possibile.

Il costo in termini di tempo dello staging è minimo: qualche minuto per aggiornare, qualche minuto per testare, un backup prima di effettuare il push. Il costo in termini di tempo per recuperare da un sito live interrotto è molto più elevato, e comporta lo stress aggiuntivo che si verifichi pubblicamente.

Avere un flusso di lavoro di staging non elimina completamente il rischio, ma intercetta la stragrande maggioranza dei problemi prima che raggiungano la produzione.

Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator Pro per eseguire il backup, migrare e mettere in staging i propri siti. La configurazione dello staging richiede pochi clic, funziona su qualsiasi host e non richiede un account di hosting separato o competenze tecniche per essere avviata.

Se questo post ti ha fatto pensare a proteggere il tuo sito prima di apportare modifiche, queste guide valgono la pena di essere lette successivamente.

• Come creare un sito di staging WordPress (per test sicuri)
• Hai bisogno di un sito di staging?
• Come eseguire il backup del sito di staging del tuo sito web prima di ogni push
• I 9 migliori plugin di staging per WordPress (+ le nostre recensioni esperte)
• Come Creare un Sito di Staging WooCommerce (+ Cosa Testare Prima di Andare Online)
• Manutenzione del database di WordPress: Cosa fare settimanalmente, mensilmente e trimestralmente