Checklist prima di pubblicare un sito web: 60 Controlli (2026)

Questa è la mia personale checklist prima di pubblicare un sito web, divisa in 5 aree: SEO di base, performance (Core Web Vitals), accessibilità, sicurezza e backup, analytics e aspetti legali. Questo è la checklist completa che uso su ogni progetto, 60 controlli reali, non teorici, prima del go-live.

SEO di base: titolo, meta, sitemap, robots, redirect

La SEO non si fa con un plugin. È una questione di struttura. Puoi avere Rank Math o Yoast configurati alla perfezione, ma se gli heading sono usati come preset estetici e il robots.txt blocca Google, il sito è invisibile.

Prima del lancio, questi sono i controlli SEO che non si saltano.

Un solo H1 per pagina (e perché è l’errore più comune)

Ogni pagina deve avere esattamente un tag H1, che contiene la keyword principale. Gli H2, H3 e così via devono seguire una gerarchia logica, non vengono usati perché “quel font ha la grandezza giusta”.

L’errore che vedo di più, anche su siti da migliaia di euro: il tema WordPress inserisce automaticamente il titolo del sito nell’H1 del footer o della barra laterale. Risultato: due H1 per pagina e gerarchia rotta per tutti i motori di ricerca.

Controlla con strumenti come SEO Meta in 1 Click (estensione Chrome) o direttamente dall’inspector. Un solo H1, keyword principale posizionata all’inizio della pagina, nient’altro.

Mentre sei lì, verifica anche:

• Meta title ≤ 60 caratteri, keyword prima, brand alla fine. Scritto per il CTR, non per riempire il campo.
• Meta description ≤ 155 caratteri. Includi la keyword, il valore specifico che offri, una call-to-action morbida.
• URL pulito, breve, senza date, con parole chiave separate da trattini. Niente ID numerici, niente parametri.
• Open Graph configurato: og:title, og:description, og:image. Determina come appare il link quando viene condiviso su WhatsApp, LinkedIn, Facebook.
• Canonical tag su tutte le pagine: evita contenuti duplicati da versioni con/senza www o parametri UTM.

Sitemap XML e Google Search Console

La sitemap XML dice ai motori di ricerca quali pagine esistono e quanto spesso si aggiornano. Senza, Google le troverà lo stesso, ma ci metterà più tempo.

Cosa fare:

1. Genera la sitemap con il tuo plugin SEO (Rank Math o Yoast la crea automaticamente).
2. Accedi a Google Search Console e verifica la proprietà del dominio.
3. Invia la sitemap: Sitemaps → Aggiungi una nuova sitemap → URL della sitemap.
4. Aspetta 24–48 ore e controlla che non ci siano errori di copertura.

Un redirect 301 coerente tra versione www e non-www è obbligatorio. Scegli una versione e mandaci tutto il traffico.

robots.txt: il blocco invisibile che nessuno controlla

Il file robots.txt dice ai crawler cosa possono e non possono scansionare. Il problema è che, durante lo sviluppo, questo file spesso blocca tutto per evitare che il sito in costruzione appaia su Google.

Su WordPress, vai in Impostazioni → Lettura. Quella casella che dice “Scoraggia i motori di ricerca dall’indicizzare questo sito”, assicurati che sia disattivata.

Se è attiva, il sito è online ma invisibile. L’ho vista attiva su siti già pubblicati da mesi.

Controlla anche il file robots.txt all’indirizzo tuosito.com/robots.txt.

Non deve contenere Disallow: / globale. Le directory sensibili come /wp-admin/ possono essere bloccate, tutto il resto deve essere accessibile.

I Plugin SEO che consiglio: Rank Math e Yoast SEO

• Rank Math: Plugin SEO completo per WordPress: gestione di title, meta description, canonical, schema markup, redirect manager, sitemap avanzata, analisi keyword integrata e molto altro. Il plugin SEO che uso su ogni sito che sviluppo. Copre tutti i controlli SEO di questa checklist prima di pubblicare un sito.
• Yoast SEO: Alternativa storica a Rank Math: editor SEO guidato con semaforo, readability check, integrazione meta OG e Twitter card. Ottimo per clienti che gestiscono i contenuti in autonomia e preferiscono un’interfaccia più semplice.

