L'obiettivo è chiaro: trasformare un prompt in un tema installabile, mantenibile, aggiornabile. Vediamo come, con esempi di codice e una checklist concreta.

Perché il 2026 è l'anno giusto per i temi AI

Due fattori tecnici hanno cambiato le regole del gioco. Il primo è WordPress 6.5+ e l'evoluzione del Full Site Editing: i block theme sono ora maturi, il file theme.json è documentato e stabile, e il pattern "global styles" permette di definire tipografia, colori e spacing senza scrivere CSS custom. Il secondo è la disponibilità di modelli AI addestrati su documentazione WordPress recente, capaci di generare strutture theme.json coerenti e block patterns sensati.

Questo non significa che qualsiasi prompt produce un tema pronto per la produzione. Significa che il rapporto tempo/qualità è cambiato: oggi puoi arrivare a un MVP funzionante in una giornata, con un block theme installabile e personalizzabile dal Site Editor. Lo stesso workflow che applichi ai plugin WordPress sviluppati con AI si adatta ai temi, con qualche differenza critica che vedremo tra poco.

Differenza tra block theme e classic theme nel workflow AI

La prima scelta che il prompt deve risolvere è: block theme (FSE) o classic theme (PHP template)? La risposta nel 2026 è quasi sempre block theme, per tre motivi concreti.

Il block theme è la scelta giusta nel 2026 per qualsiasi nuovo progetto, a meno di requisiti specifici (legacy code, plugin che richiedono template classici, integrazioni custom con PHP). Quando chiedi all'AI di generare un tema, specifica sempre "block theme conforme a WordPress 6.5+" come vincolo.

Anatomia di un block theme generato con AI

Un block theme minimo nel 2026 ha questa struttura. Non serve un file per ogni funzionalità: il core WordPress fornisce gli hook necessari, l'AI deve solo orchestrare il pacchetto.

# struttura directory di un block theme
mio-block-theme/
├── style.css
├── theme.json
├── functions.php
├── index.html
├── readme.txt
├── templates/
│   ├── index.html
│   ├── single.html
│   ├── page.html
│   └── archive.html
├── parts/
│   ├── header.html
│   └── footer.html
└── patterns/
    ├── hero.php
    └── cta-grid.php

La cosa importante è la separazione tra templates/ (pagine intere), parts/ (componenti riutilizzabili come header e footer) e patterns/ (blocchi compositi registrati). L'AI, se ben istruita, rispetta questa separazione. Se non lo fa, il tema è ingestibile.

theme.json: il cuore di tutto

Il file theme.json è dove definisci colori, tipografia, spacing, layout e impostazioni globali del tema. È un file JSON, quindi particolarmente adatto alla generazione AI. Un theme.json ben scritto sostituisce decine di righe di CSS custom e centralizza tutte le decisioni stilistiche.

Ecco un esempio di theme.json minimo generato con AI per un blog personale:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "appearanceTools": true,
    "useRootPaddingAwareAlignments": true,
    "layout": {
      "contentSize": "720px",
      "wideSize": "1200px"
    },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1e40af", "name": "Primary" },
        { "slug": "secondary", "color": "#64748b", "name": "Secondary" },
        { "slug": "background", "color": "#ffffff", "name": "Background" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "slug": "sans-serif", "name": "Sans-serif", "fontFamily": "system-ui, sans-serif" }
      ],
      "fontSizes": [
        { "slug": "small", "size": "0.875rem", "name": "Small" },
        { "slug": "medium", "size": "1rem", "name": "Medium" },
        { "slug": "large", "size": "1.5rem", "name": "Large" }
      ]
    }
  }
}

Nota la riga $schema: abilita l'autocompletamento e la validazione negli editor che supportano JSON Schema. Un dettaglio che l'AI spesso dimentica ma che fa risparmiare ore di debug.

Prompt design per generare un block theme

Il prompt per generare un block theme WordPress con AI deve contenere: tipo di sito (blog, portfolio, e-commerce, magazine), settore di riferimento, palette colori desiderata, target utente, funzionalità richieste (form contatti, ricerca, sidebar sì/no), e compatibilità minima WordPress.

Un prompt efficace è strutturato così:

Genera un block theme WordPress 6.5+ per [TIPO SITO]. Target: [DESCRIZIONE UTENTE]. Settore: [INDUSTRIA].
Requisiti tecnici:
- theme.json versione 2 con palette, tipografia, spacing
- 3 templates: index, single, page
- 2 parts: header con menu navigazione, footer con credit
- 2 patterns: hero homepage, call-to-action sezione
- stile minimal, tipografia system font, palette neutra con 1 accento
- accessibilità WCAG AA
- zero CSS custom oltre style.css di base
Output: struttura directory + contenuto di ogni file.

Più il prompt è dettagliato, meno iterazioni servono. Non lesinare sui requisiti: l'AI non indovina, esegue.

Block patterns: il vantaggio competitivo AI

I block patterns sono blocchi compositi che l'utente può inserire con un click dal Site Editor. Un tema con 10-15 patterns di qualità (hero, CTA, testimonial, pricing, FAQ, footer avanzato) è percepito come molto più completo di uno con 50 ma mediocri. L'AI eccelle nella generazione di patterns: sono blocchi autocontenuti, riutilizzabili, con un design system coerente.

Esempio di un pattern hero registrato in PHP: un file in patterns/hero-cta.php con header di metadati (Title, Slug, Categories), seguito dal markup Gutenberg per un gruppo full-width con sfondo primary, heading di livello 1, paragrafo descrittivo e un bottone di call-to-action. Il pattern è immediatamente utilizzabile nel Site Editor dall'utente finale. Una libreria ricca di patterns come questa differenzia un tema amatoriale da uno professionale. Per pattern di riferimento già pronti, il repository theme-experiments su GitHub contiene decine di esempi del core team WordPress.

Hosting e requisiti tecnici per block theme AI

Non tutti gli hosting gestiti supportano adeguatamente i block theme moderni. Alcuni hanno limitazioni su REST API, REST API autenticata per il Site Editor, o cron di sistema necessari per l'editor. Ecco un confronto diretto su tre categorie di hosting.

