Come validare i dati strutturati senza gli strumenti di Google

La validazione dei dati strutturati è diventata stranamente dipendente dagli strumenti orientati a Google. È comprensibile: molti team aggiungono JSON-LD perché vogliono risultati avanzati, e gli strumenti di test di Google sono familiari. Ma i dati strutturati non sono un formato di Google. Di solito sono JSON-LD che usa il vocabolario Schema.org, incorporato in HTML, interpretato da molti consumatori e mantenuto dal tuo workflow di pubblicazione.

Se validi solo attraverso la lente di un motore di ricerca, puoi perdere problemi di base: JSON non valido, dati che scompaiono dopo il rendering, prezzi di prodotto obsoleti, URL canonici in conflitto, o markup tecnicamente valido ma semanticamente poco sensato.

Un workflow migliore parte dagli standard. Valida i dati come dati, poi valida il vocabolario, poi valida la pagina così come esiste in produzione.

Che cosa stai davvero validando?

“I dati strutturati” non sono una cosa sola. Sulla maggior parte dei siti web hanno quattro livelli:

1. Sintassi JSON — il codice è analizzabile?
2. Modello JSON-LD — si espande in linked data significativi?
3. Vocabolario Schema.org — i tipi e le proprietà sono plausibili?
4. Verità a livello di pagina — il markup corrisponde a ciò che utenti e crawler possono vedere?

Gli strumenti di Google si concentrano soprattutto sul quarto livello più l’idoneità ai risultati avanzati specifica di Google. Utili, sì. Completi, no.

Per esempio, questo può essere JSON-LD valido e comunque essere dati strutturati scadenti:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Qui non c’è nulla di rotto. Ma se la pagina visibile ha un titolo diverso, nessuna attribuzione dell’autore e una data di ultima modifica che contraddice il markup, hai un problema di qualità più che un problema di sintassi.

Passaggio 1: analizza il JSON prima di pensare alla SEO

Inizia dal controllo noioso: il JSON può essere analizzato?

Il JSON-LD incorporato in HTML spesso si rompe per piccoli errori di template:

• virgole finali
• virgolette non sottoposte a escape nei nomi dei prodotti
• interruzioni di riga non valide dentro le stringhe
• parentesi graffe mancanti dopo campi condizionali
• blocchi script duplicati dovuti all’ereditarietà del layout
• plugin CMS che generano oggetti parziali

Per i controlli locali, non ti serve una piattaforma SEO. Usa gli strumenti già presenti nel tuo stack di sviluppo.

In JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

In CI, estrai i contenuti degli script dall’HTML renderizzato e analizzali come JSON. Questo intercetta molti problemi prima che raggiungano la produzione.

Il punto importante: fallo prima di qualsiasi validazione Schema.org. Un validatore di vocabolario non può aiutare se i dati non sono JSON valido.

Passaggio 2: controlla il comportamento JSON-LD, non solo la sintassi JSON

JSON valido non significa automaticamente JSON-LD valido. JSON-LD usa concetti come @context, @type, @id e relazioni di grafo. Se questi sono malformati, i parser possono interpretare i tuoi dati in modo diverso da quello previsto.

Come minimo, conferma che:

• ogni blocco abbia un @context appropriato
• le entità principali abbiano valori @type chiari
• le entità ripetute usino valori @id stabili dove utile
• le entità annidate siano collegate in modo logico
• gli array siano usati quando sono possibili più valori

Per i siti più grandi, gli identificatori stabili sono particolarmente utili. Se la tua organizzazione compare nei dati Article, Product, BreadcrumbList e FAQPage, usare lo stesso @id aiuta i consumatori a capire che si tratta di riferimenti alla stessa entità, non di quattro organizzazioni non correlate con lo stesso nome.

Uno schema tipico è questo:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Qui non stai cercando di impressionare un validatore. Stai rendendo i tuoi dati meno ambigui.

Passaggio 3: valida rispetto al vocabolario Schema.org

Una volta che il JSON e la struttura JSON-LD sono solidi, controlla il vocabolario.

Il validatore Schema.org è utile perché testa rispetto ai termini Schema.org invece che alle regole per i risultati avanzati di un singolo motore di ricerca. Può mostrare se le proprietà sono riconosciute, se i tipi vengono interpretati come previsto e se le strutture annidate hanno senso.

È qui che intercetti errori come:

• publishingDate invece di datePublished
• imageUrl dove ci si aspetta image
• markup Product su una pagina di categoria che non è un prodotto
• AggregateRating senza un elemento recensito significativo
• Person usato per un account di brand

Fai attenzione agli avvisi. Schema.org è intenzionalmente flessibile. Un validatore può consentire una proprietà che non è utile per il tuo caso d’uso, oppure avvisare su qualcosa che è opzionale. Tratta la validazione come un indizio, non come un verdetto.

Una regola pratica: se una proprietà aiuta una macchina a comprendere la pagina in modo più accurato, tienila. Se esiste solo perché qualcuno l’ha copiata da un generatore di snippet, mettila in discussione.

Passaggio 4: confronta il markup con il contenuto visibile

I motori di ricerca e altri consumatori di dati tendono a diffidare del markup che non corrisponde alla pagina. Ancora più importante, gli utenti meritano coerenza.

Per ogni tipo di dati strutturati, confronta il markup con la pagina visibile:

Article e BlogPosting

