Landing page su misura o builder: quale scegliere?

Che cosa cambia nel lavoro del team

Un builder può essere un servizio con hosting incluso, come Wix o Webflow, oppure un editor installato in un CMS, come Elementor su WordPress. Con un editor per WordPress devi prevedere anche chi gestirà hosting, aggiornamenti del CMS, plugin e backup: il tuo team oppure un fornitore incaricato. Sono attività che incidono sia sul costo sia sul tempo necessario per mantenere la pagina.

Anche una landing su misura può usare un CMS e componenti riutilizzabili. Se alla piattaforma attuale manca soltanto un modulo o un collegamento al CRM, chiedi al fornitore se può svilupparlo mantenendo l’editor che il team conosce già. Nel preventivo dovrà distinguere le parti riutilizzate da quelle da realizzare.

Per definire offerta, contenuti e sequenza del progetto, usa la guida su come realizzare una landing page. Se devi ancora scegliere la destinazione della campagna, parti dal confronto tra landing page e sito web.

Come confrontare le due proposte

Chiedi ai fornitori di rispondere alle stesse domande, specificando piattaforma, piano e attività comprese nel prezzo. Se una proposta promette un’integrazione, deve spiegare quali dati trasferisce, dove li invia e chi interviene quando il collegamento non funziona. Chiedi poi di verificarlo su una pagina di prova.

Che cosa puoi portare via cambiando piattaforma

Essere titolare del dominio non significa poter spostare la pagina su un altro servizio. Nel contratto chiarisci chi avrà accesso agli account, quali diritti avrai su testi, immagini e codice, come riceverai i dati dei contatti e quali licenze dovrai continuare a pagare dopo la consegna.

Wix richiede che il sito funzioni sui propri server: possedere i contenuti non equivale a poter trasferire il sito funzionante a un altro hosting.

Webflow consente di esportare HTML, CSS, JavaScript e asset con un piano Workspace a pagamento; un piano Site da solo non include l’esportazione. Il codice esportato non conserva le funzioni del CMS, l’elaborazione dei moduli e la ricerca del sito. Perciò un file ZIP non basta a dimostrare che la pagina continuerà a raccogliere richieste altrove.

Se devi poter cambiare piattaforma, chiedi al fornitore di esportare una copia della pagina e pubblicarla su un altro ambiente di prova. Verifica poi se raccoglie e invia ancora i contatti. Quando l’esportazione conserva solo il layout, occorre ricostruire le funzioni mancanti: fatti indicare costo e responsabile del lavoro. Se invece hai bisogno di trasferire tutto senza rifarlo, escludi una soluzione che non lo consente.

Come verificare qualità e integrazioni prima di scegliere

Per confrontare le soluzioni, chiedi due pagine di prova con gli stessi contenuti e le stesse operazioni: dalla compilazione del modulo all’arrivo del contatto nel CRM. Il responsabile marketing prova a modificare i contenuti; il referente tecnico controlla invii e dati. Usate contatti fittizi, un destinatario e un CRM di test, così le prove non avviano comunicazioni o attività commerciali reali.

Per le prestazioni confronta la pagina completa con gli stessi strumenti e condizioni. I Core Web Vitals considerano buoni LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1, al 75° percentile delle visite, separando mobile e desktop. Un report Lighthouse è una prova di laboratorio e non dimostra da solo questi risultati sui visitatori reali. Per il lavoro tecnico usa la guida sulla velocità delle landing page.

Se la pagina deve comparire nei risultati di ricerca, verifica titolo, meta description, URL canonico, contenuto leggibile dai motori e link interni. Per l’accessibilità parti dai controlli preliminari W3C su tastiera, contrasto, titoli ed etichette. Servono a trovare problemi iniziali; una valutazione completa richiede verifiche ulteriori. Le indicazioni W3C per gli strumenti no-code distinguono l’accessibilità dell’editor da quella del contenuto prodotto.

Per ogni prova annota la versione della pagina, il dispositivo o browser, l’operazione eseguita, il risultato atteso e quello osservato. Conserva una schermata o un log quando serve a documentare l’errore. Segna la prova come riuscita, da correggere o non eseguita. Se una richiesta si perde, manca un dato essenziale nel CRM o il modulo è inutilizzabile, il fornitore deve correggere il problema prima che tu approvi la soluzione; poi ripetete la prova sulla nuova versione.

Un esempio: assegnare le richieste al referente di zona

Immaginiamo un’azienda di installazione che vuole una landing in italiano per ricevere richieste di sopralluogo. Il modulo raccoglie CAP e tipo di impianto e invia la richiesta al referente di zona nel CRM. Nella prova, il CAP 00100 deve assegnare il contatto al referente A e il tipo di impianto deve comparire nella sua scheda. Le credenziali del CRM devono restare sul server. Il marketing prevede due modifiche di testo al mese; la pagina deve essere pronta in dieci giorni lavorativi e verrà gestita per 24 mesi.

L’azienda confronta un builder con un piccolo connettore dedicato e una pagina su misura nel CMS esistente. Supponiamo che i fornitori stimino rispettivamente sei e dieci giorni lavorativi, a partire dalla consegna dei contenuti e degli accessi di prova. Entrambe le proposte rientrano quindi nella scadenza prevista.

Per il primo collaudo, l’azienda verifica l’invio valido, l’errore del CRM e l’uso del modulo da tastiera su desktop o tramite touch su smartphone. Sono tre prove su due dispositivi per ciascuna delle due soluzioni: 3 × 2 × 2 = 12 registrazioni. Per ogni soluzione controlla anche la modifica con ripristino e il trasferimento dalla piattaforma: 2 × 2 = 4 verifiche aggiuntive. Il registro parte quindi da 16 righe.

