Una landing ha un compito: convertire. Se il traffico arriva da campagne a pagamento, il motore di ricerca è irrilevante e un builder no-code è una scelta perfettamente sensata: pubblichi in un pomeriggio, iteri senza dipendere da nessuno e misuri.
Il problema nasce quando qualcuno decide che quelle stesse landing dovrebbero portare traffico organico. Lì comincia la frustrazione: si ottimizzano i testi, si mettono le parole chiave, e la pagina continua a non comparire.
Non è un problema di contenuto. È di come viene servita.
Cosa deve fare Google per leggere la tua pagina
Quando il crawler arriva su un URL, ci sono due scenari molto diversi.
Pagina renderizzata lato server. La risposta HTTP contiene già l’HTML con il contenuto dentro. Google lo legge alla prima passata e lo manda a indicizzare. Fine.
Pagina renderizzata lato client. La risposta porta un HTML quasi vuoto e un bundle JavaScript. Per vedere il contenuto, Google deve eseguire quel JavaScript, cosa che avviene in una seconda fase di rendering messa in coda e che può richiedere tempo. Google lo fa — non siamo nel 2015 — ma è un passaggio in più, con la sua coda e il suo budget di risorse.
Per un sito con autorità consolidata quella differenza è sopportabile. Per una landing nuova che compete su una query con intento commerciale, è uno svantaggio che non serve regalare alla concorrenza.
I quattro punti dove si perde
Il JavaScript che non puoi togliere
Un builder deve essere generico: deve supportare qualsiasi blocco che qualsiasi cliente possa trascinare. Questo significa caricare il runtime dell’editor, il sistema di animazioni, il gestore dei form e le utility di tutti i blocchi, che tu ne usi due o venti.
Il risultato sono centinaia di kilobyte di JavaScript che la tua landing specifica non usa, e che non hai modo di eliminare perché non controlli la build.
Core Web Vitals
Quel peso si traduce direttamente nelle metriche che Google usa come segnale:
| Metrica | Cosa la degrada in un builder |
|---|---|
| LCP | L’elemento principale aspetta che il JS lo disegni |
| INP | Il thread principale è occupato a eseguire il runtime |
| CLS | Blocchi che si riposizionano durante l’idratazione |
I Core Web Vitals non sono il fattore di posizionamento più forte — contenuto e link pesano di più — ma sono uno spareggio reale. E su una landing hanno un effetto molto più immediato: ogni secondo di caricamento si mangia conversione, che Google c’entri o no.
L’URL che non controlli
È qui che la maggior parte dei builder resta corta:
- Sottodomini del fornitore invece del tuo dominio, per cui l’autorità che guadagni non si accumula sul tuo sito
- Percorsi imposti tipo
/p/12345invece di/agenzia-nextjs-milano - Slash finali incoerenti che generano duplicati
- Canonical che non puoi regolare quando hai varianti della stessa landing per campagne diverse
Quest’ultimo punto è quello che fa danno più silenziosamente: tre varianti di una landing senza canonical impostato bene competono tra loro e non vince nessuna.
Dati strutturati e hreflang
Se vendi in più paesi ti serve un hreflang corretto e reciproco. Se vuoi comparire con risultati avanzati ti serve JSON-LD specifico per il tuo caso. La maggior parte dei builder offre o un campo generico o niente, e inserirlo a mano tramite iniezione di codice tende a rompersi al successivo aggiornamento della piattaforma.
Cosa risolvono davvero
Sarebbe disonesto dipingere tutto di nero. Un builder risolve tre cose sul serio:
- Velocità di lancio. Dall’idea alla landing pubblicata in poche ore, senza coda di sviluppo.
- Autonomia del marketing. Chi ha l’ipotesi può provarla senza aprire un ticket.
- Iterazione economica. Cambiare un titolo non costa un deploy.
Quel valore è reale e non lo dà qualsiasi alternativa. La domanda giusta non è “builder sì o no”, è che lavoro deve fare questa landing.
Il criterio, in tabella
| Se la landing… | Allora |
|---|---|
| Riceve traffico da campagne a pagamento | Un builder va bene. La SEO non è il suo compito |
| È un test che può morire in tre settimane | Builder. Non investire in qualcosa che butterai |
| Deve posizionarsi su una query commerciale | Rendering lato server, URL proprio, controllo tecnico |
| È multilingua e multipaese | Rendering lato server: ti serve hreflang vero |
| È la porta d’ingresso principale del business | Rendering lato server, senza discussione |
La maggior parte delle aziende ha bisogno di entrambe le cose insieme, ed è lì che il falso dilemma fa male: ti costringe a scegliere tra pubblicare in fretta e posizionarti, quando il problema vero è che le due capacità vivono in strumenti incompatibili.
Il nostro approccio
È esattamente il vuoto per cui abbiamo costruito Landing Builder: editor visuale a blocchi perché il marketing pubblichi senza dipendere dallo sviluppo, ma con SEO vera sotto — rendering lato server, slug puliti sul tuo dominio, meta tag e dati strutturati per pagina — più moduli con tracking e analytics delle campagne.
Se stai anche scegliendo lo stack per il sito, abbiamo il confronto tra Next.js e Astro per il 2026.