Disponibilità
La risorsa corretta risponde nel modo corretto
Pagina, asset ed endpoint restituiscono lo stato previsto, usano HTTPS e non dipendono da catene di redirect o configurazioni fragili.
Guide
Checklist tecnica di un sito web professionale nel 2026: cosa verificare davvero
Un sito non è pronto perché la homepage si apre e il layout sembra corretto. È pronto quando server, URL, contenuti, funzioni, email, sicurezza e misurazione continuano a raccontare la stessa realtà anche fuori dall’anteprima.
La risposta breve
La verifica professionale attraversa l’intero percorso: risposte HTTP e redirect, indicizzazione, metadati, immagini, HTML semantico, tastiera, JavaScript, moduli, consegna email, sicurezza, analytics e controlli sul sito pubblicato. Un punteggio o un tool isolato non dimostrano che il sistema completo funzioni.
Gian Luca Partengo
Sviluppatore web dal 1995 · Aggiornato
Quando un sito web è davvero pronto dal punto di vista tecnico?
La risposta non coincide con l’assenza di errori visibili. Quattro condizioni devono restare vere insieme.
Comprensione
Contenuto e relazioni sono leggibili
Titoli, link, metadati, canonical e dati strutturati descrivono la stessa pagina senza segnali tardivi o contraddittori.
Uso
Le funzioni reggono condizioni reali
Menu, moduli, media e interazioni funzionano con tastiera, touch, zoom, viewport diversi, errori e connessioni non ideali.
Osservabilità
Il progetto può essere controllato nel tempo
Errori, visite, ricerca, email, scadenze e modifiche hanno strumenti, responsabilità e baseline che rendono verificabili i cambiamenti.
Quali risposte HTTP, configurazioni server e controlli TLS verificare?
Browser, crawler e integrazioni ricevono prima una risposta di rete. Se è sbagliata, ciò che appare sullo schermo può essere fuorviante.
200 soltanto per risorse realmente disponibili
Una pagina valida restituisce 200. Un contenuto assente che mostra un messaggio ma resta 200 genera una soft 404 e comunica uno stato falso.
301 o 308 per spostamenti permanenti
Il redirect porta direttamente alla destinazione canonica. Catene, loop e passaggi superflui aumentano latenza e ambiguità.
404 o 410 per risorse assenti
La pagina di errore può aiutare a proseguire, ma deve conservare lo stato corretto e non trasformare ogni URL inesistente nella homepage.
Errori 5xx osservabili e diagnosticabili
Un errore server non va mascherato come successo. Log tecnici, identificativi di richiesta e procedure di ripristino devono permettere di ricostruire l’accaduto senza esporre dati personali.
HTTPS coerente su tutto il percorso
Certificato, rinnovo, redirect da HTTP, risorse miste e hostname alternativi vanno verificati insieme: il lucchetto non certifica il resto del sito.
Header coerenti con contenuto e rischio
Content-Type, caching, compressione e header di sicurezza devono descrivere e proteggere la risposta senza rompere funzioni legittime.
Il controllo va ripetuto sulla risorsa finale e non soltanto sulla homepage: pagine, immagini, file, endpoint e varianti linguistiche possono avere comportamenti diversi.
Come verificare URL, redirect e pagine di errore senza perdere segnali?
Un indirizzo stabile collega navigazione, campagne, motori di ricerca, analytics e condivisioni. Cambiarlo richiede una decisione editoriale e tecnica unica.
Versione
Una sola destinazione rappresentativa
Protocollo, host, slash, maiuscole e parametri devono convergere in modo coerente verso la versione scelta, senza generare duplicati involontari.
Spostamento
Ogni vecchio URL raggiunge l’equivalente reale
Il redirect conserva l’intento. Mandare indiscriminatamente pagine eliminate alla home confonde persone e crawler e non sostituisce una mappa di migrazione.
Varianti
Filtri e parametri non moltiplicano il contenuto
Ordinamenti, tracking e query string devono essere gestiti affinché non creino percorsi infiniti, canonical contraddittorie o report ingestibili.
Errore utile
La 404 orienta senza fingere che la pagina esista
Messaggio, ricerca o collegamenti pertinenti aiutano l’utente; lo status HTTP conserva però la verità tecnica della risorsa mancante.
La regola pratica
Ogni URL pubblico deve avere un destino documentato: resta, si sposta, viene sostituito oppure termina con uno stato di assenza corretto.
Come rendere pagine e risorse scopribili senza confondere crawling e indicizzazione?
robots.txt, sitemap e canonical offrono segnali differenti. Nessuno di questi strumenti garantisce da solo che una pagina venga indicizzata.
Link HTML reali e percorsi interni
Le pagine importanti devono essere raggiungibili attraverso link con href, testo significativo e contesto, non soltanto tramite eventi JavaScript o sitemap.
Sitemap con sole URL canoniche
La sitemap elenca pagine pubbliche, indicizzabili e aggiornate. Redirect, 404, risultati interni e varianti duplicate non vi appartengono.
robots.txt governa l’accesso, non la rimozione
Bloccare il crawling non equivale a richiedere la deindicizzazione. Direttive, meta robots e accessibilità della pagina vanno progettati consapevolmente.
Canonical presente nell’HTML iniziale
Una canonical assoluta e coerente consolida le varianti. Modificarla in ritardo con JavaScript o dichiararne più di una crea segnali evitabili.
Lingue reciproche e URL realmente tradotte
Ogni variante linguistica indica le alternative corrette, compresa se utile x-default, mantenendo canonical autoreferenziali e contenuti localizzati.
Indicizzazione verificata con strumenti ufficiali
L’assenza dalla ricerca non si diagnostica guardando la SERP una volta. Servono ispezione URL, sitemap, stato, canonical scelta e tempo di elaborazione.
Per distinguere scoperta, crawling, rendering e indicizzazione consulta la guida sul perché un sito non appare su Google.
Come controllare title, description, heading e dati strutturati?
I metadati non riparano una pagina povera. Devono riassumere fedelmente un contenuto visibile e coerente con l’intento dell’URL.
Identità
Title unico, descrittivo e specifico
Il title distingue la pagina dalle altre e anticipa il tema senza accumulare keyword, formule ripetute o promesse assenti nel contenuto.
Sintesi
Description coerente con la pagina
La descrizione aiuta a comprendere il risultato ma può essere riscritta dal motore. Va trattata come sintesi utile, non come leva di ranking garantita.
Struttura
Heading che organizzano, non che decorano
Un H1 chiaro e sottosezioni ordinate rendono leggibile la gerarchia. Il livello dipende dalla struttura del contenuto, non dalla dimensione grafica desiderata.
Dati
Schema coerente con ciò che si vede
Tipi, proprietà, URL, date, autore e offerte devono essere reali, collegati e presenti nella pagina. Dati inventati o duplicati riducono affidabilità.
Quali controlli servono per immagini, formati e anteprime social?
La stessa immagine può avere ruoli diversi nel contenuto, nella card e nella condivisione. Ogni ruolo richiede dimensioni, ritaglio e metadati coerenti.
Sorgenti adeguate al viewport
srcset, sizes o picture permettono al browser di scegliere la risorsa giusta invece di scaricare sempre l’originale più grande.
Formato scelto sul contenuto
AVIF, WebP, JPEG, PNG e SVG hanno vantaggi diversi. La scelta considera supporto, trasparenza, dettaglio, compressione e destinazione.
Compressione controllata sul risultato
Non esiste un peso universale: si verifica qualità percepita, dimensione resa e costo di trasferimento, evitando originali sproporzionati.
Spazio riservato prima del caricamento
Width, height o aspect-ratio impediscono che testo e controlli vengano spostati mentre l’immagine arriva.
Testo alternativo utile o volutamente vuoto
Le immagini informative richiedono una descrizione contestuale; quelle decorative alt vuoto. Il nome file non è una descrizione.
OG verificata nella pagina reale
Titolo, descrizione, URL, immagine e alt social devono essere assoluti e coerenti. Una cover mancante o sbagliata compromette anteprima e riconoscibilità.
Per approfondire consegna, priorità e costo delle risorse leggi perché un sito diventa lento.
Perché HTML semantico e accessibilità fanno parte della verifica tecnica?
La struttura nativa comunica ruolo e relazione a browser, tastiera, tecnologie assistive e crawler. Ricostruirla con div e script aumenta il rischio.
Struttura
Elementi nativi per contenuto e azioni
Heading, nav, main, button, a, label e form espongono significato e comportamenti attesi. ARIA integra, non sostituisce HTML corretto.
Tastiera
Ogni funzione resta raggiungibile e visibile
Ordine del focus, apertura, chiusura, menu, modali e azioni devono funzionare senza puntatore e senza trappole.
Comprensione
Nomi, istruzioni ed errori sono associati
Controlli, campi e icone hanno nomi accessibili; gli errori spiegano cosa correggere e il focus porta al riepilogo pertinente.
Stati
Hover non è l’unico feedback
Focus, selezione, caricamento, errore, successo e disabilitazione restano percepibili anche senza colore, animazione o mouse.
Per obblighi, perimetro e verifica WCAG consulta la guida all’accessibilità dei siti web.
Come verificare JavaScript, responsive e prestazioni senza fermarsi a una demo?
Il sito va attraversato con contenuti, errori e dispositivi reali. Il fatto che una pagina funzioni nel browser dello sviluppatore non dimostra robustezza.
Contenuto essenziale nell’HTML iniziale
Titolo, testo, link e segnali principali devono essere disponibili senza affidare l’intera comprensione a un rendering successivo.
Console pulita nei percorsi verificati
Eccezioni, risorse mancanti e promesse rifiutate possono rivelare funzioni interrotte anche quando la parte visiva sembra integra.
Fallimenti gestiti senza pagina inutilizzabile
Se uno script o un servizio esterno non risponde, contenuto e azioni essenziali dovrebbero restare disponibili o mostrare un errore comprensibile.
Layout verificato fra i breakpoint
Non bastano telefono e desktop: larghezze intermedie, zoom, orientamento e contenuti lunghi rivelano overflow e righe incomplete.
Movimento controllabile e riducibile
Autoplay, reveal e transizioni non devono nascondere informazioni, bloccare interazioni o ignorare la preferenza di movimento ridotto.
Prestazioni lette come percorso
Server, cache, font, immagini, script e terze parti incidono insieme. Una misurazione sintetica aiuta, ma va collegata alle cause e all’esperienza reale.
Come collaudare moduli ed email dall’inserimento alla ricezione?
La conferma visuale non basta: bisogna distinguere validazione, protezione dagli abusi, accettazione del trasporto e consegna alla casella.
Ingresso
Validazione sia nel browser sia sul server
Lato client si aiuta l’utente; lato server si applicano limiti, formati e regole reali. Il server non si fida di campi nascosti o JavaScript.
Abusi
Spam e invii ripetuti sono limitati
Honeypot, tempi, token, rate limit e controlli contestuali si combinano senza trasformare il modulo in un ostacolo permanente.
Trasporto
Successo soltanto dopo la notifica principale
La pagina conferma l’invio quando il trasporto accetta il messaggio principale. L’autoreply viene dopo e un suo errore non cancella una notifica già accettata.
Ricezione
Inbox, spam, Reply-To e autenticazione si provano
SPF, DKIM, DMARC, header originali e una casella esterna aiutano a verificare il percorso che il solo codice non può certificare.
Accettato non significa consegnato
Un esito positivo della funzione di invio indica che il sistema di trasporto ha accettato il messaggio; non garantisce che sia arrivato nella casella o nella posta in arrivo.
Per il flusso completo consulta la guida a moduli, spam, sicurezza ed email.
Quali controlli di sicurezza e manutenzione non possono mancare?
Nessun sito è automaticamente sicuro. Il lavoro consiste nel ridurre superficie, privilegi e conseguenze, mantenendo procedure di aggiornamento e ripristino.
Browser
Header di sicurezza calibrati sul sito
CSP, HSTS, frame, referrer e policy delle funzionalità vanno configurati sul comportamento reale, non copiati in modo da rompere risorse o creare falsa sicurezza.
Applicazione
Input, output e privilegi sono controllati
Validazione, escaping, token, autorizzazione, segreti separati e permessi minimi proteggono i confini in cui entrano dati o partono azioni.
Componenti
Ogni dipendenza ha motivo e responsabilità
Librerie, plugin, API e servizi terzi richiedono inventario, aggiornamenti, licenze, accessi e una procedura quando cambiano o smettono di funzionare.
Continuità
Backup e ripristino vengono provati
Un backup non verificato è una speranza. Copie, frequenza, conservazione, accessi e prova di recupero devono essere compatibili con il rischio del progetto.
Per approfondire superficie d’attacco, aggiornamenti e ripristino leggi la guida alla sicurezza di un sito web.
Come monitorare il sito senza raccogliere dati inutili?
Misurare non significa installare ogni tag disponibile. Significa definire domande, eventi, responsabilità e limiti coerenti con privacy e obiettivi.
Uso
Analytics collegati a decisioni reali
Pagine di ingresso, sorgenti e conversioni aiutano soltanto se nomenclatura, filtri e obiettivi restano stabili e comprensibili.
Ricerca
Search Console separa presenza e traffico
Sitemap, indicizzazione, impressioni, query e pagine vengono letti nel tempo, senza confondere assenza di dati con errore tecnico.
Funzioni
Errori e percorsi critici hanno segnali utili
Log minimizzati, controlli periodici e alert proporzionati devono rendere visibili guasti, scadenze e regressioni senza registrare dati personali non necessari.
Confronto
Una baseline precede ogni giudizio
URL, data, ambiente, dispositivo e risultato creano una base confrontabile. Senza contesto, un numero isolato non spiega cosa sia cambiato.
Quale checklist usare prima di pubblicare un sito?
Il pre-pubblicazione serve a eliminare errori noti prima che cache, DNS, crawler, campagne e utenti li rendano più costosi da correggere.
-
01
Mappa pagine, URL e redirect
Conferma pagine nuove, vecchie, eliminate, lingue, stato HTTP e destinazione di ogni URL interessato.
-
02
Rivedi contenuti e metadati insieme
Title, description, H1, link, dati, prezzi, contatti, schema e anteprima social devono descrivere la versione approvata.
-
03
Attraversa viewport e contenuti reali
Controlla telefono, tablet, desktop, zoom, orientamento, lingue lunghe, immagini mancanti e quantità di testo realistiche.
-
04
Completa i percorsi con la tastiera
Menu, modali, form e CTA devono avere focus visibile, ordine logico, chiusura e feedback comprensibili.
-
05
Simula successo ed errore dei moduli
Verifica validazione, conservazione sicura dei campi, limiti, notifica, autoreply, Reply-To e comportamento quando il trasporto rifiuta.
-
06
Valida canonical, hreflang e schema
Le URL devono essere assolute, reciproche e coerenti con lingua, breadcrumb, contenuto visibile e sitemap.
-
07
Rimuovi debug, accessi e segreti esposti
Disattiva strumenti temporanei, limita permessi, verifica header e assicurati che configurazioni e backup non siano pubblicamente raggiungibili.
-
08
Registra una baseline locale o di staging
Conserva test, viewport, pagine e condizioni così che la verifica pubblica possa distinguere una regressione da una differenza di ambiente.
Quali controlli ripetere dopo la pubblicazione?
Hosting, cache, DNS, regole server e servizi esterni appartengono al risultato reale. La verifica termina sul sito pubblico, non sul file caricato.
-
01
Controlla stato e destinazione pubblici
Verifica pagine rappresentative, redirect, 404, HTTPS e varianti linguistiche dalla rete esterna.
-
02
Controlla cache e asset effettivamente serviti
HTML, CSS, JavaScript, font e immagini devono corrispondere alla versione pubblicata senza mix di file vecchi e nuovi.
-
03
Invia una prova reale a una casella esterna
Verifica notifica, autoreply, Reply-To, cartella di arrivo e header originali, senza trasformare il test in un evento commerciale.
-
04
Rileggi robots, sitemap e canonical
Assicurati che il dominio pubblico, gli URL finali e le risorse raggiungibili coincidano con ciò che era previsto in locale.
-
05
Conferma analytics senza dati personali
Pagina vista ed eventi autorizzati devono arrivare una volta, con nomi corretti e senza proprietà che espongano contenuti dei campi.
-
06
Ripeti percorsi e console sul sito pubblico
CSP, CORS, cache e origini esterne possono generare errori assenti nell’ambiente locale.
-
07
Conferma backup e possibilità di ritorno
Il punto di ripristino deve precedere la modifica e la procedura deve essere utilizzabile senza improvvisare durante un guasto.
-
08
Registra esito, data e responsabilità
Una chiusura tracciata permette di sapere cosa è stato verificato, cosa resta da osservare e chi interviene se cambia qualcosa.
Chi deve mantenere la checklist dopo il lancio?
Una verifica tecnica non è un documento da archiviare. Ogni modifica a contenuti, dipendenze, server o servizi può cambiare il risultato.
Metodo di lavoro
Ogni controllo deve avere un responsabile e un momento
Nel mio metodo sviluppo, contenuto e infrastruttura vengono verificati come un unico sistema. Le responsabilità non vengono scaricate su un plugin o su un punteggio automatico.
La manutenzione segue il rischio e le modifiche reali: non significa rifare ogni audit ogni giorno, ma sapere quali controlli ripetere e perché.
- Prima di ogni pubblicazione rilevante
- Dopo deploy, cache e modifiche server
- Quando cambiano moduli, email o terze parti
- Dopo aggiornamenti di dipendenze o browser
- Quando i dati mostrano una regressione
- Con scadenze definite per domini, certificati e backup
Quali fonti primarie sostengono questa checklist?
La guida sintetizza requisiti e pratiche da documentazione ufficiale. Ogni progetto deve adattarli alla propria architettura, al rischio e alla normativa applicabile.
-
Google Search Central — Requisiti tecniciApri la fonte
Requisiti minimi perché una pagina sia idonea a comparire nella Ricerca Google, compresa la risposta HTTP 200.
-
Google Search Central — Redirect e RicercaApri la fonte
Differenza fra redirect permanenti e temporanei e ruolo dei redirect server-side nella canonicalizzazione.
-
Google Search Central — CanonicalizzazioneApri la fonte
Segnali usati per scegliere una URL rappresentativa e rapporto fra canonical, redirect e sitemap.
-
Google Search Central — JavaScript SEOApri la fonte
Crawling, rendering, link, status HTTP, title, description e canonical nei siti che usano JavaScript.
-
Google Search Central — Guida per sviluppatoriApri la fonte
Link scansionabili, sitemap, URL uniche e controlli di base per rendere il sito comprensibile alla Ricerca.
-
W3C — Web Content Accessibility Guidelines 2.2Apri la fonte
Criteri verificabili per contenuto percepibile, interfacce utilizzabili, comprensione e robustezza.
-
W3C WAI — Forms TutorialApri la fonte
Etichette, raggruppamenti, istruzioni, errori e pratiche per moduli comprensibili e accessibili.
-
OWASP — Secure Headers ProjectApri la fonte
Documentazione e strumenti ufficiali sugli header HTTP che riducono vulnerabilità evitabili nei browser.
-
PHP Manual — mail()Apri la fonte
Il valore true indica accettazione per la consegna, non l’arrivo effettivo alla casella del destinatario.
-
W3C WAI — Easy ChecksApri la fonte
Controlli preliminari su titoli, immagini, contrasto, zoom, tastiera, moduli e struttura.
Fonti controllate il 23 settembre 2026. Specifiche, browser, strumenti e normative possono evolvere: una verifica professionale usa sempre la documentazione corrente.
Quali sono i dubbi più comuni sulla checklist tecnica?
Risposte dirette per usare la checklist senza trasformarla in una promessa automatica di qualità.
Esiste un solo tool che controlla tutto il sito?
No. Risposte HTTP, rendering, accessibilità, email, sicurezza, analytics e contenuti richiedono strumenti e prove differenti. Un report automatico è utile nel proprio perimetro, ma non sostituisce il collaudo end-to-end.
Se la homepage funziona, il sito è tecnicamente a posto?
No. Pagine interne, 404, redirect, lingue, form, immagini, file e percorsi di conversione possono usare regole diverse. Serve un campione rappresentativo e i percorsi critici vanno attraversati interamente.
robots.txt può togliere una pagina da Google?
robots.txt limita il crawling ma non è uno strumento di rimozione dall’indice. Una URL bloccata può essere comunque conosciuta. Deindicizzazione, accesso e crawling sono decisioni diverse.
La sitemap garantisce l’indicizzazione?
No. La sitemap suggerisce URL e aggiornamenti, ma il motore valuta accessibilità, stato HTTP, canonical, contenuto e altri segnali. Deve contenere soltanto URL canoniche che il sito desidera indicizzare.
Una funzione di invio email che restituisce successo garantisce la ricezione?
No. Dimostra al massimo che il trasporto ha accettato il messaggio. Consegna, autenticazione, filtri e cartella di arrivo vanno verificati con un invio reale e, quando possibile, con gli header originali.
Quante pagine bisogna controllare?
Dipende dall’architettura. Si controllano almeno tutti i template e i percorsi distinti, più homepage, contenuti principali, form, 404, redirect, pagine multilingua e stati di errore. I siti dinamici richiedono campioni di dati reali.
La checklist sostituisce una verifica WCAG?
No. Include controlli strutturali utili, ma una verifica di conformità richiede perimetro, criteri applicabili, test manuali e con tecnologie assistive, documentazione e processi di mantenimento.
Quando bisogna ripetere i controlli?
Dopo modifiche rilevanti a codice, contenuti, dipendenze, server, DNS, cache, form, email o servizi terzi; inoltre secondo una cadenza proporzionata al rischio e alle scadenze del progetto.
L’Analizzatore gratuito è un audit completo?
No. Offre una prima fotografia di prestazioni mobile, possibile impronta WordPress, peso indicativo e alcuni header di sicurezza. Non verifica l’intera checklist di questa guida.
Chi è responsabile dei problemi dopo la pubblicazione?
Dipende da contratto, proprietà e gestione. È essenziale assegnare responsabilità per hosting, codice, contenuti, domini, email, account, backup e servizi terzi prima del lancio, non durante un guasto.
Prossimo passo
Vuoi un sito costruito e verificato come un sistema completo?
Struttura, SEO tecnica, accessibilità di base, prestazioni, sicurezza, moduli e controlli di pubblicazione fanno parte dello standard dei siti che realizzo. Nessun badge automatico: responsabilità e verifiche dichiarate.