Come creare un tema WordPress custom partendo da uno starter theme

Partire da uno starter theme è una scorciatoia onesta: ti risparmia il boilerplate, non la comprensione. Ottieni una struttura di file già impostata secondo le convenzioni di WordPress, e da lì costruisci quello che serve al progetto. È un approccio diverso dal partire dalla cartella vuota, e diverso dall’adattare un tema commerciale pieno di funzioni che non userai — una strada che ha senso più spesso di quanto pensino gli sviluppatori, e che ha criteri suoi per non sbagliarla.

Questa guida spiega quali starter theme sono ancora mantenuti oggi, come si installano, e dove finisce il lavoro dello starter theme e comincia il tuo. Le fonti — repository ufficiali e documentazione dei progetti — sono state verificate il 31 agosto 2026.

Cos’è uno starter theme e perché usarlo

Uno starter theme è un tema WordPress ridotto all’essenziale, pensato per essere il punto di partenza di un tema su misura. Non porta con sé un design, un pannello di opzioni nel backend o effetti grafici. Porta:

• una struttura di file e cartelle già organizzata secondo le convenzioni di WordPress;
• i template principali già scritti nella forma minima corretta;
• il supporto agli hook e alle funzioni standard, registrato dove ci si aspetta di trovarlo;
• un CSS minimo o assente, per non dover disfare le scelte di qualcun altro.

Il vantaggio reale è il tempo che non spendi a riscrivere codice identico in ogni progetto. Il limite è che quella struttura resta una scatola nera finché non la apri: prima o poi ogni file va capito, perché è lì che intervieni quando qualcosa non si comporta come vorresti. Se preferisci il percorso opposto — costruire il tema da zero, file per file, senza ereditare le convenzioni di nessuno — la guida in quattro parti parte dalla cartella vuota e arriva al tema distribuibile.

Starter theme, block theme o tema classico: dove ti porta ciascuna strada

Prima di scegliere quale starter theme, conviene decidere che tipo di tema stai costruendo. È la domanda che negli ultimi anni ha cambiato il panorama, e ignorarla porta a scegliere una base che poi combatte contro il progetto.

Un tema classico è fatto di file PHP: header.php, single.php, archive.php, la gerarchia dei template. Il controllo è totale e il modello mentale è quello di sempre. Tutti gli starter theme di cui parla questa guida producono temi classici, con un grado variabile di apertura verso l’editor a blocchi.

Un block theme definisce layout e stili attraverso theme.json e i template HTML dei blocchi, ed è quello che abilita il Full Site Editing: chi gestisce il sito modifica header, footer e archivi dall’editor, senza toccare PHP. Qui non serve uno starter theme di terze parti: il plugin ufficiale Create Block Theme, mantenuto da WordPress.org, crea un tema vuoto, ne deriva uno dal tema attivo o genera un child theme, e salva nel file system le modifiche fatte nell’editor.

Il criterio pratico: se il sito lo gestirà una redazione che deve poter cambiare il layout senza di te, guarda ai block theme. Se il progetto ha logica applicativa, integrazioni, query fuori standard e un solo sviluppatore che ci mette le mani, un tema classico partito da uno starter theme resta la strada più diretta. E le due cose non si escludono: un tema classico può adottare theme.json e gli stili globali senza diventare un block theme.

Gli starter theme ancora mantenuti, e uno che non lo è più

Un progetto di questo tipo va giudicato su una cosa prima di tutte le altre: se è vivo. Uno starter theme abbandonato ti consegna convenzioni ferme all’anno in cui è stato lasciato, e sarai tu a pagarne il conto a ogni release di WordPress. Le date che seguono sono quelle dei repository ufficiali al 31 agosto 2026.

WP Rig

WP Rig è nato attorno a due obiettivi dichiarati: performance e accessibilità. I template usano markup semantico e sono impostati per rispettare le linee guida WCAG senza doverle rincorrere dopo; il build system integrato gestisce linting, ES6 e ottimizzazione degli asset.

