Page builder nell'era degli AI agent: sopravviveranno al prompt che genera un sito intero?

Quando Robby McCullough, co-founder di Beaver Builder, ha spiegato nel podcast #214 di WP Tavern perché il suo prodotto ha aspettato due anni prima di integrare funzioni AI, la sua risposta è stata controintuitiva: "Abbiamo aspettato perché non volevamo mettere un wrapper su GPT solo per dire che c'era. Volevamo capire cosa potesse davvero fare per l'utente, non cosa facesse clamore sul mercato". È una posizione che oggi, nel 2026, si rivela più strategica di quanto sembrasse nel 2024. Mentre concorrenti come Elementor, Divi, e Bricks hanno corso a integrare AI come layer sopra il page builder, Beaver Builder ha aspettato, e oggi sta rilasciando funzioni AI che modificano il modello di prodotto, non che ci si appiccicano sopra. Questa guida analizza il futuro dei page builder in un mondo in cui Claude Code, Cursor, e agenti specializzati possono generare un sito WordPress con un prompt, e cosa significa per chi sviluppa, agenzie, e site owner.

L'angolo è strategico e di prodotto, non recensione. Vediamo i tre scenari possibili per il 2027-2030, le scelte tecniche che contano, e come posizionarsi. È complementare alla guida su FSE + AI e a WordPress 7.0 AI Connectors.

La domanda giusta: cosa faranno gli utenti nel 2028?

Prima di parlare di page builder e AI, serve capire chi userà cosa. La frattura è tra tre profili utente.

Profilo 1: l'utente business senza competenze tecniche

Marina gestisce un Bed & Breakfast. Vuole un sito. Cosa fa nel 2028?

• Scenario A (AI puro): apre Claude, scrive "creami un sito per un B&B in Toscana con 5 camere, galleria fotografica, modulo prenotazioni, multilingua IT/EN/DE, e integrami con Booking.com". L'AI genera un sito completo in 10 minuti, lo deploya su un hosting, le spiega come gestirlo.
• Scenario B (page builder visuale): compra Elementor Pro, usa un template preimpostato per B&B, personalizza con drag-and-drop, integra un plugin di prenotazioni. Tempo: 4-6 ore.

Chi vince? La risposta non è scontata. Lo Scenario A è più veloce e meno costoso inizialmente, ma richiede un'AI affidabile, un hosting decente, e la capacità di gestire l'evoluzione del sito (aggiornare testi, aggiungere foto, gestire le email). Lo Scenario B è più lento e costoso, ma dà all'utente controllo e prevedibilità.

Profilo 2: l'agenzia di sviluppo

Luca ha un'agenzia di 5 persone, realizza 20-30 siti/anno per clienti corporate. Cosa usa?

• Page builder per prototipi rapidi e siti small-medium
• Custom theme PHP/ACF per progetti enterprise
• AI per generare boilerplate, snippet, copy
• Hosting gestito per clienti (Kinsta, WP Engine, Rocket.net)

L'agenzia non ha un vincitore unico: usa l'AI dove accelera, page builder dove serve controllo visuale, custom code dove serve performance e scalabilità.

Profilo 3: lo sviluppatore senior

Sara sviluppa plugin e temi custom per clienti enterprise. Lavora con PHP, JavaScript moderni, e ACF. Cosa fa con l'AI?

• Usa Cursor o Claude Code per scrivere plugin più velocemente
• Usa AI per refactoring e test generation
• Non usa page builder (la sua produttività è nel codice)
• L'AI è uno strumento, non un sostituto del suo lavoro

Sara non è in competizione con i page builder: opera su un altro layer.

I 3 scenari per i page builder nel 2027-2030

Sulla base delle tendenze attuali e delle scelte di produttori come Beaver Builder, Elementor, Bricks, e Divi, ecco i tre scenari più probabili.

Scenario 1: page builder come "design system visuale" (realista, 50%)