Per un block theme AI-generated, il requisito minimo è PHP 8.2+, MySQL 8.0+ o MariaDB 10.6+, HTTPS obbligatorio (per il Site Editor che richiede connessione sicura per il preview). Un hosting che non soddisfa questi requisiti costringerà l'utente finale a errori inspiegabili. Meglio specificarlo nella documentazione del tema.

Code review del tema generato

Anche per un tema, la review è obbligatoria. Ecco la mia checklist rapida:

• theme.json valido: passa lo schema, palette accessibile (contrasto WCAG AA minimo).
• functions.php snello: solo enqueue di style.css e eventuali custom block styles. Niente logica di business.
• Templates e parts: solo markup Gutenberg, zero PHP procedurale.
• Patterns: registrati con categorie semantiche, non accumulati alla rinfusa.
• style.css minimale: solo override mirati, non riscritture massive.
• readme.txt completo: descrizione, installazione, changelog, licenza GPL v2+.

Un tema che passa questa checklist è pronto per la distribuzione su wordpress.org o per la vendita. Un tema che la fallisce avrà problemi al primo aggiornamento WordPress.

Errori frequenti nei temi AI

Gli errori ricorrenti che vedo nei temi generati con AI e pubblicati su repository pubblici sono:

• Template monolitici senza parts: header e footer inline in ogni template, duplicazione massiccia, manutenzione impossibile.
• CSS custom nonostante theme.json: l'AI non sfrutta le global styles e scrive 500 righe di CSS che sovrascrivono il sistema.
• Patterns non categorizzati: una dozzina di patterns senza titolo semantico, inutilizzabili dal Site Editor.
• Font esterni senza local fallback: Google Fonts caricato senza font-display: swap, LCP penalizzato.
• Mancata dichiarazione WPGUTENBERGBLOCKPLACEHOLDER0X: l'utente finale non può modificare padding e margin dal Site Editor.

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

Strumenti AI consigliati per la generazione di temi

La mia toolchain del 2026 per block theme AI-assisted:

• Cursor con Claude 3.5+ o GPT-4o per la generazione di theme.json e patterns, con system prompt dedicato a WordPress.
• Continue.dev come alternativa open source, con modelli locali (Ollama + Code Llama) per chi ha vincoli di privacy.
• GitHub Copilot Workspace per refactoring e generazione di block patterns ripetitivi.
• WP-CLI + wp-env per testare il tema in un ambiente WordPress locale riproducibile.
• Block theme linting tools (wp-scripts, theme-check plugin) per validare lo standard prima della distribuzione.

Nessuno strumento è obbligatorio. La combinazione di un buon editor AI e di un ambiente di test locale è il minimo per evitare di pubblicare temi che si rompono al primo aggiornamento WordPress.

Workflow integrato: 5 giorni per un block theme

Un block theme production-ready si realizza in 5 giorni con questo ritmo:

• Giorno 1: requisiti (target utente, tipo di sito, palette), architettura (templates, parts, patterns necessari), generazione del theme.json.
• Giorno 2: generazione di templates e parts, primo test in ambiente locale, raccolta screenshot di anteprima.
• Giorno 3: generazione di 8-12 block patterns, test nel Site Editor per verificarne l'inserimento, ottimizzazione palette e tipografia.
• Giorno 4: code review, test di accessibilità, ottimizzazione performance, generazione readme.txt e screenshot ufficiali.
• Giorno 5: ZIP distribuzione, invio a wordpress.org o pubblicazione su marketplace, comunicazione release.

La parte più lenta è il giorno 3: i block patterns sono dove si vede la qualità del tema, e serve iterazione. Un tema con 3 pattern mediocri è un tema mediocre. Un tema con 12 pattern di qualità è un tema che gli utenti finali apprezzano.

Casi d'uso reali di block theme AI-generated

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 esempi concreti tratti dalla mia esperienza e da community di sviluppatori.

Blog personali e portfolio

Il caso d'uso più semplice: un singolo autore, contenuti testuali e visivi, niente e-commerce, niente aree riservate. Un block theme AI-generated con 8-12 patterns, due templates (single, archive) e un theme.json curato copre il 90% delle esigenze. Tempi di setup: una giornata. Manutenzione: minima, perché il contenuto cambia ma la struttura no.

Siti di documentazione e knowledge base

Progetto interessante: un block theme con un pattern "indice articoli" (lista raggruppata per categoria, con ricerca), un pattern "articolo tecnico" (titolo, sommario automatico dai heading, metadata autore, data, tag), un pattern "snippet di codice" (blocco preformattato con syntax highlighting via plugin). L'AI genera la struttura in poche ore, poi si affina con casi d'uso specifici. Performance ottima se il syntax highlighting è gestito lato server, non client.

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, ma serve personalizzazione su: schema dei template autore, block pattern per card articolo, integrazione con plugin di newsletter, gestione di pubblicità contestuale. Tempi di setup: 5-7 giorni. Manutenzione: media, perché il tema evolve con le esigenze editoriali.

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.

Confronto rapido: AI theme vs page builder

Spesso mi chiedono: meglio un tema AI-generated o un page builder? La risposta dipende dal progetto. Ecco un confronto sintetico.

Se il tuo cliente ha bisogno di modificare contenuti frequentemente e non vuole dipendere da te per ogni modifica, un block theme è la scelta giusta. Se ha bisogno di una landing page molto specifica con un design particolare, un page builder può essere più rapido. Spesso la soluzione migliore è block theme per la struttura + page builder per pagine specifiche ad alta conversione.

Personalizzazione child theme per block theme AI

Una delle resistenze più comuni all'adozione di un tema AI-generated è la paura di perdere le personalizzazioni al primo aggiornamento. La buona notizia è che nel 2026 i block theme gestiscono la personalizzazione in modo molto più pulito rispetto al passato, ma servono alcune accortezze per non reintrodurre debito tecnico.

Override di un block pattern

Se un pattern del tema non ti convince, hai due strade. La prima è duplicarlo nel child theme e modificarlo: copia il file patterns/hero-cta.php in mio-child-theme/patterns/hero-custom.php, modificalo, e WordPress userà quello del child. La seconda è sovrascrivere le global styles via theme.json del child theme: il sistema fa il merge automatico, con il child che ha priorità sul parent. La prima è più pulita per modifiche strutturali, la seconda per modifiche stilistiche.

Aggiungere un custom block style

