Schema markup su WordPress: come implementarlo passo passo

Lo schema markup è un vocabolario condiviso che descrive il contenuto di una pagina in un formato che le macchine capiscono senza interpretarlo. Su WordPress si implementa in quattro modi: da un plugin SEO come Rank Math o Yoast, con il campo per singolo contenuto, con un blocco di codice dentro la pagina, con poche righe in functions.php, oppure nei template del tema.

Quale scegliere dipende da quante pagine devi coprire e da quanto controllo vuoi: il plugin va bene per tutto il sito, il codice scritto a mano quando il dato è specifico di quella pagina.

Questa è la guida pratica: come si sceglie il tipo giusto, come si scrive il JSON-LD, dove si mette su WordPress e come si verifica che Google lo legga. La panoramica dei tipi e delle proprietà sta nella guida su SEO avanzata, link building e schema markup: qui si parte da lì e si arriva al codice.

Cos’è lo schema markup, senza giri di parole

Lo schema markup è un vocabolario condiviso per descrivere il contenuto di una pagina in modo che una macchina lo capisca senza interpretarlo. Non è una lingua di Google: è uno standard pubblico, schema.org, nato nel 2011 e mantenuto da Google, Microsoft, Yahoo e Yandex. Tu dichiari «questo è un articolo, l’ha scritto Tizio, è stato pubblicato il 12 settembre, l’immagine è questa», e i motori smettono di indovinare.

La forma più usata oggi è JSON-LD: un blocco di testo in formato JSON dentro un tag script, separato dal resto dell’HTML. Le alternative storiche sono i microdati (attributi dentro il markup) e RDFa: funzionano ancora, ma complicano il codice e sono più difficili da manutenere. Se stai iniziando, JSON-LD è la scelta.

Una cosa da mettere subito in chiaro, perché genera aspettative sbagliate: lo schema non è un fattore di posizionamento. Non fa salire una pagina nei risultati.

Quello che fa è rendere la pagina ammissibile a un risultato arricchito: stelle, prezzo, passi numerati. E rende il contenuto più facile da citare per chi lo legge con un modello linguistico. Il vantaggio si vede nel tasso di clic e nella precisione con cui vieni capito, non nella posizione.

Come si sceglie il tipo giusto per il tuo contenuto

Article o BlogPosting? La regola in una riga

C’è un campo dove si sbaglia più spesso di quanto si creda, e riguarda proprio il tipo della pagina: `Article` è il tipo generico (qualunque contenuto: una pagina di servizio, una scheda, un approfondimento); `BlogPosting` è il sottotipo per un articolo di blog. Su un sito WordPress che pubblica articoli, la scelta corretta è quasi sempre `BlogPosting`, perché dichiara la natura editoriale della pagina e la aggancia a un autore e a una data.

Perché allora molti siti hanno `Article`? Perché è il valore che il plugin propone per impostazione predefinita, e nessuno lo cambia: si imposta una volta e si dimentica. Il rimedio è di dieci secondi: nel campo dello schema del plugin (o con lo strumento che gestisce i dati strutturati del sito) si imposta il tipo del singolo contenuto. Un valore generico non danneggia il posizionamento — non fa sparire il risultato — ma è informazione che perdi: stai dicendo «è una pagina» invece di «è un articolo con un autore e una data».

Il tipo si sceglie da quello che la pagina è, non da quello che vorresti mostrare nei risultati. Si parte dal contenuto reale e si cerca il tipo che lo descrive; se il contenuto non ha quelle caratteristiche, il tipo non si usa. È la regola che sta alla base di tutte le linee guida di Google, ed è anche quella che evita le penalizzazioni.

Prima di aprire l’editor, rispondi a tre domande: la pagina racconta qualcosa (articolo, guida, notizia), vende o recensisce un prodotto, oppure organizza un evento o un servizio locale? Da qui escono quattro famiglie, che coprono quasi tutto quello che si pubblica su un blog.

