Quando si parla di dati strutturati, il rischio è ridurre tutto a una promessa tecnica: aggiungo qualche riga di JSON-LD e il risultato su Google diventa automaticamente più ricco, visibile e capace di generare contatti. La realtà è più utile, ma meno magica. Il markup aiuta i motori di ricerca a comprendere il contenuto di una pagina; non sostituisce la qualità della pagina, non corregge una promessa confusa e non garantisce una posizione o un formato speciale.
Per me i dati strutturati sono una forma di coordinamento tra contenuto, sviluppo, SEO e misurazione. Servono quando descrivono con precisione ciò che una persona può già verificare sul sito. Se diventano un inventario di caratteristiche non presenti, creano distanza tra comunicazione e dichiarazioni automatiche.
I dati strutturati sono indizi, non decorazioni
La documentazione di Google Search Central descrive i dati strutturati come un formato standardizzato che fornisce indizi espliciti sul significato di una pagina. Un titolo, un autore, una data, un’immagine o un prodotto non sono soltanto elementi grafici: possono essere descritti in modo leggibile anche da un motore di ricerca.
Il vocabolario di schema.org aiuta a dare un nome condiviso a questi elementi. JSON-LD è spesso la scelta più semplice da mantenere, ma Google supporta anche Microdata e RDFa. Prima della tecnologia viene la semantica: devo capire che cosa rappresenta davvero la pagina, poi scelgo tipo e proprietà pertinenti.
Una pagina che presenta un articolo può essere descritta come Article, NewsArticle o BlogPosting, a seconda del contesto. Una pagina che vende un prodotto segue un’altra logica. Una pagina di servizio non diventa automaticamente una recensione, un evento o una FAQ soltanto perché quei tipi sembrano offrire un risultato più visibile.
Markup valido non significa rich result garantito
Questo è il punto più spesso perso nelle proposte commerciali. Le linee guida generali di Google chiariscono che un markup corretto rende una pagina idonea a determinate funzionalità, ma non garantisce che vengano mostrate. L’algoritmo considera ricerca, dispositivo, località e altri segnali; può scegliere un risultato testuale più adatto.
La stessa guida indica altre cause di esclusione: dati non rappresentativi del contenuto principale, informazioni fuorvianti, contenuti nascosti o proprietà che il test automatico non ha riconosciuto come errate. È una distinzione importante per il marketing. Posso avere un report tecnico senza errori e, nello stesso tempo, nessuna garanzia di ottenere stelle, immagini grandi o altri elementi arricchiti.
Per questo non presenterei mai i dati strutturati come un interruttore per aumentare il ranking. Sono un modo per ridurre l’ambiguità. Il risultato di business arriva soltanto se la pagina intercetta una domanda, mantiene la promessa e offre un passo successivo comprensibile.
Si parte dal contenuto visibile, non dallo schema più conveniente
Il primo controllo è editoriale: che cosa vede una persona quando arriva sulla pagina? Se leggo un titolo, una firma, una data e un’immagine coerenti, posso descrivere quei dati anche nel markup. Se invece aggiungo un autore che non compare, una valutazione che nessuno ha espresso o una data aggiornata solo perché voglio sembrare più recente, sto creando un’informazione difficile da difendere.
La guida di Google per il markup Article ricorda che questo tipo di dati può aiutare a comprendere meglio titolo, immagini, autore e date di un articolo. Non impone però di riempire ogni proprietà disponibile. Le proprietà consigliate devono essere applicate quando sono pertinenti e realmente disponibili.
In pratica, preferisco pochi campi completi a una struttura molto estesa ma approssimativa. Per un articolo controllo almeno il titolo, l’autore, l’URL dell’autore quando esiste, l’immagine principale, la data di pubblicazione e quella di modifica se la pagina è stata davvero aggiornata. Se una revisione cambia soltanto una virgola, non la presento come una nuova edizione dell’articolo.
Il confine tra descrivere e gonfiare
La tentazione di gonfiare il markup nasce dalla ricerca di un vantaggio immediato. Un servizio diventa un Product, un commento una recensione, domande interne una FAQ pubblica. Ma un tipo schema non è un’etichetta promozionale: descrive una realtà riconoscibile nella pagina.
Le funzionalità supportate da Google Search sono un buon punto di partenza proprio perché collegano ogni formato alla documentazione, ai requisiti e alle linee guida specifiche. Non tutte le proprietà di schema.org producono un elemento visibile nei risultati e non tutti i tipi sono adatti a ogni sito.
Il markup richiede un accordo tra team
Un problema frequente non è il codice, ma la mancanza di un proprietario dell’informazione. Il marketing scrive un claim, il redattore modifica il titolo, il developer eredita uno schema dal tema e il plugin SEO genera un secondo blocco JSON-LD. La pagina può contenere dati duplicati: due autori, due date, immagini diverse, breadcrumb che non seguono il percorso reale.
Prima della pubblicazione definirei una piccola matrice: quale tipo di pagina stiamo descrivendo, quali dati sono visibili, da quale fonte arrivano, chi li aggiorna e con quale frequenza. Per un articolo, il CMS dovrebbe fornire titolo, URL canonico, autore, date e immagine dalla stessa sorgente usata per il rendering. Per un prodotto, prezzo e disponibilità dovrebbero seguire la fonte commerciale effettiva, non un campo compilato una volta e poi dimenticato.
Questo è anche un controllo di reputazione. Se nei risultati compare una data errata o un’immagine non pertinente, l’utente non vede un problema di implementazione: vede un’azienda poco accurata. La qualità del markup diventa quindi una conseguenza della qualità dei processi editoriali e commerciali.
La verifica deve avvenire in tre passaggi
Il primo passaggio è il test tecnico. Il Rich Results Test permette di controllare una URL pubblica o un frammento di codice, verificando i tipi riconosciuti, gli errori e gli avvisi. È utile anche per accertarsi che immagini e risorse siano accessibili senza login o blocchi che impediscano la scansione.
Il secondo passaggio è il controllo della pagina reale. Non mi fermo al codice incollato nel plugin: verifico l’HTML servito, l’URL canonico, l’assenza di noindex involontari, la visibilità dei contenuti descritti e la coerenza tra titolo, autore, data e immagine. Quando il markup viene inserito da JavaScript, controllo inoltre che sia presente nel DOM che il crawler può rendere.
Il terzo passaggio arriva dopo il rilascio. I report dei rich result in Search Console mostrano gli elementi validi e non validi rilevati da Google per i tipi supportati. Non sono un censimento completo di ogni pagina, ma aiutano a individuare errori ricorrenti, problemi introdotti da un template e variazioni nel tempo. Per le URL non presenti nel report, la guida indica di usare l’ispezione URL.
Misuro poi il risultato con prudenza. Nel rapporto sul rendimento di Search Console osservo impressioni, clic, query e pagine, filtrando quando disponibile il tipo di risultato. Non attribuisco ogni crescita al markup: titolo, intento, concorrenza, reputazione, qualità e stagionalità possono incidere molto di più.
Una disciplina utile per il marketing
Il vantaggio dei dati strutturati non è soltanto ottenere una forma più ricca nella pagina dei risultati. È costringere il team a rispondere a domande che spesso restano implicite: qual è l’oggetto principale di questa pagina? Chi ne è responsabile? Quale data è davvero significativa? Quale immagine rappresenta il contenuto? Quale informazione cambia quando cambia l’offerta?
Quando queste risposte sono chiare, il markup diventa l’ultimo anello di una catena ben costruita. Quando non lo sono, nessun plugin può risolvere il problema. La mia checklist essenziale è breve: descrivere soltanto ciò che è visibile; scegliere il tipo più specifico ma pertinente; mantenere una sola fonte per i dati principali; testare la URL pubblica; verificare Search Console dopo il rilascio; collegare gli eventuali cambiamenti a metriche di attenzione e di conversione, senza promettere effetti automatici.
Se stai rivedendo il sito o il modello editoriale, partirei proprio da questa domanda: i dati che vogliamo far comprendere ai motori di ricerca sono davvero chiari anche per le persone? Se la risposta è sì, il markup può aiutare a esprimerli meglio. Se la risposta è no, prima di aggiungere codice lavorerei sulla pagina, sulla fonte del dato e sul processo che dovrà mantenerli allineati. Se vuoi confrontarti su un progetto SEO o di contenuti, puoi contattarmi: preferisco costruire una misura verificabile della qualità prima di inseguire un formato più vistoso nei risultati.
Nota di trasparenza: questo articolo è stato elaborato con l'aiuto dell'intelligenza artificiale e con supervisione e responsabilità editoriale umana.