<?php
// functions.php del child theme
add_action( 'init', 'mio_child_register_block_styles' );
function mio_child_register_block_styles() {
    register_block_style( 'core/button', array(
        'name'  => 'rounded',
        'label' => 'Arrotondato',
    ) );
}

Questo snippet registra un nuovo stile "Arrotondato" per il blocco Button, selezionabile dall'utente nel Site Editor. Le personalizzazioni CSS vanno in style.css del child theme.

Quando NON serve un child theme

Se devi solo cambiare colori, tipografia e spacing, ti basta il Customizer del Site Editor: ogni modifica è una global style override che sopravvive agli aggiornamenti del parent theme. Il child theme serve solo per aggiungere funzionalità (custom block styles, pattern, hook) o per modifiche strutturali (template custom, logica PHP). Con l'AI che genera block theme già completi, il child theme è sempre meno necessario.

Manutenzione post-distribuzione

Un block theme pubblicato non è un artefatto statico. WordPress evolve, Gutenberg rilascia nuovi blocchi, le best practice cambiano. Ecco cosa monitorare e aggiornare regolarmente.

Calendario di manutenzione

Un tema che non viene mantenuto per 6 mesi accumula problemi: nuovi blocchi WordPress non supportati, pattern con markup deprecato, screenshot obsoleti che danneggiano la percezione di qualità. La manutenzione è il vero investimento a lungo termine.

Gestione issue e feedback

Predisponi un canale di feedback (forum wordpress.org, GitHub Issues, email di supporto) e rispondi entro una settimana. Le issue sono spesso preziose: ti dicono quali pattern sono usati di più, quali mancano, quali bug emergono su combinazioni di plugin specifiche. Tratta ogni issue come un input di prodotto.

Domande frequenti

I temi AI-generated sono ammessi su wordpress.org? Sì, purché rispettino le linee guida ufficiali (licenza GPL, no link a servizi a pagamento nel tema, no telemetria, codice revisionabile). L'AI è uno strumento di generazione, non un vincolo di accettazione.

Quanto è diverso un block theme nel 2026 rispetto al 2024? Significativamente. WordPress 6.5 ha consolidato il pattern "global styles", theme.json ha raggiunto la versione 2 stabile, l'API appearanceTools è completa. Un block theme del 2024 richiede spesso refactoring per essere allineato al 2026.

Posso usare un block theme con WooCommerce? Sì, WooCommerce 8+ supporta block theme nativamente con cart e checkout basati su blocchi. Devi dichiarare il supporto WooCommerce nel functions.php e includere i template WooCommerce nella directory del tema.

Qual è il costo reale di un tema AI-generated? Il costo del tempo di sviluppo (5 giorni a tariffa consulenza 400-600€/giorno, totale 2000-3000€) più il costo di hosting. Tema AI-generated non significa tema gratuito: il valore aggiunto è nella personalizzazione, nei patterns e nella documentazione.

Riferimenti ufficiali per approfondire

Per chiudere, ecco le fonti primarie che consulto sempre quando lavoro su block theme:

• Theme Handbook ufficiale WordPress — documentazione canonica su block theme, theme.json, template hierarchy aggiornata.
• Full Site Editing su wordpress.org — guida utente sul Site Editor, utile per scrivere documentazione non tecnica.
• theme.json reference su Gutenberg Times — articoli tecnici di aggiornamento su novità theme.json e global styles.
• WordPress/block-theme-examples su GitHub — esempi di temi sperimentali del core team, ottimi come riferimento di struttura.
• WP-CLI scaffold per temi — comandi per generare la struttura di un block theme da CLI.
• Plugin Check per temi — include anche validazioni specifiche per temi in submission.

Conclusione

I temi WordPress con AI nel 2026 sono una leva di produttività reale, a patto di seguire un metodo: block theme con theme.json, prompt dettagliato, code review obbligatoria, distribuzione documentata. L'AI non sostituisce la conoscenza di WordPress, ma accelera la traduzione di un'idea in un tema installabile. Se hai già un workflow per plugin AI-assisted e per ambienti di sviluppo locale, aggiungere la generazione di temi è naturale. Per confronti su coding assistant AI e su strumenti di sviluppo WordPress trovi guide dedicate sul blog. Il metodo è trasversale, il vantaggio competitivo è nella costanza, non nella magia del singolo prompt.

Per chi lavora su siti WordPress, questo cambia il metodo. Invece di chiedere all'AI "crea un tema moderno", conviene progettare un sistema leggibile da persone e agenti: brief, pagine, componenti, token, accessibilità, template, pattern e test. È lo stesso cambio di mentalità che ho già approfondito parlando di web design WordPress con Novamira.ai e di temi WordPress generati dall'intelligenza artificiale: l'AI funziona meglio quando ha un perimetro tecnico preciso.

In questa guida vediamo un flusso completo: prima si scrive la specifica, poi si usa Google Stitch per esplorare l'interfaccia, quindi si traduce il design in DESIGN.md, si implementa un block theme WordPress con theme.json, template e pattern, e infine si controlla tutto con prompt mirati, WP-CLI e test manuali. Se vuoi ripassare le basi tradizionali, puoi affiancare questa guida a come creare un tema WordPress da zero.

La tesi è semplice: il tema non deve emergere dal codice per tentativi. Deve derivare da una specifica. Il codice è una conseguenza, non il punto di partenza.

Perché partire da una specifica prima del codice

Per progettare in modo efficace un tema WordPress con standard attuali bisogna insistere su un punto: chi usa bene gli agenti AI non salta la parte difficile, salta solo la parte più meccanica dell'implementazione. Nel caso di un tema WordPress, la parte difficile non è creare una cartella in wp-content/themes. È decidere cosa il tema deve fare, cosa non deve toccare, come deve comportarsi nel Site Editor, quali blocchi deve supportare e quali vincoli non possono essere violati.

Una specifica utile deve rispondere almeno a queste domande:

• Quale problema risolve il tema e per quale pubblico?
• Quali pagine e template sono indispensabili al primo rilascio?
• Quali componenti devono essere riutilizzabili come pattern Gutenberg?
• Quali token regolano colori, font, spaziature, raggi, ombre e layout?
• Quali file l'agente AI può modificare e quali deve lasciare intatti?
• Quali criteri definiscono "finito": responsive, accessibilità, performance, SEO, compatibilità editor?

