Full Site Editing + AI: come generare temi WordPress a blocchi senza perdere il controllo

Generare un tema WordPress a blocchi con l'intelligenza artificiale è facile. Generarlo bene, mantenendo il controllo architetturale, theme.json pulito, block patterns riutilizzabili e qualità del codice in produzione, è un'altra storia. Questa guida copre esattamente quel confine: come usare l'AI per accelerare la creazione di block theme Full Site Editing senza trasformare il repository in un blob di codice generato che nessuno, due mesi dopo, riesce a mantenere.

L'idea di fondo è semplice: l'AI è eccellente per produrre block pattern, theme.json iniziale, e template HTML di base. È pessima per le decisioni di architettura, per i vincoli di accessibilità, per la coerenza tra theme.json e stili globali, e per la manutenzione a lungo termine. Il compito dello sviluppatore è guidare l'AI sui punti dove è utile, e sostituirla manualmente sui punti dove porta a corto termine a scelte che pagherai dopo.

Questo articolo si legge bene dopo la guida pratica sui temi WordPress con AI del 2026, che copre l'anatomia generale del block theme, e dopo il confronto tra AI coding assistant, che aiuta a scegliere l'editor giusto per il workflow.

Cos'è il Full Site Editing e perché è diverso dai classic theme

Il Full Site Editing, introdotto in WordPress 5.9 e maturo dalla 6.2, sposta la personalizzazione del tema dal codice PHP al Site Editor visuale. Header, footer, template di pagina, archivi, pagine singole: tutto è modificabile dall'utente finale senza toccare codice. Il tema diventa un pacchetto di template HTML (con block markup), block patterns, e un file theme.json che definisce lo stile globale.

La differenza con i classic theme non è cosmetica, è architetturale.

Il block theme è la scelta giusta nel 2026 per qualsiasi nuovo progetto che non abbia requisiti legacy specifici. L'AI può accelerare la creazione del pacchetto iniziale, ma lo sviluppatore mantiene il controllo su cosa viene generato.

Cosa può fare l'AI (e cosa non deve fare)

Una delle decisioni più importanti che prendi all'inizio di un progetto block theme con AI è stabilire il confine tra cosa generi automaticamente e cosa scrivi a mano. Questa distinzione, se fatta bene, separa un tema amatoriale da uno professionale.

Cosa l'AI può fare con qualità:

• Generare il theme.json iniziale con palette, tipografia, spacing coerenti.
• Produrre block patterns singoli (hero, CTA, testimonial, FAQ, pricing) con markup Gutenberg corretto.
• Scrivere template HTML semplici (single, page, archive) con block markup.
• Convertire mockup in descrizioni testuali di pattern.
• Generare readme.txt, changelog, e testi di documentazione.

Cosa l'AI non deve fare (o fa male):

• Decidere l'architettura del tema: numero di patterns, categorizzazione, naming convention.
• Scegliere la palette colori definitiva: serve test di accessibilità WCAG AA, non solo estetica.
• Generare CSS custom massiccio: se serve CSS custom pesante, il theme.json non è stato sfruttato.
• Scrivere logica PHP complessa in functions.php: l'AI tende a over-engineerare, serve semplicità.
• Produrre plugin di terze parti sostituendoli con funzioni custom: aumenta il debito tecnico.

La regola operativa: se il task è "descrivi un componente in markup strutturato", l'AI è perfetta. Se il task è "scegli un componente tra alternative con trade-off", la decisione è umana.

Workflow 5 step per un block theme AI-assisted

Questo è il workflow che uso nella pratica, testato su 4-5 block theme in produzione. Non è l'unico, ma è quello che produce i risultati migliori con il minor debito tecnico.

Step 1: requirements e architettura (umana)

Definisci su carta o in un file REQUIREMENTS.md:

• Tipo di sito (blog, portfolio, magazine, documentazione, e-commerce leggero).
• Target utente finale (chi personalizzerà il tema dal Site Editor).
• Numero di template necessari (index, single, page, archive, search, 404).
• Numero di block patterns da includere (8-15 è il sweet spot).
• Categorie di patterns (hero, CTA, contenuto, footer, sidebar, special).
• Palette colori iniziale (2-3 colori primari + 3-5 secondari).
• Tipografia (1 font display + 1 font body, preferibilmente system fonts o Google Fonts con local fallback).
• Vincoli di accessibilità (WCAG AA minimo, focus visibili, semantic HTML).

