Come scegliere un tema WordPress professionale: 6 criteri e la verifica in mezz’ora

Un tema WordPress si sceglie una volta e si tiene per anni. È la decisione che costa meno tempo prendere e più tempo disfare: cambiare tema a sito avviato significa rifare i template, ricontrollare ogni pagina e spesso riscrivere il CSS che nel frattempo si è stratificato. Vale la pena spenderci mezz’ora in più prima.

Questa guida non è una classifica. Le classifiche invecchiano nel giro di un anno, e un tema ottimo per un blog personale è la scelta sbagliata per un e-commerce con tremila prodotti. Quello che invecchia meno sono i criteri: cosa guardare, in che ordine, e come verificarlo da soli invece di fidarsi della scheda prodotto. I cinque temi che trovi più avanti sono esempi di come si applicano i criteri, con i dati di manutenzione accanto e la data in cui li ho letti.

Una nota sulle fonti. Le versioni dei temi, le date di aggiornamento, i requisiti di WordPress e gli standard di accessibilità citati qui li ho verificati uno per uno il 31 agosto 2026 su fonte ufficiale: il repository di WordPress.org, la documentazione di Google e le specifiche del W3C. Sono dati che si muovono: ogni affermazione ha accanto il link alla fonte, e se stai leggendo molto dopo quella data conviene aprirlo.

Una versione precedente di questo articolo consigliava di misurare il FID (First Input Delay), che Google ha sostituito con INP il 12 marzo 2024; indicava Twenty Twenty-Four come tema predefinito di WordPress, quando dalla 6.7 del novembre 2024 il predefinito è Twenty Twenty-Five; suggeriva il Mobile-Friendly Test di Google, ritirato il 1º dicembre 2023; e citava un comando wp theme validate che in WP-CLI non è mai esistito. Tutti e quattro i punti sono corretti qui sotto.

Cosa dipende dal tema, e cosa no

Prima dei criteri serve il confine, perché metà delle delusioni con un tema nasce dall’avergli chiesto una cosa che non è sua. Un tema WordPress governa l’aspetto e la struttura delle pagine: quali template esistono, come sono composti, che markup producono, quali stili e script vengono caricati. Non governa i contenuti, che stanno nel database, né le funzionalità, che stanno nei plugin. Il nome del sito è uno di quei contenuti, ed è il motivo per cui certe modifiche all’header non si ottengono cambiando tema.

La conseguenza pratica è una regola sola, e regge da vent’anni: tutto ciò che deve sopravvivere al cambio di tema va in un plugin. Un tema che registra i suoi custom post type, i suoi shortcode o il suo tracciamento analytics ti sta legando le mani: il giorno che lo disattivi, il sito perde pezzi di contenuto, non solo di aspetto. È il primo motivo per cui un tema “tutto incluso” costa più di quanto sembri, e non si vede nella demo.

Vale anche al contrario. La velocità di un sito non dipende solo dal tema: dipende dall’hosting, dalle immagini, dai plugin e dalla cache almeno quanto dal tema. Un tema leggero su un hosting lento resta lento. Se stai partendo da un sito che va piano, prima di dare la colpa al tema conviene passare dalle sei cause reali di un sito lento: il tema è una di quelle, ma raramente è la prima.

I sei criteri che contano

In ordine di quanto costa scoprire troppo tardi di aver sbagliato.

1. Chi lo mantiene, e da quanto

È il criterio che nessuno guarda per primo ed è quello che decide se fra tre anni il sito sarà ancora aggiornabile. Un tema abbandonato non smette di funzionare il giorno dopo: smette di essere compatibile un pezzo alla volta, e te ne accorgi quando WordPress cambia qualcosa e l’editor si rompe.

Sulla pagina di un tema nel repository di WordPress.org ci sono tre numeri che rispondono da soli: data dell’ultimo aggiornamento, installazioni attive e “testato fino a”. Il criterio ragionevole: ultimo aggiornamento entro sei mesi, e “testato fino a” che nomini l’ultima o la penultima versione di WordPress. Se un tema è fermo da più di un anno, non importa quanto è bello.

Per i temi premium venduti fuori dal repository il numero non c’è, e va cercato nel changelog pubblico. Se un tema a pagamento non pubblica un changelog con le date, quello è già l’informazione che cercavi.