A quel punto l’azienda può scegliere il builder con connettore: rispetta la scadenza e, con le ipotesi di costo della prossima sezione, costa meno nel periodo previsto. La scelta comporta accettare che un futuro trasferimento richieda di ricostruire il modulo. Se fosse indispensabile spostare l’intera pagina con tutte le funzioni già operative, oppure il connettore non gestisse gli errori richiesti, il prezzo più basso non sarebbe un motivo sufficiente per sceglierlo.

Quanto costa la scelta su 24 mesi

Per confrontare i costi, somma realizzazione iniziale, canoni del periodo, manutenzione, tempo del personale e un’eventuale migrazione. Usa la stessa durata e le stesse attività per entrambe le proposte. Controlla se i canoni aumentano al rinnovo e se gli importi includono l’IVA; indica sempre valuta e periodicità. Se il piano del builder comprende già l’hosting, non aggiungerlo una seconda volta.

Un riferimento reale: il listino Webflow consultato il 19 ottobre 2026 indica Basic a 15 USD al mese con fatturazione annuale, cioè 180 USD per anno, oltre alle imposte applicabili. È un piano Site per siti senza CMS; non è il costo di progettazione della landing e non include da solo l’esportazione del codice. Verifica il piano necessario per il tuo progetto prima di confrontare i totali.

Per l’azienda dell’esempio ipotizziamo questi importi in euro, al netto dell’IVA e senza aumenti nei 24 mesi. Il piano del builder comprende l’hosting; nella proposta con CMS il connettore è incluso nello sviluppo iniziale.

Con queste ipotesi, il builder costa 1.060 € in meno. Nessuna delle due proposte prevede una migrazione nei 24 mesi. Se il team dovesse impiegare anche due ore al mese per correggere manualmente i contatti del builder, aggiungerebbe 24 × 2 × 30 € = 1.440 € di lavoro: il totale salirebbe a 6.120 €, contro i 5.740 € del CMS. Inoltre, l’azienda ha richiesto lo smistamento automatico: prima di sostituirlo con un’attività manuale dovrebbe accettare esplicitamente questo cambiamento.

Per valutare voci incluse e modalità di incarico, leggi quanto costa una landing page. Nel servizio Qreativa il lavoro del team e i costi di piattaforme, hosting e software esterni sono voci distinte; chiedi che il preventivo indichi anche chi paga e rinnova ciascun servizio.

Dal brief alla decisione scritta

1. Scrivi che cosa deve fare la pagina

   Raccogli in un brief l’offerta, l’azione richiesta al visitatore, i campi del modulo e la destinazione dei dati. Aggiungi quali contenuti il team deve poter modificare, la scadenza e la durata prevista del progetto. Concorda questi requisiti con le persone che useranno la pagina e il CRM; fai chiarire gli aspetti ancora incerti prima del preventivo.

2. Escludi le proposte che non soddisfano i requisiti essenziali

   Usa il confronto e le prove per verificare ogni proposta. Se una soluzione perde le richieste o non gestisce un dato necessario, un prezzo basso o un buon editor non risolvono il problema. Se nessuna delle due funziona, chiedi un’altra soluzione tecnica oppure concorda quali requisiti puoi cambiare.

3. Confronta costi, tempi e lavoro del team

   Tra le soluzioni che superano le prove, scegli quella compatibile con il budget, la scadenza e le competenze disponibili. Distingui gli importi confermati dalle stime. Chiedi i costi ancora mancanti prima di decidere, soprattutto se potrebbero cambiare il vantaggio economico.

4. Metti per iscritto la scelta e i suoi limiti

   Conserva la data e la versione del progetto, il motivo della scelta e i vincoli accettati. Indica quando sarà necessario rivalutarla, per esempio se cambiano i dati da inviare, il prezzo del piano o la necessità di trasferire il sito. Scrivi anche chi approva la pagina prima del lancio e chi la segue dopo.

Per l’azienda dell’esempio, la decisione può essere scritta così: «Scegliamo il builder con connettore per i requisiti concordati il 19 ottobre 2026, dopo aver completato con esito positivo le due verifiche rimaste aperte. Il totale stimato è di 4.680 € su 24 mesi. Accettiamo di ricostruire il modulo in caso di trasferimento. Rivedremo la scelta se dovremo poter spostare la pagina con tutte le funzioni già operative. Il marketing approva i contenuti; il referente tecnico verifica gli invii, gestisce gli errori e segue la manutenzione». Adatta requisiti, persone e date al tuo progetto.

Scheda per confrontare due proposte

La scheda stampabile ti aiuta a raccogliere i requisiti, confrontare i costi e motivare la scelta prima di approvare il lavoro. Contiene anche il registro dell’esempio: dodici prove del modulo e quattro verifiche di modifica, ripristino e trasferimento. Le due righe finali permettono di annotare nuovi esiti conservando quelli originali.

Adatta le prove al tuo progetto. Se aggiungi dispositivi o soluzioni da confrontare, ricalcola le righe necessarie: prove del modulo × dispositivi × soluzioni, più verifiche di gestione × soluzioni. Segna come non pertinente una prova che non serve al progetto; usa invece non eseguita per una verifica necessaria che manca ancora. Se lo spazio non basta, allega schermate o log e scrivi nel registro dove trovarli.

Per valutare chi gestirà consegna e assistenza usa i criteri della guida su come scegliere un’agenzia per landing page.

Scarica brief, confronto costi e registro (PDF, 3 pagine)