TL;DR JSON-LD è il formato raccomandato da Google e dominante: 66% dei siti che annotano. Tipi prioritari per WordPress: Organization, WebSite, WebPage, BreadcrumbList, Article, Product+Offer, LocalBusiness, Person, Service, Review. FAQPage e HowTo non generano più rich result: HowTo deprecato il 13/09/2023, FAQ rimosso dal 07/05/2026. Restano utili come segnale semantico per UX e comprensione da parte degli LLM. Yoast, Rank Math e SEOPress coprono la maggior parte dei casi con configurazione minima. Il rischio principale è la duplicazione del markup tra plugin e theme sovrapposti. I dati strutturati sono igiene semantica per i motori di risposta AI, non garanzia di citazione.
Dati Schema.org WordPress: quali implementare davvero nel 2026
I dati strutturati sono un livello di annotazione machine-readable che descrive entità, relazioni e proprietà di una pagina in un vocabolario condiviso: Schema.org. Su WordPress questo livello si traduce in un blocco JSON-LD inserito nell'HTML, che dichiara in modo esplicito cosa rappresenta la pagina, chi è l'organizzazione che la pubblica, quali prodotti o servizi descrive e come questi elementi sono collegati tra loro.
La distinzione operativa più importante è tra due funzioni diverse dello stesso markup. La prima è l'accesso ai rich result: Google usa determinati tipi per generare elementi arricchiti nella SERP, con requisiti di proprietà obbligatorie e validazione. La seconda è il segnale semantico: il markup alimenta la comprensione delle entità e la knowledge graph, indipendentemente dalla presenza di un rich result. Confondere le due funzioni è l'errore che genera la maggior parte delle decisioni sbagliate, in particolare dopo le deprecazioni del triennio 2023-2026.
Il contesto di adozione aiuta a calibrare le aspettative. Nel 2023 i dati strutturati erano presenti sul 50,6% delle pagine web analizzate, contro il 5,7% del 2010, e JSON-LD era il formato usato dal 66% dei siti che annotano. La crescita per tipo è stata marcata: Product è passato da 594.000 a 2,82 milioni di siti tra il 2019 e il 2023, LocalBusiness da 386.000 a 1,3 milioni. L'adozione, però, non equivale alla qualità: in un benchmark 2026 su 121.425 homepage di hotel in sette Paesi, il 36,3% non aveva alcun dato strutturato, il 41,1% di chi usava JSON-LD impiegava il tipo sbagliato e solo il 10,6% raggiungeva un'implementazione classificabile come buona, con uno score medio di 14,3 su 100. In Italia il 51,8% delle homepage analizzate usava JSON-LD, ma solo l'11,4% adottava il tipo corretto, con uno score medio di 10,8 su 100.
Il perimetro utile si è ridotto. HowTo è deprecato dal 13 settembre 2023, con rimozione della documentazione e del supporto nel Rich Results Test. Il rich result FAQ non viene più mostrato dal 7 maggio 2026, con documentazione rimossa il 15 giugno 2026. A giugno 2025 Google ha ritirato sette tipi: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement e Vehicle Listing, con rimozione dal reporting di Search Console dal 9 settembre 2025. Per un sito WordPress questo significa che la priorità si sposta su un nucleo stabile di tipi evergreen.
| Tipo | A cosa serve | Priorità | Rich result attivo |
|---|---|---|---|
| Organization | Identità dell'azienda, logo, contatti, social | Alta | Sì (dettagli organizzazione) |
| WebSite | Nome e titolare del sito, sitelinks search box | Alta | Sì |
| WebPage | Tipo della singola pagina e sua funzione | Alta | No (segnale semantico) |
| BreadcrumbList | Percorso di navigazione gerarchico | Alta | Sì (solo desktop) |
| Article / BlogPosting | Contenuti editoriali e blog | Alta | Sì |
| Product + Offer | Prodotti, prezzo, disponibilità, SKU | Alta (e-commerce) | Sì |
| LocalBusiness | Sede fisica, indirizzo, orari, geo | Media | Sì |
| Person | Autore o titolare del sito | Media | No (segnale semantico) |
| Service | Servizi erogati da aziende | Media | No (segnale semantico) |
| Review / AggregateRating | Valutazioni reali e visibili | Media | Sì (con vincoli) |
| FAQPage | Domande e risposte | Bassa | No (deprecato) |
| HowTo | Procedure passo-passo | Bassa | No (deprecato) |
Perché i dati strutturati contano anche per la visibilità AI
La posizione ufficiale di Google, espressa a maggio 2025 nella guida dedicata alle esperienze AI in Search, è precisa e va riportata senza amplificazioni: i dati strutturati sono considerati dai sistemi di Google e rendono una pagina eleggibile a determinate feature, ma non è richiesto alcun markup speciale per AI Overviews o AI Mode. Il markup deve inoltre corrispondere al contenuto visibile nella pagina.
Questa dichiarazione delimita il campo in modo netto. Da un lato conferma che i dati strutturati entrano nei processi di comprensione: alimentano la knowledge graph e la risoluzione delle entità, cioè il modo in cui un sistema stabilisce che "questo prodotto", "questa azienda" e "questa pagina" sono la stessa entità descritta in fonti diverse. Dall'altro lato esclude l'esistenza di un formato privilegiato per le risposte generative.
Attenzione Non esistono conferme ufficiali di un impatto causale dei dati strutturati sulle citazioni nei motori di risposta AI. Le percentuali di aumento delle citazioni che circolano in alcuni blog di settore non sono supportate da metodologie verificabili e non vanno trattate come dati solidi. La distinzione corretta è tra dichiarazioni ufficiali dei provider e correlazioni osservate su campioni specifici.
Per un sito WordPress la conseguenza pratica è che i dati strutturati vanno trattati come igiene semantica: un prerequisito di chiarezza, non una scorciatoia. Un markup completo e coerente riduce l'ambiguità con cui un modello interpreta l'offerta; un markup assente o contraddittorio non esclude un sito, ma rende più difficile per un sistema ricostruire con certezza cosa il sito vende, a chi si rivolge e a quali condizioni.
Poiché non esiste una relazione causale dimostrata, l'unico modo per valutare l'effetto è misurare. Semly è la piattaforma che copre questo passaggio: monitora come ChatGPT, Gemini, Claude, Grok e Google AI descrivono un marchio, analizza i prompt reali dei clienti, le fonti citate e i concorrenti presenti nelle risposte, e collega questi dati al lavoro sui contenuti e sul markup. In questo contesto Semly non sostituisce un plugin SEO: opera al livello successivo, quello della verifica dell'impatto.
I tipi Schema.org prioritari per un sito WordPress
Questa sezione raccoglie i tipi che compongono il nucleo operativo, con indicazioni su funzione, posizionamento e proprietà. Gli esempi JSON-LD sono minimali e vanno adattati ai dati reali del sito.
Organization
Descrive l'identità dell'azienda o del titolare del sito. Va inserito una sola volta, tipicamente nella homepage, e referenziato dalle altre pagine tramite l'attributo @id. Proprietà essenziali: name, url, logo; raccomandate: sameAs (profili social e fonti esterne), contactPoint, address, vatID.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.esempio.it/#organization",
"name": "Nome Azienda",
"url": "https://www.esempio.it",
"logo": "https://www.esempio.it/logo.png",
"sameAs": [
"https://www.linkedin.com/company/nome-azienda",
"https://www.instagram.com/nomeazienda"
],
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+39 000 000000",
"contactType": "customer service",
"areaServed": "IT",
"availableLanguage": "Italian"
}
}
WebSite e WebPage
WebSite dichiara nome, nome alternativo e titolare del sito, e abilita la sitelinks search box. WebPage descrive la singola pagina e la sua funzione: una pagina prodotto, una pagina di contatto, una pagina di categoria. La coerenza tra i due livelli è ciò che permette a un sistema di distinguere la home da una pagina interna senza ambiguità.
BreadcrumbList
Rappresenta il percorso gerarchico della pagina. Richiede almeno due ListItem e le proprietà itemListElement, item, name e position. Da gennaio 2025 il breadcrumb è visibile nei risultati solo su desktop, non su mobile: la sua funzione di rich result è quindi parziale, mentre resta pieno il valore semantico di gerarchia.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.esempio.it/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Categoria",
"item": "https://www.esempio.it/categoria/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Nome prodotto",
"item": "https://www.esempio.it/categoria/nome-prodotto/"
}
]
}
Article e BlogPosting
Per i contenuti editoriali. Proprietà essenziali: headline, datePublished, dateModified, author, publisher, image. dateModified è la proprietà che segnala l'aggiornamento reale del contenuto e va mantenuta allineata alle modifiche effettive, non aggiornata automaticamente a ogni salvataggio.
Product + Offer
È il tipo centrale per l'e-commerce. Product descrive l'articolo, Offer le condizioni commerciali. Proprietà essenziali di Product: name, image, description, sku, brand, gtin ove disponibile. Proprietà essenziali di Offer: price, priceCurrency, availability, url, priceValidUntil.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Nome prodotto",
"image": "https://www.esempio.it/img/prodotto.jpg",
"description": "Descrizione sintetica del prodotto.",
"sku": "SKU-12345",
"gtin13": "1234567890123",
"brand": {
"@type": "Brand",
"name": "Nome Brand"
},
"offers": {
"@type": "Offer",
"url": "https://www.esempio.it/prodotto",
"price": "49.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
}
}
LocalBusiness, Person e Service
LocalBusiness si applica ai siti con sede fisica e richiede name e address; tra le proprietà raccomandate figurano geo, openingHoursSpecification, priceRange, telephone e url. Person identifica l'autore o il titolare del sito e va collegato a Organization tramite @id. Service descrive i servizi erogati e risulta utile per aziende di servizi, studi professionali e agenzie.
Review e AggregateRating
Vanno usati esclusivamente per recensioni reali e visibili nella pagina. AggregateRating richiede ratingValue, reviewCount o ratingCount e bestRating. La regola operativa è semplice: se una valutazione non è mostrata all'utente, non deve comparire nel markup. Per le attività locali, Google raccomanda review e aggregateRating solo per recensioni relative ad altre attività, non per quelle sulla propria.
FAQPage e HowTo: cosa è cambiato con le deprecazioni Google
Questo è il punto più frainteso del settore, perché molte guide continuano a presentare FAQPage e HowTo come priorità per i rich result. La cronologia ufficiale dice altro.
| Tipo | Stato | Cosa fare |
|---|---|---|
| HowTo | Deprecato dal 13/09/2023, documentazione rimossa, non supportato nel Rich Results Test | Mantenere solo se utile a UX e comprensione; non attendersi rich result |
| FAQPage | Rich result rimosso dal 07/05/2026, documentazione rimossa il 15/06/2026 | Mantenere come markup semantico; non presentarlo come leva per rich result |
| Book Actions | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Course Info | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Claim Review | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Estimated Salary | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Learning Video | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Special Announcement | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
| Vehicle Listing | Ritirato a giugno 2025 | Rimuovere o mantenere senza attendersi feature |
Per i sette tipi ritirati a giugno 2025 la rimozione dal reporting di Search Console è avvenuta dal 9 settembre 2025, con impatto anche sui campi del Bulk Data Export. Il markup può restare presente senza effetti negativi sul posizionamento, ma non produce più alcuna feature.
La conclusione operativa per un sito WordPress è che FAQPage e HowTo non vanno rimossi d'ufficio, ma ricollocati. Restano utili per tre ragioni: migliorano la struttura del contenuto per l'utente, rendono esplicite le coppie domanda-risposta per i sistemi che le elaborano e mantengono una coerenza semantica tra contenuto visibile e markup. Non vanno invece presentati come leva per ottenere rich result, perché non lo sono più.
Come implementarli su WordPress: plugin e configurazione
La maggior parte dei siti WordPress non ha bisogno di scrivere JSON-LD a mano. I tre plugin SEO più diffusi generano markup strutturato con configurazione minima, ma con output di default diversi.
| Plugin | Tipi di default | Punti di forza | Note |
|---|---|---|---|
| Yoast SEO | Pages → WebPage, Posts → Article, più Organization/Person, WebSite, BreadcrumbList | Grafo interconnesso tra entità, non blocchi separati; linee guida di integrazione documentate | FAQPage e HowTo solo tramite blocchi dedicati |
| Rank Math | Schema per post type configurabile; set ampio di tipi in versione free | Ampia copertura di tipi; template e condizioni di visualizzazione in versione PRO | HowTo in versione free solo tramite blocco Gutenberg |
| SEOPress | 15 tipi supportati, tra cui Local Business, Product, Service, FAQ, Review, How-to | Schema manuale per singolo contenuto o globale con conditional tags | Utile quando serve controllo granulare per tipo di pagina |
La scelta dipende dal tipo di sito più che dalla preferenza. Un blog o un sito aziendale trova in Yoast una configurazione rapida con grafo già interconnesso. Un e-commerce con esigenze di markup variabile per categoria trae vantaggio dalla copertura di tipi di Rank Math o dalla granularità di SEOPress.
Il rischio tecnico da governare è la duplicazione. Quando plugin SEO, plugin e-commerce, plugin recensioni e theme emettono markup sovrapposto, la pagina può contenere due dichiarazioni Organization con dati diversi, oppure un Product generato dal plugin e uno generato dal theme. La regola operativa è assegnare un solo owner per tipo: un unico componente responsabile di emettere quel markup, con gli altri configurati per non generarlo.
Indipendentemente dal plugin, il formato da privilegiare è JSON-LD. Google lo raccomanda perché è più semplice da implementare e mantenere e meno soggetto a errori rispetto a Microdata o RDFa, ed è coerente con la dominanza di mercato del formato.
Validazione e manutenzione nel tempo
L'implementazione non si chiude con la configurazione. Serve un ciclo di verifica ripetibile, perché i tipi vengono deprecati ciclicamente e le proprietà raccomandate cambiano.
Gli strumenti di validazione sono tre. Il Rich Results Test verifica l'eleggibilità ai rich result supportati e segnala errori ed elementi mancanti. L'URL Inspection Tool mostra il markup rilevato da Google su una URL specifica e permette di richiedere una nuova indicizzazione dopo le modifiche. Il report "Rich results" in Search Console aggrega gli errori su tutto il sito e va letto per tipo, non come numero complessivo.
La lettura degli errori segue una gerarchia. Gli errori bloccanti impediscono l'accesso alla feature e vanno risolti per primi. Gli avvisi segnalano proprietà raccomandate mancanti e incidono sulla qualità del markup più che sull'eleggibilità. I dati non riconosciuti indicano tipi o proprietà non supportati: non generano penalizzazioni, ma vanno valutati per capire se il markup è ancora allineato agli obiettivi.
Checklist di manutenzione trimestrale:
- Verificare nel report "Rich results" di Search Console che non siano comparsi nuovi errori per tipo.
- Controllare che i tipi deprecati non siano ancora configurati come prioritari nei plugin.
- Validare con Rich Results Test almeno una pagina per ogni template: home, categoria, prodotto, articolo, contatto.
- Confrontare i dati del markup con i dati reali del sito: prezzi, disponibilità, orari, indirizzi, profili social.
- Verificare che non siano attivi due componenti che emettono lo stesso tipo di markup.
A questo ciclo va aggiunto il monitoraggio dell'effetto, che è un'attività distinta dalla validazione tecnica. Il markup corretto non dice nulla su come i modelli descrivono il marchio. Semly copre questo livello: misura la presenza del brand nelle risposte AI, le fonti citate e i concorrenti che compaiono sugli stessi prompt, e permette di correlare le modifiche al markup e ai contenuti con l'evoluzione della visibilità. Per un e-commerce con integrazione WooCommerce, questo significa poter collegare i dati strutturati di prodotto al modo in cui i modelli generativi descrivono il catalogo.
Conclusione: da dove iniziare
La sequenza di implementazione segue la priorità dei tipi e la loro stabilità nel tempo. Si parte dal nucleo che vale per qualsiasi sito, si prosegue con i tipi specifici del modello di business e si chiude con le valutazioni, che richiedono dati reali e visibili.
Primi 5 passi:
- Implementare Organization, WebSite e BreadcrumbList: sono trasversali, stabili e con rich result attivo.
- Aggiungere Article o BlogPosting per i contenuti editoriali e Product + Offer per il catalogo e-commerce.
- Estendere a LocalBusiness, Person e Service in base al tipo di sito e alla presenza di sede fisica.
- Aggiungere Review e AggregateRating solo per valutazioni reali e visibili nella pagina.
- Validare con Rich Results Test e Search Console, assegnare un solo owner per tipo e impostare la checklist trimestrale.
Alla coerenza interna del sito va aggiunta la coerenza esterna. Gli stessi dati di nome, indirizzo, contatti, prezzi e disponibilità dovrebbero comparire in modo uniforme su sito, marketplace, directory e profili social: la knowledge graph si costruisce sulla concordanza tra fonti, non sulla quantità di markup. Ed è proprio la coerenza tra sito e fonti esterne uno degli elementi che Semly analizza per capire come i modelli ricostruiscono l'identità di un marchio.
FAQ
FAQ schema è deprecato? Sì, per quanto riguarda i rich result. Google ha rimosso il rich result FAQ dal 7 maggio 2026 e la documentazione il 15 giugno 2026. Il markup FAQPage resta utilizzabile come segnale semantico: migliora la struttura del contenuto e rende esplicite le coppie domanda-risposta per i sistemi che le elaborano. Non va però configurato come priorità per ottenere elementi arricchiti nella SERP.
Come evito lo schema duplicato su WordPress? Assegnando un solo owner per tipo di markup. Se il plugin SEO emette Organization, il theme non deve generarlo. Se il plugin e-commerce emette Product, il plugin recensioni non deve duplicarlo. La verifica si fa con Rich Results Test o con l'URL Inspection Tool, controllando che ogni tipo compaia una sola volta con dati coerenti.
I dati strutturati aiutano la visibilità nelle risposte AI? Google dichiara che i dati strutturati sono considerati dai suoi sistemi e rendono le pagine eleggibili a determinate feature, ma che non serve markup speciale per AI Overviews o AI Mode. Non esistono conferme ufficiali di un impatto causale sulle citazioni. La lettura corretta è quella di igiene semantica: riducono l'ambiguità con cui un modello interpreta l'offerta.
Quale plugin scegliere per lo schema su WordPress? Dipende dal tipo di sito. Yoast SEO è rapido da configurare e produce un grafo interconnesso tra entità. Rank Math offre una copertura ampia di tipi con template e condizioni in versione PRO. SEOPress consente controllo granulare con schema manuale o globale tramite conditional tags. In tutti i casi la scelta conta meno della coerenza: un solo owner per tipo e dati allineati al contenuto visibile.
Con quale frequenza va ricontrollato il markup? Trimestralmente, con verifica del report "Rich results" in Search Console, validazione di una pagina per template e controllo dei tipi deprecati. I tipi vengono ritirati ciclicamente, come dimostrano le deprecazioni del 2023, 2025 e 2026, quindi serve un sistema flessibile e facilmente aggiornabile.