Un cliente ci ha girato un sito costruito tre anni fa con un page builder, chiedendo perché ogni piccola modifica richiedesse più tempo di quanto sembrasse ragionevole. Aprendo il builder abbiamo trovato dodici livelli di div annidati per una singola sezione hero. La differenza reale tra sviluppare con blocchi Gutenberg custom e usare un page builder non si vede sul sito appena consegnato, si vede dopo due o tre anni di modifiche accumulate: un builder genera struttura extra ad ogni elemento, un blocco custom genera esattamente il markup che hai scritto tu. Non è una questione di gusto tecnico, è una questione di quanto lavoro costa mantenere quel sito nel tempo.
I page builder come Elementor o Divi funzionano bene per prototipare velocemente e per chi non scrive codice. Il compromesso che accettano, quasi sempre implicito e non dichiarato al cliente, è un livello di astrazione tra quello che l’utente disegna e l’HTML finale. Quell’astrazione produce wrapper aggiuntivi, classi generate automaticamente, CSS inline che si accumula, e soprattutto una dipendenza totale dal builder stesso per ogni intervento futuro sul sito.
Cosa succede davvero quando un builder rilascia un aggiornamento
Il rischio concreto di un page builder non è la qualità del prodotto in sé, è la dipendenza a lungo termine. Quando il builder cambia il modo in cui renderizza un componente, spesso per migliorare le performance o aggiungere una feature, i siti costruiti con la versione precedente possono avere comportamenti diversi dopo l’update: margini che cambiano, blocchi che si spostano, animazioni che si comportano diversamente su mobile.
Problema: sezione hero che cambia layout dopo un aggiornamento del page builder
Causa: il builder ha modificato la struttura HTML generata per quel componente tra una versione e l'altra, e il CSS custom scritto sopra la vecchia struttura non si aggancia più correttamente
Soluzione Blurr: bloccare gli aggiornamenti major del builder su staging prima della produzione, testare ogni sezione critica prima del deploy, mantenere un changelog interno di cosa il CSS custom presuppone della struttura del builderCon un blocco Gutenberg custom, sviluppato con block.json e un template PHP proprio, il markup che va in produzione è esattamente quello scritto durante lo sviluppo. Non cambia perché WordPress rilascia una nuova versione: cambia solo se sei tu a modificare il codice del blocco. È meno comodo per chi non sa scrivere PHP e CSS, ma è molto più prevedibile per chi deve manutenere il sito nei prossimi anni.
Anche gli aggiornamenti del core di WordPress seguono una filosofia diversa rispetto a quella di un builder commerciale: mantengono la retrocompatibilità come priorità dichiarata da anni, un impegno che nessun singolo plugin o builder di terze parti può garantire con lo stesso livello di continuità, semplicemente perché WordPress core risponde a una community enorme e a una base di siti troppo grande per permettersi rotture frequenti.
Le differenze che contano davvero
| Aspetto | Page builder | Blocchi custom Gutenberg |
|---|---|---|
| Markup HTML generato | Wrapper extra, classi generate, spesso non ottimale | Esattamente quello scritto nel template |
| Dipendenza da plugin di terze parti | Totale, il sito non funziona senza | Nessuna oltre al core WordPress |
| Curva di aggiornamento | Ogni major release va testata per rotture visive | Cambia solo se aggiorni tu il blocco |
| Velocità di prototipazione iniziale | Alta, drag and drop | Più lenta, richiede sviluppo |
| Peso CSS/JS caricato | Spesso l’intero framework del builder, anche se usi il 10% delle feature | Solo il CSS specifico del blocco, caricato via block.json |
| Autonomia del cliente nell’editing | Limitata alle opzioni del builder | Limitata ai campi ACF esposti nel blocco, più prevedibile |
Sul peso di CSS e JS caricato vale la pena approfondire: un page builder generico carica il proprio framework di stili anche quando il sito usa una minima parte delle sue funzionalità, un problema che abbiamo già trattato in dettaglio nella nostra checklist performance per siti WordPress. Un blocco registrato via block.json invece carica il proprio CSS solo nelle pagine dove il blocco è effettivamente presente, grazie al meccanismo nativo di WordPress che enqueue gli asset per blocco.
Quando il page builder resta la scelta giusta
Non tutti i progetti giustificano lo sviluppo custom. Un sito vetrina con budget limitato, consegnato in pochi giorni, con un cliente che vuole poter modificare tutto da solo senza nessuna conoscenza tecnica, trova nel page builder uno strumento adeguato al contesto. Il problema nasce quando si usa un page builder per progetti che nel tempo cresceranno molto, con manutenzione continuativa, dove il costo cumulato di gestire le incompatibilità supera abbondantemente quello che sarebbe costato sviluppare blocchi custom fin dall’inizio.
La soglia che usiamo internamente per decidere è abbastanza semplice: se il cliente ha già annunciato un piano di manutenzione a lungo termine o prevede iterazioni frequenti sul sito, i blocchi custom pagano l’investimento iniziale già nel secondo anno. Se il sito è pensato per restare sostanzialmente fermo dopo il lancio, il page builder resta la scelta più rapida ed economica.
Un caso che seguiamo per un’agenzia di Verona illustra bene la differenza. Il cliente finale, una catena di centri estetici in crescita, aveva un sito Elementor che veniva aggiornato ogni due settimane con nuove sedi e nuove promozioni. Ogni aggiunta richiedeva ricreare da zero la stessa sezione con piccole variazioni, e ogni tanto un aggiornamento del tema o del builder rompeva qualcosa in una pagina che nessuno stava guardando in quel momento. Abbiamo ricostruito il sito con blocchi ACF custom per le sezioni ricorrenti (scheda sede, scheda promozione, testimonianza), lasciando al cliente solo i campi da compilare. Il tempo medio per aggiungere una nuova sede è passato da circa quaranta minuti a otto, e in un anno di gestione non abbiamo dovuto intervenire nemmeno una volta per un problema di rendering legato a un aggiornamento.
Come impostare la scelta con il cliente in fase di preventivo
Il punto in cui molte agenzie sbagliano non è la scelta tecnica in sé, è non comunicarla al cliente. Spiegare la differenza tra le due strade, anche in termini semplici, aiuta il cliente a capire perché un progetto con blocchi custom costa di più in fase di sviluppo e perché quel costo si ripaga nel tempo con meno interventi di manutenzione imprevisti. Chi salta questa conversazione si trova poi a giustificare ex post costi di manutenzione che il cliente non si aspettava.
Se stai valutando quale approccio impostare per il prossimo progetto o vuoi confrontarti su come strutturare blocchi custom riutilizzabili tra più clienti, su blurr.it/contatti/ possiamo guardare insieme il caso specifico. Per chi vuole capire dove si posiziona lo sviluppo WordPress oggi rispetto alle alternative low-code, abbiamo scritto anche un confronto diretto tra i principali page builder disponibili nel 2026.
Domande frequenti
No. Per siti semplici, con budget limitato e senza piani di manutenzione continuativa, un page builder resta lo strumento più rapido ed economico. I blocchi custom convengono quando il sito crescerà nel tempo con aggiornamenti frequenti, dove il costo di sviluppo iniziale più alto si ripaga con una manutenzione molto più prevedibile.
Dipende dalla complessità delle sezioni, ma indicativamente lo sviluppo iniziale richiede dal 30% al 60% di tempo in più rispetto a un builder drag and drop. Il ritorno si vede nella manutenzione: meno rotture dopo gli aggiornamenti, meno tempo per replicare sezioni ricorrenti.
Sì, se il blocco è progettato con campi ACF ben strutturati. Il cliente compila i campi (testo, immagine, link) senza toccare markup o stili, con un margine di errore molto più basso rispetto a un editor drag and drop che permette di modificare qualsiasi proprietà visiva.
Nella maggior parte dei casi sì, perché il markup generato dai builder non si converte in modo pulito in blocchi nativi. È un lavoro di ricostruzione, non di migrazione automatica, e va valutato caso per caso in base a quanto contenuto e quante pagine sono coinvolte.