Cosa è la pagina	Tipo	Cosa può ottenere	Proprietà che contano
Articolo di blog o guida	Article o BlogPosting	Risultato con immagine grande, autore e data	headline, author, datePublished, dateModified, image
Pagina con domande e risposte	FAQPage	Nessun risultato visibile dal 2026: resta valido e utile per le macchine	mainEntity con almeno due coppie domanda/risposta
Procedura numerata	HowTo	Risultato ritirato da Google nel 2023	name, step con name e text
Recensione di prodotto	Product + Review	Prezzo e valutazione	name, offers, aggregateRating
Attività con sede fisica	LocalBusiness	Scheda con indirizzo e orari	address, telephone, openingHoursSpecification
Evento con data	Event	Data, luogo, biglietti	startDate, location, offers

Due trappole ricorrenti. La prima: una pagina, un tipo principale. Se dichiari sia Article sia Product sullo stesso URL, stai dicendo due cose diverse e il risultato è che nessuna delle due viene usata. La seconda: i tipi che Google non supporta — circa trenta nella lista ufficiale dei dati strutturati supportati — si possono scrivere. Non producono però nessun risultato arricchito: si usano solo se servono a un altro consumatore di dati.

Cosa è cambiato nel 2026: FAQ e HowTo non danno più risultati arricchiti

Se ti serve il contesto completo della regola — cosa Google mostrava prima, cosa ha ritirato e quando, e come si comporta il markup oggi — la trovi nella guida sugli errori e le strategie di schema markup, aggiornata con la stessa correzione. È lo stessa verifica, raccontata dal lato delle conseguenze pratiche.

Due tipi che trovi in tutte le guide non producono più niente di visibile: le FAQ e le procedure. Vale la pena saperlo prima di scriverli, perché il lavoro è lo stesso ma l’aspettativa è sbagliata. Google ha ritirato i risultati arricchiti delle FAQ il 7 maggio 2026, dopo averli già limitati nel 2023 ai soli siti governativi e sanitari; le HowTo erano state ritirate nel 2023.

Cosa comporta, in pratica:

• Il FAQPage resta un tipo valido: non genera errori, non è una violazione e Google continua a leggere il markup per capire la pagina. Semplicemente non mostra più il menu a tendina nei risultati.
• Lo stesso vale per HowTo: descrive una procedura reale, ma non aspettarti i passi numerati nella pagina dei risultati.
• Dal giugno 2026 il Rich Results Test non supporta più le FAQ, e il rapporto dedicato è stato tolto da Search Console: se cerchi quelle voci nei rapporti, non le trovi più.
• Quello che continua a produrre risultati arricchiti è il resto: articoli, prodotti e recensioni, eventi, attività locali, breadcrumb, video. Se il tuo obiettivo è un risultato visibile, il tempo si investe lì.

Perché allora continuare a dichiarare FAQ e procedure? Perché i dati strutturati non servono solo a decorare i risultati: servono a far capire la pagina. Una sezione di domande marcata come FAQPage dice a chi legge la pagina con un modello che quelle sono domande con risposte. E gli dice qual è la risposta esatta a ognuna.

È la stessa informazione che serve a un assistente per citarti senza inventare. La regola del 2026 è questa: si marca quello che serve a capire, non quello che si spera di vedere.

La cronologia ufficiale è nella pagina degli aggiornamenti della documentazione di Google: la voce del 7 maggio 2026 sulla deprecazione delle FAQ, e prima ancora il ritiro delle HowTo.

Anatomia di un blocco JSON-LD

Un blocco JSON-LD ha quattro parti: il vocabolario, il tipo, le proprietà e i collegamenti tra oggetti. Capire queste quattro parti è il 90% del lavoro, perché ogni errore che farai sarà in una di loro.

• @context — dichiara il vocabolario: https://schema.org. Va scritto una volta per blocco, identico sempre.
• @type — il tipo dell’oggetto descritto: Article, FAQPage, Product. È la parola che dice «questa cosa è un…».
• Le proprietà — i dati veri: headline, datePublished, image. I nomi sono fissi e in maiuscolo/minuscolo misto: datePublished non è datepublished.
• Gli oggetti collegati — quando una proprietà è a sua volta un oggetto: l’autore è una Person, l’editore è una Organization, le domande sono Question con le loro Answer.

