Checklist lancio sito web: controlli prima e dopo il go-live

Una checklist lancio sito web serve a trasformare il go-live da momento improvvisato a rilascio verificabile. Prima di pubblicare non basta controllare che le pagine “si vedano”: bisogna provare contenuti, navigazione, form, tracciamenti, indicizzazione, sicurezza operativa e procedure di ripristino.

La regola pratica è semplice: un sito è pronto quando ogni controllo critico ha un responsabile, un esito documentato e una soluzione prevista in caso di errore. Questa guida organizza le verifiche prima, durante e dopo la messa online, distinguendo ciò che blocca il lancio da ciò che può essere migliorato in seguito.

Checklist lancio sito web: prima definisci cosa può bloccare il go-live

Una checklist piatta, con decine di voci tutte uguali, rende difficile decidere. Il primo passaggio è classificare i controlli in base al rischio.

• Bloccante: impedisce di pubblicare. Per esempio, form che non invia, pagine importanti non raggiungibili, dominio non configurato, blocco di indicizzazione involontario o tracciamento delle conversioni assente quando il sito sostiene campagne già attive.
• Importante: non rende il sito inutilizzabile, ma può compromettere chiarezza, fiducia o misurazione. Va corretto prima del lancio quando possibile e assegnato con una scadenza se non è bloccante.
• Evolutivo: riguarda ottimizzazioni successive, nuove funzionalità o test che richiedono dati reali. Non dovrebbe ritardare il go-live se la base è solida.

Per ogni voce della checklist lancio sito web annota almeno: area, test da eseguire, responsabile, esito, evidenza e azione correttiva. In questo modo “controllato” non significa “qualcuno ci ha dato un’occhiata”, ma indica un test ripetibile.

Prima del lancio: contenuti, navigazione e segnali di fiducia

Il controllo editoriale non si limita ai refusi. Ogni pagina deve avere un compito preciso e accompagnare l’utente verso un passo successivo coerente.

Contenuti e call to action

• titolo e apertura chiariscono subito argomento, destinatario e valore della pagina;
• servizi, condizioni e limiti sono descritti senza promesse non dimostrabili;
• numeri, certificazioni, recensioni, loghi e casi citati sono verificabili e autorizzati;
• la call to action porta alla destinazione corretta e non cambia significato tra testo, pulsante e pagina di arrivo;
• non restano testi segnaposto, pagine vuote, immagini provvisorie o link all’ambiente di sviluppo.

Navigazione e percorsi reali

Prova il sito partendo dai compiti dell’utente, non dalla sitemap. Una persona riesce a trovare un servizio, capire per chi è adatto, verificare l’affidabilità dell’azienda e contattarla senza tornare continuamente al menu? Controlla menu, breadcrumb quando presenti, footer, logo, ricerca interna e percorsi alternativi verso le pagine principali.

La verifica va ripetuta su desktop e dispositivi mobili. Non basta restringere la finestra del browser: prova almeno i flussi essenziali su dispositivi e browser rappresentativi del pubblico previsto.

Accessibilità: controlli iniziali, non certificazioni improvvisate

Una prima revisione dovrebbe includere titoli gerarchici, testi alternativi pertinenti, contrasto, zoom, focus visibile, navigazione da tastiera, etichette dei campi e messaggi di errore comprensibili. Le verifiche preliminari della W3C Web Accessibility Initiative aiutano a individuare problemi di base, ma non sostituiscono una valutazione completa di conformità.

Controlli tecnici prima di pubblicare il sito

La parte tecnica della checklist lancio sito web deve confermare che il progetto funzioni nel contesto reale: dominio definitivo, HTTPS, cache, servizi esterni, email e permessi possono comportarsi diversamente rispetto all’ambiente di test.

Dominio, HTTPS e configurazione di produzione

