Scegliere un page builder WordPress oggi non significa semplicemente trovare l’editor con più widget o con l’interfaccia drag and drop più immediata. La scelta incide sul modo in cui costruirai template, componenti e contenuti dinamici, ma anche sulla manutenzione futura del sito, sulle licenze necessarie e sulla difficoltà di cambiare sistema in seguito.
Il mercato, inoltre, si è differenziato parecchio. Elementor e Beaver Builder lavorano come plugin sopra WordPress; Divi combina tema e builder; Bricks è direttamente un tema con visual site builder integrato; Oxygen e Breakdance puntano a workflow più strutturati; il Site Editor permette invece di costruire molte parti del sito restando nell’ecosistema nativo di WordPress.
Per questo non troverai una classifica basata su stelline arbitrarie. Il page builder migliore è quello che risolve meglio i vincoli del progetto senza aggiungere complessità che non ti serve.
In questa guida confronteremo Elementor, Divi, Bricks, Breakdance, Oxygen, Beaver Builder, Brizy, WPBakery, SiteOrigin e lo stack nativo WordPress, concentrandoci soprattutto sulle differenze che possono cambiare davvero la scelta.
Page builder WordPress: quale scegliere in breve
Se vuoi un orientamento immediato, partirei da questa logica:
- Elementor se cerchi un ambiente visuale accessibile, un ecosistema ampio e la possibilità di partire gratuitamente;
- Divi 5 se vuoi tema, Visual Builder e Theme Builder dentro lo stesso ecosistema;
- Bricks se lavori in modo più strutturato con classi, componenti, template e contenuti dinamici;
- Breakdance se vuoi un builder visuale avanzato senza adottare necessariamente il modello theme-based di Bricks;
- Oxygen 6 se il tuo workflow è vicino allo sviluppo e vuoi un controllo molto approfondito sulla costruzione del frontend;
- Beaver Builder se preferisci un ambiente maturo e prevedibile, soprattutto in un workflow professionale o multi-sito;
- SiteOrigin se il budget è minimo e cerchi un page builder WordPress gratuito consolidato;
- Site Editor se puoi ottenere ciò che ti serve con blocchi e block theme senza aggiungere un builder proprietario.
Non è una graduatoria. Due progetti WordPress apparentemente simili possono richiedere scelte diverse perché cambiano chi gestirà il sito, quali contenuti dovrà pubblicare, quanto design personalizzato serve e quale livello di dipendenza dallo strumento è accettabile.
Il migliore dipende soprattutto dal tipo di progetto
Il primo errore è confrontare i builder isolando le feature.
Un elenco come “100 widget contro 80 widget” dice poco se il progetto richiede soprattutto un buon sistema di template, oppure se chi aggiornerà il sito ha bisogno di modificare autonomamente poche landing page.
Le domande che contano di più sono altre:
- chi costruirà il sito?
- chi lo aggiornerà dopo la pubblicazione?
- devi progettare solo pagine o anche header, footer, archivi e template?
- utilizzerai custom post type o custom fields?
- devi personalizzare WooCommerce?
- lavori su un sito o su molti progetti?
- vuoi un design system riutilizzabile?
- quanto ti interessa poter cambiare stack in futuro?
Il page builder dovrebbe essere una conseguenza di queste risposte, non il punto di partenza.
Tabella comparativa dei principali builder
| Soluzione | Approccio | Versione gratuita | Modello commerciale | La valuterei soprattutto quando |
|---|---|---|---|---|
| Site Editor | nativo WordPress / block theme | sì | incluso in WordPress | vuoi ridurre le dipendenze esterne |
| Elementor | plugin + ecosistema | sì | abbonamento per le funzioni premium | vuoi accessibilità e ampio controllo visuale |
| Divi 5 | tema + Visual Builder + Theme Builder | no | annuale o lifetime per il prodotto base | vuoi lavorare nell’ecosistema Divi |
| Bricks | tema + visual site builder | no | annuale o lifetime | vuoi design system e sviluppo visuale strutturato |
| Breakdance | visual site builder | sì | abbonamento per Pro | vuoi un builder avanzato con workflow visuale |
| Oxygen 6 | visual development environment | no | licensing lifetime corrente | vuoi un approccio più tecnico |
| Beaver Builder | plugin + Theme + Themer nei piani correnti | versione Lite disponibile | abbonamento | gestisci workflow professionali e più siti |
| Brizy | plugin visuale | sì | abbonamento Pro | privilegi semplicità e composizione visuale |
| WPBakery | plugin | no | licenza lifetime per sito | devi mantenere uno stack che già lo utilizza |
| SiteOrigin | plugin | sì | core gratuito + Premium opzionale | vuoi una soluzione gratuita essenziale |
Le condizioni commerciali cambiano più rapidamente delle caratteristiche architetturali: prima di acquistare conviene quindi controllare sempre il listino ufficiale del prodotto che stai valutando. Divi continua a offrire sia licenze annuali sia lifetime per il prodotto base; Bricks propone licenze annuali e lifetime; Breakdance utilizza un modello Free + Pro; Oxygen mantiene attualmente un’offerta lifetime; Beaver Builder utilizza piani annuali.
Cos’è un page builder e cosa permette di fare
Un page builder è uno strumento che permette di costruire il layout di una pagina WordPress attraverso un’interfaccia visuale, riducendo la necessità di modificare direttamente PHP, HTML e CSS per ogni intervento.
Il concetto, però, è diventato più ampio.
I builder moderni possono controllare anche header, footer, template degli articoli, archivi, contenuti dinamici, loop, componenti riutilizzabili e parti di WooCommerce. In molti casi siamo quindi molto più vicini a un sistema di site building che a un semplice editor di pagine.
È utile anche distinguere il builder dalle altre componenti di WordPress. Un tema WordPress definisce il livello di presentazione del sito, mentre i plugin WordPress aggiungono o modificano funzionalità. Alcuni builder sono plugin, altri sostituiscono o incorporano anche il ruolo del tema.
Page builder, theme builder e site builder non sono la stessa cosa
Un page builder interviene principalmente sul contenuto e sul layout delle singole pagine.
Un theme builder estende il controllo ai template globali. Puoi, per esempio, creare un modello per tutti gli articoli, un header differente per una determinata sezione o un template per un custom post type.
Un site builder tende invece a riunire gran parte di queste responsabilità in uno stesso ambiente.
I confini non sono sempre netti perché molti prodotti sono cresciuti oltre la categoria da cui sono partiti. Elementor Pro include strumenti di Theme Building; Divi combina tema, Visual Builder e Theme Builder; Bricks è direttamente un visual site builder che funziona come tema.
La terminologia, quindi, conta meno della domanda pratica: quali parti del frontend saranno controllate da questo strumento?
Più la risposta si avvicina a “quasi tutto il sito”, più la scelta del builder diventa una scelta architetturale e non semplicemente editoriale.
Cosa cambia con il Site Editor di WordPress
WordPress offre anche un percorso nativo.
Con un block theme, il Site Editor permette di modificare attraverso i blocchi non soltanto il contenuto, ma anche template, pattern e parti globali del sito. Non equivale automaticamente a Elementor, Bricks o agli altri builder: il workflow, gli strumenti di design e il livello di astrazione sono differenti. Ma oggi ignorarlo in una comparativa sui page builder significherebbe confrontare soltanto una parte delle opzioni disponibili.
La documentazione ufficiale del Site Editor descrive proprio il controllo di navigation, styles, pages, templates e patterns attraverso questo ambiente.
La conseguenza pratica è importante: prima di aggiungere un page builder, verifica se il progetto ne ha davvero bisogno.
Per un sito editoriale relativamente semplice, uno stack basato su block theme e blocchi può essere sufficiente. Se devi realizzare sistemi visuali complessi, interazioni avanzate, template dinamici molto personalizzati o workflow più vicini allo sviluppo visuale, un builder dedicato può invece ridurre notevolmente l’attrito.
Come confrontare davvero due page builder WordPRess
Una buona comparativa dovrebbe partire dai criteri che continuano a contare dopo l’entusiasmo iniziale per l’interfaccia.
Il builder dovrà convivere con WordPress, tema, plugin, hosting, contenuti e persone che amministrano il sito. Per questo la qualità della scelta emerge soprattutto quando il progetto cresce.
Facilità d’uso e curva di apprendimento
“Facile da usare” può significare cose molto diverse.
Per un utente che vuole spostare visivamente testi, immagini e pulsanti, un’interfaccia immediata può essere un vantaggio decisivo. Per un web designer che costruisce decine di pagine, invece, la facilità può dipendere dalla possibilità di definire classi globali, componenti, variabili e sistemi riutilizzabili.
Un builder molto intuitivo all’inizio può diventare laborioso quando ogni modifica viene applicata elemento per elemento.
Allo stesso modo, un ambiente più tecnico può richiedere maggiore apprendimento iniziale ma diventare più efficiente quando il progetto cresce.
Per questo valuterei separatamente:
facilità di iniziare e facilità di mantenere il sistema.
Non sono necessariamente la stessa cosa.
Controllo del design, classi e design system
Su un piccolo sito puoi permetterti di modificare colori e spaziature elemento per elemento. Su cinquanta pagine diventa rapidamente un problema.
Un design system ben impostato permette di modificare una decisione globale senza dover correggere manualmente ogni istanza.
È qui che strumenti come classi, variabili, componenti e stili globali diventano importanti.
Elementor sta spostando il proprio editor di nuova generazione verso un modello più orientato a classi e styling riutilizzabile attraverso l’Atomic Editor. La documentazione ufficiale specifica però che l’Editor V4 continua attualmente a convivere con elementi e workflow della generazione precedente: non va quindi presentato come una transizione già completamente conclusa. La documentazione di Elementor V4 spiega questa convivenza.
Bricks parte invece da un’impostazione più vicina al visual development e rende classi, componenti e strutture riutilizzabili elementi centrali del workflow.
Nessuno dei due modelli è automaticamente migliore. La differenza è quanto vuoi che la costruzione visuale assomigli a un sistema invece che a una sequenza di personalizzazioni locali.
Theme Builder, contenuti dinamici e WooCommerce
Se devi creare soltanto pagine statiche, molti builder sembreranno equivalenti.
Le differenze aumentano quando entrano in gioco:
- custom post type;
- custom fields;
- template dinamici;
- archivi;
- query e loop;
- condizioni di visualizzazione;
- cataloghi;
- schede prodotto;
- template WooCommerce.
In questi casi non basta verificare se il builder “supporta WooCommerce”.
Devi capire che cosa puoi realmente controllare, con quali condizioni, attraverso quale piano e con quante dipendenze aggiuntive.
Un sito immobiliare, per esempio, dovrebbe normalmente conservare prezzo, superficie e caratteristiche dell’immobile come dati strutturati indipendenti dal layout. Il builder dovrebbe poi occuparsi della loro presentazione.
Questo approccio riduce almeno una parte del lock-in: i dati restano dati WordPress anche se un giorno cambierai frontend.
Performance, codice generato e manutenzione
Un page builder partecipa alla costruzione del frontend e può quindi aggiungere markup, CSS, JavaScript, font o altre risorse.
Questo non permette però di stabilire una classifica universale sulla velocità.
Le prestazioni reali dipendono anche da:
- struttura della pagina;
- immagini;
- font;
- plugin;
- script esterni;
- advertising;
- analytics;
- hosting;
- cache;
- CDN;
- quantità e qualità delle personalizzazioni.
Due siti costruiti con lo stesso builder possono quindi avere risultati molto diversi.
La domanda sensata non è “questo page builder è veloce?”, ma:
riesco a costruire il progetto richiesto mantenendo sotto controllo struttura, risorse e complessità?
Prezzo, licenza e numero di siti
Guardare soltanto il prezzo di ingresso è un altro confronto fuorviante.
Per un singolo sito può contare molto il costo iniziale. Per un freelance o un’agenzia diventano importanti anche:
- numero di installazioni consentite;
- costo del rinnovo;
- lifetime vs subscription;
- accesso agli aggiornamenti;
- supporto;
- white label;
- funzioni riservate ai livelli superiori;
- servizi cloud o AI fatturati separatamente.
Divi e Bricks continuano a offrire opzioni lifetime, mentre Elementor, Breakdance e Beaver Builder utilizzano soprattutto modelli ricorrenti per le rispettive offerte premium. Oxygen presenta attualmente un modello commerciale lifetime per la nuova generazione. Le condizioni vanno comunque verificate sulle rispettive pagine ufficiali prima dell’acquisto.
Lock-in: cosa succede se un giorno cambi builder
Questo è uno dei criteri che valuterei prima, non dopo aver costruito il sito.
Passare da un page builder all’altro raramente significa installare il nuovo plugin e continuare a lavorare.
Puoi dover ricostruire:
- layout;
- template;
- componenti;
- styling;
- condizioni;
- popup;
- moduli;
- loop;
- parti WooCommerce;
- integrazioni;
- relazioni con contenuti dinamici.
Il testo e i dati WordPress possono essere molto più portabili se sono stati archiviati correttamente. Il sistema visuale normalmente lo è molto meno.
Per questo è preferibile separare, per quanto possibile:
dati e contenuti → WordPress
da:
presentazione → builder
La dipendenza da uno strumento non è automaticamente negativa. Una dipendenza consapevole può essere perfettamente razionale. Il problema nasce quando scopri soltanto durante una migrazione quanto del sito dipendesse realmente dal builder.
Elementor: la scelta più accessibile per un ecosistema completo
Elementor rimane uno dei riferimenti naturali quando il progetto richiede un workflow fortemente visuale.
La versione gratuita permette di costruire pagine attraverso il plugin, mentre i livelli premium estendono l’ambiente con funzioni che, a seconda del piano, possono comprendere Theme Builder, contenuti dinamici, form, popup e strumenti dedicati a WooCommerce. La struttura commerciale attuale non rende però corretto trattare “Elementor Pro” come un unico pacchetto identico in ogni livello: conviene sempre verificare la matrice corrente dei piani.
Se vuoi entrare molto più nel dettaglio, abbiamo dedicato una guida separata a Elementor, alle versioni disponibili e al suo ruolo attuale in WordPress.
Elementor V4 e Atomic Editor: cosa sta cambiando
L’evoluzione più interessante riguarda l’Editor V4 e l’Atomic Editor.
La direzione è quella di un sistema maggiormente basato su classi, proprietà e stili riutilizzabili, avvicinando il workflow visuale a concetti normalmente familiari a chi lavora con CSS e design system.
C’è però una distinzione importante: la transizione non è ancora un semplice “V3 spento, V4 acceso”. La documentazione Elementor indica che il nuovo editor continua a convivere con componenti della generazione precedente.
Per un nuovo progetto questa evoluzione è interessante; per un sito esistente, invece, non rappresenta da sola un motivo per ricostruire tutto.
Quando scegliere Elementor e quando guardare altrove
Lo prenderei seriamente in considerazione quando:
- il team deve lavorare visualmente sui layout;
- vuoi partire con una versione gratuita;
- Theme Builder e contenuti dinamici fanno parte del progetto;
- WooCommerce richiede un controllo visuale maggiore;
- preferisci un ecosistema ampio di strumenti e integrazioni.
Guarderei anche Bricks, Oxygen o lo stack nativo quando il requisito prioritario diventa un workflow molto strutturato, vicino allo sviluppo, oppure la riduzione delle dipendenze da un builder.
Se il sito usa già Elementor bene, invece, cambiare solamente perché un altro prodotto sembra più moderno raramente è una ragione sufficiente.
La migrazione deve risolvere un problema reale.
Divi 5: builder e tema in un ecosistema integrato
Divi va interpretato in modo diverso da Elementor perché nasce come ecosistema che combina Divi Theme, Visual Builder e Theme Builder.
Con Divi 5 Elegant Themes ha ricostruito parti sostanziali dell’architettura del builder. La versione è uscita dalla fase beta ed è diventata la linea corrente del prodotto, mentre lo sviluppo continua attraverso release successive.
Nella nostra analisi completa di Divi 5 approfondiamo proprio questo cambio di generazione.
Cosa cambia realmente con Divi 5
Uno dei cambiamenti più significativi riguarda l’abbandono, nella nuova architettura, della vecchia dipendenza dagli shortcode che caratterizzava Divi 4.
Questo modifica anche una delle obiezioni storiche più frequenti sul lock-in del prodotto. Non significa che un layout Divi diventi improvvisamente trasferibile verso Elementor o Bricks: template, design e configurazioni continuano ad appartenere al sistema Divi.
Significa che il tipo di dipendenza è cambiato e non è corretto valutare Divi 5 ripetendo automaticamente tutti i limiti attribuiti alle generazioni precedenti.
L’offerta base continua inoltre a essere disponibile attraverso licenze annuali e lifetime, mentre servizi aggiuntivi dell’ecosistema possono seguire condizioni commerciali separate.
Quando Divi ha più senso di Elementor o Bricks
Divi diventa interessante se vuoi adottare deliberatamente il suo ecosistema:
- tema e builder fortemente integrati;
- Theme Builder;
- design system interno;
- strumenti e servizi Elegant Themes;
- licenza utilizzabile su più progetti secondo il piano scelto.
Ha meno senso scegliere Divi soltanto perché “include tante cose”.
Se utilizzerai una piccola parte dell’ecosistema, un altro stack potrebbe essere più semplice.
Rispetto a Bricks, inoltre, cambia la filosofia di lavoro. Bricks tende maggiormente verso il visual development strutturato; Divi cerca di rendere un sistema molto ampio utilizzabile anche attraverso un’interfaccia visuale accessibile.
Bricks Builder: controllo visuale con un approccio più vicino allo sviluppo
Bricks merita un posto centrale in una comparativa attuale perché rappresenta un approccio differente dai page builder plugin tradizionali.
Bricks è anche il tema attivo del sito.
Il modello è quindi più vicino a:
WordPress → Bricks theme/site builder → plugin funzionali necessari
che a:
WordPress → tema → plugin page builder
La guida completa a Bricks Builder approfondisce questa differenza e le conseguenze sullo stack.
Perché Bricks è diverso dai classici page builder
Bricks mette al centro concetti come:
- classi;
- variabili;
- componenti;
- template;
- contenuti dinamici;
- Query Loop;
- controllo responsive;
- elementi riutilizzabili.
Questo lo rende particolarmente interessante quando vuoi costruire un sistema di frontend, non soltanto una raccolta di pagine.
La release stabile corrente appartiene alla linea 2.3.x, mentre la serie 2.4 è ancora beta. Quest’ultima contiene anche nuove funzioni legate all’AI e all’interazione via MCP, che proprio perché beta non utilizzerei come requisito critico di un sito in produzione.
È una distinzione importante: roadmap e beta aiutano a capire dove sta andando un prodotto, ma non hanno lo stesso peso delle funzioni già stabili.
Quando Bricks è una scelta migliore e quando complica inutilmente il progetto
Lo valuterei soprattutto per:
- web designer con un workflow strutturato;
- agenzie;
- siti dinamici;
- custom post type e custom fields;
- componenti riutilizzabili;
- design system;
- WooCommerce molto personalizzato;
- progetti in cui classi e struttura sono parte del metodo di lavoro.
Per una persona che deve semplicemente creare poche pagine promozionali, invece, questa maggiore profondità può diventare complessità non necessaria.
Bricks non è “migliore perché più tecnico”.
È migliore quando quel livello di controllo viene realmente utilizzato.
Breakdance: equilibrio tra builder visuale e strumenti avanzati
Breakdance appartiene alla generazione di builder che cerca di combinare facilità visuale e funzionalità più ampie di site building.
Offre una versione gratuita e una linea Pro. Il prodotto comprende strumenti per costruzione visuale, dati dinamici, form e WooCommerce, con differenze fra Free e Pro da verificare nella documentazione commerciale corrente.
Cosa offre oggi Breakdance e cosa appartiene alla versione 3 beta
Qui serve attenzione alle versioni.
La linea stabile corrente è Breakdance 2.8, mentre Breakdance 3 è ancora in beta. Quando confronti il prodotto per un progetto reale, la base dovrebbe quindi essere ciò che è disponibile nella versione stabile; le novità della beta possono essere considerate un’indicazione della direzione futura.
Questo criterio vale per qualsiasi builder: una comparative seria non dovrebbe sommare feature stabili, beta e roadmap come se fossero equivalenti.
Per quali progetti lo sceglierei
Breakdance è interessante quando vuoi un ambiente visuale molto completo ma non vuoi necessariamente adottare il modello in cui il builder coincide con il tema, come avviene con Bricks.
Lo confronterei soprattutto con Elementor e Bricks quando il progetto richiede:
- Theme Building;
- dynamic data;
- WooCommerce;
- form;
- workflow visuale avanzato;
- un numero contenuto di strumenti esterni per costruire il frontend.
La scelta dipenderà poi da quanto il team valorizza accessibilità dell’editor, design system, estensibilità e modello commerciale.
Oxygen 6: controllo tecnico per sviluppatori e siti custom
Oxygen è cambiato abbastanza da rendere poco utile valutarlo soltanto attraverso vecchie comparative.
La nuova generazione Oxygen 6 è production-ready, mentre Oxygen Classic continua a esistere come prodotto distinto. Lo sviluppo della linea 6 prosegue inoltre con release beta successive, che non vanno confuse con la versione stabile utilizzabile in produzione.
Per caratteristiche e differenze puoi approfondire nella nostra guida dedicata a Oxygen Builder.
Il nuovo Oxygen rispetto a Oxygen Classic
Il punto più importante è non trattare Oxygen 6 come una semplice nuova versione numerica del vecchio editor.
Il prodotto viene riposizionato come ambiente di visual development più moderno, mentre Classic rimane separato.
Per chi parte oggi da zero è quindi la nuova generazione quella da valutare. Per chi possiede un progetto Oxygen Classic, invece, il problema è diverso: prima di qualsiasi migrazione va analizzato quanto l’installazione dipenda dall’architettura precedente.
Anche qui nuovo non significa automaticamente “devi migrare”.
Quando Oxygen ha senso rispetto a Bricks e Breakdance
Oxygen ha più senso quando chi costruisce il sito vuole un ambiente vicino al visual development e possiede già una buona comprensione di HTML e CSS.
Se l’obiettivo è permettere a utenti meno tecnici di intervenire frequentemente sul layout, altri builder possono offrire un compromesso più semplice.
Il confronto con Bricks è particolarmente interessante perché entrambi possono attrarre un pubblico più tecnico, ma adottano architetture e workflow differenti.
La scelta andrebbe fatta costruendo un piccolo prototipo rappresentativo del progetto reale, non contando gli elementi disponibili nell’editor.
Beaver Builder: stabilità e workflow per freelance e agenzie
Beaver Builder continua a seguire un approccio più conservativo rispetto ad alcuni concorrenti.
Questo può apparire meno spettacolare in una pagina marketing, ma per un progetto professionale la prevedibilità del workflow può avere valore.
La struttura commerciale corrente comprende livelli basati sul numero di siti e, nei piani attuali, riunisce Page Builder, Beaver Builder Theme e Beaver Themer.
La nostra guida a Beaver Builder approfondisce funzioni e utilizzo; alcune sezioni storiche di quella pagina richiedono tuttavia un aggiornamento editoriale separato, soprattutto per eliminare vecchi claim assoluti su SEO e performance.
Builder, Theme e Themer nello stesso ecosistema
È utile distinguere i tre livelli.
Beaver Builder costruisce visualmente i contenuti.
Beaver Builder Theme fornisce il livello tema.
Beaver Themer estende il controllo verso template e parti dinamiche.
Questa combinazione permette quindi di costruire uno stack molto più completo rispetto al semplice editor delle pagine.
Non significa che tu debba necessariamente utilizzare tutti e tre. Se un tema esistente gestisce già bene il frontend e devi modificare solo alcune pagine, il page builder può bastare.
Dove Beaver Builder continua ad avere senso
Lo considererei soprattutto quando:
- vuoi un workflow relativamente prevedibile;
- lavori su più siti;
- preferisci un ecosistema maturo;
- non vuoi inseguire ogni nuova funzione del mercato;
- Theme e Themer sono utili al progetto;
- il team conosce già lo strumento.
Non lo sceglierei perché sarebbe genericamente “il più stabile” o “il più veloce”: senza un confronto metodologico sul progetto reale sarebbero claim troppo forti.
Brizy, WPBakery e SiteOrigin: quando considerarli ancora
Non tutti i progetti richiedono uno dei builder più discussi del momento.
Brizy, WPBakery e SiteOrigin rispondono a esigenze diverse e, soprattutto nel caso di un sito esistente, la continuità può pesare più della novità.
Brizy per semplicità e workflow visuale
Brizy mantiene un’offerta WordPress gratuita affiancata da livelli premium.
Il suo posizionamento resta molto orientato alla costruzione visuale e alla facilità di composizione. È quindi una soluzione da considerare quando vuoi un editor immediato senza adottare necessariamente un workflow più tecnico come Bricks o Oxygen. Le condizioni correnti dei piani WordPress sono disponibili nella pagina ufficiale di Brizy.
La domanda da farti non è se abbia “abbastanza widget”, ma se il suo modello di Theme Building, dynamic content e licensing soddisfi davvero ciò che dovrai costruire.
WPBakery per continuità con siti e temi esistenti
WPBakery è spesso trattato come un prodotto da scartare soltanto perché appartiene a una generazione storica di page builder.
È una semplificazione.
La linea continua a essere sviluppata e il modello commerciale attuale prevede licenze lifetime.
Per un nuovo progetto confrontarei attentamente WPBakery con gli strumenti più moderni prima di sceglierlo.
Per un sito esistente costruito profondamente attorno a WPBakery, invece, la domanda cambia:
esiste un problema sufficientemente importante da giustificare la ricostruzione?
Se il sito funziona, è mantenuto correttamente e il builder soddisfa i requisiti, migrare solo per modernizzare lo stack può generare più lavoro e rischio che valore.
SiteOrigin per chi cerca una soluzione gratuita e consolidata
SiteOrigin Page Builder rimane disponibile gratuitamente e può essere esteso attraverso un’offerta Premium opzionale.
Non offre necessariamente lo stesso modello operativo dei builder visual-development più avanzati, ma può avere senso quando:
- il budget è prioritario;
- le esigenze di layout sono relativamente semplici;
- vuoi mantenere un sito che già utilizza SiteOrigin;
- non servono design system o workflow dinamici particolarmente sofisticati.
È un buon esempio del perché una comparativa non dovrebbe premiare automaticamente lo strumento con più funzioni.
Se le funzioni aggiuntive non servono, non generano valore soltanto perché esistono.
Page builder WordPress gratis: quali puoi usare senza pagare
La ricerca di un page builder WordPress gratis non è necessariamente un sotto-intent diverso dalla scelta del builder: spesso è il primo filtro con cui una persona prova lo strumento.
Le alternative realmente gratuite includono Elementor Free, Brizy Free, Beaver Builder Lite, SiteOrigin e naturalmente gli strumenti nativi di WordPress. Breakdance propone anch’esso una versione gratuita con funzionalità più limitate rispetto a Pro.
La vera domanda è fino a che punto puoi restare nella versione gratuita.
Elementor Free, Beaver Builder Lite, Brizy e SiteOrigin
Per la costruzione di pagine relativamente semplici, una versione free può essere sufficiente.
Il limite emerge quando il progetto richiede funzioni che il vendor riserva ai piani premium, per esempio:
- template globali avanzati;
- contenuti dinamici;
- WooCommerce;
- form;
- popup;
- condizioni;
- strumenti professionali o white label.
Non partirei quindi dal prezzo della versione Pro.
Partirei dal requisito che costringe eventualmente a passare alla versione Pro.
È molto più facile capire il costo reale del progetto.
Site Editor e block builder come alternativa gratuita
La soluzione più radicale consiste nel chiedersi se serva davvero un page builder esterno.
Con un block theme e il Site Editor puoi costruire progressivamente una parte sempre più ampia del frontend utilizzando gli strumenti di WordPress. Plugin di blocchi possono inoltre ampliare le possibilità dell’editor nativo.
Questo non rende automaticamente inutile Elementor.
Rende però meno sensata la vecchia equivalenza:
voglio progettare WordPress visualmente → devo installare un page builder
Oggi esiste anche:
voglio progettare WordPress visualmente → valuto prima cosa posso ottenere con blocchi e Site Editor
Quando una versione free smette di essere sufficiente
Una versione gratuita smette di essere conveniente quando inizi a ricostruire attraverso molti plugin separati ciò che il livello premium risolverebbe in modo più coerente.
Supponiamo che ti servano:
- Theme Builder;
- form;
- popup;
- custom fields;
- elementi WooCommerce;
- condizioni;
- widget aggiuntivi.
Installare cinque estensioni soltanto per evitare una licenza non è automaticamente un risparmio.
Il costo va misurato anche come complessità dello stack, aggiornamenti, compatibilità e tempo di manutenzione.
Gutenberg e Site Editor possono sostituire un page builder?
Sì, in alcuni progetti. Non in tutti.
Il Site Editor permette già di intervenire su template e parti globali quando il sito utilizza un block theme. Il risultato è un’architettura molto vicina agli strumenti nativi di WordPress.
Un builder dedicato continua però a offrire vantaggi quando il progetto richiede un livello di controllo, un workflow o strumenti che il tuo stack a blocchi non soddisfa in modo efficiente.
Quando restare nello stack nativo WordPress
Considererei seriamente Site Editor + blocchi quando:
- il sito è prevalentemente editoriale;
- il layout non richiede sistemi visuali estremamente complessi;
- vuoi ridurre il numero di dipendenze;
- il team lavora bene nell’editor WordPress;
- il block theme scelto copre bene il progetto;
- la portabilità verso il paradigma nativo è una priorità.
Non significa “zero plugin”.
Significa evitare di introdurre un page builder quando non risolve un problema concreto.
Quando un builder dedicato offre ancora un vantaggio reale
Un page builder dedicato tende ad avere più senso quando aumentano:
- varietà dei layout;
- controllo responsive;
- componenti;
- design system;
- contenuti dinamici;
- query visuali;
- template WooCommerce;
- interazioni;
- workflow di agenzia;
- necessità di consegnare agli editor un ambiente visuale specifico.
È qui che Elementor, Divi, Bricks, Breakdance, Oxygen e Beaver Builder iniziano a differenziarsi molto più chiaramente dallo stack nativo.
Page builder e performance: il builder più veloce non esiste in assoluto
Le classifiche “builder più veloce” sono spesso molto più precise di quanto permetta l’evidenza.
Un benchmark ha valore soltanto se conosci:
- hosting;
- versione PHP;
- tema;
- pagina testata;
- quantità di componenti;
- immagini;
- font;
- cache;
- plugin attivi;
- configurazione;
- metodologia;
- numero di test.
Senza queste informazioni, assegnare cinque stelle alla velocità di un builder e tre a un altro crea una precisione che non possediamo.
Perché le stelline sulla velocità dicono poco
Il builder produce una parte del frontend, ma non è l’intero sito.
Prendi due pagine:
Pagina A
- builder relativamente complesso;
- immagini ben ottimizzate;
- pochi font;
- nessuna pubblicità;
- cache ben configurata.
Pagina B
- markup teoricamente più leggero;
- immagini enormi;
- diversi font esterni;
- advertising;
- chat;
- script di terze parti.
Non puoi dedurre quale sarà più veloce dal nome del builder.
Questo è il motivo per cui eliminerei qualsiasi classifica di performance priva di una metodologia riproducibile.
Cosa controllare realmente prima di scegliere
Se le prestazioni sono importanti, costruisci un prototipo rappresentativo del progetto.
Non una pagina vuota.
Una pagina con:
- hero reale;
- immagini;
- header;
- menu;
- sezioni;
- form;
- template;
- font;
- eventuale WooCommerce;
- plugin realmente necessari.
A quel punto misura.
Controlla inoltre quante dipendenze devi aggiungere attorno al builder. Un editor essenziale che necessita di numerosi addon può produrre uno stack più complicato di un builder che include nativamente le funzioni richieste.
Performance, Core Web Vitals e SEO: cosa possiamo affermare e cosa no
Google utilizza i Core Web Vitals per valutare aspetti dell’esperienza della pagina come caricamento, interattività e stabilità visuale, e li include tra i segnali considerati dai propri sistemi. Google specifica però anche che buoni risultati Core Web Vitals, da soli, non garantiscono posizioni elevate. La documentazione ufficiale sui Core Web Vitals è molto più prudente delle promesse che spesso vengono associate ai singoli page builder.
Quindi:
GOOGLE_CONFIRMED: i Core Web Vitals riguardano aspetti misurabili della page experience e fanno parte dei segnali utilizzati dai sistemi Google.
NON DIMOSTRATO: “usare builder X migliora automaticamente la SEO”.
NON DIMOSTRATO: “builder Y impedisce di posizionarsi”.
Il builder può contribuire a markup, CSS, JavaScript e struttura. Il risultato SEO dipende però da un sistema molto più ampio.
Quale page builder scegliere per il tuo progetto
A questo punto possiamo trasformare le differenze in decisioni.
Non considerare questi scenari come regole rigide. Servono a ridurre il numero di alternative da testare.
Sito vetrina
Per un normale sito aziendale valuterei per prima cosa la complessità del design e chi dovrà amministrarlo.
Elementor è una scelta naturale se il cliente o il team deve modificare visualmente le pagine.
Divi può avere senso se vuoi adottare l’intero ecosistema Elegant Themes.
Site Editor può essere sufficiente quando il progetto è relativamente semplice e vuoi mantenere lo stack vicino a WordPress.
Bricks diventa più interessante se il sito vetrina fa parte di un metodo di produzione più strutturato, per esempio quello di un web designer o di un’agenzia.
Blog e sito editoriale
Per un progetto fortemente editoriale partirei dal Site Editor prima di aggiungere un builder.
Articoli, categorie, tassonomie e contenuti dovrebbero rimanere il più possibile indipendenti dal sistema di presentazione.
Un builder diventa più utile quando hai molti template speciali, landing page, contenuti dinamici o requisiti visuali che lo stack a blocchi non gestisce come desideri.
Landing page
Qui un builder visuale può avere un vantaggio evidente perché permette di iterare rapidamente su layout, sezioni e componenti.
Elementor, Divi, Brizy e Breakdance sono candidati naturali per workflow visuali. Bricks può diventare molto efficiente se le landing fanno parte di un design system più ampio.
Prima del builder, però, viene la struttura della pagina: nella nostra guida trovi un approfondimento su come progettare e ottimizzare una landing page.
WooCommerce
Per un ecommerce non sceglierei mai il builder guardando soltanto la home page.
Verificherei almeno:
- template prodotto;
- archivio prodotti;
- carrello;
- checkout;
- account;
- loop;
- filtri;
- dynamic data;
- compatibilità con le estensioni realmente utilizzate.
Elementor Pro, Divi, Bricks e Breakdance offrono strumenti differenti per intervenire sul livello visuale dell’ecommerce. WooCommerce continua però a gestire prodotti, ordini, carrello e logiche commerciali: il page builder non sostituisce WooCommerce.
Se devi prima chiarire questa distinzione, trovi qui la nostra guida introduttiva a WooCommerce.
Agenzia e gestione di molti siti
Per un’agenzia aumentano di importanza criteri spesso secondari sul singolo progetto:
- licensing multi-sito;
- white label;
- componenti riutilizzabili;
- design system;
- velocità del workflow;
- onboarding del team;
- staging;
- manutenzione;
- continuità del vendor.
Bricks, Beaver Builder, Divi ed Elementor possono tutti essere razionali, ma per motivi differenti.
Il vero risparmio non deriva necessariamente dal builder meno costoso.
Deriva dal sistema che permette di lavorare in modo ripetibile senza moltiplicare eccezioni e correzioni manuali.
Progetti custom per sviluppatori
Quando il progetto richiede molti custom post type, custom fields, logiche dinamiche e frontend molto controllato, guarderei soprattutto a Bricks e Oxygen, senza escludere Breakdance.
In questo scenario la capacità di lavorare con classi, struttura HTML, componenti, query e dati può pesare molto più del numero di template predefiniti.
Esiste inoltre una nuova generazione di strumenti, come Etch, che sta spingendo ulteriormente il concetto verso il visual development environment anziché il semplice page builder. È un segnale interessante sull’evoluzione della categoria, ma non trasformerei un player emergente in una raccomandazione principale soltanto perché propone un approccio nuovo.
Posso cambiare page builder in seguito?
Sì, ma raramente senza lavoro.
Quanto lavoro dipende da quanto profondamente il builder controlla il sito.
Se lo hai utilizzato soltanto per due landing page, la migrazione può essere relativamente circoscritta.
Se gestisce:
- header;
- footer;
- template;
- archivi;
- custom post type;
- WooCommerce;
- popup;
- form;
- contenuti dinamici;
- centinaia di pagine;
stai sostituendo una parte consistente dell’architettura di presentazione.
Lock-in, shortcode, template e contenuti
Il lock-in non è un concetto binario.
Può riguardare:
- storage dei contenuti;
- markup;
- template;
- stili;
- componenti proprietari;
- dynamic data;
- workflow del team.
Un builder potrebbe lasciare leggibile il testo ma rendere necessaria la ricostruzione completa del layout.
Un altro potrebbe non utilizzare shortcode e creare comunque una forte dipendenza dai propri template e componenti.
Per questo chiedere semplicemente “usa shortcode?” non basta.
La domanda completa è:
cosa rimane utilizzabile quando questo sistema non controlla più il frontend?
Quando conviene migrare e quando è meglio non toccare un sito esistente
Una migrazione è più facile da giustificare quando il vecchio sistema provoca problemi concreti:
- incompatibilità;
- sviluppo interrotto;
- manutenzione insostenibile;
- limiti che impediscono nuove funzioni necessarie;
- workflow troppo costoso;
- problemi strutturali che non puoi risolvere ragionevolmente nello stack attuale.
È molto più difficile giustificarla quando la motivazione è soltanto:
è uscito un builder che sembra più moderno.
Un sito stabile non deve inseguire continuamente il mercato dei page builder.
L’obiettivo è avere uno stack sostenibile, non possedere sempre l’editor più recente.
Domande frequenti sui page builder WordPress
Serve ancora un tema se uso un page builder?
Dipende dal builder.
Elementor e Beaver Builder sono plugin e normalmente lavorano insieme a un tema. Divi comprende il proprio tema. Bricks è direttamente un tema con visual site builder integrato. Con Site Editor utilizzi invece un block theme.
Quindi “page builder” non identifica una sola architettura.
Un page builder rallenta WordPress?
Può contribuire al peso e alla complessità del frontend, ma non puoi prevedere le performance reali soltanto dal nome del builder.
Markup, CSS e JavaScript del builder sono una parte del risultato. Immagini, font, plugin, hosting, cache, script esterni e struttura delle pagine possono incidere altrettanto o più, a seconda del progetto.
La risposta corretta è misurare una configurazione rappresentativa.
Qual è il miglior page builder gratuito?
Se vuoi un classico editor visuale, Elementor Free è uno dei punti di partenza più completi da valutare. Brizy, Beaver Builder Lite, SiteOrigin e Breakdance Free sono altre alternative.
Se il sito può essere costruito attraverso block theme e blocchi, Site Editor è invece l’opzione nativa da verificare prima di aggiungere un builder esterno.
Il “migliore” dipende dalle funzioni che ti servono senza passare al piano premium.
Elementor, Divi o Bricks: quale scegliere?
Userei questa distinzione iniziale:
Elementor se vuoi accessibilità, ecosistema ampio e possibilità di partire gratuitamente.
Divi se preferisci un ecosistema integrato che comprende tema, Visual Builder e Theme Builder.
Bricks se vuoi un workflow maggiormente orientato a design system, classi, componenti e visual development.
Prima della decisione finale costruirei comunque un piccolo caso reale con ciascuno dei due candidati rimasti.
È meglio Gutenberg o un page builder?
Se con Site Editor e blocchi riesci a soddisfare il progetto senza introdurre complessità artificiale, restare vicino allo stack nativo è una scelta perfettamente razionale.
Se invece il progetto richiede strumenti visuali, dinamici o di design che il tuo stack nativo non gestisce in modo efficiente, un page builder dedicato può essere una soluzione migliore.
La domanda quindi non è “Gutenberg o page builder in assoluto?”, ma:
quale stack permette di costruire e mantenere questo progetto con il minor compromesso complessivo?
Conclusione
Il mercato dei page builder WordPress è diventato troppo articolato per essere ridotto a una classifica basata sul numero di widget.
Elementor resta una scelta forte se accessibilità ed ecosistema sono prioritari. Divi 5 ha senso quando vuoi lavorare nell’ambiente Elegant Themes. Bricks e Oxygen diventano particolarmente interessanti quando il workflow è più vicino allo sviluppo visuale e ai design system. Breakdance occupa una posizione intermedia molto interessante, mentre Beaver Builder privilegia un approccio più consolidato. Brizy, WPBakery e SiteOrigin rimangono opzioni razionali in scenari specifici.
E prima di scegliere uno qualsiasi di questi strumenti, vale la pena verificare se Site Editor e block theme siano già sufficienti.
Il criterio che userei è semplice:
scegli il builder che risolve le esigenze reali del progetto con la quantità di dipendenze, manutenzione e lock-in che sei disposto ad accettare.
Se stai costruendo da zero, prova i candidati rimasti su una pagina realmente rappresentativa del sito. Se invece il progetto esiste già, non iniziare dal builder che vorresti installare: inizia dai problemi che vuoi risolvere.
Quando il punto non è più soltanto scegliere l’editor ma decidere tema, architettura, performance, WooCommerce, manutenzione e struttura complessiva del progetto, la scelta del builder diventa parte della progettazione professionale di un sito WordPress, non un acquisto isolato.