I page builder evolvono da "strumenti per costruire pagine" a design system visuali che l'AI può interrogare e modificare. L'utente finale usa ancora il page builder per la personalizzazione fine, ma l'AI può generare siti completi che rispettano il design system del page builder.

Concretamente: l'AI genera la struttura del sito, sceglie i blocchi del page builder, li configura. L'utente apre il page builder, vede il sito finito, modifica dove vuole con il visual editor.

Esempio reale: Elementor AI 2.0 (rilasciato in beta a maggio 2026) permette di descrivere una sezione in linguaggio naturale e vederla generata direttamente nel builder, con i widget nativi. L'utente può poi modificare ogni widget come al solito.

Pro: integra l'AI senza stravolgere il modello. Contro: richiede all'AI di conoscere il DSL del page builder (cosa non banale).

Scenario 2: page builder come "legacy" (possibile, 25%)

L'AI diventa così brava a generare siti completi da prompt che i page builder tradizionali vengono percepiti come obsoleti. I visual editor rimangono per chi vuole "vedere" cosa sta costruendo, ma la maggior parte degli utenti usa solo l'AI.

Concretamente: 70% dei nuovi siti WordPress nel 2028 viene generato via prompt AI, 30% tramite page builder. I page builder tradizionali si contraggono a una nicchia.

Pro: mercato si semplifica, focus su qualità. Contro: chi ha investito in page builder perde terreno.

Scenario 3: page builder come "editor AI-augmented" (possibile, 25%)

I page builder diventano ambienti collaborativi uomo + AI dove l'utente e l'AI co-editano il sito in tempo reale. L'utente fa modifiche strutturali, l'AI fa suggerimenti contestuali, copy, ottimizzazioni.

Concretamente: un'interfaccia tipo Figma + Cursor, dove muovi un blocco e l'AI propone varianti, ottimizza per conversioni, scrive il copy.

Pro: il meglio dei due mondi. Contro: complessità tecnica alta, curva di apprendimento ripida.

Cosa sta facendo Beaver Builder (e perché è interessante)

La scelta di Beaver Builder è un caso studio. Invece di mettere un "pulsante AI" nel builder (come hanno fatto in tanti), il team sta lavorando a un editor collaborativo in tempo reale dove l'utente e l'AI possono co-editare la pagina.

McCullough spiega che l'AI migliore in un page builder non è quella che "genera una sezione", ma quella che capisce il contesto della sezione esistente e propone miglioramenti chirurgici. L'AI lavora sui blocchi già presenti, non ne crea di nuovi da zero.

// Esempio concettuale di AI contestuale nel page builder
const block = editor.getSelectedBlock();

// L'AI analizza il blocco nel contesto della pagina
const suggestions = await ai.suggest({
    type: 'inline_edit',
    block: block,
    page_context: editor.getPageContext(), // altri blocchi, tema, brand
    user_goal: 'increase_readability',
});

// L'utente vede le 3 varianti inline, applica quella preferita
editor.showInlineAISuggestions( block, suggestions );

È un approccio molto diverso dal "clicca qui per generare una sezione con AI". Meno spettacolare, ma più integrato nel workflow reale.

Le 5 decisioni strategiche per chi sviluppa page builder

Se stai sviluppando (o gestisci) un page builder, ecco le 5 decisioni strategiche che contano per il 2026-2028.

Decisione 1: integrare l'AI come layer sopra o come motore nativo

Scelta attuale di Elementor: AI come layer (pulsanti AI ovunque). Scelta di Beaver Builder: AI come motore contestuale (in lavorazione). La prima è più veloce da implementare, la seconda è più profonda e più difficile da copiare.

Decisione 2: supportare il Full Site Editing o restare sul modello classico

Il FSE di WordPress è un paradigma diverso dal page builder classico: blocchi nativivi, template parts, global styles. I page builder possono:

• (a) Competere con FSE, offrendo un'esperienza più ricca
• (b) Integrarsi con FSE, offrendo blocchi custom che lavorano dentro l'editor nativo
• (c) Ignorare FSE, scommettendo sulla nicchia "visual editor ricco"

