Che cosa tenere separato nella copia di prova del tuo sito

Se tieni una copia del sito accesa accanto a quella che serve i clienti, la domanda è che cosa quella copia deve isolare e che cosa deve restare uguale. Il 3 novembre 2026 ho letto due pagine aggiornate nel 2017, la guida di Search Central sugli spostamenti che non cambiano l'indirizzo visibile, e la pagina delle chiavi di Stripe. Non dicono la stessa cosa. Non ho misurato un sito e non ho acceso una copia.

Che cosa la pagina del 2017 vuole uguale

La pagina The Twelve-Factor App, fattore Dev/prod parity, scrive Last updated 2017. In fondo il copyright è 2026, Salesforce. Nella risposta letta il 3 novembre 2026 non c'è last-modified. Le due date non coincidono. Non le unisco. Il titolo chiede di tenere sviluppo, staging e produzione il più simili possibile. Staging, in quella pagina, è uno dei deploy, insieme allo sviluppo e alla produzione. Non è, in quella frase, una copia da spegnere dopo una prova.

Descrive tre distanze. Il tempo: il codice può restare giorni, settimane o mesi prima di arrivare in produzione, e la pagina contrappone ore o minuti. Le persone: chi scrive e chi mette in produzione possono essere persone diverse, e la pagina contrappone le stesse persone. Gli strumenti: l'esempio mette da una parte Nginx, SQLite e OS X, e dall'altra MySQL, Linux e un altro server web. La tabella riassume: settimane contro ore, persone diverse contro le stesse persone, ambienti divergenti contro ambienti il più simili possibile.

Sui servizi di appoggio la pagina è più stretta. Nomina la base dati, la coda e la cache. Dice che lo sviluppatore a dodici fattori resiste all'idea di usare servizi diversi tra sviluppo e produzione, anche quando una libreria nasconde la differenza. L'esempio è SQLite in locale e PostgreSQL in produzione, oppure la memoria del processo in sviluppo e Memcached in produzione. Le differenze fanno emergere incompatibilità piccole, e il codice che in sviluppo o in staging ha superato le prove fallisce in produzione. La frase finale, per tutti i deploy, è che sviluppo, staging e produzione usino lo stesso tipo e la stessa versione di ciascun servizio di appoggio.

Questa pagina non dice che le righe della base dati vadano copiate. Non dice nemmeno di lasciarle stare. Dice il tipo e la versione. Non aggiungo una regola sulle righe.

Che cosa l'altra pagina del 2017 vuole diverso

La pagina Config, stessa opera, è un altro fattore. Anche lei scrive Last updated 2017, copyright 2026 in fondo, e la risposta del 3 novembre 2026 non ha last-modified. Definisce la configurazione come tutto ciò che è probabile cambi tra i deploy: staging, produzione, ambienti di sviluppo, e così via. Nell'elenco mette i riferimenti a risorse come la base dati, Memcached e gli altri servizi di appoggio. Poi le credenziali verso servizi esterni: gli esempi sono Amazon S3 e Twitter. Poi i valori che cambiano per ogni deploy, come il nome canonico di quel deploy.

Il tipo e la versione, nella pagina sulla parità, restano. Il riferimento alla risorsa, nella pagina sulla configurazione, cambia tra i deploy. Non le unisco in una sola frase. Il resto di quella pagina, i file fuori dal controllo di revisione e le variabili, sta già nell'articolo sulla chiave. Non lo ricopio. Perché la chiave del tuo sito non sta nel codice.

I pagamenti, sulla pagina di Stripe

Ho letto la pagina Chiavi API all'indirizzo docs.stripe.com/keys il 3 novembre 2026. La risposta non aveva last-modified. Nel testo non c'è una data di revisione. Non ne invento una. È la pagina di un fornitore. Non la estendo agli altri.

La pagina distingue una sandbox e la modalità live. Nella parentesi inglese chiama la sandbox un ambiente di prova isolato, per provare le funzioni dell'account senza toccare l'integrazione live. Nella tabella italiana scrive che, in una sandbox, i circuiti delle carte e i fornitori di pagamento non elaborano i pagamenti. In modalità live, scrive, li elaborano. Ciascuna modalità ha le proprie chiavi. Gli oggetti di una modalità non sono accessibili dall'altra. L'esempio della pagina: un prodotto della sandbox non può far parte di un pagamento in modalità live.