È il progetto con la manutenzione più regolare dei tre: la versione 3.4.2 è del 4 agosto 2026. Se lavori su progetti pubblici, scolastici o sanitari, dove l’accessibilità è un requisito contrattuale e non un auspicio, è la base che ti fa partire più avanti.

Sage di Roots

Sage è l’opzione per chi arriva da un background di sviluppo strutturato. Usa Blade — il motore di template di Laravel — per separare la logica dalla presentazione, e un’organizzazione dei file di tipo MVC. Composer gestisce le dipendenze PHP, e Acorn porta dentro WordPress una parte dei servizi di Laravel.

La versione 11 ha modernizzato la toolchain: la compilazione degli asset è affidata a Vite, con Tailwind CSS integrato e la configurazione riflessa in theme.json. È la scelta giusta per progetti grandi o per team che lavorano sullo stesso tema; è sovradimensionata per un sito vetrina, dove la curva di apprendimento non si ripaga.

Air-light

Air-light è sviluppato dall’agenzia finlandese Digitoimisto Dude e ha un obiettivo dichiarato in una riga: nessuna dipendenza, meno di 20 kB, pronto per la produzione. Usa SASS e Parcel come build tool, richiede PHP 8.3 o superiore, ed è documentato bene. La release 10.2.0 è del 23 giugno 2026.

Il progetto nasce insieme a Dudestack, l’ambiente di sviluppo della stessa agenzia, a sua volta ispirato a Bedrock di Roots: se adotti Air-light senza Dudestack funziona comunque, ma perdi la parte di workflow per cui è stato pensato.

_Underscores (_s): archiviato, e conviene saperlo

Per anni _Underscores è stato lo starter theme di riferimento: sviluppato da Automattic, minimale, commentato riga per riga, la base didattica su cui in molti hanno imparato come è fatto un tema WordPress.

Il 5 settembre 2025 Automattic ha archiviato il repository, che da allora è in sola lettura. La motivazione è nel README: essendo ormai orientati ai block theme, non aggiorneranno più _s, e rimandano alla documentazione sui block theme di Themeshaper. Attenzione a un dettaglio che inganna: underscores.me è ancora online e il generatore funziona ancora. Il sito non dice nulla dell’archiviazione — la si vede solo sul repository.

Il codice che genera non è diventato sbagliato da un giorno all’altro, e per studiare la struttura di un tema classico resta leggibile come prima. Ma su un progetto che dovrà vivere qualche anno stai partendo da una base che nessuno aggiornerà: le convenzioni introdotte dalle versioni successive di WordPress dovrai portarle tu, una per una.

Come scegliere, in pratica

Tre domande, in quest’ordine. Il progetto ha vincoli di accessibilità? WP Rig. Ci lavora un team con pratiche di sviluppo strutturate, o servono Blade e Composer? Sage. Serve la base più leggera possibile, con il minimo di dipendenze? Air-light. Se nessuna delle tre domande ha risposta netta, il segnale è che lo starter theme non ti serve: valuta il percorso da zero, dove non erediti convenzioni che dovrai comunque studiare.

Un criterio che vale più di qualunque classifica: prima di adottare uno starter theme, apri il suo repository e guarda la data dell’ultimo commit. È l’informazione che invecchia per prima e che nessun articolo può tenere aggiornata al posto tuo.

Come installare uno starter theme

Il procedimento cambia a seconda che il tema si scarichi come archivio o si generi con Composer. Do per scontato che tu abbia già un ambiente locale funzionante: se non ce l’hai, la prima parte della guida da zero elenca cosa installare prima di cominciare.

Installazione classica

1. Scarica lo starter theme dal sito o dal repository ufficiale del progetto.
2. Estrai l’archivio dentro /wp-content/themes/.
3. Rinomina la cartella con il nome del tuo tema e aggiorna l’intestazione di style.css con i metadati corretti: Theme Name, Text Domain e Version sono quelli che WordPress legge davvero.
4. Attiva il tema da Aspetto → Temi.

Il passaggio che si salta più spesso è il terzo. Se lasci il Text Domain dello starter theme, le stringhe del tuo tema continueranno a cercare le traduzioni con il nome sbagliato, e il problema salterà fuori solo quando servirà una seconda lingua.

