Come testare gli rich snippet (e correggere gli errori dello schema)

TL;DR: Verifica l’idoneità ai rich snippet con il Rich Results Test di Google. Usa la modalità URL per la pagina pubblicata, correggi tutti gli errori e tratta i warning come miglioramenti opzionali. Poi monitora il report corrispondente in Google Search Console. Un test superato significa che la pagina è idonea per un rich result, non che lo riceverà garantitamente.

La scelta dello strumento conta. Google descrive il Rich Results Test come “Lo strumento ufficiale di Google per testare i tuoi structured data e vedere quali rich results di Google possono essere generati dallo structured data presente nella pagina”, nella documentazione Search Central sugli structured data.

È da qui che parto quando qualcuno mi chiede di testare l’idoneità ai rich snippet. Non con un’estensione del browser, un plugin con la spunta verde, né con lo Structured Data Testing Tool ritirato citato in un vecchio tutorial.

Una correzione terminologica: oggi Google li chiama rich results. “Rich snippet” è la frase più vecchia che molte persone continuano a usare. Entrambe descrivono inserzioni di ricerca potenziate che possono includere valutazioni, prezzi, immagini, breadcrumb, date di eventi, dettagli di ricette e altre informazioni oltre al titolo e alla descrizione standard.

Gli structured data non sono il risultato di ricerca in sé. Sono una descrizione della pagina leggibile dalle macchine, spesso scritta in JSON-LD. Google può anche interpretare microdata e RDFa, ma JSON-LD è in genere più facile da generare, ispezionare e mantenere senza “impigliarsi” il markup dentro HTML visibile.

Gli structured data validi creano l’idoneità. Google decide ancora se un potenziamento appare per quella specifica pagina e query. Questa distinzione spiega gran parte delle segnalazioni “il test passa, ma non vedo alcun rich snippet”.

Come testare correttamente un rich snippet

Il Rich Results Test ha modalità URL e Code. Si sovrappongono, ma non provano la stessa cosa.

1. Apri il Rich Results Test di Google.
2. Seleziona URL per una pagina pubblicata oppure Code per HTML o JSON-LD che non è stato distribuito.
3. Esegui il test e lascia che Google recuperi, renderizzi o processi l’input.
4. Apri ogni tipo di rich-result rilevato invece di fermarti al riepilogo.
5. Controlla gli errori, i warning e le proprietà parse per ogni elemento.
6. Correggi ogni errore e rilancia il test.
7. Distribuisci la modifica, svuota le cache rilevanti e testa di nuovo l’URL live.
8. Dopo che Google ha effettuato di nuovo il crawling delle pagine interessate, controlla il report di Search Console corrispondente e valida lì la correzione.

Inizia con la modalità URL per le pagine di produzione

La modalità URL risponde alla domanda utile per la produzione: cosa può recuperare Google da questo URL, proprio adesso?

Il tuo JSON-LD può essere perfetto in un campo del CMS e assente nella pagina pubblicata. Una condizione del template potrebbe sopprimerlo, una cache potrebbe servire la versione precedente, un errore JavaScript potrebbe bloccare l’iniezione oppure il deployment di produzione potrebbe omettere del tutto il componente. L’editor è una prova di intenti. L’URL live è una prova dell’output.

La modalità URL inoltre esegue il rendering delle pagine, quindi può rilevare gli structured data inseriti tramite JavaScript. Detto questo, preferisco un JSON-LD renderizzato lato server quando possibile, perché elimina un ulteriore punto di failure (non tutte le implementazioni hanno bisogno di un altro pezzo in movimento).

Durante la migrazione di gennaio 2026 da seojuice.io a seojuice.com, i test rappresentativi su URL live erano parte della checklist di rilascio. Una migrazione può preservare il template dello schema cambiando canonicals, percorsi di produzione, cache e output della pagina attorno ad esso. Testare soltanto lo snippet JSON-LD avrebbe ignorato gran parte del rischio della migrazione.

Usa la modalità Code prima della pubblicazione

La modalità Code è utile mentre costruisci o modifichi il markup. Incolla l’HTML o il JSON-LD rilevante, esegui il test e ripara la struttura prima di toccare la produzione.

Incolla uno snippet grezzo come questo relativo all’Article e testalo prima che la pagina vada online:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Test Rich Snippets",
  "author": { "@type": "Person", "name": "Vadim Kravcenko" },
  "datePublished": "2026-07-19"
}
</script>

Per i problemi ostinati, testane entrambi. La modalità Code ti dice se il markup proposto è accettabile. La modalità URL ti dice se quella versione è arrivata effettivamente nella pagina. Spesso questi risultati divergono: non è un fastidio, è l’indizio che cercavi.