• il dominio e le varianti previste conducono alla versione canonica scelta;
• il certificato TLS è valido e non rimangono risorse caricate in HTTP;
• URL, email, webhook e chiavi di integrazione non puntano più allo staging;
• modalità manutenzione, account temporanei e strumenti di debug sono gestiti secondo il piano di rilascio;
• backup e procedura di ripristino sono disponibili prima della modifica.

Funzioni critiche e messaggi di errore

Esegui azioni reali con dati di test riconoscibili. Invia ogni form, verifica la conferma mostrata all’utente e controlla che la richiesta arrivi al destinatario corretto. Prova telefonate, email, mappe, download, ricerca, login e integrazioni previste. Per un e-commerce servono verifiche specifiche su catalogo, carrello, checkout, pagamenti, email e gestione dell’ordine: non vanno trattate come una semplice estensione della checklist di un sito vetrina.

Registra anche cosa accade quando un dato è mancante o non valido. Un flusso non è testato davvero se è stata verificata soltanto la situazione ideale.

Prestazioni: laboratorio e comportamento reale

Controlla il caricamento delle pagine principali, la stabilità visiva e la risposta alle interazioni su connessioni e dispositivi diversi. I test di laboratorio sono utili per diagnosticare, mentre i dati sul campo descrivono ciò che sperimentano gli utenti reali. La documentazione web.dev sulla misurazione dei Web Vitals spiega perché le due fonti non sono intercambiabili.

Checklist SEO per il lancio del sito web

Un sito pubblicato può essere tecnicamente raggiungibile e, allo stesso tempo, non essere pronto per la ricerca. Il QA SEO deve verificare sia le singole pagine sia il rapporto tra gli URL.

Indicizzazione, canonical e sitemap

• le pagine che devono comparire nei motori di ricerca non hanno direttive noindex involontarie;
• robots.txt non impedisce la scansione delle risorse e delle sezioni necessarie;
• canonical, hreflang quando pertinente e collegamenti interni usano gli URL definitivi;
• title, meta description, H1 e slug sono coerenti con il compito di ogni pagina;
• la sitemap contiene URL canonici che si desidera rendere disponibili in ricerca.

Google chiarisce che la sitemap aiuta a comunicare gli URL preferiti ma non garantisce l’indicizzazione. Le indicazioni ufficiali su come creare e inviare una sitemap sono il riferimento corretto per questo controllo.

Nuovo sito o sostituzione di un sito esistente?

La differenza è decisiva. Se il progetto sostituisce un sito esistente, prima del rilascio servono un inventario dei vecchi URL e una mappatura verso destinazioni pertinenti. Non è corretto inviare indiscriminatamente tutte le pagine alla home.

La guida di Google Search Central sulle migrazioni con modifica degli URL raccomanda di verificare redirect, canonical, direttive robots e sitemap, oltre ad aggiornare i collegamenti interni. Per un progetto di restyling del sito web, questa mappa deve esistere prima del go-live, non essere ricostruita quando il traffico è già calato.

Tracking e conversioni: prova il percorso completo

La presenza di un tag non dimostra che la misurazione funzioni. Parti dall’azione reale: invio di un modulo, click sul telefono, richiesta di preventivo, prenotazione o acquisto. Poi verifica l’evento, la destinazione analytics e l’eventuale piattaforma pubblicitaria.

1. esegui l’azione dal sito pubblicato o dall’ambiente previsto per il test;
2. controlla che l’utente riceva conferma e che il reparto corretto riceva la richiesta;
3. verifica nome, parametri e attivazione dell’evento;
4. controlla che l’evento sia classificato correttamente rispetto agli obiettivi di business;
5. escludi duplicazioni dovute a ricaricamenti, thank you page riaperte o tag ripetuti.

In GA4, Realtime e DebugView possono aiutare a verificare gli eventi durante l’implementazione; la documentazione ufficiale di DebugView precisa anche che i controlli sul consenso possono influire sulla visibilità degli eventi di debug. Un test tecnico va quindi interpretato nel contesto della configurazione privacy effettiva.