Performance e Core Web Vitals

Un ritardo di 100ms nel TTFB (Time to First Byte) può ridurre il tasso di conversione del 7%. Non è un’opinione, è un dato operativo emerso dall’analisi di migliaia di siti. La velocità non è un dettaglio tecnico: è un fattore di conversione.

Google ha definito i Core Web Vitals come misure standard delle prestazioni percepite dall’utente. Sono fattori di ranking ufficiali dal 2021.

LCP, CLS, INP — i target reali

Misura con PageSpeed Insights (dati field, non solo lab) e GTmetrix. Il test da mobile conta più del desktop, è lì che la maggior parte degli utenti arriva.

Immagini WebP, lazy load, width e height (no CLS)

Le immagini sono quasi sempre il collo di bottiglia del LCP. Regole operative:

• Formato: WebP obbligatorio (o AVIF per i browser moderni). Peso ridotto del 25–35% rispetto a JPG equivalente.
• Lazy load: loading="lazy" su tutte le immagini tranne l’hero. L’hero usa loading="eager" e fetchpriority="high".
• Width e height espliciti su ogni <img>: anche quando usi CSS per adattarli. Senza, il browser non sa quanto spazio riservare e il layout si sposta (CLS).
• Preload dell’immagine hero: aggiungi <link rel="preload" as="image" href="hero.webp"> nel <head> per caricarla prima.

Cache, GZIP/Brotli, minificazione CSS/JS

Tre leve che abbassano il TTFB e il peso totale della pagina:

1. Cache lato server: una pagina già generata risponde 10× più veloce di una calcolata al volo. Con WordPress: W3 Total Cache, WP Rocket, o la cache nativa del tuo hosting.
2. Compressione: GZIP o Brotli sull’HTML, CSS e JS. Riduci il peso trasferito del 60–80%. Si attiva via .htaccess o dalla configurazione del server. Verifica su GTmetrix.
3. Minificazione e audit plugin: ogni plugin WordPress è un potenziale freno. Se una funzionalità si può risolvere con 10 righe nel functions.php, il plugin non si installa. Audita la lista dei plugin attivi prima del lancio ed elimina tutto il ridondante.

Il PHP deve essere alla versione 8.2 o superiore. Versioni precedenti sono più lente e non ricevono aggiornamenti di sicurezza. Verifica in Strumenti → Salute del sito su WordPress.

Cache plugin consigliato: Airlift

Il plugin cache che uso sulla maggior parte dei miei siti. Ottimizzazione automatica di immagini, CSS e JS, CDN integrato, regole di cache granulari. Rispetto ai plugin cache gratuiti classici, i miglioramenti sui Core Web Vitals sono significativi, soprattutto su LCP e TTFB. Configurazione rapida, risultati misurabili su PageSpeed Insights.

Accessibilità — WCAG 2.2 e EAA 2025

L’accessibilità non è un optional per grandi aziende. Dal 2025, la European Accessibility Act (EAA) si applica anche a servizi digitali di aziende private con più di 10 dipendenti o 2 milioni di fatturato. E anche al di fuori dell’obbligo legale: un sito accessibile funziona meglio per tutti, inclusi gli utenti su connessioni lente o dispositivi di fascia bassa.

Ho dedicato un intero articolo ai requisiti di accessibilità sito web 2025 e EAA, leggilo se vuoi approfondire. Qui elenco i controlli pre-lancio essenziali.

Contrasti minimi, target di tocco, gerarchia heading

Le WCAG 2.2 del W3C definiscono tre livelli (A, AA, AAA). Il target minimo per la conformità è il livello AA:

• Contrasto colore testo/sfondo: ≥ 4.5:1 per testo normale, ≥ 3:1 per testo grande (≥18pt o ≥14pt bold). Usa WebAIM Contrast Checker per verificare.
• Touch target: ≥ 44×44px per tutti i link e i bottoni. Su mobile, un bottone “piccolo e elegante” che non si riesce a cliccare è un bottone inutile.
• Gerarchia heading: H1 → H2 → H3, senza salti. Non si passa da H1 a H4 solo perché “la dimensione del font è giusta”.