Se devi prima costruire il JSON-LD, usa il nostro Schema markup generator, poi passa l’output nel test di Google. Un generatore può ridurre errori di parentesi, annidamento e proprietà. Non può verificare che il tuo CMS abbia fornito i dati corretti, né che in produzione il blocco finale venga renderizzato davvero.

Gli errori bloccano l’idoneità; i warning di solito no

Questa è la distinzione da tenere a mente quando leggi l’output del test.

Per elemento si intende un singolo oggetto di structured data rilevato nella pagina. Un singolo URL può contenere diversi elementi e diversi tipi di schema, ciascuno con uno stato diverso.

Ho visto team cancellare una dozzina di warning lasciando irrisolto un errore su una proprietà obbligatoria. Cambia completamente la priorità. Correggi prima i blocchi, rilancia il test e metti i warning davvero utili in una backlog di ottimizzazione.

Un warning può comunque mettere a nudo dati sorgente deboli. Per esempio, un’immagine o un identificatore opzionale possono aiutare Google a comprendere e presentare un Product in modo più completo. Ma “consigliato” non significa “richiesto in segreto” (e aggiungere valori inventati per zittire un warning è peggio che lasciarlo così).

Come correggere gli errori ricorrenti di schema

Mancanza di proprietà richieste

Il Rich Results Test di solito indica la proprietà mancante. Partiamo da lì, invece di cambiare plugin o copiare il JSON-LD di un altro sito.

Un elemento Product potrebbe mancare del nome o delle informazioni necessarie su offers, review o aggregate-rating. Una Recipe potrebbe mancare un’immagine. I requisiti cambiano a seconda del tipo di rich-result, quindi apri la documentazione di Google per la feature rilevata e confronta la struttura attesa con l’elemento effettivamente parsato.

Poi risali alla proprietà mancante a monte. Se un template si aspetta un campo price, author, image o date e il record del CMS è vuoto, modificare il JSON-LD generato tratta il sintomo. La soluzione vera è correggere il content model, la regola di validazione o un fallback del template.

Da quello che vediamo in SEOJuice su vari siti, questi “fallimenti goffi” tendono a succedere in quella fase di passaggio tra logica di schema valida e dati incompleti della pagina. Il generatore sa dove deve stare un valore; non può inventarsi un prezzo reale o una review visibile che la pagina non contiene. Né dovrebbe.

Tipi errati e formati dei valori sbagliati

Non tutte le proprietà schema accettano testo semplice. Una proprietà può richiedere un numero, un URL, un Offer, un PostalAddress o un altro oggetto annidato. Un valore può sembrare sensato per un lettore, ma avere comunque il tipo leggibile dalla macchina sbagliato.

Apri l’elemento interessato nel test, individua la proprietà precisa e confronta il valore con il tipo atteso. Se il template ha generato lo stesso errore su un URL, testa diverse altre pagine che usano quel template. Un singolo fallimento spesso è un esempio di un problema più ampio, non una pagina isolata.

Correggere il template una volta è la mossa efficiente. Correggere 80 pagine generate manualmente significa 80 occasioni per rifare lo stesso errore (o 79, se la fortuna accompagna la prima modifica).

Date non valide

Proprietà come datePublished, dateModified e startDate richiedono valori ISO 8601 leggibili dalle macchine. Un CMS può mostrare “19 luglio 2026” correttamente ai lettori mentre passa allo schema una stringa localizzata o ambigua.

Correggi il formatter della data a livello di template. Controlla anche i fusi orari per eventi e offers; un timestamp sintatticamente valido può comunque comunicare l’ora di inizio o di scadenza sbagliata.

Schema presente nell’editor ma assente nella pagina

Esegui il Rich Results Test sull’URL di produzione. Se il tipo atteso non viene rilevato, ispeziona l’output reale invece di modificare ripetutamente l’oggetto schema.

• Verifica che il JSON-LD compaia nella pagina consegnata o renderizzata.
• Controlla le condizioni del CMS e del theme che determinano dove viene inserito.
• Rivedi le impostazioni e le esclusioni dei plugin.
• Svuota le cache di pagina, CDN e applicazione dove applicabile.
• Verifica se l’esecuzione di JavaScript fallisce prima dell’iniezione dello schema.
• Conferma che la logica di consenso o personalizzazione non lo nasconda ai crawler.

SEOJuice genera automaticamente lo schema sulle pagine che gestisce, ma Lida ed io testiamo comunque un output rappresentativo. Siamo un team di due persone, quindi l’automazione è essenziale. Trattare l’automazione come infallibile non farebbe altro che automatizzare il nostro punto cieco.

Markup duplicato o in conflitto

Una pagina può ricevere schema dal theme, da un plugin SEO, da un plugin di commerce, da un plugin specialistico per schema e anche da JSON-LD personalizzato, tutto insieme. Il Rich Results Test separa gli elementi rilevati, rendendo più facile individuare copie incomplete o non previste.