Ecco un Article completo, con tutte le proprietà che Google richiede:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema markup su WordPress: come implementarlo passo passo",
  "description": "Come scegliere il tipo, scrivere il JSON-LD e verificarlo con gli strumenti di Google.",
  "image": "https://esempio.it/wp-content/uploads/copertina.png",
  "datePublished": "2026-09-25T08:00:00+02:00",
  "dateModified": "2026-09-25T08:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Nome Cognome",
    "url": "https://esempio.it/chi-scrive/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Nome del sito",
    "logo": {
      "@type": "ImageObject",
      "url": "https://esempio.it/wp-content/uploads/logo.png"
    }
  }
}
</script>

Tre dettagli che sbagliano quasi tutti. Le date vanno in formato ISO 8601 con il fuso orario (2026-09-25T08:00:00+02:00): senza fuso, Google interpreta l’ora come UTC e la data può slittare di un giorno. Il campo image vuole un URL assoluto, non un percorso relativo. E headline deve contenere il titolo vero della pagina: se scrivi un titolo diverso da quello visibile, stai descrivendo un’altra pagina.

Cosa emette già il tuo sito (e cosa rischi di duplicare)?

Cosa emette ognuno, in una tabella

Qui i nomi servono, e non sono pubblicità: sapere cosa emette il plugin che hai già è l’informazione che evita il tipo duplicato. Questa tabella è misurata su un sito WordPress 7.1 con tema a blocchi e un plugin SEO attivo (il sito su cui girano questi articoli).

Sorgente	Cosa emette di solito	Cosa fare
Yoast SEO	Un blocco per la pagina con tipo WebPage, Article o BlogPosting a seconda delle impostazioni, più BreadcrumbList, WebSite e Organization	Lascia fare a lui per i tipi base, e usa il campo «Schema» dello Yoast solo per aggiungere quello che manca (FAQ, HowTo)
Rank Math	Gli stessi tipi base, con il modulo «Schema» attivo di default nella versione gratuita	Attenzione al doppio: se aggiungi lo schema FAQ dal plugin e dal codice, la pagina ne dichiara due
WooCommerce	Product, Offer, AggregateRating e Review sulle schede prodotto	Non aggiungere Product a mano: rischi il duplicato. Intervieni solo se manca un campo (per esempio la disponibilità)
Tema a blocchi	Poco, e in modo prevedibile: struttura della pagina e qualche WebPage	Nessun intervento. È la sorgente più «silenziosa» delle tre
Un blocco di codice nel contenuto	Esattamente quello che scrivi tu, niente di più	È la via con il controllo massimo: usala quando il plugin non copre il tipo che ti serve

La regola che risolve il 90% dei casi: prima guardi cosa c’è (aprendo il codice sorgente della pagina, come nel primo passo), poi aggiungi solo quello che non c’è. Un tipo duplicato non è un errore grave, ma è inutile — e in alcuni casi confonde il validatore.

WooCommerce: i quattro tipi che contano per un negozio

Se il sito vende (o affitta, o prenota), lo schema che conta non è quello degli articoli: sono quattro tipi legati tra loro, e WooCommerce li emette da solo sulle schede prodotto.

• Product (schema.org/Product): il prodotto, con nome, descrizione, immagine e codice identificativo. È il contenitore di tutto il resto.
• Offer: il prezzo, la valuta e la disponibilità. È il campo che Google legge per mostrare «disponibile / esaurito» e il prezzo nei risultati: se è incompleto, il risultato non compare.
• AggregateRating: la media dei voti, se il prodotto ha recensioni. È il tipo più regolamentato di tutti: non puoi dichiarare un voto che non esiste in pagina.
• Review: la singola recensione, con autore e data. Anche qui: deve corrispondere a una recensione visibile.

Cosa fare, in pratica: lascia fare a WooCommerce e controlla. Si verifica con il Rich Results Test (o il rapporto Dati strutturati di Search Console) che Product e Offer siano letti correttamente; i problemi più frequenti non sono di markup ma di contenuto mancante — un prezzo senza valuta, un’immagine troppo piccola, un codice prodotto assente.

Prima di aggiungere schema, guarda quello che c’è già. Su un sito WordPress moderno lo schema arriva da tre sorgenti diverse, e il plugin che installi è solo una di queste: il core di WordPress, il tema a blocchi, e il plugin SEO.

