Checklist per il lancio di un sito web: come testarlo prima della messa online

Una checklist per il lancio di un sito web è l’elenco dei test che il sito deve superare prima della messa online: contenuti, link, moduli, dispositivi, velocità, accessibilità, basi della SEO, consenso, sicurezza, analytics e backup. Va seguita in un ordine fisso: registra ogni difetto in un unico posto, correggi, testa di nuovo e lancia solo quando non resta nulla di bloccante. Questa guida offre la checklist completa per area, un processo di QA numerato, una tabella dei tipi di test con chi li esegue e quando, e le risposte alle domande più frequenti di chi compra.

Ultimo aggiornamento: 19 ottobre 2026.

Cos’è il QA di un sito web e perché è importante?

Il quality assurance (QA) è la verifica pianificata di un sito web rispetto a ciò che deve fare, prima che siano i visitatori reali a trovare i difetti al posto tuo. Non è un giro veloce sulla home page dal laptop dello sviluppatore. È un insieme di test, eseguiti su dispositivi e browser reali, con un registro di ciò che non ha funzionato e la prova che è stato corretto.

È importante perché il lancio è il momento in cui tutti giudicano il sito insieme: clienti, motori di ricerca e chiunque controlli se i tuoi moduli ti arrivano davvero. Un modulo di contatto rotto, un banner dei cookie che carica i tracker prima del consenso o una pagina che non scorre su un telefono possono costare più dell’intera fase di test.

In Odduel, agenzia creativa e tecnologica con sedi a Barcellona e São Paulo, il QA fa parte di ogni progetto di realizzazione siti web, non è un’aggiunta finale. Gran parte dei controlli ripetitivi (scansione dei link, screenshot a molte larghezze, verifica dei layout nelle diverse lingue) è affidata a script, così le persone dedicano il loro tempo al giudizio: si legge bene, dà la sensazione giusta, funziona per chi usa la tastiera o uno screen reader.

In breve: il QA trasforma un sito che funziona su uno schermo in un sito che funziona per tutti. Servono una checklist scritta, dispositivi reali, un registro dei difetti e un secondo passaggio dopo le correzioni. Inizia quando i contenuti sono definitivi, non la mattina del lancio. E lascia tempo per le correzioni che emergeranno.

Quando iniziare a testare un sito web?

I test dovrebbero iniziare molto prima dell’ultima settimana. Alcuni controlli appartengono al design (contrasto, dimensioni delle aree di tocco, ordine dei titoli), altri allo sviluppo (moduli, layout responsive), e il passaggio completo va fatto alla fine, quando i contenuti sono definitivi.

Una regola utile: non puoi chiudere il QA su testi segnaposto. I titoli reali sono più lunghi, le fotografie reali più pesanti e le pagine legali reali cambiano il footer. Pianifica il passaggio completo dopo il blocco dei contenuti e lascia spazio a un intero giro di correzioni e nuovi test. Se lavori con un sito di staging, testa prima lì, poi ripeti i controlli critici sull’indirizzo definitivo subito dopo il lancio, perché server, cache e certificati sono diversi.

Se stai ancora scegliendo come costruire il sito, la nostra guida allo sviluppo di siti web descrive le fasi che vengono prima di questa.

La checklist QA del sito web, area per area

Ogni area qui sotto elenca cosa testare. Segna ogni riga come superata, non superata o non applicabile, e registra ogni errore con l’indirizzo della pagina, il dispositivo, il browser e uno screenshot.

Contenuti e testi

• Ogni pagina ha il testo definitivo: niente lorem ipsum, niente «XX», niente note di bozza.
• Ortografia e grammatica sono verificate in ogni lingua del sito.
• Nomi, indirizzi, numeri di telefono e orari coincidono esattamente con quelli degli altri tuoi profili.
• Date, prezzi e ragioni sociali sono aggiornati e coerenti tra le pagine.
• Le immagini sono le versioni definitive, ben ritagliate a ogni larghezza, con un testo alternativo utile.
• I titoli seguono un ordine logico: un H1 per pagina, poi H2, poi H3.
• Le pagine legali (privacy, cookie, note legali) sono pubblicate e collegate dal footer.
• Nessuna parola resta da sola sull’ultima riga di un titolo alle larghezze più comuni.