Questa è la differenza tra vibe coding casuale e sviluppo assistito serio: non chiedi all'AI di indovinare, le dai un contratto operativo.

Architettura del workflow

Il flusso consigliato è diviso in sette fasi. Ogni fase produce un output che diventa input per la successiva.

Step 1: scrivere il brief tecnico del tema

Prima di aprire Stitch o un editor, crea un file SPEC.md. Questo file descrive il risultato atteso in modo verificabile.

# SPEC.md - Tema WordPress per studio professionale

## Obiettivo
Creare un block theme WordPress per uno studio di consulenza B2B.
Il tema deve comunicare autorevolezza, chiarezza, velocità e affidabilità.

## Pagine prioritarie
- Homepage
- Servizi
- Caso studio
- Blog
- Contatti
- 404

## Vincoli
- Nessun page builder esterno.
- Compatibile con Site Editor e Gutenberg.
- Tutte le sezioni riutilizzabili devono diventare pattern.
- Nessun H1 duplicato nei template.
- Palette e tipografia governate da theme.json.
- CSS custom ridotto al minimo.

## Criteri di completamento
- Mobile, tablet e desktop senza overflow.
- Contrasto WCAG AA sulle CTA principali.
- Template principali presenti in /templates.
- Header e footer presenti in /parts.
- Pattern registrati in /patterns.
- Score PageSpeed da verificare prima del rilascio.

Il prompt iniziale per l'agente AI non deve chiedere codice. Deve chiedere di verificare la specifica.

Agisci come senior WordPress theme architect.

Leggi questa specifica per un block theme WordPress.
Non generare codice.

Task:
1. Trova requisiti ambigui.
2. Elenca decisioni mancanti.
3. Proponi una struttura file coerente con un block theme moderno.
4. Indica quali parti devono diventare template e quali pattern.
5. Restituisci solo una checklist tecnica approvabile.

SPEC:
[incolla qui SPEC.md]

Step 2: progettare le prime schermate con Google Stitch

Google descrive Stitch come un canvas AI-native per creare, iterare e collaborare su UI ad alta fedeltà usando linguaggio naturale. Nel workflow WordPress non va usato come scorciatoia per copiare HTML a caso, ma come strumento di esplorazione: produce direzioni visive, layout e varianti che poi vanno convertite in un sistema WordPress mantenibile.

Un prompt efficace per Stitch deve contenere obiettivo, pubblico, tono, struttura e vincoli. Ecco un esempio pronto.

Design a responsive WordPress block theme homepage for a B2B consulting studio.

Business goal:
Generate qualified leads for consulting calls.

Audience:
Small business owners and marketing managers who need a reliable WordPress partner.

Visual direction:
Clean, editorial, professional, calm. Avoid generic SaaS gradients and oversized decorative blobs.

Page structure:
1. Header with logo, navigation and primary CTA.
2. Hero with clear value proposition and one CTA.
3. Trust strip with service areas.
4. Services grid with 3 cards.
5. Case study preview.
6. Process section with 4 steps.
7. FAQ.
8. Final CTA.
9. Footer with contacts and legal links.

Constraints:
- Design must translate cleanly into WordPress Gutenberg blocks.
- Use reusable sections that can become block patterns.
- Keep text readable on mobile.
- Use accessible contrast for buttons and links.

Dopo aver ottenuto una variante convincente, non fermarti allo screenshot. Chiedi a Stitch o all'agente di estrarre le decisioni di design: palette, font, scala tipografica, spacing, componenti e stati. Queste informazioni diventano il materiale per DESIGN.md.

Step 3: trasformare il design in DESIGN.md

DESIGN.md è utile perché rende esplicito il design system in un formato testuale leggibile dagli agenti. Il repository ufficiale di Google Labs include anche comandi CLI per validare, confrontare ed esportare token. La documentazione WordPress, invece, indica theme.json come il file fondamentale per impostazioni e stili globali di un block theme. Il ponte naturale è questo: DESIGN.md governa il linguaggio visivo, theme.json lo applica in WordPress.

Un esempio essenziale di DESIGN.md per il tema potrebbe essere:

# DESIGN.md

## Brand
Name: Studio Atlas
Personality: clear, practical, reliable, technical.
Audience: business owners, marketing managers, WordPress site owners.

## Color Tokens
- primary: #1E3A5F
- primary-hover: #15304F
- accent: #D97706
- background: #F7F8FA
- surface: #FFFFFF
- text: #17202A
- muted: #5F6B7A
- border: #D9DEE7

## Typography
- heading-font: Inter Tight, system-ui, sans-serif
- body-font: Inter, system-ui, sans-serif
- h1: 56px / 1.08 / 700
- h2: 40px / 1.15 / 700
- h3: 26px / 1.25 / 650
- body: 18px / 1.7 / 400
- small: 14px / 1.5 / 400

## Spacing
- xs: 8px
- sm: 16px
- md: 24px
- lg: 40px
- xl: 64px
- section: 96px

## Components
Button primary:
- background: primary
- text: #FFFFFF
- radius: 6px
- padding: 14px 22px
- hover: primary-hover
- focus: 2px solid accent

Card:
- background: surface
- border: 1px solid border
- radius: 8px
- padding: 24px
- no decorative shadow unless needed for hierarchy

## WordPress Rules
- Prefer core blocks and patterns.
- Avoid hard-coded inline styles in templates.
- Put global decisions in theme.json.
- Use CSS only for behavior not expressible through theme.json.

Prima di usare questo file come contesto per un agente, validalo. La CLI ufficiale consente il controllo strutturale.

# comando lint
npx @google/design.md lint DESIGN.md

Quando fai evolvere il design, confronta due versioni per evitare regressioni nei token.

# confronto due versioni
npx @google/design.md diff DESIGN.md DESIGN-v2.md

Step 4: creare lo scheletro del block theme

Un tema a blocchi moderno parte da pochi file ordinati. La documentazione ufficiale WordPress ricorda che i block theme usano blocchi per tutte le parti del sito, inclusi header, contenuto e footer. Per questo conviene progettare la struttura in modo compatibile con Site Editor.