C’è un segnale in più, meno immediato ma difficile da simulare: dove si vede chi sviluppa quel tema. Il changelog pubblico, il repository, le risposte nei forum di supporto di WordPress.org e — per i progetti più solidi — la presenza agli eventi ufficiali della community WordPress, dove gli autori dei temi più diffusi tengono sessioni e siedono ai tavoli del Contributor Day. Un tema i cui autori non sono rintracciabili da nessuna parte resta un rischio anche quando i tre numeri della scheda sono a posto.

2. Cosa succede se lo togli

Il test mentale è brutale ma veloce: se domani disattivo questo tema, cosa resta del sito? Se la risposta è “i contenuti, che poi riformatto”, il tema è onesto. Se è “perdo le schede prodotto, i box team e metà delle pagine costruite con i blocchi proprietari”, stai comprando un lock-in.

Il segnale più affidabile sono gli shortcode proprietari. Un tema che ti fa scrivere [nome_tema_pricing] dentro i contenuti ha messo la sua sintassi nel tuo database: disattivandolo, quelle stringhe restano visibili nel testo. I blocchi personalizzati sono meno gravi ma vanno nella stessa direzione. La forma pulita, quando un tema porta funzioni sue, è che siano in un plugin companion separato — così il tema si cambia e le funzioni restano.

3. Come si integra con l’editor a blocchi

Oggi i temi si dividono in due famiglie, e la differenza non è estetica: cambia chi può modificare cosa.

• Temi a blocchi (o FSE, Full Site Editing): header, footer, archivi, 404 e ogni altro template si modificano dall’editor del sito, senza toccare PHP. Si riconoscono dalla presenza delle cartelle /templates/ e /parts/ e di un file theme.json che centralizza colori, tipografia e spaziature.
• Temi classici: i template sono file PHP, la personalizzazione passa dal Customizer e dal codice. Non sono obsoleti — molti dei temi più diffusi lo sono ancora — ma il lavoro di modifica richiede uno sviluppatore.

La domanda giusta non è “quale delle due è meglio”, è chi metterà mano al sito. Se il sito lo aggiornerà una persona non tecnica, un tema a blocchi le dà autonomia su cose che altrimenti costano una chiamata. Se il sito lo gestisci tu e hai già una pipeline di sviluppo, un tema classico ben scritto non ti toglie niente.

Attenzione a una terza categoria, quella che genera i problemi: i temi costruiti attorno a un page builder. Funzionano, ma il layout finisce nel builder, e a quel punto la scelta vera che hai fatto non è il tema — è il builder, che è molto più difficile da abbandonare.

4. Quanto pesa davvero

I numeri dichiarati nelle schede prodotto (“meno di 10 KB!”) non sono verificabili e cambiano da una versione all’altra: sono materiale di marketing, non un criterio. Quello che si misura è cosa carica una pagina reale, e si misura in due minuti sulla demo del tema.

Apri la demo, premi F12, scheda Network, ricarica e ordina per tipo. Quello che guardi:

• Quanti file CSS e JS arrivano dal tema su una pagina semplice. Più di tre o quattro caricati ovunque è un tema che non fa caricamento condizionale.
• Se c’è jQuery, e chi lo chiede. WordPress non lo carica più da solo sul frontend: se c’è, l’ha aggiunto il tema o un plugin.
• Quanti font esterni. Ogni famiglia tipografica caricata da un dominio terzo è una connessione in più prima che il testo compaia, ed è anche una questione di privacy.
• Il peso totale della pagina. Una pagina di contenuto sotto il megabyte è un buon punto di partenza; se la demo — che è la vetrina, curata apposta — ne pesa tre, il tuo sito peserà di più.

5. Se è accessibile davvero

L’accessibilità è il criterio dove la distanza fra quello che un tema dichiara e quello che fa è più ampia, perché “accessibile” non è un’etichetta protetta e nessuno controlla chi se la mette. C’è una sezione dedicata più avanti; qui basta il filtro veloce: nel repository di WordPress.org esiste il tag accessibility-ready, che si ottiene superando una revisione manuale del Theme Review Team. Non garantisce che il sito finito sia accessibile — quello dipende anche da come lo riempi — ma è l’unico segnale verificato da qualcuno che non sia chi vende il tema.

6. Che codice produce

Serve saper leggere un po’ di PHP, ma bastano tre controlli. Scaricato il tema, cerca nei file:

