Dati strutturati: grafo di entità, generazione automatica e cosa portano davvero

Sui dati strutturati circolano due visioni opposte e sbagliate: la scorciatoia per il ranking e l'orpello inutile. La realtà sta nel mezzo, ed è tecnica: i dati strutturati descrivono entità e relazioni in un formato che i motori di ricerca leggono senza ambiguità. Fatti bene, aiutano Google a capire chi sei, cosa offri e come sono collegate le tue pagine. Fatti con un plugin che aggiunge blocchi isolati, servono a poco.

Dal blocco isolato al grafo

L'errore più comune è trattare ogni pagina come un'isola: un blocco Organization nel footer, un Article generato dal plugin SEO, un LocalBusiness incollato a mano in un'altra pagina, ognuno con dati leggermente diversi. Google vede tre organizzazioni che forse sono la stessa.

L'approccio corretto è un grafo con identificatori stabili:

• ogni entità principale ha un @id univoco e permanente (per esempio l'URL del sito seguito da #organization o #persona);
• le pagine fanno riferimento a quelle entità tramite @id, invece di ridichiararle: un Article ha come author la persona con quell'@id, come publisher l'organizzazione con quell'@id;
• sameAs collega le entità ai profili esterni ufficiali, rafforzando l'identificazione.

Il risultato è un'unica descrizione coerente, ripetuta per riferimento in tutto il sito.

Generare, non scrivere a mano

I dati strutturati devono corrispondere a ciò che è visibile nella pagina. Il modo più affidabile per garantirlo è generarli dalla stessa fonte dei contenuti: se titolo, data, autore e domande frequenti di un articolo stanno nel frontmatter, il JSON-LD si costruisce da lì. Quando il contenuto cambia, cambiano anche i dati strutturati, senza disallineamenti.

Scriverli a mano pagina per pagina è il modo più rapido per ritrovarsi con date vecchie, prezzi superati e FAQ che non esistono più nel testo.

Cosa porta ancora risultati arricchiti

Google ha ridimensionato diversi tipi negli ultimi anni. In sintesi, oggi:

• Breadcrumb: ancora utile, aiuta la presentazione dell'URL nei risultati;
• Product, Offer, Review aggregate: centrali per l'e-commerce, con requisiti precisi su prezzo, disponibilità e recensioni reali;
• LocalBusiness e affini: utili insieme al profilo dell'attività su Google;
• Event, JobPosting, Recipe, Video: attivi nei rispettivi ambiti;
• Article: aiuta l'interpretazione di autore e date;
• FAQPage: risultato arricchito limitato quasi solo a siti istituzionali e sanitari;
• HowTo: non più mostrato come risultato arricchito.

Promettere a un cliente «le stelline» o «le FAQ in pagina» senza verificare lo stato attuale delle linee guida è il modo migliore per deluderlo.

Regole che non si negoziano

• Il markup descrive solo contenuti visibili nella pagina.
• Niente recensioni scritte da sé su sé stessi per ottenere le stelle.
• Un tipo per lo scopo giusto: un servizio non è un Product, un articolo non è un NewsArticle se non è una notizia.
• Le proprietà obbligatorie e consigliate di ogni tipo vanno compilate con dati reali, non con segnaposti.

Come verifico

1. Test dei risultati multimediali di Google per l'idoneità ai risultati arricchiti.
2. Validatore di schema.org per la correttezza generale del grafo, anche sui tipi che Google non usa.
3. Rapporti di Search Console per errori e avvisi su scala, dopo la pubblicazione.
4. Controllo a campione che il JSON-LD corrisponda al contenuto visibile, soprattutto dopo un aggiornamento.

Dove si inseriscono nel lavoro SEO

I dati strutturati non compensano contenuti deboli, pagine lente o un'architettura confusa. Vengono dopo: quando il sito è chiaro, veloce e ben collegato, rendono esplicito ciò che c'è. In una migrazione vanno trattati come i redirect, cioè conservati e verificati (lo spiego in Rifare il sito senza perdere il posizionamento).

Un esempio di grafo, a parole

Su una pagina di servizio di un professionista, il grafo che imposto contiene:

• un nodo WebSite, con @id stabile, che indica come editore la persona o l'organizzazione;
• un nodo Person o ProfessionalService (o il tipo più specifico), con nome, indirizzo, area servita, sameAs verso i profili ufficiali, sempre con lo stesso @id su tutto il sito;
• un nodo WebPage per la pagina, con isPartOf verso il sito e about verso il servizio;
• un nodo Service con nome, descrizione e provider che rimanda all'@id del professionista;
• un BreadcrumbList coerente con il percorso visibile.

Su un sito multilingua, ogni lingua ha la propria pagina con inLanguage, mentre le entità principali (persona, organizzazione) mantengono lo stesso @id: sono la stessa entità descritta in due lingue, non due entità diverse.

Come la vedo io

In questo sito i dati strutturati non li scrive nessuno a mano. Un'unica funzione aggiunge a ogni pagina il profilo con i riferimenti a me e alla mia attività, le pagine aggiungono breadcrumb e, per gli articoli, autore, date e domande frequenti, tutto letto dagli stessi file Markdown da cui nasce il testo. Le FAQ restano nel markup perché descrivono il contenuto, anche sapendo che oggi Google le mostra raramente.

È lo stesso principio che applico a tutto il resto: una fonte di verità, e tutto ciò che ne deriva generato in automatico. Con un plugin che aggiunge blocchi indipendenti si ottiene il contrario.

E quando eredito un sito, una delle prime verifiche è proprio il grafo: dice molto su quanto il sito è stato curato nel tempo.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Imposto i dati strutturati come grafo coerente, generato dai contenuti e verificato, senza promettere risultati che Google non dà più.

Se vuoi capire come Google legge il tuo sito, scrivimi: in una chiacchierata di circa 20 minuti guardiamo cosa c'è e cosa manca. Il servizio è in Velocità e SEO.