Per le integrazioni nuove, la pagina dice di usare una sandbox generale separata, così impostazioni e dati restano isolati dalla modalità live. Le chiavi di quella sandbox, scrive, iniziano con pk_test_ per quelle pubblicabili, rk_test_ per quelle con limitazioni e sk_test_ per quelle private. Le chiavi live iniziano con pk_live_, rk_live_ e sk_live_. Non incollo un valore. La pagina dice anche di non mettere le chiavi nel codice. Quella frase è già nell'articolo sulla chiave. Non la riapro. Non descrivo come si mostra una chiave, né come la si sostituisce.

Questa pagina non dice quale tipo di base dati usare. La pagina del 2017 non dice che i circuiti si fermano in una sandbox. Restano due discorsi.

L'indice, ed è uno spostamento

La guida Changing your hosting ha last-modified 10 dicembre 2025 alle 18:38:05 GMT. In pagina: Last updated 2025-12-10 UTC. Il giorno coincide. Vale solo per gli spostamenti che non cambiano l'indirizzo visibile. Se l'indirizzo cambia, rimanda all'altra guida. Il procedimento che scrive è preparare la nuova infrastruttura, puntare il nome, controllare il traffico, spegnere la vecchia infrastruttura quando tutti, crawler compreso, ricevono i contenuti da quella nuova. È un cambio di casa. Non è una copia che resta accesa accanto al sito.

Nella preparazione scrive di caricare una copia e di provarla. Suggerisce un ambiente di prova, forse con accesso limitato per indirizzo, per provare le funzioni prima che il sito vada in linea. Poi, a parte, un nome host temporaneo per una prova pubblica. L'esempio della guida è beta.example.com. Serve a vedere se i browser ci arrivano, e se ci arriva il crawler. Per non far indicizzare la prova per sbaglio, scrive di aggiungere la regola noindex nel HTML o nelle intestazioni delle pagine.

Quando si è pronti a iniziare lo spostamento, la stessa guida dice di togliere i blocchi temporanei. Nomina due cose: un file che chiude tutta la scansione, oppure noindex nel meta o nelle intestazioni, usati mentre si costruiva la copia. Vanno tolti dalla copia nuova al momento di partire. La regola messa durante la prova e la regola tolta alla partenza sono due frasi. Non le unisco. Come il file e noindex divergono, se la pagina è chiusa, è già scritto nell'articolo sulla cartella. Non lo ricopio. Che cosa succede su Google se chiudi una cartella del tuo sito.

La pagina sulla migrazione segue queste guide come cambio definitivo, non come copia permanente. Non la riscrivo. Come migrare il tuo sito senza perdere le pagine su Google.

Una copia che resta accesa non è il nome host temporaneo di quello spostamento, e non è il momento in cui la guida dice di togliere il blocco. La pagina del 2017, a parte, vuole che quella copia usi lo stesso tipo e la stessa versione dei servizi. Non è la stessa frase della guida.

Esempio ipotetico

prova.bottega.example è un nome di scuola. bottega.example è l'altro. Non ho aperto nessuno dei due. beta.example.com resta l'esempio della guida del 10 dicembre 2025, non il nome della bottega.

Non le assegno un tipo di base dati, una versione, un riferimento, una chiave, un prefisso, né uno stato sull'indice. Non dico che una prova sia finita su Google e non dico che un pagamento sia partito. Non l'ho misurata.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho copiato righe da una base dati. Non ho letto la pagina di un altro fornitore di pagamenti, quindi non dico che la sandbox di Stripe valga per gli altri. Non ho riscritto la pagina sulla chiave, quella sulla migrazione, quella sulla cartella, quella sulla compressione e quella sulle misure. La copertina di questa pagina è nuova, perché la pagina è nuova.

Fonti lette il 3 novembre 2026. The Twelve-Factor App, Dev/prod parity, Last updated 2017, copyright 2026 in fondo, senza last-modified, https://12factor.net/dev-prod-parity. The Twelve-Factor App, Config, Last updated 2017, copyright 2026 in fondo, senza last-modified, https://12factor.net/config. Changing your hosting, Last updated 2025-12-10 UTC, last-modified 10 dicembre 2025 alle 18:38:05 GMT, https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes. Chiavi API di Stripe, letta lo stesso giorno, senza last-modified e senza data di revisione in pagina, https://docs.stripe.com/keys.