Bricks ha scelto (a) e (b): compete con FSE per i siti avanzati, ma offre compatibilità. Elementor ha fatto scelte ibride. Divi è più fedele al modello classico.

Decisione 3: pricing basato su features o su AI credits

Sta emergendo un modello in cui le funzioni AI sono "a consumo" (crediti), mentre le funzioni classiche restano in abbonamento. È un modello più giusto per l'utente (paghi solo quello che usi) ma più complesso da gestire.

Decisione 4: plugin gratuito o premium

La maggior parte dei page builder ha un tier gratuito limitato. La scelta per il 2026 è se ampliare il free tier (per intercettare utenti che userebbero solo AI) o restare premium-only (per monetizzare meglio).

Decisione 5: focus su performance o su funzionalità

Bricks è il campione della performance. Elementor è il campione delle funzionalità. La domanda è: nel 2027, gli utenti premieranno la velocità (Core Web Vitals) o le feature?

Cosa significa per le agenzie

Le agenzie che oggi usano page builder per il 70% del loro lavoro devono riposizionarsi. Tre raccomandazioni concrete.

1. Smetti di vendere "il sito", vendi "il sistema"

Un sito statico fatto con page builder vale sempre meno. Un sistema (sito + automazioni + integrazioni + AI custom) vale di più. Riposiziona la tua offerta su quest'ultimo.

2. Impara l'AI almeno quanto hai imparato il page builder

Se la tua produttività viene dal page builder, sei sostituibile dall'AI. Se la tua produttività viene dalla capacità di combinare AI + page builder + custom code + design thinking, sei molto più difficile da sostituire.

3. Offri "AI setup" come servizio

C'è un mercato enorme di aziende che vogliono usare WPVibe, gli AI Connectors di WP 7.0, o agenti custom, ma non sanno da dove partire. Offrire un servizio di setup + formazione è una nicchia remunerativa e scalabile.

Cosa significa per chi usa page builder

Se sei un utente finale che usa un page builder, ecco i consigli pratici.

Consiglio 1: non stravolgere il tuo workflow

Se oggi usi Elementor e funziona, non passare a Bricks solo perché "è più veloce". Il costo di apprendimento potrebbe non valere. Aspetta che l'integrazione AI maturi.

Consiglio 2: testa le funzioni AI ma non fidarti ciecamente

Quando il tuo page builder aggiunge AI, provala. Ma fai sempre review umana di quello che genera, specialmente per copy e design. L'AI sbaglia ancora, e gli errori sono meno tollerabili su un sito live.

Consiglio 3: mantieni la portabilità del sito

Siti costruiti con page builder proprietari possono essere difficili da migrare. Mantieni backup regolari e una exit strategy. Idealmente, costruisci con page builder che esportano in HTML standard o in blocchi FSE nativi.

Esempio tecnico: integrare l'AI come motore contestuale in un page builder

Vediamo come potrebbe funzionare un'integrazione AI contestuale in un page builder (pseudocodice del flusso di Beaver Builder).

// Sistema di suggerimenti AI contestuali
class ContextAwareAI {
    constructor( pageState, userPreferences ) {
        this.pageState = pageState;
        this.userPreferences = userPreferences;
    }

    async suggestBlockImprovement( block ) {
        // 1. Recupera il contesto della pagina
        const context = {
            page_type: this.pageState.getPageType(),
            surrounding_blocks: this.pageState.getSurroundingBlocks( block.id, 2 ),
            theme_tokens: this.pageState.getThemeDesignTokens(),
            brand_voice: this.userPreferences.getBrandVoice(),
        };

        // 2. Chiedi all'AI con contesto specifico
        const response = await this.callAI( {
            model: 'claude-3-5-sonnet',
            system: `Sei un assistente per page builder. Migliori blocchi esistenti
                    senza stravolgerli. Rispondi in JSON con {"variants": [...]}.`,
            user: `Blocco attuale: ${JSON.stringify( block.data, null, 2 )}
                   Contesto: ${JSON.stringify( context, null, 2 )}
                   Obiettivo utente: ${block.userGoal}`,
        } );

        // 3. Restituisci 3 varianti contestualizzate
        return response.variants.map( v => ({
            ...v,
            blockId: block.id,
            // Mantieni la struttura del blocco, cambia solo contenuto/stile
            preserveStructure: true,
        }) );
    }