Misurato su un sito WordPress 7.1 con tema a blocchi e plugin SEO attivo — è il sito su cui girano questi articoli — la situazione è questa:

Pagina	Blocchi JSON-LD presenti	Tipi che contengono
Articolo del blog	2	Article con Person, ImageObject, Organization
Articolo con FAQ	2	il blocco dell’articolo più FAQPage con Question e Answer
Home	2	WebSite con SearchAction, più Organization

Il problema nasce quando aggiungi il tuo pezzo senza guardare: due Article sulla stessa pagina sono un errore, e Google può scegliere quello con i dati peggiori. Prima di scrivere schema a mano, quindi, apri il codice sorgente di una pagina pubblicata e cerca application/ld+json: vedi subito quante sorgenti stanno parlando e cosa dicono.

Come si guarda il codice sorgente di una pagina

Apri la pagina nel browser, clic destro, «Visualizza sorgente pagina» (o Ctrl+U / Cmd+U), poi cerca ld+json con la ricerca del browser. Ogni blocco trovato è una sorgente: il plugin SEO, il tema, un blocco inserito a mano. Se il conteggio non torna, hai una duplicazione da sistemare.

Quale via scegliere per implementarlo su WordPress?

Il plugin SEO copre il caso normale; il codice serve per il dato che il plugin non conosce. Non sono alternative in conflitto. La scelta giusta è il plugin per tutto quello che è standard — titolo, autore, data, immagine, organizzazione — e il codice solo dove il contenuto ha caratteristiche che nessun campo prevede.

1. Il plugin SEO, dal campo per singolo contenuto

È la via normale e non richiede codice. Apri l’articolo, cerchi la sezione dello schema nella barra laterale, scegli il tipo e compili i campi. Il plugin si occupa del resto: genera il JSON-LD, lo aggancia alla pagina e costruisce gli oggetti collegati. L’autore diventa una Person dall’utente WordPress, l’editore una Organization dalle impostazioni del sito.

Ha senso per il 90% dei contenuti. Il limite è la forma dei campi: se il tuo contenuto ha una struttura che il plugin non prevede — una serie di specifiche tecniche, un listino con tre varianti di prezzo — i campi non bastano. E finisci per lasciare metà dei dati fuori.

2. Un blocco di codice dentro la singola pagina

Quando il dato vale per una pagina sola, il modo più diretto è inserire il JSON-LD dentro la pagina: nell’editor aggiungi un blocco «HTML personalizzato» e incolli lo script con il tuo JSON. Nessun file da toccare, nessun rischio per il resto del sito, e chi scrive vede quello che succede.

Attenzione a una cosa: il blocco «HTML personalizzato» serve per questo caso e per questo soltanto. Se dentro ci finisce del testo, o un riquadro con una classe che il tema non conosce, ottieni un pezzo di pagina senza stile e difficile da modificare. Per il contenuto normale si usano i blocchi veri, come nella guida all’editor a blocchi di WordPress.

3. Poche righe in functions.php

Serve quando lo schema deve valere per tutte le pagine di un tipo, o quando il dato va calcolato. Si aggancia all’evento wp_head e si limita l’intervento con i condizionali di WordPress: is_single() per gli articoli, is_page() per le pagine, is_product() se usi WooCommerce.

add_action( 'wp_head', function () {
    if ( ! is_single() ) {
        return;
    }

    $post = get_queried_object();
    if ( ! $post instanceof WP_Post ) {
        return;
    }

    $dati = array(
        '@context'      => 'https://schema.org',
        '@type'         => 'Article',
        'headline'      => get_the_title( $post ),
        'datePublished' => get_the_date( 'c', $post ),
        'dateModified'  => get_the_modified_date( 'c', $post ),
        'author'        => array(
            '@type' => 'Person',
            'name'  => get_the_author_meta( 'display_name', $post->post_author ),
        ),
    );

    printf(
        '<script type="application/ld+json">%s</script>',
        wp_json_encode( $dati, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE )
    );
}, 20 );

Il formato della data lo fa WordPress con get_the_date( 'c' ): la «c» è il formato ISO 8601 completo di fuso orario, che è esattamente quello che serve per il JSON-LD. Due accortezze: wp_json_encode() invece di json_encode(), perché gestisce correttamente i caratteri accentati, e la priorità 20 per finire dopo il plugin SEO — così puoi leggere quello che ha già scritto, se ti serve.