Questo file è il brief che darai all'AI nei passi successivi. Senza brief chiaro, l'AI genera codice generico e il tema perde identità.

Step 2: theme.json generato con AI (assistita)

Con il brief in mano, chiedi all'AI di generare il theme.json. Un prompt efficace è strutturato come il seguente.

Genera un theme.json WordPress 6.5+ per un block theme di tipo [TIPO SITO].
Requisiti:
- versione 2 dello schema
- palette colori: [lista colori con nome semantico]
- tipografia: [font display + font body, scala font sizes]
- spacing: [scala 0-12 in rem]
- layout: contentSize 720px, wideSize 1200px
- appearanceTools: true per padding/margin editabili
- useRootPaddingAwareAlignments: true
- $schema abilitato per autocompletamento editor
Output: solo il JSON, niente markdown.

L'AI produce un theme.json valido. Lo sviluppatore poi:

• Verifica la palette con uno strumento di contrasto (es. WebAIM Contrast Checker).
• Rimuove colori duplicati o troppo simili.
• Aggiunge $schema se l'AI lo ha dimenticato.
• Controlla che appearanceTools sia attivo (senza, l'utente finale non può modificare padding dal Site Editor).

Step 3: block patterns generati con AI (assistita)

I block patterns sono il vantaggio competitivo di un block theme ben fatto. L'AI eccelle qui: può produrre 10-15 patterns in un'ora, ognuno con markup Gutenberg corretto. Il prompt tipo per un pattern hero è il seguente.

Genera un block pattern WordPress "Hero con call-to-action".
Requisiti:
- gruppo full-width con sfondo primary e testo background
- layout constrained
- heading H1 con titolo placeholder
- paragrafo descrittivo
- blocco buttons con 2 bottoni (primario + secondario)
- spaziatura coerente con theme.json
- accessibilità: link focus visibili, contrasto WCAG AA
Output: file PHP del pattern con header Title/Slug/Categories + markup Gutenberg puro.

Lo sviluppatore poi:

• Testa il pattern nel Site Editor reale (non solo leggendo il codice).
• Verifica che le classi CSS siano applicate correttamente.
• Categorizza semanticamente il pattern (featured, hero, cta, testimonial, pricing, faq).
• Aggiunge screenshot e descrizione al pattern header.

Step 4: template HTML generati con AI (assistita)

I template (index.html, single.html, page.html, archive.html) sono file HTML con block markup. L'AI può generarli velocemente, ma servono attenzione a:

• Includere sempre le parts di header e footer tramite il block comment dedicato alle template-part, con slug e tagName appropriati.
• Usare i block dinamici per titolo, contenuto ed excerpt del post (le tre block API standard per post singolo).
• Aggiungere blocchi di paginazione dedicati sugli archivi (il block comment per query-pagination).
• Includere il block comment che richiama un pattern registrato per i pattern hero in homepage.

Il template single.html per un blog è un buon esempio di output AI-assisted. La struttura è: apertura con un block comment che include la template-part di header, poi un blocco group con tag semantico main, dentro il group il titolo del post, l'immagine in evidenza e il contenuto del post (tutti come block dinamici con le rispettive block API), poi chiusura del group e block comment per la template-part di footer. Il markup Gutenberg completo è quello descritto nella Block API reference ufficiale.

Semplice, semantico, modificabile dall'utente finale. Questo è il livello di complessità che l'AI può produrre con qualità.

Step 5: code review e test (umana + AI di supporto)

La review finale è sempre umana, ma l'AI può accelerare i controlli ripetitivi:

• Confronto del theme.json generato con il template canonico WordPress.
• Validazione del markup Gutenberg contro il reference delle block API.
• Test di accessibilità automatico (axe-core, pa11y) sui pattern.
• Generazione di una checklist di review basata sui requisiti iniziali.

Un tema che passa questa review è pronto per la distribuzione. Uno che la fallisce richiede iterazione prima della release.

theme.json: il file che governa tutto

Il theme.json è il cuore di un block theme. Definisce palette, tipografia, spacing, layout, e impostazioni globali. Centralizza tutte le decisioni stilistiche in un file JSON che l'AI può generare con qualità, e che lo sviluppatore può validare in modo deterministico.

Una theme.json ben scritta ha una gerarchia chiara:

# gerarchia delle sezioni theme.json
$schema → punta a schema WordPress ufficiale (autocompletamento editor)
version → 2 (standard corrente)
settings → aspetto globale (colori, tipografia, spacing, layout)
styles → override globali di default blocks (paragraph, heading, link)
templateParts → definizione di header, footer, e altre parts
customTemplates → template custom per pagine specifiche

Una theme.json scarsa ha: palette con colori troppo simili, scala tipografica incoerente, spacing non standard, mancanza di appearanceTools, nessuna validazione di accessibilità.

Per verificare la qualità della theme.json, ci sono 5 controlli minimi da fare:

Un tema che passa questi 5 controlli è già oltre il 70% dei temi block pubblicati su wordpress.org.

Block patterns: il vantaggio competitivo AI

I block patterns sono dove l'AI brilla davvero. Generare un pattern hero, una sezione testimonial, un pricing table, un blocco FAQ, un footer avanzato: l'AI produce markup Gutenberg corretto in pochi secondi. La qualità del tema dipende dalla varietà e dalla qualità dei pattern inclusi.

Una libreria pattern production-ready ha 12-15 patterns ben categorizzati. Ecco la mia tassonomia standard per un block theme magazine.

L'AI può generare tutti questi in 2-3 ore di prompt iterativo. Lo sviluppatore poi testa, categorizza, e affina. Un tema con 15 pattern ben fatti vale 10 volte un tema con 50 pattern mediocri.

Controllo qualità: la review che salva il progetto

Una review attenta separa un tema block amatoriale da uno professionale. I problemi più comuni che vedo nei temi generati con AI e pubblicati su repository pubblici sono:

• Template monolitici: header e footer inline in ogni template, duplicazione massiccia.
• CSS custom nonostante theme.json: l'AI scrive 500 righe di CSS che sovrascrivono il sistema.
• Patterns non categorizzati: dozzine di patterns senza titolo semantico.
• Font esterni senza fallback: Google Fonts caricato senza font-display: swap.
• Mancata dichiarazione appearanceTools: l'utente finale non può modificare padding/margin.
• PHP in functions.php non necessario: logica che dovrebbe stare nei block patterns.

Tutti evitabili con una review attenta di 30-60 minuti. Il prompt perfetto non esiste: la review è dove il tema diventa professionale.

Strumenti AI consigliati per FSE

Per generare block theme Full Site Editing con AI nel 2026, la mia toolchain tipo è:

Nessuno strumento è obbligatorio, ma la combinazione di un editor AI con un ambiente di test locale (Playground o wp-env) è il minimo per evitare di pubblicare temi che si rompono al primo aggiornamento WordPress.

Casi d'uso reali di FSE + AI

I block theme generati con AI non sono un esercizio teorico: nel 2026 sono usati in produzione su migliaia di siti. Ecco i tre contesti in cui li vedo funzionare meglio, con i pattern architetturali ricorrenti.

Blog personali e portfolio

Il caso d'uso più semplice: un singolo autore, contenuti testuali e visivi, niente e-commerce. Un block theme con 10-12 patterns, due template (single, archive) e un theme.json curato copre il 90% delle esigenze. Tempi di setup: una giornata. Manutenzione: minima.

Siti di documentazione e knowledge base

Progetto interessante: block theme con un pattern "indice articoli" (lista raggruppata per categoria, con ricerca), un pattern "articolo tecnico" (titolo, sommario automatico dai heading, metadata autore), un pattern "snippet di codice" (blocco preformattato). L'AI genera la struttura, lo sviluppatore affina con casi d'uso specifici.

Magazine e siti editoriali con più autori

Il caso più complesso: molti autori, gerarchie di categorie, sidebar contestuali, pubblicazioni programmate. Il block theme AI diventa la base, poi serve personalizzazione su: schema template autore, block pattern per card articolo, integrazione con plugin di newsletter. Tempi di setup: 5-7 giorni. Manutenzione: media.

In tutti e tre i casi, il pattern è lo stesso: l'AI accelera la fase iniziale (theme.json, patterns, templates), la review umana e l'iterazione con utenti reali producono la versione finale. Nessun tema AI-generated è usabile in produzione senza almeno 2-3 cicli di feedback.

Errori da evitare con FSE + AI

Gli errori più gravi che vedo nei progetti FSE con AI sono cinque, e tutti evitabili con disciplina.

• Generare il tema e non testarlo mai nel Site Editor: il codice può sembrare corretto ma rompere il Site Editor per conflitti con i core blocks. Soluzione: test sistematico in Playground dopo ogni generazione AI.
• Sovrastimare la capacità dell'AI sull'architettura: l'AI tende a generare troppi template, troppi pattern, troppe variazioni. La regola è 8-15 pattern, 3-5 template, niente di più.
• Ignorare l'accessibilità: la palette generata dall'AI spesso non passa WCAG AA. La review di accessibilità è sempre obbligatoria.
• Saltare la categoria semantica dei pattern: senza categorie, il Site Editor diventa un mare di pattern indistinguibili. Ogni pattern deve avere una categoria chiara (featured, hero, cta, testimonial, footer).
• Pubblicare il tema senza testare con Gutenberg aggiornato: WordPress 6.7 e 6.8 hanno introdotto miglioramenti al Site Editor che richiedono test specifici. Un tema AI-generated senza test sull'ultima versione può rompersi.

Domande frequenti

L'AI può sostituire uno sviluppatore WordPress nella creazione di block theme?

No. L'AI accelera la generazione di theme.json, block patterns e template HTML, ma le decisioni architetturali (quanti pattern, come categorizzarli, quali vincoli di accessibilità), la review finale, e la manutenzione a lungo termine restano compiti umani. Un buon sviluppatore con AI è 4-6 volte più produttivo. Un principiante con AI genera codice non mantenibile.

Qual è il prompt migliore per generare un theme.json con AI?

Un prompt efficace deve contenere: tipo di sito, palette colori (con nomi semantici), tipografia (font display + font body, scala font sizes), spacing (scala in rem o px), layout (contentSize, wideSize), e requisiti di accessibilità (WCAG AA minimo). Maggiore è il dettaglio, minore è l'iterazione necessaria. Il prompt perfetto non esiste, ma prompt dettagliati producono risultati utilizzabili al 70-80% senza modifiche.

I block theme generati con AI sono compatibili con WooCommerce?

Sì, con un caveat. WooCommerce richiede template specifici (woocommerce/archive-product.php, woocommerce/single-product.php) che il block theme non fornisce nativamente. La soluzione è usare i template WooCommerce per block theme rilasciati dal team WooCommerce nel 2025. L'AI può adattare un block theme generico a WooCommerce con poche iterazioni, ma serve consapevolezza delle convenzioni WooCommerce.

Quanto costa sviluppare un block theme con AI?

Dipende dalla complessità. Un tema personale con 10 pattern: 200-400$ di abbonamenti AI (Cursor, Claude Code) e 1-2 giornate di lavoro. Un tema magazine con 15 pattern e-commerce: 600-1200$ di tool AI e 5-7 giornate di lavoro. Il risparmio rispetto allo sviluppo tradizionale è del 40-60% sui tempi, ma a condizione di fare review e test adeguati. Risparmiare sul testing è la causa numero uno di fallimenti.

Posso usare modelli AI locali per generare block theme?

Sì, con limiti. Modelli locali 70B (DeepSeek Coder, Qwen 2.5 Coder, Code Llama) producono theme.json validi e block patterns di buona qualità. Modelli 7B-13B faticano su template complessi e theme.json con molte opzioni. La regola pratica: per theme.json e pattern semplici, modelli locali bastano. Per refactoring massivi e architettura, cloud è ancora superiore.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• Documentazione Full Site Editing WordPress - guida ufficiale Site Editor.
• Theme.json reference - schema completo e opzioni.
• Block patterns reference - come registrare e usare i pattern.
• Block API reference - markup Gutenberg completo.
• Theme experiments su GitHub - esempi di pattern del core team.
• WordPress Playground - ambiente di test browser-based.
• Gutenberg Times - news e tutorial su FSE.
• WebAIM Contrast Checker - verifica accessibilità palette.
• WordPress Coding Standards - PHPCS ruleset per WordPress.
• Sito ufficiale WP-CLI - command line interface WordPress.
• WooCommerce block theme templates - integrazione WooCommerce + FSE.

Questa guida verrà aggiornata ad ogni major release di WordPress. Per suggerimenti o correzioni, l'area commenti è aperta.