Custom post type e tassonomie in WordPress: guida aggiornata al 2026

Questo articolo è stato pubblicato per la prima volta nel 2010 e completamente riscritto a ottobre 2026: i commenti più vecchi si riferiscono alla versione originale.

Nell’agosto del 2010 WordPress 3.0 era appena uscito e io, reduce dal WordCamp di Milano, scrivevo con l’entusiasmo del neofita un articolo pieno di plugin e di snippet copiati dal Codex per usare «bene» i custom post type, che allora sembravano la chiave per trasformare un motore di blog in un CMS vero. Alcuni di quei plugin oggi sono chiusi da anni, il Codex ha lasciato il posto a developer.wordpress.org e il mio modo di registrare un post type, riletto con gli occhi di oggi, farebbe sorridere anche il più indulgente dei code reviewer.

L’idea di fondo però ha retto benissimo il passare del tempo, ed è per questo che ho deciso di riscrivere l’articolo da capo: in questa versione ti racconto come si registrano oggi custom post type e tassonomie, perché show_in_rest è diventato il parametro più importante di tutti, come si gestiscono i campi personalizzati, come si costruiscono i template nel Site Editor e, soprattutto, quando conviene creare un nuovo tipo di contenuto e quando invece è meglio lasciar perdere.

Che cosa sono oggi i custom post type

Un custom post type è un tipo di contenuto che affianca articoli e pagine, con una sua schermata di amministrazione, un suo URL, un suo archivio e un suo endpoint nella REST API: se il tuo sito deve gestire eventi, corsi, prodotti di un catalogo o casi studio, invece di infilare tutto negli articoli e distinguerli con una categoria puoi dare a ciascuno di questi oggetti un’identità propria. Le tassonomie sono il secondo pezzo del puzzle, perché servono a classificare quei contenuti, gerarchicamente come le categorie o in modo libero come i tag, mentre i campi personalizzati descrivono gli attributi specifici di ogni elemento, per esempio la data di un evento o la durata di un corso.

Quello che non è cambiato dal 2010 è il modello dati sottostante: tutti i post type finiscono nella stessa tabella wp_posts, i termini delle tassonomie vivono nelle loro tabelle e i campi in wp_postmeta. Ne parlavo anche nell’articolo sulle novità di WordPress 7.0, dove facevo notare che proprio le schermate elenco dei tipi di contenuto personalizzati non sono ancora passate alle nuove DataViews e continuano a basarsi su WP_List_Table: è un dettaglio che vale la pena conoscere se scrivi plugin che aggiungono colonne o filtri a quelle schermate.

Registrare un post type nel 2026

Si registra un post type con register_post_type() sull’hook init, preferibilmente dentro un plugin e non nel functions.php del tema, perché i contenuti devono sopravvivere al giorno in cui deciderai di cambiare tema. L’esempio che segue registra un post type evento con un archivio, il supporto all’editor a blocchi e ai campi personalizzati, e un template iniziale che precompila l’editor con alcuni blocchi.

<?php
/**
 * Registra il post type "evento" e la tassonomia "citta".
 */
add_action( 'init', function () {

	register_post_type( 'evento', array(
		'labels'       => array(
			'name'          => __( 'Eventi', 'mio-plugin' ),
			'singular_name' => __( 'Evento', 'mio-plugin' ),
		),
		'public'       => true,
		'has_archive'  => true,                 // archivio su /eventi/
		'rewrite'      => array( 'slug' => 'eventi' ),
		'menu_icon'    => 'dashicons-calendar-alt',
		'show_in_rest' => true,                 // editor a blocchi e REST API
		'rest_base'    => 'eventi',             // /wp-json/wp/v2/eventi
		'supports'     => array( 'title', 'editor', 'thumbnail', 'excerpt', 'custom-fields' ),
		'template'     => array(                // stato iniziale dell'editor
			array( 'core/paragraph', array( 'placeholder' => 'Descrivi l\'evento...' ) ),
		),
	) );

	register_taxonomy( 'citta', 'evento', array(
		'label'             => __( 'Città', 'mio-plugin' ),
		'hierarchical'      => true,            // si comporta come le categorie
		'show_admin_column' => true,            // colonna nella lista degli eventi
		'show_in_rest'      => true,            // visibile nell'editor a blocchi
	) );
} );