• Come vengono caricati stili e script. Devono passare da wp_enqueue_style() e wp_enqueue_script(). Tag <link> e <script> scritti a mano dentro header.php sono il segnale che il tema ignora le convenzioni di WordPress, e da lì in giù di solito ne ignora altre.
• Come viene stampato l’input. Ogni valore che finisce nell’HTML dovrebbe passare da esc_html(), esc_attr(), esc_url() o wp_kses(). Una echo $_GET[...] senza escape è una vulnerabilità, non una svista di stile.
• Come si parla col database. Query dirette con $wpdb->query() senza $wpdb->prepare() sono il modo classico di aprire una SQL injection. In un tema, query dirette al database dovrebbero essere rare in partenza.

Se non vuoi leggere il codice a mano, il plugin Theme Check esegue automaticamente le stesse verifiche che il repository fa sui temi in revisione: si installa, si attiva, e da Strumenti → Theme Check analizza il tema attivo. Non sostituisce la lettura, ma le violazioni grosse le trova tutte.

Gratuito o premium: la domanda è mal posta

La differenza che conta non è fra gratuito e a pagamento — quasi tutti i temi seri sono freemium, cioè gratuiti nel repository e a pagamento per le funzioni avanzate. La differenza che conta è chi c’è dietro e cosa succede se smette.

Un tema nel repository di WordPress.org ha superato una revisione su sicurezza e conformità, è distribuito sotto licenza GPL e resta scaricabile anche se l’autore sparisce. Un tema comprato su un marketplace ha in più il supporto e gli aggiornamenti — finché l’autore li fornisce. Su un marketplace generalista la qualità varia enormemente da un autore all’altro: il numero di vendite dice quanto è popolare, non quanto è ben scritto.

Tre cose da controllare prima di pagare, che valgono più della lista delle funzionalità:

• Che tipo di licenza è. Annuale con aggiornamenti che si fermano alla scadenza, o “lifetime”? Nel primo caso, il costo reale è quello ricorrente. Il codice resta tuo in ogni caso — è GPL — ma senza aggiornamenti diventa un problema di sicurezza.
• Da quando esiste. Un autore con cinque anni di changelog pubblico è un rischio diverso da uno arrivato l’anno scorso.
• Cosa dicono le richieste di supporto recenti, non le recensioni. Le recensioni le lascia chi ha appena comprato; i ticket li apre chi usa il tema da un anno.

Sui temi “nulled”, cioè le versioni premium ridistribuite gratis con la licenza rimossa, non c’è molto da discutere: sono il vettore di infezione più banale che esista, e il codice aggiunto si trova regolarmente nelle analisi post-compromissione. Se ti interessa come si entra in un sito WordPress passando da un componente di terze parti, ne ho scritto in come funziona un attacco alla catena di fornitura.

Prestazioni: le metriche giuste, e quella che non esiste più

Se cerchi materiale sulla scelta di un tema trovi ancora, in quantità, riferimenti a tre metriche: LCP, FID e CLS. Una delle tre non esiste più. Google ha sostituito il FID (First Input Delay) con l’INP (Interaction to Next Paint) il 12 marzo 2024, e dal 9 settembre 2024 gli strumenti Chrome hanno smesso di restituire il FID. Non è un cambio di nome: il FID misurava solo il ritardo della prima interazione, l’INP misura la reattività di tutte le interazioni della visita, ed è molto più severo.

Le tre metriche attuali, e cosa c’entra il tema con ciascuna:

Il CLS è quello su cui il tema ha la responsabilità più diretta e più facile da verificare: se il layout balla mentre la demo carica, non ballerà di meno sul tuo sito. Le due cause tipiche sono immagini senza width e height dichiarati e font caricati senza font-display: swap.

Per misurare, tre strumenti bastano: PageSpeed Insights per il quadro d’insieme con i dati di campo, Lighthouse — che è integrato in Chrome DevTools, scheda Lighthouse, e non richiede di installare nulla — per i test ripetuti mentre lavori, e WebPageTest quando serve capire l’ordine di caricamento delle risorse. Un avvertimento che vale per tutti e tre: testa la demo interna del tema, non la sua homepage di vendita, che è ottimizzata a parte e non dice niente sul tema.