Il codice va in un plugin di frammenti o nel tema child, mai nel tema genitore. Al primo aggiornamento del tema, il file viene sostituito e il tuo schema sparisce senza che nessuno se ne accorga.

4. Nei template del tema

È la via di chi controlla il tema: il JSON-LD si genera dentro i file del tema a blocchi, con le funzioni WordPress e l’escaping corretto. Ha senso per un tema scritto su misura o per una pagina speciale che non è né un articolo né una pagina. Per un sito con un tema pronto, non è la strada: i template si aggiornano, e il codice che ci metti dentro si perde.

L’implementazione, passo per passo

Dieci passi, nell’ordine in cui vanno fatti. I primi cinque sono di analisi e non toccano niente: fanno risparmiare la maggior parte del lavoro, perché evitano di riscrivere una pagina già sistemata o di duplicare uno schema che c’è.

1. Apri il codice sorgente di una pagina pubblicata e conta i blocchi application/ld+json: sai quante sorgenti stai già usando.
2. Decidi quale tipo descrive davvero quella pagina, guardando la tabella qui sopra: uno solo, il più specifico possibile.
3. Scrivi le proprietà che Google richiede per quel tipo, e solo quelle: le altre si aggiungono dopo, quando servono.
4. Verifica che i dati siano identici a quelli visibili: titolo, autore, data, prezzo, passi. Se differiscono, il contenuto cambia.
5. Controlla che il tipo non sia già emesso da un’altra sorgente su quello stesso URL.
6. Implementa con la via giusta: plugin se il dato è standard, blocco se vale per una pagina, wp_head se vale per tutte quelle di un tipo.
7. Valida il codice con lo strumento di Google: gli errori bloccanti vanno risolti, gli avvisi si leggono e si valutano.
8. Pubblica la pagina e controlla che il risultato arricchito compaia: non è immediato, Google deve prima riscansire la pagina.
9. Segna il rapporto «Dati strutturati» in Search Console tra i controlli mensili: è lì che si vedono i tipi validi e quelli con problemi.
10. Aggiorna dateModified ogni volta che modifichi l’articolo in modo sostanziale: è il dato che dice a Google che il contenuto è vivo.

Come si verifica che funzioni

Si verifica in tre stadi: il codice, la pagina pubblicata, i risultati nel tempo. Ognuno risponde a una domanda diversa, e saltare il primo stadio significa scoprire l’errore solo dopo la pubblicazione.

Per il primo stadio ci sono due strumenti gratuiti, e servono a cose diverse. Il Rich Results Test di Google dice se la pagina è ammissibile a un risultato arricchito: è la domanda che conta per il posizionamento. Il validatore di schema.org controlla la correttezza formale del vocabolario: trova le proprietà scritte male o i tipi incoerenti che Google non segnala perché non li usa.

Il secondo stadio è Search Console: nella sezione dei dati strutturati vedi quanti elementi validi ha rilevato Google, e quanti hanno problemi, raggruppati per tipo. È l’unico posto dove il dato è reale — quello che Google ha effettivamente letto — perché i validatori guardano il codice, non l’indicizzazione.

Quello che leggi	Cosa significa davvero	Cosa fare
Errore «campo obbligatorio mancante»	Manca una proprietà che Google richiede per quel tipo	Aggiungerla: senza, il risultato arricchito non si genera
Avviso «campo consigliato mancante»	Il tipo funziona, ma il risultato è più povero	Valutare se il dato esiste e si può dichiarare
«Impossibile accedere alla pagina»	Google non riesce a leggere l’URL che hai dichiarato	Controllare che l’URL sia pubblico e non bloccato da robots.txt
Tipo valido ma nessun risultato arricchito	La pagina è ammissibile, Google ha scelto di non mostrarlo	Niente: è una decisione editoriale dei motori, non un errore
Due Article sulla stessa pagina	Il codice è valido ma le fonti sono in conflitto	Scegliere una sorgente sola e togliere l’altra

Quali errori annullano il lavoro?

Lo schema si annulla per il contenuto, non per la sintassi. Un JSON-LD valido che descrive cose che l’utente non vede è peggio di nessuno schema: Google lo ignora, e nei casi sistematici lo considera una manipolazione delle linee guida.