    async callAI( payload ) {
        // Usa la WordPress AI API (vedi guida AI Connectors)
        return await wpAiRequest( payload );
    }
}

// Uso nell'editor
const ai = new ContextAwareAI( pageState, userPrefs );
const suggestions = await ai.suggestBlockImprovement( selectedBlock );

// Mostra le varianti inline nel page builder
ui.showInlineVariants( selectedBlock, suggestions );

È un pattern più complesso del "clicca e genera", ma molto più integrato con il workflow dell'utente.

Domande frequenti

I page builder sono morti?

No. Stanno evolvendo. Il page builder come strumento puramente visuale sta cedendo spazio a un modello ibrido dove visuale + AI coesistono. La categoria sopravvive, ma il prodotto singolo deve evolversi.

Meglio imparare un page builder o l'AI oggi?

Entrambi, in ordine di priorità: prima il page builder (perché è ancora il modo più prevedibile di costruire un sito), poi l'AI (per accelerare). Non sono alternativi, sono complementari.

Beaver Builder è indietro rispetto a Elementor sull'AI?

No, è in una posizione diversa. Elementor ha integrato l'AI come feature aggiuntiva (più veloce da implementare, meno profondo). Beaver Builder sta integrando l'AI come cambio di paradigma (più lento, più profondo). I due approcci non sono direttamente confrontabili.

L'AI può sostituire un web designer professionista?

Per task semplici (landing page, siti vetrina, blog personali), sì, oggi. Per task complessi (e-commerce enterprise, portali custom, integrazioni), no, non ancora. La soglia si alza ogni anno, ma la complessità dei progetti reali cresce più velocemente.

Il Full Site Editing di WordPress rende obsoleti i page builder?

No, ma li costringe a specializzarsi. FSE è ottimo per siti piccoli/medi, ma manca di molte feature che i page builder offrono (conditional display, dynamic content, theme builder avanzato). I page builder che si integrano con FSE hanno il futuro assicurato; quelli che lo combattono sono a rischio.

Vale la pena investire in Bricks (performance) o in Elementor (ecosistema)?

Dipende dal tipo di progetti. Per siti dove la performance è critica (publishing, e-commerce ad alto traffico), Bricks è superiore. Per progetti dove servono molte integrazioni e un ecosistema ampio, Elementor vince. La scelta giusta è progetto-specific.

Quando arriverà un page builder veramente AI-native?

Ci sono già prototipi (Bricks AI, Divi AI 2.0, l'approccio Beaver Builder), ma un page builder "AI-native" nel senso pieno del termine (dove l'AI è il motore primario, non un layer sopra) non esiste ancora. Probabile orizzonte: 2027-2028.

Riferimenti utili per approfondire

• WP Tavern #214 con Robby McCullough - il podcast originale.
• Elementor AI 2.0 release notes - esempio di approccio "AI come layer".
• Bricks Builder AI features - esempio di approccio performance-first con AI.
• Divi AI documentation - altro esempio di integrazione AI.
• Beaver Builder roadmap pubblica - visione strategica del team.
• WordPress FSE documentation - come evolve il core.
• Anthropic Computer Use demo - dove sta andando l'AI agentica.
• FSE + AI per temi a blocchi mrtux.it - guida pratica su FSE + AI.
• WordPress 7.0 AI Connectors mrtux.it - il motore AI lato core.
• Strumenti AI per sviluppatori WordPress mrtux.it - la cassetta degli attrezzi AI.

Questa guida verrà aggiornata quando Beaver Builder rilascerà la sua AI contestuale e quando Elementor AI raggiungerà la versione 3.0. Per discussioni o casi d'uso specifici, l'area commenti è aperta.