Bricks Builder è un visual site builder per WordPress self-hosted distribuito come tema. Ti permette di costruire visivamente pagine, template, header, footer, archivi, layout dinamici e parti di un ecommerce, ma il punto interessante non è soltanto il drag-and-drop: Bricks porta dentro l’editor concetti come classi CSS, variabili, componenti, query e contenuti dinamici.
Questo cambia il modo in cui conviene valutarlo. Se lo confronti con altri builder contando widget, effetti o template pronti, rischi di perderne il senso. Bricks è più interessante quando viene utilizzato come sistema con cui progettare e mantenere l’intero sito, non come strumento per costruire una singola landing page.
Ed è anche il motivo per cui non è automaticamente la scelta giusta per tutti.
Se stai iniziando da zero con il CMS, prima può esserti utile chiarire come funziona WordPress e quale ruolo hanno core, tema e plugin. Qui ci concentriamo invece su cosa cambia quando scegli Bricks come base visuale del progetto.
Nota sulle versioni: al momento della verifica la release stabile è Bricks 2.3.11. La serie 2.4 è ancora beta e introduce anche nuove funzioni legate ad AI, MCP e workflow WooCommerce. Nell’articolo distinguiamo quindi ciò che puoi considerare stabile da ciò che è ancora in fase di test.
Cos’è Bricks Builder e perché non è un normale page builder
La definizione ufficiale di Bricks parla di un visual site builder theme per siti WordPress self-hosted. Questa formulazione è importante: Bricks non è semplicemente un plugin che installi sopra un tema scelto separatamente. È esso stesso il tema attivo del sito e incorpora il sistema con cui ne costruisci il frontend.
In pratica riunisce in un unico ambiente buona parte di ciò che, in altre configurazioni WordPress, può essere suddiviso tra tema, page builder, theme builder e diversi strumenti di styling.
Bricks è un tema con site builder integrato, non un plugin
In una configurazione WordPress tradizionale puoi avere, per esempio:
WordPress → tema → page builder → plugin aggiuntivi
Con Bricks il modello diventa più vicino a:
WordPress → Bricks theme/site builder → eventuali plugin funzionali
Non significa che Bricks sostituisca ogni plugin. WooCommerce continua a occuparsi della logica ecommerce, ACF può continuare a gestire campi personalizzati e un plugin SEO continua ad avere il proprio ruolo.
Significa invece che la costruzione visuale del frontend e gran parte del sistema di template dipendono direttamente dal tema Bricks.
La distinzione è più chiara se conosci già che cos’è un tema WordPress e quale funzione svolge: scegliendo Bricks non stai semplicemente aggiungendo un editor al tema, ma stai scegliendo anche la base che governerà il rendering visuale del sito.
Cosa cambia quando tema e sistema di costruzione del sito coincidono
Il vantaggio principale è l’integrazione.
Quando layout, template, componenti e design system vivono nello stesso ambiente, hai meno livelli da coordinare. Puoi costruire un header, definire le regole tipografiche globali, creare il template di un custom post type e riutilizzare un componente senza passare continuamente tra strumenti differenti.
Il rovescio della medaglia è altrettanto importante: la scelta di Bricks diventa architetturale.
Se costruisci molte parti del sito con Bricks, cambiare builder in futuro non equivale a cambiare semplicemente un plugin. Template, styling, componenti e strutture visuali dovranno essere rivalutati o ricostruiti.
Per questo Bricks ha molto più senso su un progetto nuovo, o su un redesign pianificato, che come acquisto impulsivo da installare su un sito esistente soltanto perché hai visto una demo interessante.
Come funziona Bricks Builder: dall’editor visuale al design system
Aprendo Bricks Builder trovi un editor visuale, ma sotto l’interfaccia grafica rimangono riconoscibili diversi concetti del frontend web.
È uno degli aspetti che lo differenziano dai builder che cercano di nascondere quasi completamente HTML e CSS.
Bricks ti consente di lavorare visualmente, ma ragiona comunque in termini di contenitori, layout, classi, proprietà CSS, breakpoint e componenti riutilizzabili. La conseguenza è interessante: puoi iniziare senza scrivere codice, ma capire il funzionamento di CSS e del browser rende il builder molto più potente.
Section, Container, Block e Div: come viene costruito un layout
La documentazione ufficiale dedicata al layout di Bricks distingue quattro elementi strutturali principali:
- Section, pensata per dividere la pagina in grandi aree;
- Container, che fornisce una struttura contenitiva con impostazioni predefinite;
- Block, un elemento flex a larghezza piena utile per organizzare righe e colonne;
- Div, il contenitore più neutro, senza styling predefinito.
Non sono quattro “widget grafici” indipendenti. Section, Container e Block sono sostanzialmente elementi div con preset che velocizzano il lavoro.
Questa distinzione diventa utile quando vuoi evitare il classico problema dei builder visuali: aggiungere contenitori su contenitori senza capire quale struttura HTML stai creando.
Se per esempio devi realizzare una sezione con tre card, puoi costruire una gerarchia logica:
Section → Container → 3 Block → contenuto delle card
La domanda diventa quindi “quale struttura serve al layout?”, non “quale widget posso trascinare qui?”.
Flexbox, CSS Grid, breakpoint e controllo responsive
I layout possono utilizzare Flexbox oppure CSS Grid e gli elementi strutturali espongono controlli visuali per gestirne le proprietà.
È un vantaggio soprattutto quando i layout diventano più articolati. Una griglia di card, per esempio, non deve essere simulata utilizzando colonne arbitrarie: può essere costruita realmente come grid.
Lo stesso approccio continua sul responsive. Bricks mette a disposizione breakpoint predefiniti e consente di modificare proprietà a seconda della viewport.
Qui emerge una distinzione che vale per qualsiasi builder: responsive non significa vedere il desktop rimpicciolito sul telefono.
Se una hero ha due colonne su desktop, su mobile potresti dover:
- cambiare direzione del layout;
- ridurre padding e gap;
- modificare dimensione tipografica;
- cambiare ordine degli elementi;
- nascondere un elemento puramente decorativo;
- ridefinire la dimensione di immagini o media.
Bricks mette a disposizione i controlli. La qualità del risultato dipende comunque dalle decisioni di chi costruisce il sito.
Classi, variabili e Style Manager: perché conviene ragionare per sistema
Uno degli errori più facili con qualsiasi editor visuale è personalizzare ogni elemento singolarmente.
Imposti un bottone blu. Poi un secondo bottone quasi uguale. Un mese dopo cambi il colore del brand e scopri che devi correggere decine di elementi.
Con Bricks puoi invece costruire un design system basato su Theme Styles, classi globali, variabili, colori, tipografia e scale gestite attraverso lo Style Manager.
Immagina di avere:
--color-primary--space-m--radius-m
e una classe:
.button-primary
Il bottone non deve ricordarsi autonomamente quali siano colore, spaziatura e raggio. Riceve quelle decisioni dal sistema.
Se cambia il colore principale del brand, modifichi la variabile. Se cambia il modo in cui devono apparire tutti i pulsanti principali, modifichi la classe.
Il vantaggio non è semplicemente “fare prima”. È ridurre le eccezioni.
Più un sito cresce, più le eccezioni diventano costose da mantenere. Dieci pagine costruite una per una possono sembrare gestibili; cento pagine, più template, landing ed ecommerce rendono molto più evidente il valore di regole globali.
Components e riuso: modificare una struttura senza ricostruirla ogni volta
Le classi riutilizzano lo stile. I Components portano il riuso a un livello superiore: permettono di riutilizzare strutture complete mantenendo una relazione con il componente principale. Bricks supporta inoltre proprietà dei componenti e varianti basate anche su classi globali.
Pensa a una card di servizio composta da:
icona → titolo → descrizione → link
Se la copi manualmente in venti pagine, hai venti strutture indipendenti.
Se diventa un componente, puoi mantenere una struttura comune e controllare quali proprietà devono cambiare nelle singole istanze.
È una differenza sostanziale per agenzie, freelance o progetti editoriali con molti elementi ripetuti: il sito smette gradualmente di essere una collezione di pagine e diventa una libreria di regole e componenti.
Template, contenuti dinamici e Query Loop: dove Bricks Builder diventa più di un editor visuale
La parte più interessante di Bricks emerge quando smetti di progettare singole pagine statiche.
WordPress è un CMS: contiene articoli, pagine, utenti, tassonomie, custom post type, prodotti e metadati. Un site builder diventa realmente utile quando riesce a collegare il design a questa struttura dati.
Bricks lo fa attraverso template, Dynamic Data e Query Loop.
Header, footer, single, archive e condizioni dei template
Un template descrive come deve essere visualizzato un tipo di contenuto, non il contenuto specifico.
Puoi quindi creare un template per:
- header;
- footer;
- singoli articoli;
- archivi;
- custom post type;
- risultati di ricerca;
- parti di WooCommerce.
Questo evita di ricostruire lo stesso layout per ogni contenuto.
Supponiamo di avere un sito immobiliare con 500 immobili.
Non costruisci 500 pagine grafiche una per una. Crei un custom post type “Immobili”, definisci i dati necessari e costruisci un template single che stabilisce dove visualizzare titolo, gallery, prezzo, superficie e altre informazioni.
Quando cambia il layout del prezzo, modifichi il template. Non 500 pagine.
Dynamic Data: collegare il layout ai contenuti di WordPress
La Dynamic Data di Bricks permette di utilizzare nel layout valori provenienti dal database WordPress.
Puoi richiamare, tra gli altri:
- titolo del post;
- immagine in evidenza;
- autore;
- data;
- categorie e tassonomie;
- custom field;
- dati utente;
- informazioni WooCommerce.
Il modello mentale è:
dato → tag dinamico → elemento del template → output frontend
Tornando all’esempio dell’immobile, il componente visivo che mostra il prezzo non contiene “€ 350.000” scritto manualmente.
Contiene il riferimento al campo “prezzo”.
WordPress conserva il dato. Bricks decide dove e come renderlo.
È questa separazione tra dati e presentazione a rendere scalabile un sito dinamico.
ACF, Meta Box e JetEngine
La documentazione Bricks include integrazioni per Advanced Custom Fields, Meta Box e Crocoblock JetEngine, oltre ad altri sistemi di custom fields. I campi possono essere richiamati come Dynamic Data e, in diversi casi, utilizzati anche all’interno dei Query Loop.
Questo consente di creare strutture che sarebbero difficili da gestire se ogni pagina fosse progettata manualmente.
Un sito di corsi, per esempio, potrebbe avere:
Corso → docente → durata → livello → prezzo → data di partenza
Il CMS conserva queste informazioni come dati strutturati.
Bricks può costruire il template che li presenta.
La conseguenza pratica è importante: il contenuto può cambiare senza dover ridisegnare la pagina.
Query Loop, filtri e ricerca dinamica
Il Query Loop di Bricks serve a interrogare una sorgente dati e ripetere un layout per ogni risultato.
In forma semplificata:
query → risultati → componente/layout → ripetizione
Può essere usato per articoli, termini, utenti e altre sorgenti supportate. Bricks dispone inoltre di strumenti di filtering e live search collegati ai loop.
Per esempio, una pagina “Team” può recuperare automaticamente tutte le persone appartenenti a un determinato ruolo e renderizzarle usando la stessa card.
Oppure un archivio immobiliare può combinare:
Query Loop → immobili → card immobile → filtri → risultati
A quel punto Bricks Builder non sta più funzionando come semplice editor di pagine. Sta diventando l’interfaccia con cui costruisci la relazione tra dati WordPress e frontend.
Cosa puoi costruire con Bricks Builder
Non esiste un unico tipo di sito per cui Bricks abbia senso. La sua architettura copre sia pagine relativamente semplici sia progetti nei quali template e dati dinamici hanno un ruolo importante.
La domanda utile è piuttosto: quanto controllo vuoi avere sul sistema che costruisce il frontend?
Siti aziendali, landing page, blog e siti basati su custom post type
Per un sito aziendale puoi utilizzare Bricks per costruire l’intero sistema visuale:
header → pagine → componenti → template blog → archivi → footer
Su una landing page puoi controllare layout, responsive, interazioni, moduli e componenti senza dipendere da un template preconfezionato.
Su siti più strutturati, però, diventano particolarmente interessanti template e dati dinamici.
Directory, immobiliari, portali di professionisti, cataloghi e progetti con custom post type sono casi nei quali la combinazione di template + custom fields + Query Loop può evitare una grande quantità di lavoro manuale.
WooCommerce: prodotti, shop, carrello, checkout e account
Bricks integra un WooCommerce Builder che permette di intervenire visualmente su shop, archivi prodotto, schede prodotto, carrello, checkout e area account.
È utile perché WooCommerce non è soltanto una griglia di prodotti.
Un ecommerce comprende:
catalogo → prodotto → carrello → checkout → account
e ogni fase ha una funzione differente.
La possibilità di progettare questi template nello stesso sistema utilizzato dal resto del sito rende Bricks interessante quando il negozio richiede un’identità visuale o una struttura più personalizzata rispetto ai template standard.
Questo non elimina però la complessità dell’ecommerce. Pagamenti, tasse, spedizioni, compatibilità dei plugin, tracking, sicurezza e processi commerciali rimangono problemi distinti dal builder. Se stai progettando l’intero progetto e non soltanto l’interfaccia, trovi questi aspetti nella nostra guida su come creare un sito ecommerce.
Form, menu, popup, interazioni e codice personalizzato
Bricks include funzioni che in altri stack possono richiedere strumenti separati, tra cui menu, form, popup, condizioni e interazioni. La documentazione ufficiale raccoglie queste capacità tra le feature del builder.
È possibile inoltre integrare codice personalizzato quando il progetto lo richiede.
Qui serve però una distinzione netta.
Avere un campo nel quale inserire PHP o JavaScript non rende automaticamente sicuro qualsiasi snippet. Bricks protegge l’esecuzione del codice con impostazioni, capability e firme dedicate.
In un progetto reale il principio dovrebbe restare:
visual builder dove è sufficiente, codice dove aggiunge valore reale, controllo tecnico quando il codice diventa eseguibile.
Bricks Builder, performance e SEO: cosa dipende davvero dal builder
Performance e SEO sono probabilmente l’area in cui si incontrano più facilmente claim troppo semplici.
Bricks pone molta enfasi su markup, HTML/CSS e caricamento degli asset. La sua documentazione descrive anche strategie per caricare alcune librerie frontend solo quando effettivamente necessarie.
Questo è un buon punto di partenza tecnico.
Non è però una garanzia di sito veloce e, soprattutto, non significa che usare Bricks produca automaticamente un vantaggio SEO.
Markup HTML, CSS e struttura semantica
Un builder influenza l’HTML, il CSS e il JavaScript inviati al browser.
Questo conta.
Se per costruire una struttura semplice vengono prodotti molti wrapper inutili, CSS duplicato e script non necessari, il browser dovrà comunque elaborarli.
Allo stesso modo, avere un controllo più diretto sugli elementi HTML può aiutarti a costruire una struttura semantica migliore.
Ma “può” è la parola importante.
Un builder che permette di scegliere correttamente gli elementi non impedisce a chi lo usa di creare una gerarchia sbagliata.
Puoi avere uno strumento flessibile e costruire comunque:
- heading senza logica;
- sezioni inutilmente annidate;
- immagini enormi;
- font caricati male;
- animazioni eccessive;
- JavaScript di terze parti;
- layout instabili.
Il builder definisce il potenziale tecnico. L’implementazione determina il risultato reale.
Perché un builder leggero non garantisce automaticamente un sito veloce
La velocità finale nasce da più strati:
hosting → WordPress → tema/builder → plugin → media → font → JavaScript → cache/CDN → implementazione
Bricks agisce soprattutto su uno di questi livelli.
Un sito Bricks con immagini da diversi megabyte, dieci servizi di tracking, font esterni mal configurati e hosting inadeguato può tranquillamente essere lento.
Al contrario, una buona implementazione lavora sull’intero percorso.
Per questo giudicherei la performance misurando il sito reale, non scegliendo un builder soltanto sulla base della promessa commerciale di essere leggero.
Perché “Bricks è migliore per la SEO” è una semplificazione
Google non indica Bricks, Elementor o Gutenberg come scorciatoie per il ranking.
La documentazione Google sulla page experience conferma che i Core Web Vitals vengono utilizzati dai sistemi di ranking, ma chiarisce anche che ottenere buoni risultati tecnici non garantisce le prime posizioni e che la page experience non va ridotta a un unico segnale.
La distinzione corretta è quindi:
GOOGLE_CONFIRMED: Core Web Vitals e aspetti della page experience sono rilevanti nel sistema complessivo di Search.
VENDOR FACT: Bricks mette a disposizione un determinato output, controlli tecnici e strategie di asset loading.
INFERENCE: un’implementazione ben costruita con Bricks può aiutarti a raggiungere una buona base tecnica.
NON DIMOSTRATO: “passare a Bricks farà salire le posizioni”.
Cambiare builder solo per ottenere un presunto boost SEO sarebbe quindi una motivazione debole. Il rebuild ha costi e rischi; dovrebbe risolvere un problema reale più ampio.
Quanto costa Bricks Builder e cosa comprende la licenza
Bricks non offre una normale versione gratuita da installare sul tuo sito. Puoi però provarlo attraverso il playground ufficiale prima di acquistarlo.
Al momento della verifica, il listino ufficiale di Bricks è questo:
| Piano | Siti | Prezzo | Modello |
|---|---|---|---|
| Starter | 1 | 79 USD | annuale |
| Business | 3 | 149 USD | annuale |
| Agency | illimitati | 249 USD | annuale |
| Ultimate Lifetime | illimitati | 599 USD | una tantum |
I prezzi possono cambiare e le eventuali imposte vengono calcolate in base alla località al checkout. Prima dell’acquisto conviene quindi controllare il listino ufficiale corrente.
Starter, Business, Agency e Ultimate Lifetime
La differenza principale tra i piani non è una lista di funzionalità Premium sbloccate progressivamente.
Secondo la pagina ufficiale, tutti i piani includono il set completo delle feature. A cambiare sono soprattutto il numero di siti utilizzabili e il modello annuale o lifetime.
Questo semplifica abbastanza la scelta:
- un singolo progetto può rientrare nello Starter;
- chi gestisce pochi siti può valutare Business;
- agenzie e freelance con molti progetti trovano nell’Agency il limite siti illimitato;
- Ultimate Lifetime elimina il rinnovo annuale con un pagamento una tantum.
Il piano lifetime merita però una valutazione economica, non emotiva. Se pensi di usare Bricks per molti anni e numerosi progetti può avere senso; per provarlo su un singolo sito, pagare subito il massimo soltanto perché “lifetime” non è necessariamente la decisione migliore.
Siti staging, aggiornamenti, supporto e garanzia
I siti locali e di staging non vengono conteggiati nel limite delle licenze. I piani annuali comprendono aggiornamenti e supporto durante il periodo della sottoscrizione, mentre la licenza lifetime include aggiornamenti futuri e supporto secondo le condizioni dichiarate dal vendor. Bricks offre inoltre una garanzia di rimborso di 60 giorni.
La gestione dello staging è particolarmente utile in un workflow professionale.
Aggiornare il builder direttamente sul sito di produzione senza verificare template, componenti, WooCommerce e integrazioni è una pratica rischiosa indipendentemente dal prodotto utilizzato.
Come provare Bricks prima di acquistarlo
Bricks mette a disposizione un playground gratuito basato su una installazione dedicata.
Lo userei per verificare almeno:
- struttura dell’editor;
- gestione delle classi;
- logica del responsive;
- Components;
- Style Manager;
- creazione di template;
- Query Loop.
Non concentrarti soltanto sul tempo necessario per costruire una bella hero.
La domanda più utile è:
“Questo modo di organizzare il sito coincide con il modo in cui voglio lavorare ogni giorno?”
È molto più importante di una demo spettacolare.
Bricks Builder è facile da usare? Il punto è quale workflow vuoi adottare
Bricks può essere utilizzato senza scrivere codice, ma questo non significa che tutte le sue funzioni siano immediatamente comprensibili a chi non ha mai lavorato con HTML e CSS.
La stessa documentazione introduce esplicitamente concetti come Flexbox, Grid, global classes e CSS custom properties.
Non lo considero un difetto.
È piuttosto una conseguenza del tipo di controllo che Bricks cerca di offrire.
Cosa può fare anche chi non programma
Puoi costruire visualmente:
- pagine;
- layout responsive;
- template;
- menu;
- popup;
- form;
- loop;
- elementi WooCommerce;
- componenti.
Per un sito relativamente semplice non è indispensabile scrivere PHP o JavaScript.
Anche molte operazioni CSS sono rappresentate da controlli visuali.
Il rischio, però, è confondere “non scrivere codice” con “non dover capire il web”.
Perché classi, variabili e struttura CSS richiedono comunque un modello mentale
Immagina due utenti.
Il primo crea ogni bottone, assegna manualmente colori, padding e font e poi duplica l’elemento.
Il secondo crea variabili, una classe globale e componenti.
Entrambi stanno usando Bricks senza programmare.
Ma stanno costruendo due siti profondamente diversi dal punto di vista della manutenzione.
Per usare bene un sistema di questo tipo devi capire almeno concetti come:
- eredità;
- riuso;
- specificità;
- responsive;
- struttura dei contenitori;
- differenza tra stile locale e globale.
Non serve diventare sviluppatore frontend.
Serve però superare il modello mentale “trascino un elemento e scelgo il colore”.
Quando la curva di apprendimento diventa un vantaggio
La curva iniziale acquista valore quando devi mantenere il sito nel tempo.
Supponiamo che un cliente chieda di aumentare il border radius di tutte le card e modificare contemporaneamente lo spacing verticale.
In un sito costruito come collezione di eccezioni hai un problema.
In un sito costruito con classi e variabili hai due modifiche di sistema.
La differenza è questa:
più lavoro di modellazione all'inizio → meno lavoro ripetitivo dopo
Non sempre conviene.
Per una landing usa-e-getta potrebbe essere sovrastrutturazione.
Per un sito aziendale destinato a crescere o per un’agenzia che deve mantenere molti progetti, può diventare uno dei motivi principali per scegliere Bricks.
Bricks vs Elementor e Gutenberg: quale approccio cambia davvero
Confrontare Bricks Builder con Elementor o Gutenberg utilizzando soltanto una tabella di feature porta facilmente a conclusioni superficiali.
La domanda più utile è quale architettura e quale workflow vuoi adottare.
Bricks vs Elementor: integrazione, ecosistema e controllo
Elementor e Bricks condividono ormai più concetti di quanto suggeriscano alcuni vecchi confronti.
Elementor ha sviluppato con il proprio Editor 4 una base Atomic che comprende anch’essa Classes, Variables e Components. Non è quindi più corretto descrivere il confronto come “Bricks usa classi, Elementor no”.
Rimane però una differenza strutturale importante.
Bricks è un tema/site builder.
Elementor mantiene un modello da website builder che vive nell’ecosistema WordPress come soluzione separata dal tema.
Questo influenza migrazione, compatibilità, ecosistema di add-on, modalità di adozione e workflow.
Elementor dispone inoltre di un ecosistema più ampio e di una base installata molto più estesa; Bricks tende a interessare particolarmente chi vuole un controllo più vicino ai concetti CSS e un sistema molto integrato.
Se vuoi approfondire la direzione che sta prendendo Elementor, abbiamo analizzato separatamente Elementor 4.2, Atomic Editor e workflow agentici.
Non sceglierei però tra i due contando soltanto gli elementi disponibili.
Confronterei:
workflow → design system → contenuti dinamici → compatibilità → manutenzione → ecosistema → migrazione
Bricks vs Gutenberg: builder autonomo o strumenti nativi WordPress
Il confronto con Gutenberg è ancora più architetturale.
Con un block theme, WordPress permette di modificare tramite Site Editor anche template e parti globali del sito utilizzando i blocchi. È quindi possibile costruire sempre più elementi dell’esperienza visuale rimanendo nel sistema nativo WordPress.
Bricks offre invece un ambiente di costruzione dedicato e un proprio design system.
La scelta può essere letta così:
Gutenberg/block theme: maggiore vicinanza al paradigma nativo del CMS.
Bricks: ambiente visual-development più specializzato e maggiore concentrazione degli strumenti di design e dynamic building nello stesso builder.
Se vuoi capire prima il paradigma nativo, trovi qui la nostra guida a WordPress Gutenberg.
Le due realtà, inoltre, non sono completamente isolate.
Bricks consente di rendere alcuni Components disponibili nel block editor, ma la sua integrazione Components as Blocks è indicata dalla documentazione come experimental e disabilitata di default.
È quindi una possibilità interessante, non qualcosa su cui costruirei una decisione come se fosse già un layer maturo e definitivo.
Breakdance, Etch e Builderius: quando guardare oltre i due nomi più noti
Il mercato dei builder WordPress non si ferma a Bricks, Elementor e Gutenberg.
Breakdance continua a sviluppare un builder visuale con WooCommerce, dynamic data e strumenti integrati. Etch si presenta come un visual development environment con forte enfasi su scalabilità e accesso al codice, mentre Builderius sta spingendo maggiormente sull’integrazione tra visual development e agenti AI.
Non significa che siano automaticamente alternative migliori.
Significa che la categoria si sta spostando.
Il vecchio confronto:
quale page builder ha più widget?
sta lasciando spazio a domande più interessanti:
come gestisce classi e componenti?come collega dati e layout?quanto è portabile il progetto?come dialoga con il codice?come integra automazione e AI?
Bricks va quindi valutato all’interno di questa nuova categoria di strumenti, non soltanto rispetto ai page builder storici.
I limiti di Bricks Builder da considerare prima di costruirci un sito
Una guida utile non può fermarsi alle feature.
Più un builder diventa centrale nell’architettura del progetto, più devi valutare cosa succede se un giorno vuoi abbandonarlo, quali competenze richiede e quali feature sono davvero stabili.
Cambiare builder dopo: contenuti, template e lock-in operativo
Qualsiasi sistema visuale crea una certa dipendenza dal proprio modo di descrivere layout e componenti.
Con Bricks questa dipendenza va considerata con attenzione proprio perché il builder coincide con il tema.
Il contenuto editoriale conservato in normali campi WordPress rimane un problema diverso dalla struttura visuale costruita nel builder.
Per esempio, se una scheda immobile conserva prezzo e superficie come custom fields, quei dati possono sopravvivere a un cambio di frontend.
Il template Bricks che li renderizza, invece, è parte del sistema che dovrai sostituire.
Questa distinzione suggerisce una buona pratica generale:
mantieni i dati importanti nei sistemi appropriati e usa il builder principalmente per la presentazione.
Riduce il lock-in dove è realmente possibile ridurlo.
Ecosistema più piccolo non significa necessariamente meno dipendenze
Bricks include molte funzioni native, ma un progetto reale può comunque dipendere da plugin di terze parti per:
- SEO;
- cache;
- sicurezza;
- ecommerce;
- custom fields;
- traduzioni;
- cookie/privacy;
- integrazioni commerciali;
- funzionalità verticali.
Quindi “uso Bricks e non avrò bisogno di plugin” è una promessa troppo forte.
La domanda migliore è:
quali dipendenze sono realmente necessarie a questo progetto?
Due siti costruiti con lo stesso builder possono avere stack completamente diversi.
E più lo stack cresce, più diventano importanti staging, backup e procedure di aggiornamento. Se il progetto è già diventato difficile da mantenere, una gestione e assistenza WordPress strutturata può essere più importante del cambio di builder.
Funzioni experimental, beta e roadmap non vanno trattate come feature stabili
Questo è particolarmente importante in una fase in cui i builder stanno introducendo rapidamente nuove capacità.
La release stabile corrente di Bricks è distinta dalla serie 2.4 beta. La beta 2.4 introduce AI Abilities basate su WordPress Abilities API e MCP, consentendo a client compatibili di interagire con pagine, elementi, template, componenti, design system e altre strutture Bricks.
È un’evoluzione significativa.
Ma è ancora una beta.
Inoltre la roadmap Bricks distingue queste Abilities dall’AI agent integrato nel builder, che risulta ancora pianificato.
Quindi oggi sarebbe sbagliato scrivere:
“Bricks include un agente AI completo per costruire il sito”.
La formulazione corretta è più prudente:
Bricks sta costruendo un layer agentico; alcune capacità via MCP sono già presenti nella beta, mentre altre parti rimangono in sviluppo.
Per un sito in produzione, roadmap e beta sono segnali sulla direzione del prodotto. Non sono feature su cui basare un requisito critico finché non raggiungono uno stato adeguatamente stabile.
Quando sceglierei Bricks Builder e quando sceglierei altro
A questo punto la decisione è più semplice perché non dipende da una classifica astratta.
Bricks ha senso soprattutto quando vuoi costruire un sistema, non soltanto pagine.
Bricks per freelance, web designer e agenzie che vogliono un sistema riutilizzabile
Lo prenderei seriamente in considerazione quando il workflow richiede:
- classi globali;
- variabili;
- componenti;
- template;
- responsive controllato;
- riuso tra molte pagine;
- siti che devono essere mantenuti nel tempo.
Per un freelance o un’agenzia il valore cresce ulteriormente quando questi concetti diventano parte di un metodo ripetibile.
Non significa necessariamente riutilizzare lo stesso design su ogni cliente.
Significa riutilizzare il modo di organizzare il lavoro.
Bricks per siti dinamici e progetti WooCommerce personalizzati
Bricks diventa particolarmente interessante quando i contenuti non sono statici.
Se il progetto richiede custom post type, custom fields, archivi filtrabili, componenti ripetuti e template dinamici, la combinazione di Dynamic Data e Query Loop può ridurre drasticamente la quantità di pagine da gestire manualmente.
Lo stesso vale per WooCommerce quando vuoi controllare in modo più profondo la presentazione delle principali aree del negozio.
Qui il vantaggio non è “avere più effetti”.
È:
dato una volta → template una volta → rendering ovunque
Quando Gutenberg, Elementor o un altro builder possono essere una scelta più razionale
Non sceglierei Bricks automaticamente.
Guarderei prima a Gutenberg/block theme se la priorità è mantenere il progetto il più vicino possibile agli strumenti nativi WordPress e il livello di personalizzazione richiesto può essere soddisfatto bene da quel modello.
Elementor può avere più senso quando esiste già un sito importante costruito nel suo ecosistema, il team lo conosce bene o dipende da integrazioni specifiche che renderebbero costoso il passaggio.
Un altro builder può essere preferibile se risolve meglio un requisito particolare del progetto.
E soprattutto non ricostruirei un sito stabile soltanto perché Bricks appare tecnicamente più elegante.
Un rebuild comporta sempre:
analisi → ricostruzione → migrazione → test → responsive QA → performance QA → SEO QA → regressioni → formazione
La domanda non dovrebbe essere:
“Bricks è migliore del mio builder?”
Dovrebbe essere:
“Quale problema reale del mio progetto risolve Bricks, e il beneficio giustifica il costo del cambiamento?”
Se la risposta è vaga, probabilmente non è ancora il momento di migrare.
Conclusione
Bricks Builder diventa interessante quando smetti di pensarlo come un semplice page builder.
Il suo punto di forza è la combinazione tra site building visuale, struttura CSS, design system, componenti, template e contenuti dinamici. Questa impostazione permette di costruire siti nei quali le decisioni importanti vengono centralizzate e riutilizzate invece di essere replicate pagina per pagina.
È proprio questa profondità, però, a richiedere una scelta consapevole.
Se vuoi un editor che ti permetta principalmente di comporre qualche pagina velocemente, potresti non sfruttare la parte più interessante di Bricks. Se invece progetti siti aziendali articolati, sistemi basati su custom fields, ecommerce personalizzati o lavori come freelance/agenzia, classi, variabili, componenti e Query Loop possono diventare parte di un workflow molto più strutturato.
Non sceglierei Bricks perché “è il più veloce”, “è migliore per la SEO” o perché una nuova funzione AI compare in beta.
Lo sceglierei quando il suo modello operativo coincide con il modo in cui voglio costruire e mantenere il progetto.
Ed è probabilmente il criterio più utile per valutare qualsiasi builder WordPress: non quale prodotto permette di fare più cose in una demo, ma quale architettura rende più semplice mantenere bene il sito dopo che la demo è finita.