Una landing page è una pagina con un obiettivo solo. Deve fare due cose insieme — farsi trovare da chi cerca quel servizio, e portare quella persona a compiere un'azione — e su entrambe circolano consigli generici che non si possono verificare.
Vale la pena partire dal punto in cui la maggior parte delle ottimizzazioni si perde: la misura.
Il test A/B che non misura niente#
// La domanda che quasi nessuno si pone prima di un test A/B:// quanti visitatori servono perché il risultato significhi qualcosa?//// Formula per il confronto di due proporzioni (α = 0,05, potenza 80%)://// n ≈ 16 · p · (1 − p) / d²//// p = tasso di conversione attuale// d = differenza assoluta che si vuole poter rilevare// n = visitatori PER VARIANTEfunction campioneNecessario(p, miglioramentoRelativo) { const d = p * miglioramentoRelativo; return Math.ceil(16 * p * (1 - p) / (d * d));}campioneNecessario(0.02, 0.20); // 2% → +20% (a 2,4%): 78 400 per variantecampioneNecessario(0.02, 0.50); // 2% → +50% (a 3,0%): 12 600 per variantecampioneNecessario(0.05, 0.20); // 5% → +20% (a 6,0%): 30 400 per variante// Con 300 visite al mese e un tasso del 2%, rilevare un miglioramento// del 20% richiederebbe circa 43 ANNI di traffico per variante.// Il test A/B, su quei numeri, non è uno strumento disponibile.Il calcolo è quello standard per il confronto fra due proporzioni, e il risultato è scomodo: i test A/B richiedono volumi che la maggior parte dei siti professionali non ha. Con un tasso di conversione del 2% — che è un valore normale per una landing di servizi — e l'obiettivo di rilevare un miglioramento del 20%, servono circa 78 000 visitatori per variante.
Cosa usare al posto#
Che cosa fare quando il traffico non basta per un test statistico(cioè: quasi sempre, per un sito professionale o di piccola impresa). ✓ Test moderatore su 5 persone Cinque utenti reali che provano a completare l'azione mentre parlano ad alta voce. Non produce percentuali: produce l'elenco dei punti in cui si bloccano — che è l'informazione che serve. Cinque persone individuano circa l'80% dei problemi di usabilità. ✓ Registrazioni delle sessioni e mappe di calore Dove si fermano, dove tornano indietro, dove abbandonano il modulo. Qualitativo, ma non richiede volumi. Attenzione alla privacy: quasi tutti questi strumenti sono terze parti, e vanno trattati come tali (consenso, informativa). ✓ Correzione dei difetti oggettivi Un modulo con dieci campi, un tempo di caricamento di 6 secondi, un pulsante invisibile su mobile: sono problemi che non hanno bisogno di essere testati per essere problemi. ✗ Test A/B con 40 conversioni totali Non è un test: è rumore con un'interfaccia grafica.La terza voce è quella che rende di più e viene saltata più spesso. Un modulo con dieci campi, un tempo di caricamento di sei secondi, un pulsante che si sposta mentre lo si tocca: sono difetti oggettivi. Non hanno bisogno di essere testati per essere difetti, e correggerli non richiede alcun campione statistico.
Il modulo, che è dove si perde#
<!-- Il modulo è il punto in cui si perde la maggior parte delle conversioni, e quasi tutte le perdite sono evitabili. --><!-- ✗ Le cinque cose che fanno abbandonare --><input type="text" name="email" placeholder="Email"><!-- 1. type sbagliato: su mobile non compare la tastiera giusta 2. niente label: il placeholder sparisce quando si scrive, e chi usa uno screen reader non sa cosa deve inserire 3. niente autocomplete: il browser non può compilare 4. niente inputmode 5. niente messaggio di errore associato --><!-- ✓ La forma corretta --><label for="email">Email <span aria-hidden="true">*</span></label><input id="email" name="email" type="email" autocomplete="email" inputmode="email" required aria-describedby="email-aiuto email-errore"><p id="email-aiuto" class="aiuto">Ti risponderò a questo indirizzo.</p><p id="email-errore" class="errore" role="alert" hidden></p><!-- autocomplete è la riga con il rendimento più alto dell'intero modulo: permette al browser di compilare in un tocco, e su mobile è la differenza fra completare e rinunciare. -->Cinque errori in una riga sola, e tutti e cinque costano conversioni misurabili. Il type sbagliato fa comparire su mobile la tastiera generica invece di quella con la chiocciola. Il placeholder usato al posto della label sparisce appena si comincia a scrivere — e chi usa uno screen reader non sa cosa deve inserire.
Ma la riga con il rendimento più alto è autocomplete. Con l'attributo corretto, il browser compila il campo in un tocco attingendo ai dati già memorizzati; senza, l'utente deve digitare il proprio indirizzo email su una tastiera piccola. Su mobile è spesso la differenza fra completare e rinunciare.
Ogni campo ha un costo#
Ogni campo ha un costo. La domanda per ciascuno: "Se non lo chiedo, cosa non posso fare?" Nome → serve per rispondere in modo umano. TIENI Email → serve per rispondere. TIENI Messaggio → serve per capire la richiesta. TIENI ──────────────────────────────────────────────────────────────── Telefono → si può chiedere dopo, nella risposta. TOGLI Azienda → si deduce dal dominio dell'email. TOGLI Budget → chi lo compila mente, chi non lo sa esce. TOGLI Come ci hai conosciuto → interessa a voi, non a chi scrive. TOGLI Settore → si chiede in fase di qualificazione. TOGLIIl modulo non è un questionario di qualificazione: è l'inizio diuna conversazione. Ogni campo tolto è una percentuale guadagnata,e le informazioni tolte si ottengono nella prima risposta.La tentazione di aggiungere campi viene dal lato giusto della scrivania — sapere il budget e il settore prima di rispondere farebbe risparmiare tempo. Ma sposta il costo su chi non ha ancora nessun motivo per fidarsi, nel momento in cui è meno disposto a sostenerlo. Le stesse informazioni si ottengono nella prima risposta, quando la conversazione è già cominciata.
La SEO è corrispondenza con l'intento#
// La SEO di una landing è una sola cosa: corrispondere all'INTENTO// della ricerca. Le quattro categorie, e cosa serve a ciascuna.// 1. Informazionale — "come funziona un chatbot aziendale"// → una guida. Una landing commerciale qui non si posiziona,// e se ci arriva l'utente rimbalza.// 2. Commerciale — "migliore CRM per studi legali"// → confronti, criteri, tabelle. L'utente sta valutando.// 3. Transazionale — "sviluppatore web preventivo"// → QUI vive la landing. L'utente ha già deciso di comprare.// 4. Navigazionale — "nome azienda contatti"// → la vostra pagina contatti.// L'errore ricorrente: scrivere una landing transazionale e// aspettarsi che si posizioni su una ricerca informazionale.// Sono pagine diverse, per persone in momenti diversi.È l'errore strutturale più comune: scrivere una pagina che vende e aspettarsi che si posizioni su ricerche di chi sta ancora studiando il problema. Sono pagine diverse per persone in momenti diversi, e servono entrambe — ma l'una non fa il lavoro dell'altra. La guida attira chi cerca di capire; la landing raccoglie chi ha già deciso.
// Dati strutturati: non migliorano il posizionamento, migliorano// l'ASPETTO del risultato — e quindi la percentuale di clic, che// a parità di posizione conta quanto una posizione guadagnata.{ "@context": "https://schema.org", "@type": "Service", "name": "Sviluppo siti web su misura", "provider": { "@type": "ProfessionalService", "name": "…", "areaServed": "IT" }, "offers": { "@type": "Offer", "priceCurrency": "EUR", "priceSpecification": { "@type": "PriceSpecification", "minPrice": 1500, "priceCurrency": "EUR" } }}// E le FAQ, che occupano spazio verticale nella pagina dei risultati:{ "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Quanto costa un sito su misura?", "acceptedAnswer": { "@type": "Answer", "text": "…" } }]}Una precisazione che vale la pena fare, perché i dati strutturati vengono spesso presentati come fattore di posizionamento: non lo sono. Servono a far comprendere il contenuto e a ottenere risultati arricchiti, che occupano più spazio verticale e attirano più clic. L'effetto è sulla percentuale di clic a parità di posizione — che vale comunque molto, ma è un'altra cosa.
La velocità, misurata invece che invocata#
# L'effetto della velocita' sulla conversione non e' un'opinione:# e' misurabile sul proprio sito, confrontando i segmenti.# In qualunque strumento di analisi, la domanda e':# "il tasso di conversione di chi ha caricato in <2,5 s# e' diverso da quello di chi ha caricato in >4 s?"# E la misura preliminare, senza strumenti:npx lighthouse https://esempio.it/servizio --only-categories=performance \> --form-factor=mobile --throttling-method=simulateLargest Contentful Paint 3.8 s ← sopra la soglia di 2,5 sTotal Blocking Time 410 msCumulative Layout Shift 0.24 ← sopra la soglia di 0,1# CLS 0,24 su una landing significa che il pulsante si sposta# mentre l'utente lo sta toccando. E' un difetto oggettivo:# non serve un test A/B per sapere che va corretto.Il collegamento fra velocità e conversione è documentato, ma il modo utile di usarlo non è citare uno studio: è segmentare i propri dati. Confrontare il tasso di conversione di chi ha caricato la pagina sotto i 2,5 secondi con quello di chi ha impiegato più di 4 dice, sul vostro sito e sul vostro pubblico, quanto vale il tempo di caricamento — e se valga la pena investirci prima di riscrivere i testi. L'argomento è ripreso in dettaglio nell'articolo sui Core Web Vitals.
Misurare senza tracciare#
// Misurare la conversione senza strumenti di terze parti: l'evento// che conta avviene sul VOSTRO server, e da lì si registra.app.post('/api/contatto', async (req, res) => { const dati = SchemaContatto.parse(req.body); await invia(dati); // Nessun pixel, nessun cookie: un contatore lato server, con // la sola informazione che serve davvero. await metriche.registra({ evento: 'contatto', pagina: String(req.get('referer') || '').slice(0, 200), quando: new Date().toISOString() }); res.json({ ok: true });});// Il denominatore (le visite) si ricava dai log del server, che// esistono comunque. Tasso di conversione = contatti / visite alla// pagina, senza tracciare nessuno e senza banner.Questo è il punto in cui il tema tecnico incontra quello della privacy. L'evento che vi interessa — qualcuno ha inviato una richiesta — avviene sul vostro server. Non serve un pixel di terze parti per saperlo: serve una riga in una tabella. Il denominatore, le visite alla pagina, si ricava dai log del server, che esistono comunque per ragioni di sicurezza.
Il risultato è un tasso di conversione reale, senza cookie, senza banner di consenso e senza trasferire l'indirizzo IP dei visitatori a nessuno. Quello che si perde rispetto a uno strumento di analisi completo sono le attribuzioni multi-canale e il comportamento di navigazione — informazioni che su una landing con un obiettivo solo raramente cambiano una decisione.
| Intervento | Serve un test? | Effetto atteso |
|---|---|---|
| Togliere campi non necessari | no | diretto e misurabile sul numero di invii |
autocomplete corretto | no | alto su mobile, costo: una riga |
| Correggere un CLS > 0,1 | no | è un difetto, non una variante |
| LCP da 4 s a 2 s | no | segmentare i propri dati per quantificarlo |
| Cambiare il testo del pulsante | sì | serve traffico che quasi nessuno ha |
| Cambiare il colore del pulsante | sì | effetto tipicamente sotto la soglia rilevabile |
| Riscrivere titolo e promessa | sì, o test moderato | può essere grande: vale l'osservazione diretta |
| Aggiungere prova sociale reale | no | difficile da sbagliare, se è vera |
La riga finale merita una nota: la prova sociale funziona quando è verificabile. Un nome, un ruolo, un'azienda, un risultato specifico. Le testimonianze anonime e generiche — «servizio eccellente, consigliato!» — non aggiungono fiducia perché chiunque potrebbe scriverle, e un lettore attento lo sa.