Il parametro che fa la differenza è show_in_rest, che per impostazione predefinita vale false: la documentazione ufficiale lo dice senza giri di parole, perché senza di esso il post type non è disponibile nell’editor a blocchi e resta confinato nell’editor classico, e lo stesso vale per le tassonomie, che non compaiono nel pannello laterale dell’editor se non le esponi alla REST API. Gli altri argomenti da conoscere sono pochi ma importanti:

• supports, che per default include solo titolo ed editor e va esteso con thumbnail, excerpt, revisions o custom-fields secondo le necessità;
• has_archive e rewrite, che governano l’archivio e la struttura degli URL;
• template e template_lock, che ti permettono di guidare chi scrive con una struttura di blocchi predefinita, bloccandola del tutto con all o lasciando modificare solo i contenuti con contentOnly;
• capability_type e map_meta_cap, da toccare quando vuoi permessi dedicati, per esempio per un ruolo che gestisce solo gli eventi.

Un ultimo dettaglio che nel 2010 mi è costato qualche pomeriggio di 404 inspiegabili: quando registri un nuovo post type le regole di riscrittura degli URL vanno rigenerate, e il modo corretto è chiamare flush_rewrite_rules() una sola volta, all’attivazione del plugin, e mai a ogni caricamento di pagina.

Campi personalizzati, REST API e Block Bindings

I campi personalizzati si dichiarano con register_post_meta(), indicando tipo, unicità e visibilità nella REST API, e diventano così dati strutturati che l’editor, le app esterne e gli strumenti di automazione possono leggere e scrivere in modo affidabile. C’è un requisito che inciampa molti: per i meta registrati su un custom post type, il post type deve supportare custom-fields, altrimenti i campi non compaiono nella risposta della REST API anche se li hai registrati con show_in_rest.

<?php
add_action( 'init', function () {
	// Data dell'evento come stringa ISO, un solo valore per post
	register_post_meta( 'evento', 'data_evento', array(
		'type'         => 'string',
		'single'       => true,
		'show_in_rest' => true,
		'sanitize_callback' => 'sanitize_text_field',
		'auth_callback'     => function () {
			return current_user_can( 'edit_posts' );
		},
	) );
} );

Fatto questo, il post type risponde su /wp-json/wp/v2/eventi con titolo, contenuto, termini e campi, ed è esattamente il punto di aggancio che uso quando collego WordPress a un flusso di automazione o a un’applicazione esterna. Dalla versione 6.5 c’è poi la Block Bindings API, che permette di collegare un campo a un blocco core come paragrafo, titolo, immagine o pulsante senza scrivere un blocco personalizzato; dalla 6.7 il collegamento si può fare anche dall’interfaccia dell’editor, per impostazione predefinita solo dagli amministratori, e con la 6.9 l’esperienza è stata ulteriormente semplificata.

Un post type senza show_in_rest, nel 2026, è come un negozio con la saracinesca abbassata: c’è tutto, ma nessuno riesce a entrare.

Se non vuoi scrivere codice gli strumenti non mancano e, a differenza di quelli che citavo nel 2010, sono vivi e aggiornati: Custom Post Type UI resta il modo più rapido per creare tipi e tassonomie da interfaccia, Advanced Custom Fields dalla versione 6.1 registra anche post type e tassonomie oltre ai campi, e alternative come Secure Custom Fields, Pods o Meta Box con il suo componente gratuito per i post type coprono esigenze simili. Il mio consiglio è di usarli per prototipare e poi, quando il modello dati si è stabilizzato, esportare o riscrivere la registrazione in codice versionato.