Alt text, form accessibili, focus management

• Alt text su tutte le immagini che veicolano informazioni. Le immagini decorative usano alt="". Mai omettere l’attributo, lo screen reader legge il nome del file altrimenti.
• Form: ogni campo <input> deve avere un <label> collegato via for/id. Il placeholder non sostituisce la label.
• Focus visibile su tutti gli elementi interattivi. outline: none è il peggior nemico dell’accessibilità, rimuoverlo per “estetica” invalida la navigazione da tastiera.
• Lingua dichiarata nel tag HTML: lang="it". Serve agli screen reader per scegliere la voce corretta.

Sicurezza e backup

Un sito violato non è solo un problema tecnico. È una potenziale responsabilità legale, danni di immagine difficili da riparare e, nei casi peggiori, perdita di dati dei clienti. La sicurezza non si improvvisa dopo il lancio.

Il lancio non è un click: è un incontro di competenze. E la sicurezza è la competenza che i clienti non vedono ma danno per scontata.

SSL, redirect HTTPS e mixed content

Il certificato SSL trasforma HTTP in HTTPS e cifra la comunicazione tra browser e server. È prerequisito fondamentale, Google segnala i siti HTTP come “non sicuri” e penalizza il ranking.

Tre cose da verificare:

1. Certificato attivo e valido per almeno 90 giorni. Con rinnovo automatico (Let’s Encrypt è gratuito e si rinnova da solo).
2. Redirect 301 forzato HTTP → HTTPS via .htaccess o configurazione server. Nessuna versione HTTP deve restare raggiungibile.
3. Nessun “Mixed Content” — risorse (immagini, script, font) caricate in HTTP su una pagina HTTPS. Rompono l’indicatore di sicurezza del browser. Cerca con la console di Chrome o tool come Why No Padlock.

Hardening: XML-RPC, login protection, no utente “admin”

WordPress è il CMS più usato al mondo — e il più attaccato. Queste non sono precauzioni paranoiche: sono standard operativi.

• Elimina l’utente “admin”: è il primo username che i bot di brute-force provano. Crea un nuovo utente amministratore con nome personalizzato, poi elimina “admin”.
• Limit Login Attempts: blocca l’IP dopo 3–5 tentativi falliti. Plugin: Limit Login Attempts Reloaded o WP Cerber.
• Disattiva XML-RPC se non usi Jetpack o app mobile: è un vettore di attacco frequente. Un plugin o due righe nel functions.php bastano.
• Permessi file corretti: 755 per le cartelle, 644 per i file. Niente permessi 777.

Backup esterno + test di ripristino

Un backup non testato è un backup che non esiste.

L’ho detto a ogni cliente, lo ripeto qui: un backup sullo stesso server dell’hosting non ti protegge se il server viene compromesso, bruciato o spento senza preavviso. Ho visto clienti perdere anni di lavoro per questo.

Le regole operative che uso su ogni progetto:

• Storage esterno obbligatorio: AWS S3, Wasabi, Google Cloud Storage o BackupBuddy con Dropbox. Non sullo stesso server.
• Retention minima: 30 giorni di storico. Spesso un attacco malware si scopre settimane dopo l’infezione.
• Test di ripristino reale prima del go-live: ripristina il backup su un ambiente di staging e verifica che tutto funzioni. Non il giorno in cui il sito crasha alle 2 di notte.

Antispam: reCAPTCHA v3 o Honeypot, email obfuscation

I bot scansionano i form di contatto. Senza protezione, riceverai spam industriale entro ore dal lancio.