Link e navigazione

• Un crawler non trova link interni rotti (nessun errore 404).
• I link esterni aprono la pagina giusta e funzionano ancora.
• Menu principale, menu del footer e breadcrumb funzionano su ogni pagina.
• I vecchi indirizzi del sito precedente reindirizzano ai nuovi con un 301.
• I link telefonici avviano la chiamata, i link email si aprono con l’indirizzo giusto, i link alle mappe aprono le indicazioni.
• La pagina 404 esiste, è progettata e aiuta il visitatore a ritrovare la strada.

Moduli

• Ogni modulo si invia e il messaggio arriva nella casella giusta.
• Il visitatore vede una conferma chiara, e l’eventuale email di conferma arriva e si legge bene.
• Campi obbligatori, messaggi di errore e validazione funzionano, anche con un modulo vuoto.
• Gli errori sono segnalati con chiarezza e il focus si sposta sul primo campo sbagliato.
• La protezione antispam funziona senza bloccare le persone reali.
• La casella del consenso, dove serve, non è già spuntata e rimanda alla privacy policy.
• I dati dei moduli sono conservati o inoltrati solo dove lo dice la tua privacy policy.

Browser e dispositivi

• Versioni attuali di Chrome, Safari, Firefox ed Edge su desktop.
• Safari su iPhone e Chrome su Android, su telefoni reali, non solo in un emulatore.
• Le larghezze più comuni, dai telefoni piccoli agli schermi desktop larghi, in verticale e in orizzontale.
• Touch: i menu si aprono e si chiudono, nulla dipende dall’hover, le aree di tocco sono abbastanza grandi.
• Animazioni ed effetti di scorrimento funzionano e rispettano l’impostazione di sistema per la riduzione del movimento.
• Il sito funziona ancora, almeno nelle basi, quando uno script non si carica.

Prestazioni e Core Web Vitals

• Misura i tre Core Web Vitals descritti da Google nella documentazione di Search Central: Largest Contentful Paint (caricamento), Interaction to Next Paint (reattività) e Cumulative Layout Shift (stabilità visiva).
• Testa le pagine più pesanti, non solo la home page: un articolo lungo, una galleria, una scheda prodotto.
• Le immagini sono in formati moderni, dimensionate per lo spazio che occupano e caricate in lazy loading sotto la prima schermata.
• I font sono ospitati sul tuo server o precaricati, con un font di riserva che evita che le righe saltino.
• Cache e compressione sono attive e i file statici hanno una durata di cache lunga.
• Nessuno script di terze parti blocca il primo rendering.

Accessibilità

• Usa come obiettivo di lavoro il livello AA delle WCAG 2.2, la linea guida attuale del W3C.
• Ogni pagina si può usare solo con la tastiera, con un indicatore di focus visibile.
• Il contrasto del testo raggiunge 4,5:1 per il testo corrente e 3:1 per il testo grande, sul colore di fondo reale.
• Le immagini hanno un testo alternativo che le descrive, e quelle decorative un alt vuoto.
• I campi dei moduli hanno etichette e gli errori non sono indicati solo dal colore.
• Un test con screen reader (VoiceOver o NVDA) sui percorsi principali: home, un servizio, il modulo di contatto.
• Se vendi prodotti o determinati servizi ai consumatori nell’UE, verifica se si applica l’European Accessibility Act: la direttiva (UE) 2019/882 si applica dal 28 giugno 2025, con esenzioni per le microimprese che forniscono servizi.

Basi della SEO

• Ogni pagina ha un title e una meta description unici.
• Gli indirizzi sono brevi, in minuscolo e con trattini; la nostra guida agli URL SEO friendly spiega come sceglierli.
• Ogni pagina indica un link canonico e le pagine tradotte hanno l’hreflang.
• Esiste una sitemap XML che elenca solo le pagine che vuoi far trovare.
• Il robots.txt consente l’accesso al sito definitivo e non resta nessun «noindex» dallo staging.
• I dati strutturati (organizzazione, articoli, breadcrumb) si convalidano senza errori.
• Un’immagine e un titolo di condivisione appaiono correttamente quando si incolla un link in un’app di messaggistica.