Il Mobile-Friendly Test di Google, che compare ancora in molte checklist, è stato ritirato il 1º dicembre 2023 insieme al report Usabilità sui dispositivi mobili di Search Console e alla relativa API: la sua vecchia pagina di supporto oggi reindirizza alla documentazione di Lighthouse, che è il sostituto indicato da Google. Attenzione anche a quello che si trova cercandolo: nel Chrome Web Store esistono estensioni di terze parti con lo stesso nome, che non sono uno strumento Google.

Sul resto — cache, lazy loading, minificazione — il tema fa la sua parte ma il grosso si fa a valle: se vuoi il quadro completo, l’ho messo in lazy loading, caching e minificazione.

Accessibilità: lo standard di riferimento è WCAG 2.2

Il riferimento corrente sono le WCAG 2.2, Raccomandazione del W3C nella versione del 12 dicembre 2024. Non mandano in pensione le 2.1 — il W3C precisa che una pagina conforme alle 2.2 è conforme almeno quanto una conforme alle 2.1 — ma aggiungono criteri, e sono quelle su cui conviene misurarsi oggi. Il livello a cui puntare è AA: è quello richiesto dalla normativa europea per i soggetti che ne sono obbligati, ed è la soglia sensata anche per chi non lo è.

Cosa deve fare il tema, in concreto:

• Struttura semantica. <header>, <nav>, <main>, <footer> al posto giusto e un solo <h1> per pagina. È anche quello che rende leggibile la pagina ai crawler, quindi il criterio paga due volte.
• Focus visibile. Navigando col tasto Tab si deve sempre vedere dove si è. L’indicatore va definito su :focus-visible e non su :focus, che lo mostrerebbe anche al clic del mouse. Un tema che azzera outline: none senza rimpiazzarlo è da scartare.
• Contrasto. Almeno 4,5:1 per il testo normale, 3:1 per il testo grande. Vale anche per i testi sopra le immagini di testata, che è dove le palette dei temi cedono più spesso.
• Dimensione dei target. Le WCAG 2.2 introducono il criterio 2.5.8 Target Size (Minimum), livello AA: 24×24 pixel CSS come minimo per gli elementi cliccabili. Per i controlli principali su mobile conviene stare più larghi, intorno ai 44-48 pixel.
• Skip link. Il link “salta al contenuto” all’inizio della pagina, visibile quando riceve il focus.

Gli strumenti automatici — WAVE, axe DevTools, Accessibility Insights — sono il primo passaggio e trovano in pochi secondi contrasti insufficienti, alt mancanti e label scollegate. Quello che non possono fare è dire se un testo alternativo descriva la cosa giusta o se l’ordine di tabulazione abbia senso: quelli sono giudizi, e la parte di WCAG che si misura da sola è la minoranza. Il modo di coprire il resto è passare le pagine campione a mano, con una checklist di audit, e il controllo singolo più redditizio è provare a usare il sito con la sola tastiera: dieci minuti, e ti dice più di qualsiasi punteggio.

Sul responsive, invece, non c’è più molto da decidere: l’indicizzazione di Google avviene sulla versione mobile della pagina per tutti i siti, e un tema che non sia mobile-first oggi semplicemente non esiste in commercio. Quello che resta da verificare a mano è la leggibilità — corpo del testo, interlinea, larghezza della riga sullo schermo piccolo — e il comportamento del menu, che è il punto in cui i temi si differenziano ancora parecchio.

La verifica in mezz’ora, prima di installare

Sette passaggi in ordine. I primi tre si fanno sulla demo pubblica, senza installare niente; gli altri quattro in un ambiente di staging. Se un tema cade ai primi tre, gli altri quattro te li risparmi.

1. Leggi la scheda del repository. Ultimo aggiornamento, installazioni attive, “testato fino a”, presenza del tag accessibility-ready. Trenta secondi, e scarta più candidati di qualsiasi altro passaggio.
2. Apri la demo con DevTools sulla scheda Network. Conta i file CSS e JS del tema, cerca jQuery, guarda i font esterni e il peso totale. Fallo su una pagina di contenuto interna, non sulla home della demo.
3. Naviga la demo con la sola tastiera. Tab dall’inizio: se il focus sparisce, se il menu non si apre, se non c’è lo skip link, il tema ha un problema di accessibilità che non si risolve con il CSS.
4. Installa in staging e attiva Theme Check. Le violazioni di sicurezza e di convenzione escono qui, prima che il tema tocchi il sito vero.
5. Metti dentro i tuoi contenuti veri, non i contenuti dimostrativi. I titoli lunghi, le tabelle, le immagini con proporzioni sbagliate e i post senza immagine sono esattamente i casi che le demo evitano, ed è dove i template si rompono.
6. Attiva i plugin che userai davvero — quello dei form, quello SEO, WooCommerce se serve — e guarda cosa succede all’aspetto e alla console. I conflitti di stile e di JavaScript si vedono subito.
7. Misura. PageSpeed Insights sulla pagina di staging più pesante che hai, non sulla home. Confronta con il valore che avevi prima: è l’unico numero che conta davvero.