• Schema che non corrisponde al testo — titolo diverso da quello visibile, date inventate, un autore che non ha scritto l’articolo. È l’errore più grave e il più facile da evitare.
• FAQ senza FAQ visibili — domande e risposte che esistono solo nel codice. Se la pagina non ha una sezione di domande, il tipo FAQPage non va messo.
• HowTo su contenuti che non sono procedure — un articolo teorico non diventa una procedura perché lo dichiari tale. I passi devono esistere, essere numerati e avere un ordine reale.
• Schema duplicato — il tuo più quello del plugin o del tema. Due fonti sullo stesso URL si contraddicono: si sceglie una sorgente.
• Dati di contorno sbagliati — dateModified vecchio su un articolo aggiornato, logo con un URL che risponde 404, immagine dichiarata che non esiste più.
• Dichiarare contenuti nascosti — testo che c’è nel codice ma non si vede nella pagina: se non è visibile, non si marca.

Molti di questi problemi nascono da un errore tecnico a monte, non dallo schema: se l’articolo ha date sbagliate, immagini che rispondono 404 o due versioni della stessa pagina, il JSON-LD eredita il difetto. Vale la pena ripassare l’elenco degli errori SEO su WordPress prima di dare la colpa ai dati strutturati.

Perché lo schema conta anche per le risposte AI?

I dati strutturati non sono letti solo dai motori di ricerca. Quando un assistente deve citare una fonte, il vantaggio va a chi ha reso esplicito cosa contiene la pagina: chi è l’autore, quando è stata aggiornata, quale è il prezzo, quali sono i passi. Sono esattamente le informazioni che uno schema dichiara una volta sola e in modo non ambiguo.

Questo non significa che un assistente legga il JSON-LD al posto del testo: significa che due pagine con lo stesso contenuto non sono sullo stesso piano. Quella con i dati dichiarati viene capita con meno interpretazione, e l’errore di attribuzione — citare un prezzo vecchio, un autore sbagliato — diventa meno probabile. È lo stesso principio che sta dietro a E-E-A-T: essere espliciti su chi scrive, quando e su quale fonte conviene sempre.

In sintesi

• Lo schema descrive quello che la pagina è: tipo giusto, dati veri, una sorgente sola.
• Non fa salire il posizionamento: rende la pagina ammissibile a un risultato arricchito e più facile da citare.
• Su WordPress hai quattro vie: plugin SEO per il dato standard, blocco di codice per una pagina, wp_head per tutti i contenuti di un tipo, template del tema quando il tema è tuo.
• Guarda prima cosa emette già il sito: su un sito con tema a blocchi e plugin SEO ci sono già due blocchi JSON-LD per pagina. Aggiungerne un terzo senza leggere i primi due è il modo più rapido per fare danno.
• Verifica in tre stadi: validatore del codice, Search Console per la pagina pubblicata, rapporto dati strutturati come controllo mensile.
• FAQ e HowTo non danno più risultati arricchiti (dal 7 maggio 2026 le prime, dal 2023 le seconde): il markup resta valido e utile per farsi capire, ma non aspettarti un risultato visibile.

Domande frequenti sullo schema markup

Le risposte qui sotto sono marcate come FAQPage: dal maggio 2026 non producono più il menu a tendina nei risultati di Google. Restano però il modo più chiaro per dire a una macchina quale è la domanda e quale la risposta esatta.

Fonti

• Introduzione ai dati strutturati — Google Search Central: cosa sono, come si legge il formato e cosa si rischia.
• Elenco dei dati strutturati supportati — i tipi che possono generare un risultato arricchito, con i requisiti per ognuno.
• schema.org — il vocabolario: tipi, proprietà e relazioni, è il riferimento ufficiale.
• JSON-LD 1.1 — la raccomandazione del W3C che definisce il formato usato dai dati strutturati.
• JSON-LD su Wikipedia — la storia del formato e le alternative, per capire da dove arriva.
• Linee guida sui dati strutturati — cosa è considerato manipolazione e cosa no.

Chi scrive

theonlymadalin

nerd

Vedi tutti gli articoli di theonlymadalin →