studio-atlas/
├── style.css
├── functions.php
├── theme.json
├── screenshot.png
├── templates/
│   ├── index.html
│   ├── front-page.html
│   ├── single.html
│   ├── page.html
│   ├── archive.html
│   └── 404.html
├── parts/
│   ├── header.html
│   └── footer.html
├── patterns/
│   ├── hero-consulenza.php
│   ├── servizi-grid.php
│   ├── processo.php
│   ├── faq.php
│   └── cta-finale.php
└── assets/
    ├── css/
    └── js/

Il file style.css contiene l'intestazione riconosciuta da WordPress.

/*
Theme Name: Studio Atlas
Theme URI: https://example.com/studio-atlas
Author: Emilio Petrozzi
Description: Block theme WordPress progettato con DESIGN.md, Google Stitch e specifiche AI.
Version: 1.0.0
Requires at least: 6.5
Tested up to: 6.9
Requires PHP: 8.0
Text Domain: studio-atlas
*/

Il prompt per generare lo scheletro deve limitare il raggio d'azione dell'agente.

Agisci come sviluppatore senior WordPress specializzato in block theme.

Contesto:
- SPEC.md definisce requisiti e pagine.
- DESIGN.md definisce token e componenti.

Task:
Crea lo scheletro del tema "studio-atlas".

Vincoli:
- Non creare plugin.
- Non usare page builder.
- Non inserire CSS inline nei template.
- Usa theme.json per colori, font, spacing e layout.
- Crea solo file necessari al primo rilascio.

Output:
1. Alberatura file.
2. Contenuto di style.css.
3. Contenuto minimo di functions.php.
4. Contenuto iniziale di theme.json.
5. Note sui file da completare dopo approvazione.

Step 5: tradurre DESIGN.md in theme.json

theme.json è il punto in cui il design system diventa editoriale: palette, tipografia, spaziature e layout appaiono sia nel frontend sia nell'editor. WordPress lo definisce una lingua comune tra tema, plugin, utenti e interfaccia di editing.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "appearanceTools": true,
    "layout": {
      "contentSize": "760px",
      "wideSize": "1180px"
    },
    "color": {
      "palette": [
        { "slug": "primary", "name": "Primary", "color": "#1E3A5F" },
        { "slug": "accent", "name": "Accent", "color": "#D97706" },
        { "slug": "background", "name": "Background", "color": "#F7F8FA" },
        { "slug": "surface", "name": "Surface", "color": "#FFFFFF" },
        { "slug": "text", "name": "Text", "color": "#17202A" },
        { "slug": "muted", "name": "Muted", "color": "#5F6B7A" }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "slug": "inter",
          "name": "Inter",
          "fontFamily": "Inter, system-ui, sans-serif"
        },
        {
          "slug": "inter-tight",
          "name": "Inter Tight",
          "fontFamily": "\"Inter Tight\", Inter, system-ui, sans-serif"
        }
      ],
      "fontSizes": [
        { "slug": "small", "name": "Small", "size": "14px" },
        { "slug": "base", "name": "Base", "size": "18px" },
        { "slug": "h2", "name": "Heading 2", "size": "40px" },
        { "slug": "hero", "name": "Hero", "size": "56px" }
      ]
    },
    "spacing": {
      "spacingScale": {
        "steps": 0
      },
      "spacingSizes": [
        { "slug": "sm", "name": "Small", "size": "16px" },
        { "slug": "md", "name": "Medium", "size": "24px" },
        { "slug": "lg", "name": "Large", "size": "40px" },
        { "slug": "xl", "name": "Extra Large", "size": "64px" }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var:preset|color|background",
      "text": "var:preset|color|text"
    },
    "typography": {
      "fontFamily": "var:preset|font-family|inter",
      "fontSize": "var:preset|font-size|base",
      "lineHeight": "1.7"
    },
    "elements": {
      "heading": {
        "typography": {
          "fontFamily": "var:preset|font-family|inter-tight",
          "lineHeight": "1.15"
        }
      },
      "button": {
        "border": {
          "radius": "6px"
        },
        "color": {
          "background": "var:preset|color|primary",
          "text": "var:preset|color|surface"
        }
      }
    }
  }
}

Prompt consigliato per questa conversione:

Agisci come WordPress block theme engineer.

Input:
- DESIGN.md con token colore, tipografia, spacing e componenti.
- SPEC.md con vincoli del tema.

Task:
Genera un theme.json compatibile con WordPress 6.5+.

Regole:
- Usa version 2 e $schema ufficiale.
- Inserisci palette, fontFamilies, fontSizes, spacingSizes e layout.
- Evita valori duplicati non necessari.
- Non generare template.
- Non usare commenti nel JSON.

Output:
Solo JSON valido.

Step 6: creare template e parti riutilizzabili

I template HTML di un block theme sono markup Gutenberg. L'obiettivo non è replicare pixel per pixel l'output di Stitch, ma ricostruire le sezioni usando blocchi core, classi coerenti e pattern.

Esempio di parts/header.html:

<!-- wp:group {"align":"full","style":{"spacing":{"padding":{"top":"16px","bottom":"16px"}}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull" style="padding-top:16px;padding-bottom:16px">
  <!-- wp:group {"layout":{"type":"flex","justifyContent":"space-between","flexWrap":"wrap"}} -->
  <div class="wp-block-group">
    <!-- wp:site-title {"level":0} /-->
    <!-- wp:navigation {"layout":{"type":"flex","justifyContent":"right"}} /-->
    <!-- wp:buttons -->
    <div class="wp-block-buttons">
      <!-- wp:button -->
      <div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Prenota una consulenza</a></div>
      <!-- /wp:button -->
    </div>
    <!-- /wp:buttons -->
  </div>
  <!-- /wp:group -->
</div>
<!-- /wp:group -->

Prompt per generare template senza perdere controllo:

Agisci come Gutenberg block theme developer.

Task:
Crea i template HTML per:
- front-page.html
- single.html
- archive.html
- 404.html
- parts/header.html
- parts/footer.html

Vincoli:
- Usa solo markup di blocchi core WordPress.
- Non creare un H1 nel contenuto se il template già usa post-title.
- Usa template parts per header e footer.
- Le sezioni complesse devono richiamare pattern, non duplicare markup.
- Non usare CSS inline salvo padding/spaziature supportate dai blocchi.

Output:
Un file alla volta, con percorso e contenuto completo.

Step 7: convertire le sezioni in pattern Gutenberg

I pattern sono il punto in cui un tema diventa davvero usabile. Un cliente o editor può inserire una hero, una CTA o una FAQ senza chiedere modifiche al codice. Un pattern PHP minimo contiene intestazione e markup blocchi.

<?php
/**
 * Title: Hero consulenza
 * Slug: studio-atlas/hero-consulenza
 * Categories: featured
 */
?>

<!-- wp:group {"align":"full","style":{"spacing":{"padding":{"top":"96px","bottom":"80px"}}},"backgroundColor":"background","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull has-background-background-color has-background" style="padding-top:96px;padding-bottom:80px">
  <!-- wp:heading {"level":1,"fontSize":"hero"} -->
  <h1 class="wp-block-heading has-hero-font-size">Un sito WordPress più chiaro, veloce e facile da gestire</h1>
  <!-- /wp:heading -->

  <!-- wp:paragraph {"fontSize":"base"} -->
  <p class="has-base-font-size">Progettiamo temi WordPress su misura con design system, Gutenberg e workflow AI controllati.</p>
  <!-- /wp:paragraph -->

  <!-- wp:buttons -->
  <div class="wp-block-buttons">
    <!-- wp:button -->
    <div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Richiedi una consulenza</a></div>
    <!-- /wp:button -->
  </div>
  <!-- /wp:buttons -->
</div>
<!-- /wp:group -->

Per pattern più complessi, come pricing o FAQ, chiedi prima all'agente una lista di campi modificabili. Poi genera il markup. Questo riduce il rischio di sezioni belle ma scomode da gestire.

Step 8: aggiungere funzioni WordPress minime

Un block theme pulito deve avere un functions.php essenziale. Evita di trasformarlo in un plugin mascherato: registra asset, supporti e piccole ottimizzazioni legate al tema. Per logiche avanzate, meglio creare un plugin dedicato. Puoi approfondire la logica degli hook nella guida su azioni e filter WordPress.

<?php
/**
 * Studio Atlas theme setup.
 */

add_action('after_setup_theme', function () {
    add_theme_support('wp-block-styles');
    add_theme_support('editor-styles');
    add_editor_style('assets/css/editor.css');
});

add_action('wp_enqueue_scripts', function () {
    wp_enqueue_style(
        'studio-atlas-style',
        get_stylesheet_uri(),
        array(),
        wp_get_theme()->get('Version')
    );
});

add_filter('should_load_separate_core_block_assets', '__return_true');

Se servono interazioni più evolute, valuta la Interactivity API, disponibile in WordPress Core dalla versione 6.5 tramite il pacchetto @wordpress/interactivity. Non usarla per tutto: è utile quando l'interazione appartiene a blocchi e componenti, non per animazioni decorative superflue.

Prompt ottimizzati per implementare il tema passo passo

La regola operativa è: un prompt, un risultato verificabile. Non chiedere all'agente di "fare tutto il tema" in una volta sola. Spezza il lavoro.

Prompt 1: revisione architetturale

Agisci come reviewer senior WordPress.

Analizza SPEC.md e DESIGN.md.
Non scrivere codice.

Dimmi:
1. Quali requisiti sono incompleti.
2. Quali rischi tecnici vedi.
3. Quali template e pattern sono davvero necessari.
4. Quali decisioni devono finire in theme.json.
5. Quali controlli fare prima del rilascio.

Prompt 2: implementazione controllata

Agisci come implementatore WordPress.

Task:
Implementa solo theme.json e style.css.

Input:
- SPEC.md
- DESIGN.md

Vincoli:
- Non modificare template.
- Non creare pattern.
- Non aggiungere dipendenze.
- Mantieni JSON valido.
- Usa token coerenti con DESIGN.md.

Dopo l'implementazione:
1. Spiega le scelte.
2. Elenca cosa resta da fare.
3. Suggerisci un comando di verifica.

Prompt 3: generazione pattern

Agisci come Gutenberg pattern designer.

Task:
Crea il pattern "servizi-grid.php".

Requisiti:
- 3 card servizio.
- Ogni card ha titolo, testo breve e link.
- Usa colori e font di theme.json.
- Markup compatibile con blocchi core.
- Nessun CSS custom nel pattern.

Output:
Solo contenuto completo del file PHP.

Prompt 4: QA finale

Agisci come QA engineer WordPress.

Analizza il tema appena creato.

Controlla:
- Struttura file.
- Validità theme.json.
- Presenza template principali.
- Presenza header e footer.
- Pattern registrati.
- Possibili H1 duplicati.
- Accessibilità base.
- Responsive risk.
- SEO tecnica.

Output:
Tabella con problema, severità, file coinvolto e correzione consigliata.

Verifiche tecniche prima della pubblicazione

Quando il tema è pronto, installalo prima in locale o staging. Se hai WP-CLI disponibile, puoi automatizzare alcune verifiche.

# verifica temi installati
wp theme list

Attiva il tema solo in ambiente di test.

# attivazione in staging
wp theme activate studio-atlas

Controlla che WordPress non segnali errori PHP dopo l'attivazione.

# controllo errori recenti
wp eval 'echo "Tema attivo: " . wp_get_theme()->get("Name");'

La checklist finale deve includere:

• Homepage leggibile su mobile senza overflow orizzontale.
• Menu e CTA accessibili da tastiera.
• Un solo H1 per pagina.
• Contrasto sufficiente per testo, link e pulsanti.
• Template per singolo articolo, pagina, archivio e 404.
• Pattern modificabili nel Site Editor.
• Nessun contenuto essenziale hard-coded se deve essere gestito dal cliente.
• Font caricati in modo efficiente.
• Performance controllata con PageSpeed Insights.

Errori comuni da evitare

Il primo errore è usare Stitch come se producesse direttamente un tema WordPress finito. Può aiutare molto nella direzione UI, ma il tema deve rispettare gerarchie WordPress, Gutenberg, template parts e manutenzione futura.

Il secondo errore è mettere tutto in CSS. Se palette, font e spacing finiscono solo in style.css, l'editor non riflette davvero il design system. Il cliente vedrà opzioni incoerenti e tenderà a rompere il layout.

Il terzo errore è chiedere all'AI output troppo ampi. Prompt enormi come "crea tutto il tema" generano codice plausibile ma difficile da verificare. Meglio far lavorare l'agente su una porzione alla volta, con file e confini chiari.

Il quarto errore è non documentare le decisioni. Se il tema evolve, aggiorna SPEC.md e DESIGN.md. Altrimenti l'agente continuerà a lavorare su istruzioni vecchie e produrrà incoerenze.

Risorse utili

• Google Stitch: canvas AI per esplorare interfacce e prototipi.
• Blog Google su Stitch e vibe design: panoramica ufficiale dell'evoluzione di Stitch.
• Google Labs DESIGN.md: specifica, CLI, lint, diff ed export token.
• Documentazione WordPress su theme.json: base tecnica per stili globali e impostazioni.
• Documentazione WordPress sui block theme: introduzione al modello Site Editor.
• Interactivity API: standard WordPress per blocchi interattivi moderni.

FAQ

Posso creare un tema WordPress completo solo con Stitch?

No, non in modo professionale. Stitch è utile per ideazione, layout e direzione visiva. Un tema WordPress completo richiede struttura del tema, theme.json, template, pattern, compatibilità Gutenberg, test e controlli tecnici.

DESIGN.md sostituisce theme.json?

No. DESIGN.md documenta il design system in forma leggibile dagli agenti AI. theme.json applica quelle decisioni dentro WordPress, rendendole disponibili al frontend e all'editor.

Meglio un tema classico o un block theme?

Per un nuovo progetto orientato a Gutenberg e Site Editor, un block theme è spesso la scelta più coerente. Un tema classico resta valido quando il progetto ha vincoli legacy, template PHP complessi o dipendenze già consolidate.

Gli agenti AI possono implementare direttamente il tema?

Sì, ma solo se ricevono specifiche, confini e criteri di verifica. Il punto del documento allegato è proprio questo: l'AI produce risultati migliori quando il lavoro di progettazione è esplicito, scritto e verificabile.

Conclusione

Creare un tema WordPress completo con AI non significa delegare il pensiero al modello. Significa spostare il valore sulla progettazione: descrivere bene il sistema, definire vincoli, produrre un design system e far implementare porzioni controllate. Google Stitch aiuta a esplorare l'interfaccia, DESIGN.md conserva la coerenza visiva, theme.json porta quella coerenza dentro WordPress.

La domanda utile, prima di generare codice, è questa: se un altro sviluppatore o un agente AI dovesse costruire il tema senza parlarti, avrebbe abbastanza informazioni per farlo correttamente? Se la risposta è no, non manca un prompt migliore. Manca una specifica migliore.

Il punto non e usare piu tool possibile. Al contrario: un buon flusso di web design per WordPress dovrebbe essere abbastanza snello da non rallentare il progetto, ma abbastanza rigoroso da evitare incoerenze tra design, sviluppo e pubblicazione. In questa guida trovi una selezione ragionata di strumenti per creare temi WordPress moderni, con particolare attenzione a block theme, Gutenberg, design system e Core Web Vitals.

Per approfondimenti gia pubblicati su MrTux, puo essere utile leggere anche Temi WordPress vs Page Builder: cosa scegliere nel 2026, Articoli WordPress ottimizzati SEO con AI e Strumenti Programmazione 2026: guida per sviluppatori.

Prima di scegliere i tool: che tipo di tema vuoi costruire?

La scelta degli strumenti dipende dal tipo di tema. Un tema classico richiede un approccio diverso rispetto a un block theme basato su theme.json, template HTML e Site Editor. Allo stesso modo, un tema per un magazine, un sito aziendale o un e-commerce avra priorita differenti.

Prima di aprire Figma, VS Code o un builder, conviene definire tre cose: quali parti del sito devono essere modificabili dal cliente, quali componenti devono restare controllati dal tema e quali metriche non possono essere sacrificate. Se un tema e bello ma produce layout instabili, font caricati male e blocchi difficili da riutilizzare, il progetto non e davvero finito.

Un tema WordPress efficace non e solo una veste grafica: e un sistema di decisioni ripetibili su layout, tipografia, componenti, contenuti e prestazioni.

Gli strumenti essenziali per progettare temi WordPress

Qui sotto trovi una vista sintetica degli strumenti piu utili. Non e una classifica assoluta: e una mappa pratica per capire quale problema risolve ogni categoria.

Figma: il centro del flusso visuale

Figma resta uno degli strumenti piu solidi per progettare interfacce WordPress. Il suo valore non e solo nel disegno delle pagine, ma nella capacita di definire componenti, varianti, stili e variabili che possono diventare la base del tema.

Per un tema WordPress, Figma dovrebbe contenere almeno: griglia, scala tipografica, palette colore, stati dei pulsanti, campi form, card, header, footer, template articolo, archivio, pagina categoria e layout mobile. Se il progetto prevede Gutenberg, conviene progettare anche i blocchi principali nello stesso linguaggio visivo che verra poi implementato nel tema.

• Usa componenti per elementi ricorrenti come bottoni, card, menu e blocchi editoriali.
• Definisci variabili per colori, spacing e radius, evitando valori casuali pagina per pagina.
• Prepara stati reali: hover, focus, errore, disabilitato e mobile.
• Nomina gli elementi con lo stesso linguaggio che userai in WordPress: hero, query card, post meta, sidebar, CTA.

Risorsa autorevole: la documentazione ufficiale di Figma Help Center e utile per approfondire componenti, variabili e Dev Mode.

WordPress Theme Handbook e theme.json

Per i temi moderni, la documentazione ufficiale WordPress e il riferimento da cui partire. Il Theme Handbook spiega struttura dei temi, template, pattern, funzioni e standard. Per i block theme, la sezione su Global Settings and Styles e centrale per capire theme.json.

theme.json non e un dettaglio tecnico secondario. E il punto in cui il design system incontra WordPress: palette, tipografia, spaziature, layout width, stili globali e impostazioni dei blocchi possono essere governati da li. Questo riduce CSS disperso, rende l'editor piu coerente e limita le scelte casuali dell'utente finale.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1E40AF", "name": "Brand" },
        { "slug": "text", "color": "#111827", "name": "Text" }
      ]
    },
    "layout": {
      "contentSize": "720px",
      "wideSize": "1120px"
    }
  }
}