Vale la pena fare la rinomina completa subito, non solo nell’intestazione: il prefisso delle funzioni, il text domain nelle stringhe traducibili e i nomi degli handle passati a wp_enqueue_style() e wp_enqueue_script(). Sono tre sostituzioni su tutto il progetto, e farle il primo giorno costa dieci minuti; farle a tema finito significa rileggere ogni file.

Installazione con Sage

composer create-project roots/sage nome-tema
cd nome-tema
npm install
npm run build

Il primo comando crea il progetto e installa già le dipendenze PHP: non serve lanciare composer install subito dopo. I due comandi npm installano la toolchain e producono gli asset compilati; da qui in avanti il ciclo di sviluppo passa da Vite.

Personalizzare la struttura del tema

Installato il tema, il lavoro vero comincia. Qualunque starter theme tu abbia scelto, i file su cui metterai le mani per primi sono sempre gli stessi:

• style.css — l’intestazione con cui WordPress riconosce il tema, e in molti starter theme anche il punto di ingresso degli stili.
• functions.php — dove si registrano script, menu, supporti del tema, custom post type.
• header.php, footer.php, sidebar.php — le sezioni fisse del layout. Lo starter theme te li consegna già scritti, ma restano i file che modificherai di più: vale la pena sapere cosa contengono davvero header, footer e sidebar e come si incastrano fra loro.
• index.php, page.php, single.php, archive.php — i template delle diverse tipologie di contenuto. Prima di riscriverli conviene capire come WordPress sceglie quale di questi caricare.
• /assets/ o /resources/ — SCSS, JavaScript, immagini e file statici, a seconda delle convenzioni del progetto.

La regola che tiene in piedi il tema mentre cresce è tenere separate le tre cose: la logica in PHP, la presentazione nei template, lo stile nei fogli SCSS. Gli starter theme sono impostati per rendertelo facile; è mescolarle che richiede uno sforzo.

Gli errori tipici di chi parte da uno starter theme

Sono quasi sempre gli stessi quattro, e nascono tutti dallo stesso equivoco: trattare la base ereditata come se fosse già il tuo tema.

• Rinominare a metà. Cambi il nome della cartella e il Theme Name, ma lasci il prefisso originale su funzioni, hook e text domain. Il tema funziona, finché non installi un secondo tema derivato dalla stessa base sullo stesso sito e le funzioni collidono. Rinomina tutto in un passaggio solo, con una sostituzione sull’intero progetto, prima di scrivere la prima riga tua.
• Aggiornare lo starter theme. Non si aggiorna: nel momento in cui lo hai rinominato è diventato codice tuo. Se esce una versione nuova con qualcosa che ti interessa, si legge il changelog e si porta a mano la modifica.
• Tenere quello che non si usa. Ogni starter theme porta funzioni di esempio, commenti didascalici e file di cortesia. Se dopo un mese non li hai toccati, toglili: il codice che nessuno ha deciso di tenere è quello che nessuno saprà spiegare fra un anno.
• Non leggere il package.json. I comandi di build cambiano da progetto a progetto e fra una versione e l’altra dello stesso progetto. La risposta è in quel file, non nel primo risultato di una ricerca.

Integrare funzioni personalizzate

Il vantaggio di una base minimale è che aggiungi soltanto quello che serve. Un functions.php di partenza dichiara i supporti del tema e registra i menu:

add_theme_support( 'post-thumbnails' );
add_theme_support( 'title-tag' );
add_theme_support( 'html5', array( 'search-form', 'comment-form', 'gallery', 'caption' ) );

function nometema_register_menus() {
    register_nav_menus( array(
        'main-menu'   => __( 'Menu principale', 'nometema' ),
        'footer-menu' => __( 'Menu footer', 'nometema' ),
    ) );
}
add_action( 'after_setup_theme', 'nometema_register_menus' );

Due dettagli che fanno la differenza. I menu vanno registrati su after_setup_theme, non su init: è l’hook previsto per le funzioni di configurazione del tema, e arriva al momento giusto del caricamento. E il secondo argomento di __() è il text domain: senza, la stringa non viene raccolta dagli strumenti di traduzione.