• Cloudflare Turnstile (gratuito, nessun puzzle, nessuna dipendenza da Google, conforme GDPR). La mia prima scelta per i nuovi progetti: zero attrito per l’utente, zero costo, massima compatibilità.
• hCaptcha: (alternativa privacy-first a reCAPTCHA, conforme GDPR, verifica visiva solo su richieste sospette). Buona scelta per chi vuole uscire dall’ecosistema Google.
• Google reCaptcha: (invisibile, punteggio di rischio automatico, nessun puzzle per l’utente). Molto diffuso e affidabile, ma invia dati a Google. Da valutare in base alla policy privacy del progetto.
• Honeypost: (campo nascosto nel form compilato dai bot, ignorato dagli utenti reali, zero overhead JS, 100% accessibile). Ottimo come strato aggiuntivo o come soluzione standalone per form semplici con traffico basso.
• Email non in plain-text nel codice HTML. Gli scraper la raccolgono in secondi. Usa codifica HTML entities per mailto: o un form di contatto al posto dell’indirizzo diretto.

I Plugin che consiglio per i Backup: BlogVault e Updraft Plus

• BlogVault: Backup incrementali in tempo reale, staging integrato con un click, migrazione semplificata tra hosting. Il plugin che uso sui progetti con esigenze di recovery critiche. Dashboard centralizzata per gestire più siti in parallelo. Il test di ripristino reale (obbligatorio in questa checklist) è banale da eseguire.
• UpdraftPlus: Alternativa gratuita e molto affidabile: backup schedulati su Google Drive, Dropbox, AWS S3, Wasabi, FTP e altri. La versione free è più che sufficiente per siti vetrina, blog e piccole aziende. Installazione e configurazione in meno di 10 minuti.

Analytics e tracciamento conversioni

Pubblicare un sito senza analytics è come aprire un negozio al buio. Non sai chi entra, da dove viene, cosa guarda, dove esce. Non stai gestendo un business: stai sperando.

E attenzione: installare GA4 senza configurare gli eventi di conversione non conta. Contare le visite è inutile se non sai quante si trasformano in contatti.

GA4 con eventi di conversione configurati

Google Analytics 4 è lo standard. Ma la configurazione di default traccia solo visite e pagine viste, non le azioni che interessano davvero.

Prima del lancio, configura questi eventi di conversione:

• Form submission: invio del modulo di contatto (evento form_submit o pagina thank-you).
• Click su telefono: link tel: (evento click con destination filter).
• Click su email: link mailto: (stessa logica).
• Se e-commerce: purchase, add_to_cart, begin_checkout.

Senza questi eventi, GA4 è decorativo.

Microsoft Clarity: heatmap e registrazioni sessione

Clarity è gratuito e ti dice cosa fanno davvero gli utenti sulla tua pagina: dove cliccano, fino a dove scrollano, dove si bloccano. Non dove pensi che vadano, dove vanno davvero.

Installalo insieme a GA4, non in alternativa. I due strumenti si integrano: in GA4 puoi aprire la registrazione di sessione di un utente che ha abbandonato il checkout. Questo è ottimizzare con i dati, non con le opinioni.

Google Search Console: proprietà verificata e sitemap inviata

Se GA4 ti dice cosa fa l’utente sul sito, Search Console ti dice come Google vede il tuo sito.

Tre cose da fare prima del lancio:

1. Verifica la proprietà del dominio (metodo DNS o tag HTML — evita il file HTML perché non sopravvive ai rinnovi del tema).
2. Invia la sitemap.
3. Controlla che non ci siano errori di copertura — pagine escluse, redirect a catena, errori 404.

Dopo il lancio, usa “Ispezione URL” e “Richiedi indicizzazione” per le pagine più importanti. Non aspettare che Google le trovi da solo.

Privacy, cookie e aspetti legali

La conformità legale non è burocratica. È un requisito che il Garante Privacy italiano può contestare, con sanzioni che arrivano al 4% del fatturato globale per violazioni GDPR gravi. E nel 2022, il Garante ha pubblicato linee guida esplicite sul consenso cookie che cambiano cosa è legalmente accettabile.

Cookie bar conforme: blocco preventivo pre-consenso

Non basta mostrare un banner. La cookie bar deve bloccare tutti i cookie di tracciamento prima del consenso dell’utente.