Un buon approccio consiste nel progettare i token in Figma, tradurli in theme.json e usare CSS custom solo dove serve davvero. In questo modo il tema rimane piu pulito e piu compatibile con l'editor a blocchi.

Local, Docker e WP-CLI: ambiente di lavoro stabile

Un tema WordPress non dovrebbe essere sviluppato direttamente online. Servono ambienti locali ripetibili. Local e una scelta comoda per molti freelance e piccoli team; Docker e piu adatto quando vuoi replicare in modo preciso versioni PHP, database, estensioni e workflow di deploy. WP-CLI, invece, diventa indispensabile appena il lavoro passa da "installo un tema" a "gestisco un progetto".

• Con WP-CLI puoi creare utenti, installare plugin, esportare contenuti, svuotare cache e verificare configurazioni.
• Con Docker puoi evitare differenze tra ambiente locale, staging e produzione.
• Con un ambiente locale puoi testare pattern, template e aggiornamenti senza rischiare il sito pubblico.

Per chi lavora spesso su temi, il tempo investito nella configurazione dell'ambiente viene recuperato rapidamente. Debug, rollback e test diventano piu semplici, soprattutto quando il sito cresce.

VS Code e strumenti per il codice

VS Code rimane uno standard pratico per lavorare su temi WordPress. Le estensioni per PHP, CSS, JavaScript, linting e formattazione aiutano a mantenere il codice leggibile. Ma il punto non e installare decine di estensioni: serve un ambiente coerente con il progetto.