Controlla che titolo, autore, data di pubblicazione, data di modifica, immagine ed editore siano visibili o ragionevolmente deducibili. Se pubblichi contenuti assistiti dall’AI, i tuoi dati strutturati non dovrebbero essere usati per ripulire una paternità poco chiara. Abbiamo scritto separatamente sulla dichiarazione onesta dell’AI su un piccolo sito web, e qui vale lo stesso principio: i metadati dovrebbero chiarire, non oscurare.

Product

Controlla nome, prezzo, disponibilità, valuta, varianti, valutazioni e numero di recensioni. I dati strutturati di prodotto sono particolarmente inclini a diventare obsoleti perché prezzi e disponibilità cambiano al di fuori del CMS.

LocalBusiness

Controlla nome, indirizzo, numero di telefono, orari di apertura e area servita. Se il tuo footer dice una cosa e il tuo JSON-LD ne dice un’altra, il JSON-LD non è “migliore”. È contraddittorio.

BreadcrumbList

Controlla che le posizioni dei breadcrumb corrispondano al percorso breadcrumb visibile e che gli URL siano canonici, scansionabili e non reindirizzati inutilmente.

Non è un lavoro affascinante. È anche il punto in cui si trovano molti problemi dei dati strutturati.

Passaggio 5: valida la pagina renderizzata, non il tuo template

Molti siti generano JSON-LD tramite JavaScript, tag manager, livelli di personalizzazione o hydration dei componenti. Questo significa che il file del template potrebbe non rappresentare ciò che un crawler o un browser vede effettivamente.

Valida l’HTML renderizzato in almeno tre stati:

• build di sviluppo locale
• URL di staging o anteprima
• URL di produzione

Usa browser DevTools per ispezionare il DOM finale. Cerca application/ld+json e copia il contenuto esatto dello script che esiste dopo il rendering. Se il markup renderizzato lato server differisce dal markup dopo hydration, decidi quale versione ti aspetti che i consumatori leggano.

Controlla anche se i dati strutturati vengono duplicati. Blocchi Article o Product duplicati sono comuni quando un plugin CMS e un componente personalizzato emettono entrambi schema. La duplicazione non è sempre fatale, ma la duplicazione in conflitto è un problema: due prezzi, due autori, due date di pubblicazione o due URL canonici.

È simile alla lettura di report sulle prestazioni e di diagnostica: il primo compito non è farsi prendere dal panico, ma separare il segnale dal rumore. La stessa abitudine aiuta quando leggi un report Lighthouse senza farti prendere dal panico — anche se i dati strutturati in sé non dovrebbero essere ridotti a un singolo punteggio.

Passaggio 6: controlla i dettagli di trasporto in produzione

I dati strutturati possono essere perfetti nel sorgente e comunque fallire in produzione perché la pagina non è accessibile nel modo che presumi.

Controlla:

• il codice di stato finale sia 200, non un soft 404
• l’URL canonico corrisponda alla pagina che stai validando
• i redirect siano intenzionali e stabili
• le direttive robots non blocchino l’indicizzazione dove l’indicizzazione è attesa
• l’HTML non venga sostituito da una pagina di errore per alcuni user agent
• le pagine in cache non servano JSON-LD obsoleto

Qui l’ispezione HTTP conta. Se una pagina prodotto passa attraverso tre URL prima di raggiungere una destinazione canonica, valida la pagina finale, non il primo URL copiato dal CMS. Per i meccanismi di base, la nostra guida al debug di redirect e header HTTP in produzione è un utile complemento.

I dati strutturati non vivono nel vuoto. Viaggiano con header, redirect, caching, tag canonici e direttive robots.

Passaggio 7: aggiungi test sui dati strutturati al tuo processo di rilascio

La validazione manuale va bene per una pagina. Non scala su centinaia o migliaia di URL.

Una semplice suite di test automatizzati può intercettare gli errori più costosi:

• recuperare URL rappresentativi da ogni tipo di template
• estrarre tutti i blocchi JSON-LD
• analizzarli con JSON.parse
• verificare i campi obbligatori per ogni tipo di pagina
• controllare che le date siano stringhe ISO 8601 valide
• controllare che gli URL siano assoluti e canonici
• controllare che prezzi e disponibilità esistano per le pagine prodotto
• controllare che le entità duplicate non siano in conflitto

Puoi eseguire tutto questo in CI per i template e su base pianificata per gli URL di produzione. L’obiettivo non è dimostrare che ogni funzionalità di risultati avanzati apparirà. Nessuno al di fuori del motore di ricerca può prometterlo. L’obiettivo è mantenere i tuoi dati accurati, analizzabili e coerenti.

<!-- tool-cta:start -->

💡 Prova questo: Prima di convalidare la logica dello schema, passa il tuo JSON-LD nel JSON Formatter per individuare errori di sintassi che altrimenti farebbero fallire ogni controllo successivo.

<!-- tool-cta:end -->

Una checklist di validazione basata prima sugli standard

Usa questa breve checklist prima di chiederti se una pagina piace a un motore di ricerca:

• Ogni blocco JSON-LD è JSON valido?
• Ogni blocco include il @context e il @type corretti?
• Le proprietà Schema.org sono scritte correttamente?
• Il markup corrisponde al contenuto visibile?
• Date, prezzi, valutazioni e disponibilità sono aggiornati?
• Gli URL sono assoluti, canonici e raggiungibili?
• La pagina di produzione renderizzata è la stessa pagina che hai testato?
• Le entità duplicate sono intenzionali e non in conflitto?

Se puoi rispondere sì a queste domande, hai fatto la parte durevole del lavoro sui dati strutturati. I test specifici per la ricerca possono comunque essere utili in seguito, ma dovrebbero essere il controllo finale di compatibilità, non il fondamento del tuo processo di validazione.