Non festeggiare un singolo Product valido ignorando un secondo blocco Product rotto. Identifica quale sistema emette ciascun oggetto e scegli un unico “owner” per quel tipo di schema. Disabilitare l’output ridondante è in genere più sicuro che provare a mantenere sincronizzati più generatori.

Attenzione però prima di eliminare markup apparentemente duplicato per Organization o WebSite. Oggetti simili possono descrivere entità diverse oppure avere scopi diversi a livello di pagina. Confronta prima i loro identificatori, tipi e relazioni (qui “rimuovi i duplicati” è troppo brutale).

Il tuo markup deve combaciare con il contenuto visibile

Anche markup tecnicamente valido può violare le policy sugli structured data di Google. Un validatore controlla se i dati possono essere parsati; non certifica che le affermazioni siano vere.

“Non aggiungere markup per contenuti che non siano visibili ai lettori della pagina.”

Le linee guida generali sugli structured data di Google aggiungono: “I tuoi structured data devono rappresentare fedelmente il contenuto della pagina”. La conseguenza è esplicita anche lei: “Un’azione manuale sui tuoi structured data comporta la perdita dell’idoneità della pagina a comparire come rich result.”

Non aggiungere stelle di recensioni aggregate se gli utenti non riescono a trovare quelle recensioni nella pagina. Non marcare una data di evento che la pagina non mostra. Non trasformare un articolo qualunque in un oggetto Recipe solo perché il risultato Recipe sembra più “in evidenza”.

Vale anche per valori stantii. Se il prezzo visibile del prodotto cambia ma il JSON-LD in cache conserva il vecchio prezzo, il markup non rappresenta più la pagina. Può avere una sintassi perfetta e comunque essere sbagliato.

Lo Structured Data Testing Tool vecchio non c’è più

Google ha messo in pensione il suo vecchio Structured Data Testing Tool nel 2020. La validazione generica di schema.org continua ora tramite il Schema Markup Validator, mentre Google indirizza i test di idoneità rich-result al Rich Results Test.

• Rich Results Test: controlla se Google può generare una delle sue funzionalità di ricerca supportate a partire dalla pagina o dal codice.
• Schema Markup Validator: controlla il markup rispetto al vocabolario più ampio di schema.org, inclusi i tipi che Google non rende come rich results.

Un tipo schema.org può quindi essere valido senza generare un potenziamento Google. Non c’è contraddizione: schema.org descrive molte più entità e relazioni rispetto alla galleria di ricerca supportata da Google.

Usa il validatore per rispondere “Questo markup schema.org è valido?”. Usa lo strumento di Google per rispondere “È idoneo a un rich result di Google?”. Se ti serve la distinzione più profonda, la nostra guida Schema.org 2026 spiega cosa Google legge e utilizza oggi.

Non inseguire i rich results di FAQ o HowTo

Molti tutorial sugli schema, anche di qualità, sono ormai superati.

La structured-data search gallery live di Google resta la fonte da consultare prima di implementare un tipo per la visibilità in ricerca. Le funzionalità supportate includono, tra le altre: Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental e Video.

FAQ e HowTo non ci sono.

Google ha rimosso HowTo come funzionalità di ricerca nel 2023. Nel changelog della documentazione Google afferma: “Rimosciuta la documentazione structured data How-to, poiché questo rich result non viene più mostrato nei risultati di ricerca, sia su desktop sia su dispositivi mobile.”

FAQ è sopravvissuto più a lungo in una forma limitata, ma anche questo è finito. Barry Schwartz ha riportato su Search Engine Land che Google ha dismesso i rich results FAQ a partire dal 7 maggio 2026. L’avviso nella documentazione di Google diceva:

“I rich results FAQ non vengono più visualizzati su Google Search. Rimuoveremo la comparsa in ricerca FAQ, il report rich result e il supporto nel Rich results test nel giugno 2026.”

FAQPage resta parte di schema.org e altri sistemi potrebbero processarlo. Non genererà però un rich result FAQ di Google. Il markup HowTo può ancora descrivere contenuti istruttivi in senso semantico generale, ma non guadagna più un potenziamento HowTo in Google Search.

Lascia pure FAQ utili e istruzioni passo-passo per i lettori. Semplicemente non pianificare tempo di implementazione assumendo che questi due tipi di schema creeranno rich snippet di Google. Questa tattica è scaduta.

Passa dai test su una singola pagina al monitoraggio su tutto il sito

Il Rich Results Test è una diagnostica a livello di pagina. Search Console riporta ciò che Google ha riscontrato tra le pagine scansionate.

Apri il report rilevante, ad esempio Breadcrumbs, Product snippets o Merchant listings. Controlla gli URL interessati, individua il template o la sorgente dati condivisi, distribuisci la correzione e seleziona Validate fix quando disponibile. Google deve eseguire nuovamente crawling e processare gli URL prima dell’aggiornamento del report.