Da qui in avanti lo stesso file può ospitare custom post type registrati con register_post_type(), aree widget, shortcode, opzioni del Customizer e il supporto ai blocchi. Quando comincia a superare il centinaio di righe, spezzalo in file tematici dentro una cartella /inc/ e includili da functions.php: è la differenza fra un tema che si mantiene e uno che si consulta con la ricerca.

La toolchain di uno starter theme moderno

Ogni starter theme porta con sé un sistema di build, ed è la parte che cambia più spesso fra una versione e l’altra. Al momento in cui scrivo, Sage 11 usa Vite, Air-light usa Parcel, WP Rig ha il suo build system basato su npm. Non è una scelta che fai tu: la erediti dal progetto, e conviene sapere cosa stai ereditando.

• Il bundler (Vite, Parcel, o quello che il progetto adotta) compila SCSS e JavaScript, minifica e gestisce il ricaricamento durante lo sviluppo. I bundler moderni includono l’hot module replacement, che aggiorna il browser senza ricaricare la pagina.
• npm gestisce le dipendenze front-end. Il file package.json del tema dice quali comandi sono disponibili: leggilo prima di cercare online il comando giusto.
• ESLint e Stylelint analizzano il codice mentre lo scrivi e tengono coerente lo stile in un team.
• Blade, in Sage, separa i template dalla logica con una sintassi più leggibile del PHP intercalato all’HTML.

Una raccomandazione che vale per tutti: non committare la cartella degli asset compilati insieme al sorgente senza aver deciso quale delle due è la verità. È la causa più comune dei conflitti quando in due lavorate sullo stesso tema.

Versionamento e buone pratiche

Metti il tema sotto Git dal primo commit, non dal primo problema. Un .gitignore che escluda node_modules/, vendor/ e gli asset generati tiene il repository leggibile.

Sul rapporto con il tema di partenza c’è un equivoco da chiarire. Uno starter theme non è un tema parent: lo scarichi, lo rinomini e da quel momento il codice è tuo, quindi lo modifichi direttamente. Il child theme è un’altra cosa e serve in un altro caso — quando estendi un tema di terze parti che continuerà a ricevere aggiornamenti. Fare un child theme del proprio starter theme aggiunge un livello di indirezione senza dare nulla in cambio.

Infine, un README.md nel repository con i comandi di build, i requisiti di versione e le istruzioni di deploy: sono le tre cose che nessuno ricorda a distanza di sei mesi, compreso chi le ha scritte.

Dove finisce questa guida e comincia il resto

Lo starter theme ti ha portato fino a un tema funzionante e personalizzato. Restano due passaggi, e per entrambi c’è una guida dedicata: rendere i template solidi dal punto di vista di SEO, performance e accessibilità, e preparare il tema alla consegna, fra validazione, traduzioni e checklist prima del rilascio.

Domande frequenti

In sintesi

Partire da uno starter theme ha senso quando il progetto giustifica un tema su misura ma non l’apprendimento della struttura di WordPress da zero. Nel 2026 le basi ancora mantenute sono tre — WP Rig per l’accessibilità, Sage per i progetti strutturati, Air-light per la leggerezza — e la prima verifica da fare su qualunque candidato è la data dell’ultimo commit.

Nota sulle correzioni. Una versione precedente di questo articolo indicava _Underscores come starter theme attivo: Automattic ha archiviato il repository il 5 settembre 2025. Descriveva inoltre Sage come basato su Laravel Mix e Browsersync, mentre dalla versione 11 usa Vite; attribuiva ad Air-light un’integrazione con Trellis e Bedrock, mentre il progetto nasce insieme a Dudestack; e chiamava «Local by Flywheel» lo strumento che oggi si chiama Local by WP Engine. Tutte le fonti sono state verificate il 31 agosto 2026.

Hai bisogno di un tema WordPress su misura?

Sviluppo temi WordPress personalizzati, partendo dalla base più adatta al progetto invece che da quella di moda. Contattami e ne parliamo.