Per un tema block-based, conviene avere controllo su HTML dei template, JSON, CSS e JavaScript solo dove necessario. I file principali da trattare con attenzione sono theme.json, templates/, parts/, patterns/, functions.php e gli eventuali asset CSS/JS.

Gutenberg, pattern e Site Editor

Chi progetta temi WordPress oggi deve conoscere Gutenberg non come semplice editor, ma come ambiente di composizione. Pattern, template part e stili globali permettono di dare al cliente liberta controllata: puo aggiornare contenuti e sezioni senza rompere il design.

Il modo migliore per progettare con Gutenberg e pensare per blocchi editoriali: hero, sezione servizi, griglia articoli, testimonial, call to action, FAQ, card categoria, blocco autore. Ogni pattern dovrebbe avere uno scopo chiaro e funzionare con contenuti realistici, non solo con testo fittizio.

Un pattern utile non e quello che impressiona nella demo, ma quello che un editor puo riutilizzare senza chiedere aiuto allo sviluppatore.

Performance: Lighthouse, PageSpeed Insights e Core Web Vitals

Un tema WordPress va misurato. Non basta vederlo fluido sul proprio computer. Strumenti come PageSpeed Insights, Lighthouse e la documentazione web.dev sui Core Web Vitals aiutano a capire se il design regge anche dal punto di vista dell'esperienza utente.

• Controlla LCP: immagini hero troppo pesanti e font caricati male sono spesso il problema principale.
• Riduci CLS: assegna dimensioni prevedibili a immagini, iframe e sezioni dinamiche.
• Monitora INP: JavaScript non necessario, slider pesanti e page builder sovraccarichi possono peggiorare la reattivita.
• Testa mobile prima del desktop: e li che emergono le scelte sbagliate.

Il tema migliore non e quello con piu effetti, ma quello che resta veloce mentre comunica bene. Animazioni, font variabili e layout complessi hanno senso solo se non peggiorano leggibilita e prestazioni.

Accessibilita: strumenti da usare prima della consegna

L'accessibilita non dovrebbe essere una fase finale, ma un criterio di progetto. Colori, focus state, dimensioni dei font, ordine degli heading e navigazione da tastiera incidono direttamente sulla qualita del tema. Per i riferimenti tecnici, MDN e le linee guida WCAG sono risorse solide; per il controllo operativo, axe DevTools e Lighthouse possono evidenziare problemi comuni.

• Verifica contrasto tra testo e sfondo.
• Non rimuovere il focus visibile dagli elementi interattivi.
• Usa una gerarchia heading coerente.
• Evita testi dentro immagini quando il contenuto deve essere letto o indicizzato.
• Controlla menu, modali e form con tastiera.

Risorsa autorevole: MDN Web Docs resta uno dei riferimenti piu affidabili per HTML, CSS e JavaScript, inclusi media queries, custom properties e semantica.

Quando usare un page builder e quando evitarlo

Page builder come Elementor, Bricks o altri strumenti visuali possono essere utili quando il cliente ha bisogno di autonomia immediata e il progetto richiede molte landing page modificabili. Ma per un tema su misura, soprattutto se deve durare, conviene valutare con attenzione peso, lock-in e manutenzione.

La domanda pratica e semplice: il builder risolve un problema reale o sta sostituendo una progettazione debole? Se ogni pagina richiede decine di widget, CSS personalizzato e override, forse e meglio costruire pattern Gutenberg ben progettati. Se invece il sito vive di campagne, test rapidi e pagine commerciali, un builder puo avere senso.

Checklist pratica prima di consegnare un tema

• Il design system e documentato: colori, tipografia, spacing, bottoni e componenti principali.
• theme.json contiene palette, font size, layout width e impostazioni coerenti.
• I template principali sono testati: home, articolo, pagina, archivio, categoria, search e 404.
• I pattern sono riutilizzabili con contenuti reali.
• Il tema e testato su mobile, tablet e desktop.
• Le immagini hanno dimensioni corrette e attributi alt sensati.
• Lighthouse non segnala problemi gravi di performance o accessibilita.
• Il cliente puo modificare cio che deve modificare, ma non puo rompere facilmente il layout.

Conclusione

Gli strumenti migliori per il web design di temi WordPress non sono quelli piu alla moda, ma quelli che rendono il progetto piu chiaro, veloce da mantenere e coerente nel tempo. Figma aiuta a progettare il sistema, WordPress Theme Handbook e theme.json danno struttura tecnica, WP-CLI e ambienti locali rendono il lavoro controllabile, mentre Lighthouse, PageSpeed Insights e strumenti di accessibilita verificano se il tema funziona davvero.

Nel 2026 un tema WordPress efficace deve essere pensato come un prodotto editoriale e tecnico insieme. Deve essere bello, certo, ma anche governabile, accessibile, veloce e pronto per contenuti reali. La combinazione giusta di strumenti serve proprio a questo: trasformare il design in un sistema WordPress solido, non in una semplice pagina ben impaginata.