Il giorno del go-live: sequenza, responsabilità e rollback

Il lancio dovrebbe avere una finestra concordata e un referente in grado di decidere. Prima dell’intervento salva la versione ripristinabile, congela le modifiche non necessarie e comunica cosa verrà pubblicato. Durante il rilascio annota l’ordine delle operazioni.

Subito dopo, esegui uno smoke test breve ma bloccante:

• home e pagine commerciali principali rispondono correttamente;
• menu, CTA e form essenziali funzionano;
• HTTPS e dominio canonico sono coerenti;
• non compaiono errori applicativi evidenti;
• tracciamenti prioritari ricevono gli eventi attesi;
• direttive di indicizzazione e redirect critici corrispondono al piano.

Il piano di rollback deve stabilire chi può attivarlo, quale stato viene ripristinato e quali dati potrebbero essere cambiati nel frattempo. “Abbiamo un backup” non è sufficiente se non è chiaro come usarlo e quali attività andrebbero perse.

Dopo il lancio del sito: cosa controllare nei primi giorni

La messa online non chiude il progetto. Nei primi controlli successivi verifica errori server e applicativi, richieste ricevute, eventi analytics, URL non trovati, redirect, indicizzazione delle pagine strategiche e comportamento sui dispositivi reali. Confronta i risultati con una baseline raccolta prima del rilascio quando il sito sostituisce una versione precedente.

Assegna ogni anomalia a una delle tre categorie:

• regressione: qualcosa che funzionava non funziona più;
• difetto emerso in produzione: dipende da condizioni non riprodotte nei test;
• opportunità evolutiva: richiede dati e non compromette il rilascio.

Questo evita di confondere un’emergenza con una miglioria. Per preservare stabilità e continuità dopo la consegna, la manutenzione del sito web deve partire da controlli programmati, responsabilità chiare e tracciabilità degli interventi.

Checklist lancio sito web: la matrice di accettazione

Una matrice compatta rende la checklist utilizzabile da cliente, progettista, sviluppatore e marketing senza perdere responsabilità.

La matrice non impone che ogni progetto abbia gli stessi ruoli. Impone però che nessun controllo critico resti senza proprietario e che l’approvazione sia basata su evidenze.

Domande frequenti sul lancio di un sito web

Quando un sito è davvero pronto per essere pubblicato?

Quando i flussi essenziali funzionano, i controlli bloccanti sono chiusi, la misurazione è verificata e sono definiti responsabilità, monitoraggio e rollback. La perfezione assoluta non è necessaria; la gestione consapevole dei rischi sì.

Chi deve approvare il go-live?

Dipende dall’organizzazione, ma la decisione deve avere un responsabile chiaro. Sviluppo, contenuti, marketing e referente aziendale possono validare aree diverse; una persona deve infine confermare che i requisiti bloccanti siano soddisfatti.

La checklist cambia per un restyling?

Sì. Un restyling aggiunge la gestione del patrimonio esistente: URL, redirect, contenuti indicizzati, dati analytics, integrazioni, backlink rilevanti e continuità delle campagne. Questi aspetti non esistono nello stesso modo per un dominio completamente nuovo.

Serve controllare il sito anche dopo la pubblicazione?

Sì. Alcuni problemi emergono soltanto con dominio, traffico e servizi di produzione. Per questo il piano deve includere verifiche immediate e monitoraggio successivo, con soglie e referenti per l’escalation.

Una checklist lancio sito web non sostituisce competenze e responsabilità, ma rende visibili decisioni, rischi ed esiti. BNZ Solutions progetta e realizza siti web professionali collegando struttura, esperienza utente, sviluppo, SEO e misurazione. Se devi creare o portare online un nuovo progetto, possiamo definire insieme requisiti, controlli di accettazione e continuità post-lancio.