Search Console è più lenta del testing “incolla-codice” perché riflette il ciclo di crawling di Google, non la tua ultima modifica locale. Quel ritardo può essere frustrante (ho aggiornato quei report sapendo benissimo che non sarebbe cambiato nulla), ma è anche ciò che rende i dati utili: rappresentano pagine di produzione su larga scala.

Il nostro SEO audit gratuito può aiutarti a individuare problemi più ampi del sito prima di restringere l’indagine a singoli URL. Dopo, conferma l’idoneità rich-result nel test di Google; una verifica di terze parti non dovrebbe essere l’autorità finale su una feature di Google.

Perché un test superato può non produrre un rich result

Un risultato valido significa idoneità, non visualizzazione garantita.

Google decide se mostrare un potenziamento per ogni query e risultato. Anche la qualità della pagina, markup fuorviante o non coerente, tipi di feature non supportati e azioni manuali sugli structured-data possono influenzare la comparsa in ricerca.

Se il test passa ma non appare alcun potenziamento:

1. Conferma di aver testato l’URL canonico finale.
2. Verifica che le informazioni marcate siano visibili e aggiornate.
3. Rivedi il report corrispondente di Search Console.
4. Controlla in Search Console le azioni manuali.
5. Verifica che il tipo di schema continui a comparire nella search gallery di Google.
6. Monitora più query rilevanti invece di trattare una singola ricerca manuale come conclusiva.

Ho fiducia in questa sequenza diagnostica. Predire con precisione quando Google “decorerà” un risultato idoneo è meno certo perché Google non offre garanzie di visualizzazione. Riscrivere JSON-LD già valido ogni volta che un rich result scompare può introdurre nuovi errori senza cambiare la decisione di base.

L’idoneità e la presentazione sono cose diverse anche oltre lo schema. La nostra guida a SERP snippets e AI visibility spiega perché indicizzazione e controllo degli snippet continuano a contare anche quando le piattaforme di ricerca scelgono poi la presentazione finale.

Domande frequenti

Come faccio a testare se la mia pagina è idonea per rich results?

Incolla l’URL pubblicato nel Rich Results Test di Google. Usa la modalità Code per HTML o JSON-LD che non è stato pubblicato. Lo strumento identifica i tipi di rich-result supportati e mostra errori, warning e proprietà parse. Usa Search Console per informazioni aggregate su pagine scansionate.

Cosa è successo allo Structured Data Testing Tool?

Google ha ritirato lo Structured Data Testing Tool. Per verificare l’idoneità rich-result su Google usa il Rich Results Test; per la validazione più ampia di schema.org usa il Schema Markup Validator su validator.schema.org.

Qual è la differenza tra Rich Results Test e Schema Markup Validator?

Il Rich Results Test verifica se il markup può produrre un rich result supportato da Google. Lo Schema Markup Validator controlla la validità generale di schema.org, inclusi i vocabolari che Google non usa per i potenziamenti in ricerca. Superare il secondo non prova l’idoneità su Google.

Qual è la differenza tra un errore di schema e un warning?

Un errore significa che manca una proprietà richiesta o che un valore è invalido, rendendo l’elemento interessato non idoneo. Un warning di solito indica che manca una proprietà consigliata, mentre l’elemento resta idoneo. Correggi prima tutti gli errori, poi valuta i warning in base alla loro utilità e ai dati effettivamente mostrati nella pagina.

Lo schema FAQ genera ancora rich results nel 2026?

No. Google ha rimosso completamente i rich results FAQ il 7 maggio 2026 e, successivamente, ha disattivato anche il supporto correlato a test e report. FAQPage resta valido nel vocabolario schema.org, ma non genera più un rich result FAQ di Google.

Perché non viene rilevato alcuno schema sulla mia pagina live?

Il markup potrebbe non essere arrivato in produzione, potrebbe essere soppresso da una condizione di template, potrebbe restare dietro una cache non aggiornata oppure potrebbe dipendere da JavaScript che è fallito durante il rendering. Confronta la modalità Code con la modalità URL, poi ispeziona l’output di produzione renderizzato e ogni sistema in grado di iniettare schema.

Perché il mio rich result non compare anche se il test passa?

Passare significa che la pagina è idonea, non che riceverà garantitamente un inserimento potenziato. Verifica che il markup corrisponda al contenuto visibile, controlla il report di Search Console pertinente, conferma che la feature resta supportata e assicurati che il sito non abbia azioni manuali sugli structured-data.

Se stai generando o riparando JSON-LD, inizia da una pagina rappresentativa: testala in modalità Code, pubblicala, poi testa l’URL live. Una volta pulita quella pagina, applica la correzione a livello di template su tutto il sito e lascia che Search Console confermi il risultato su larga scala.