Se hai Google Analytics, Facebook Pixel o qualsiasi altro cookie non tecnico che si carica al primo accesso, sei già a rischio sanzione. I cookie devono caricarsi solo dopo che l’utente ha dato il consenso.

Usa Iubenda o Cookiebot (o equivalenti) correttamente configurati in modalità “blocco preventivo”. Testa aprendo il sito in finestra privata con le DevTools aperte: nessun cookie di terze parti deve apparire prima del click su “Accetta”.

Privacy policy + checkbox form non pre-selezionata

• Privacy policy raggiungibile dal footer di ogni pagina. Deve essere scritta in italiano, comprensibile, aggiornata. Non copia-incolla da un altro sito.
• Cookie policy separata se necessario (dipende dalla complessità dei cookie usati).
• Checkbox nei form: deve essere non pre-selezionata. L’utente deve scegliere attivamente di accettare l’informativa privacy. Una checkbox spuntata di default non vale come consenso valido secondo il GDPR.

Per i dettagli normativi, consulta le linee guida del Garante Privacy.

Email non in plain-text nel codice HTML

Ogni bot che scansiona il web raccoglie gli indirizzi email scritti in chiaro nel codice, e in poche ore iniziano gli spam. Usa:

• Codifica HTML entities per mailto: ogni carattere diventa un codice ASCII decimale. Oppure, meglio ancora, un form di contatto che non espone l’email nel codice sorgente.
• Obbligo legale IT: partita IVA e ragione sociale devono essere visibili nel footer, ma l’email può essere sostituita da un form.

La mia checklist prima di pubblicare un sito web: una routine di 60 controlli reali

Dai un’occhiata a questi tool, ti faranno risparmiare molto tempo ed errori

• Admin and Site Enhancements: il plugin che consiglio a chiunque sviluppi siti WordPress professionalmente. Sostituisce 10+ plugin separati: disabilita XML-RPC, gestisce il limite tentativi di login, ottimizza la dashboard admin, rimuove il bloat di WordPress, aggiunge gestione redirect, controlla il caricamento degli script per area del sito (frontend, backend, specifiche pagine). Disponibile in versione gratuita e PRO.
• Nexter Extension: estensioni avanzate per WordPress: CSS custom per sezione, ottimizzazione query database, utility per sviluppatori. Complementa bene ASE su siti con esigenze tecniche più elevate o builder page come Kadence, Elementor e simili.
• Classic Monks: Toolkit e risorse per chi sviluppa e gestisce siti WordPress su scala. Utile per standardizzare configurazioni e flussi di lavoro su più progetti client, riducendo il tempo di setup su ogni nuovo sito.
• WP Tools di Sinan Isler: raccolta di utility, snippet e strumenti per sviluppatori WordPress. Reference rapido per soluzioni tecniche specifiche di configurazione, ottimizzazione e debug. Bookmarkato come risorsa di consultazione, non come plugin da installare.

Ho pubblicato siti web per piccole imprese, freelance, studi professionali e micro e-commerce. Ogni progetto che esce dal mio studio passa attraverso questa checklist, non come esercizio teorico, ma come standard di qualità che tutela sia me che il cliente.

La prima versione di questa checklist sito web l’ho scritta dopo aver quasi pubblicato un sito con robots.txt: Disallow: / ancora attivo dalla fase di sviluppo. Il sito sarebbe andato online perfettamente, ma sarebbe risultato invisibile a Google. Da quel giorno, il controllo del robots.txt è il primo che faccio.

Nel corso degli anni ho aggiunto una voce dopo l’altra, dopo aver commesso o visto errori, miei o di colleghi, che sono costati tempo e soldi.

I controlli sulla sicurezza hanno catturato molta attenzione dopo aver seguito da vicino casi di siti compromessi di clienti. Il controllo del blocco preventivo cookie è entrato dopo le linee guida del Garante del 2022.

Questa è la mia personale checklist prima di pubblicare un sito web, e-commerce o landing page.

Usala, personalizzala, salva questo articolo nei preferiti oppure stampala se vuoi.