Privacy, consenso e banner dei cookie

• Nessun tracker di analytics o pubblicità si carica prima che il visitatore lo accetti, come richiedono il GDPR e le norme ePrivacy.
• Rifiutare è facile quanto accettare, e la scelta viene ricordata.
• Il visitatore può cambiare la sua scelta in seguito da un link nel footer.
• La cookie policy elenca ogni cookie e ogni chiave di archiviazione del browser che il sito imposta davvero.
• Anche video incorporati, mappe e widget di chat aspettano il consenso, o usano una modalità rispettosa della privacy.

Sicurezza

• HTTPS su ogni indirizzo, con certificato valido che si rinnova da solo.
• HTTP e la versione www reindirizzano all’unico indirizzo preferito.
• Le intestazioni di sicurezza sono impostate (HSTS, tipo di contenuto, protezione dai frame, referrer policy).
• Le aree di amministrazione usano password robuste e accesso in due passaggi; gli account predefiniti sono rimossi.
• Software, temi e plugin sono aggiornati, e quelli inutilizzati sono rimossi.
• Moduli e pagine di accesso sono protetti dai tentativi ripetuti.
• Nessun file di test, backup o file di configurazione si può scaricare dal web.

Analytics e tracciamento

• Gli analytics registrano le visualizzazioni di pagina e gli eventi che contano (modulo inviato, chiamata cliccata, acquisto).
• Il traffico di test è escluso, o segnalato, così i dati della settimana di lancio restano puliti.
• La modalità di consenso, dove usata, trasmette la scelta del visitatore a ogni tag.
• Search Console e gli altri strumenti per webmaster sono verificati e la sitemap è inviata.

Backup e piano di ritorno

• Prima del lancio esiste un backup completo di file e database, conservato fuori dal server.
• I backup automatici sono programmati e un ripristino è stato davvero provato.
• Sai come rimettere online la versione precedente in pochi minuti se il lancio va male.
• Il monitoraggio dell’uptime è attivo e gli avvisi arrivano a una persona in grado di intervenire.

Come fare il QA di un sito web, passo dopo passo?

Una checklist funziona solo dentro un processo. Questo è l’ordine che seguiamo.

1. Blocca i contenuti. Concorda che testi, immagini e pagine legali sono definitivi per questo giro.
2. Scrivi il piano di test. Elenca pagine, percorsi, browser, dispositivi e larghezze da coprire, e chi testa cosa.
3. Esegui i controlli automatici. Scansione dei link, validazione HTML, scansione di accessibilità, misure delle prestazioni, screenshot a molte larghezze.
4. Esegui i controlli manuali. Percorri ogni percorso chiave su dispositivi reali: trovare un servizio, leggere un articolo, inviare un modulo, cambiare lingua.
5. Registra ogni difetto in un unico posto. Indirizzo, dispositivo, browser, passaggi per riprodurlo, screenshot e una gravità: bloccante, grave o minore.
6. Correggi e testa di nuovo. Ogni correzione è verificata da una persona diversa da chi l’ha fatta, e si testa di nuovo anche l’area intorno.
7. Fai la revisione go / no-go. Lancia solo quando non resta aperto nessun difetto bloccante e quelli gravi sono stati concordati per iscritto.
8. Lancia, poi testa il sito online. Ripeti i controlli critici sull’indirizzo definitivo entro la prima ora: moduli, consenso, redirect, HTTPS, analytics.
9. Tieni d’occhio la prima settimana. Controlla i log degli errori, il registro dei 404, la consegna dei moduli e Search Console, e correggi ciò che rivelano i visitatori reali.

Quali test servono e chi li esegue?

Non ogni test richiede uno specialista, e non ogni test si può automatizzare. La tabella qui sotto mostra i tipi principali, chi di solito li esegue, quando e con quali strumenti.