Un’ultima cosa sulla verifica del codice, perché è l’errore più diffuso nelle guide in circolazione: WP-CLI non ha un comando che valida un tema. I sottocomandi di wp theme servono a installare, attivare, aggiornare ed elencare; non esiste un wp theme validate. La validazione si fa con il plugin Theme Check, oppure — per chi ha una pipeline — con WordPress Coding Standards su PHP_CodeSniffer.

Cinque temi, con i numeri della manutenzione

Non è una classifica: sono cinque temi che superano i criteri di sopra, messi in fila con i dati che quei criteri chiedono di guardare. La colonna che conta di più è l’ultima.

Le differenze che orientano la scelta, in una riga ciascuna:

• GeneratePress è il più essenziale dei cinque e il più adatto a chi scrive anche il CSS: poca superficie, poche sorprese. È anche l’unico della lista fermo da più di sei mesi — non è abbandonato, ma è il dato da rivedere.
• Kadence ha l’insieme più completo per e-commerce e siti a contenuti, con builder di header e footer. Da sapere: il progetto è passato sotto Nexcess (gruppo Liquid Web) e il vecchio dominio kadencewp.com oggi reindirizza alle pagine di Liquid Web.
• Blocksy è quello con il lavoro più recente sull’editor a blocchi ed è aggiornato con la frequenza più alta dei cinque.
• Astra è il più diffuso in assoluto e il più documentato, con il maggior numero di starter site pronti; è anche quello che dichiara i requisiti più bassi, il che significa molto codice di compatibilità con installazioni vecchie.
• Neve è il più leggero da configurare per siti piccoli, blog e landing page, con meno opzioni da attraversare.

Fuori dalla lista ma da tenere presente: Twenty Twenty-Five, il tema predefinito di WordPress, arrivato con la versione 6.7 del novembre 2024. È a blocchi, è mantenuto dal progetto stesso e per un sito di contenuti fa il suo lavoro senza aggiungere niente. Vale la pena provarlo prima di comprare qualcosa: il tema predefinito è la base di confronto, ed è già installato.

Quando conviene non sceglierlo

Ci sono due casi in cui la scelta giusta non è un tema di terze parti.

Il primo è quando il tema che ti serve esiste già ma va modificato. Modificarne i file direttamente significa perdere le modifiche al primo aggiornamento: la forma corretta è un child theme, che eredita tutto dal tema padre e sovrascrive solo quello che serve. È mezz’ora di lavoro e risolve il problema una volta sola.

Il secondo è quando il progetto durerà anni, il markup e il peso sono requisiti scritti e non desideri, e ogni tema che provi va bene al 70%. Lì costruirne uno da zero smette di essere un lusso e diventa la strada meno costosa — a patto di sapere che il costo non è scriverlo, è mantenerlo. Una via di mezzo praticabile è partire da uno starter theme, che ti dà la struttura corretta senza gli stili di qualcun altro da smontare.
Sopra a tutto questo c’è un’ultima possibilità, che però non è più una scelta di tema ma di architettura: rinunciare del tutto al tema e far disegnare le pagine a un’applicazione separata. Ha senso solo con requisiti precisi, e raddoppia la manutenzione.

C’è poi la strada opposta, quella di non scegliere affatto e lasciare che sia un generatore automatico a produrre il sito: è veloce, ed è ragionevole per un sito piccolo che deve solo esistere. Cosa ci si guadagna e cosa ci si perde l’ho misurato sull’AI Website Builder di WordPress.com.

Domande frequenti

Vuoi un parere sul tema del tuo sito?

Sono Alessandro Aili, sviluppatore WordPress. Se stai scegliendo fra due o tre candidati, o se hai un tema che ti sta dando problemi di prestazioni o di accessibilità, posso guardarlo con te e dirti cosa costa tenerlo e cosa costa cambiarlo. Scrivimi dalla pagina contatti.