Template dedicati nel Site Editor

Nei temi a blocchi la gerarchia dei template è la stessa dei temi classici, con la differenza che i file sono HTML invece che PHP: per il nostro esempio WordPress cerca single-evento.html per il singolo evento e archive-evento.html per l’archivio, e ricade su single.html e archive.html se non li trova. Non serve nemmeno aprire l’editor di codice, perché dal Site Editor, nella sezione Template, puoi aggiungere un nuovo template e scegliere il tipo di contenuto a cui applicarlo, costruendolo con i blocchi Query Loop, titolo, immagine in evidenza e, grazie ai Block Bindings, con i valori dei tuoi campi.

Se invece usi un tema classico o ibrido, come faccio io su questo blog con un child theme di Blocksy, i file restano single-evento.php e archive-evento.php nel child theme, e il ragionamento non cambia: il template appartiene al tema, mentre la registrazione del post type appartiene al plugin. Se ti stai chiedendo quale delle due strade sia più adatta al tuo progetto, ne parlo nell’articolo su come scegliere un tema WordPress oggi.

Quando usarli e quando no

Conviene creare un custom post type quando un contenuto ha una struttura diversa dagli articoli, un ciclo di vita proprio e un archivio che ha senso consultare da solo; non conviene quando la differenza è solo di argomento, perché in quel caso basta una categoria o una tassonomia. È la domanda che faccio sempre all’inizio di una consulenza, e la risposta onesta è spesso meno entusiasmante di quanto il cliente si aspetti.

• Sì per eventi, corsi, prodotti di un catalogo, casi studio, schede tecniche, membri di un team: oggetti con campi propri e un archivio dedicato.
• No per distinguere notizie e approfondimenti, o articoli di sezioni diverse: è un lavoro da tassonomia, e un post type in più ti costringe a duplicare template, permessi e configurazioni SEO.
• Attenzione ai post type creati dal tema: se cambi tema i contenuti restano nel database ma spariscono dall’amministrazione, e recuperarli è un lavoro noioso che puoi evitare mettendo la registrazione in un plugin fin dal primo giorno.
• Attenzione anche ai volumi: decine di migliaia di elementi con molti meta interrogati in query complesse mettono alla prova wp_postmeta, e lì conviene ragionare su indici, caching o tabelle dedicate prima che sia il server a ricordartelo.

Un’ultima nota per chi lavora con gli agenti di coding: la registrazione di post type, tassonomie e meta è proprio il tipo di codice ripetitivo e ben documentato che strumenti come Claude Code scrivono bene, a patto di dare loro un contesto preciso sul modello dati, come racconto nella guida pratica a Claude Code; la decisione su che cosa debba diventare un post type, però, resta una scelta di progettazione che non delegherei a nessuno.

Tirando le somme

I custom post type sono ancora, sedici anni dopo, uno degli strumenti più potenti di WordPress, ma il modo di usarli è cambiato parecchio: oggi si registrano in un plugin con show_in_rest attivo, si accompagnano a tassonomie e campi dichiarati in modo esplicito, si mostrano con template dedicati nel Site Editor o nel tema e si collegano al resto del mondo attraverso la REST API. Se devi approfondire, la fonte da tenere aperta è la documentazione di register_post_type() su developer.wordpress.org, insieme alle pagine sulla gerarchia dei template e sulla Block Bindings API; per il resto trovi altri spunti nella categoria WordPress di questo blog.

Se usi i custom post type in modo diverso da come l’ho raccontato, o se hai una storia di post type spariti dopo un cambio di tema, scrivila nei commenti, che qui sotto sono ancora aperti dal 2010, e se l’articolo ti è stato utile condividilo con chi sta progettando il prossimo sito. E se vuoi una mano a modellare i contenuti di un progetto reale, puoi prenotare una call conoscitiva gratuita o passare dai contatti.