Tipo di test	Chi lo esegue	Quando	Strumenti tipici
Revisione dei contenuti	Cliente e copywriter	Dopo il blocco dei contenuti	Una checklist, un secondo lettore
Controllo di link e redirect	Sviluppatore	Prima e dopo il lancio	Un crawler, i log del server
Test di moduli ed email	Sviluppatore e cliente	Prima del lancio, poi online	Invii reali verso caselle reali
Browser e dispositivi	Tester QA o sviluppatore	Passaggio finale	Telefoni reali, servizi di test sui browser
Performance	Sviluppatore	Durante lo sviluppo e nel passaggio finale	Lighthouse, PageSpeed Insights, dati reali
Accessibilità	Designer e sviluppatore	Design, sviluppo e passaggio finale	Scanner automatico, tastiera, screen reader
Basi della SEO	Responsabile SEO o sviluppatore	Passaggio finale e giorno del lancio	Crawler, Search Console, test dei dati strutturati
Consenso e privacy	Sviluppatore e consulente legale	Passaggio finale	Strumenti per sviluppatori del browser, la cookie policy
Sicurezza	Sviluppatore o amministratore del server	Prima del lancio, poi con regolarità	Controllo delle intestazioni, report degli aggiornamenti, limiti di accesso
Collaudo utente	Cliente	Ultimo passo prima del lancio	I percorsi reali, un modulo di approvazione

Lo schema da notare: gli strumenti automatici sono veloci e accurati su ciò che si può misurare, mentre le persone servono per tutto ciò che richiede giudizio. Uno scanner ti dirà che un pulsante non ha un’etichetta; solo una persona ti dirà che l’etichetta confonde.

Quanto tempo richiede il QA di un sito web e da cosa dipende?

Il tempo dipende dalle dimensioni del sito, dal numero di template e di lingue, da quanti moduli e integrazioni contiene e da quanti dispositivi ti impegni a coprire. Un piccolo sito vetrina con un modulo si testa bene in poco tempo. Un sito multilingue con negozio online, sistema di prenotazione e animazioni su misura richiede giorni di passaggi accurati e almeno un giro di correzioni.

Ciò che rallenta di più il QA non sono i test, ma i contenuti in ritardo, la responsabilità poco chiara delle correzioni e l’assenza di una scala di gravità concordata. Quando tutti sanno cosa significa «bloccante», la decisione go / no-go diventa semplice.

Per una singola pagina di campagna l’elenco è più breve e la logica del budget è diversa; il nostro articolo su quanto costa una landing page spiega come si definisce il perimetro di queste pagine.

Cosa va storto più spesso al lancio?

Gli stessi difetti si ripresentano di continuo, e quasi tutti costano poco da intercettare prima:

• Moduli di contatto che inviano a una casella di test, o le cui email finiscono nello spam.
• L’impostazione «scoraggia i motori di ricerca» o un tag noindex rimasti attivi dallo staging.
• Tracker che partono prima del consenso, perché un tag è stato aggiunto fuori dallo strumento di gestione del consenso.
• Vecchi indirizzi senza redirect, così i link da altri siti e dai risultati di ricerca finiscono su un 404.
• Un menu o un popup che non si chiude su un telefono, o una pagina che non scorre.
• Immagini caricate alla dimensione originale della fotocamera, che rallentano la prima schermata con i dati mobili.
• Una cache che continua a mostrare ai visitatori il vecchio foglio di stile dopo una modifica.

Ognuno di questi punti è nella checklist qui sopra. Lo scopo di un elenco scritto è che nessuno debba ricordarseli sotto pressione.

Le domande più comuni

Se il tuo sito è vicino al lancio e vuoi che sia testato come si deve, o stai pianificando un nuovo sito e vuoi il QA integrato nel lavoro fin dal primo design, il nostro team di realizzazione siti web può aiutarti: parlaci del tuo progetto e vedremo di cosa ha bisogno il tuo lancio.

Per approfondire: Sicurezza WordPress nel 2027: le minacce e i rimedi, Accessibilità dei siti web: cosa chiede l’European Accessibility Act, Quanto tempo serve per realizzare un sito web? I tempi fase per fase, Checklist per un audit UX: cosa controllare e come condurlo in sette passaggi, Checklist SEO per il restyling del sito web: rifare il sito senza perdere traffico organico.