Nell’ambito delle attività finalizzate all’ottimizzazione SEO dei siti web, un posto rilevante viene occupato dai dati strutturati (structured data).
Scopriamo insieme cosa sono, perché usarli e come!
I dati strutturati sono informazioni fornite dalle pagine web “non visibili” agli utenti umani. Infatti la finalità con cui li utilizziamo è quella di trasmettere queste informazioni ai motori di ricerca come Google e Bing in una forma che sia per questi intelligibile. I dati strutturati sono parte integrante dei documenti HTML e possono essere scritti in 2 modi:
Microdati, ovvero mediante attributi aggiunti al normale markup HTML
JSON-LD, inserendo le informazioni in sezioni separate del documento HTML in formato JSON
Più avanti approfondiremo i due diversi approcci.
Va precisato che i dati strutturati non hanno alcun impatto sull’esperienza dell’utente che consulta la pagina web, infatti non intervengono sul layout di pagina o sui contenuti. I dati strutturati seguono una sintassi e degli standard condivisi affinché siano interpretabili dai crawler dei motori di ricerca.
Chi si occupa di SEO, ovvero di tecniche di ottimizzazione per il posizionamento sui motori di ricerca, lo sa bene: lo scopo di Google e dei vari motori di ricerca è quello di rispondere alle domande degli utenti in modo puntuale e preciso. I loro algoritmi sono sempre più raffinati e intelligenti, di conseguenza la capacità dei crawler di catalogare le pagine web e i relativi contenuti in base ad argomenti generali o specifici è di grande efficacia.
Eppure un crawler non è in grado di comprendere realmente i contenuti dei siti internet: volessimo precisare con dei concetti provenienti dalla linguistica, potremmo dire che i crawler comprendono la sintassi, ma non la semantica. Fondamentalmente per la catalogazione dei contenuti - in funzione dell’argomento trattato - il crawler si basa da una parte su meta tag all’interno del codice, come il title nella head o su tag come <h1>, <h2>, tag <b>... Per il resto si affida alla semantica dei testi.
I dati strutturati vengono in supporto dal momento che ci consentono, come anticipato, di fornire informazioni secondo formati e strutture standard condivisi. Il presupposto è che in ogni pagina web facciamo riferimento a delle entità che hanno delle proprietà che a loro volta possono essere nuovamente delle entità.
Proviamo a fare un esempio per capire meglio la reale utilità di un linguaggio condiviso. Andremo nel dettaglio vedendo un esempio pratico di codice: se ti sembra troppo informatichese non preoccuparti, all’interno del testo troverai tutti i riferimenti utili!
Una ricetta di cucina è un’entità che avrà come proprietà un nome, degli ingredienti, una descrizione della preparazione e un tempo di cottura. Il nome e la descrizione vengono valorizzati con testo normale, es. “Spaghetti alla carbonara”, e così la preparazione. Queste informazioni vengono trasmesse in modo che, quando esprimiamo il nome della ricetta, Google saprà esattamente che stiamo parlando di una ricetta e saprà esattamente qual è il suo nome e come descriviamo la sua preparazione.
Un approfondimento interessante lo merita il tempo di cottura. Potrebbe essere descritto nel testo in italiano ad esempio con “Un’ora e venti minuti”, oppure con “1 ora e 20 minuti”, o ancora in modo più elaborato con “1 ora in forno e 20 minuti a riposo”, e sono solo alcune opzioni!
Nella lingua parlata (e scritta) potrei descrivere il tempo di cottura in diversi modi, tutti comprensibili a un essere umano che conosca la lingua italiana. Esiste un modo per passare questa informazione ai motori di ricerca secondo un formato standard e condiviso attraverso un microdato o un JSON-LD.
La ricetta è un'entità di tipo:
CreativeWork -> HowTo -> Recipe (https://schema.org/Recipe)
Una delle proprietà dell’entità Recipe è cookTime, che si esprime seguendo lo standard ISO 8601 duration format. Nel nostro caso dovremmo valorizzare cookTime con “PT1H20M”. Questa informazione è valida per tutte le lingue ed è comprensibile per Google, che quindi saprà che nella pagina web stiamo parlando di una ricetta, definendo con chiarezza per lui quali sono gli ingredienti, come si procede per la preparazione e, in modo scientifico, qual è il tempo di cottura.
Ci siamo, più o meno?
Pronto per un esempio più complesso?
L’indirizzo e le coordinate di geolocalizzazione sono proprietà di un’entità di tipo Place. La proprietà address dell'entità Place può essere espressa con una semplice stringa, ma in alternativa con una entità di tipo PostalAddress che a sua volta avrà le sue proprietà fra cui, ad esempio, la nazione, la regione, la città e il codice postale. Vuol dire che possiamo annidare entità dentro altre entità.
Tutte le entità sono catalogate in vocabolari che seguono delle strutture predefinite. È possibile visionare queste entità in vocabolari come Schema.org. Come possiamo verificare, le entità seguono degli schemi gerarchici.
Un negozio di piante sarà un’entità di questo tipo:
Organization -> LocalBusiness -> Store -> Florist
Mentre un’agenzia immobiliare avrà una gerarchia più semplice:
Organization -> LocalBusiness -> RealEstateAgent
Più precisamente un’agenzia immobiliare potrà seguire un’altra gerarchia:
Place -> LocalBusiness -> RealEstateAgent
Ovvero essa è considerata sia un Place sia un LocalBusiness, e di conseguenza erediterà le proprietà di entrambi i genitori. Puoi osservare la sua struttura qui: https://schema.org/RealEstateAgent.
Ora che sappiamo perché sono utili, scopriamo come procedere per inserire i dati strutturati nei documenti HTML.
Ripartiamo dall’esempio del negozio di piante. Faremo riferimento a questo vocabolario. Non è necessario definire tutte le proprietà previste, infatti compileremo solo quelle che ci interessano.
Ho anticipato che esistono 2 modalità.
Partiamo dalla prima, quella dei microdati: inseriamo quindi degli attributi specifici ai tag HTML del documento. In questo ci viene in aiuto la natura stessa dell’HTML che ha una struttura gerarchica, esattamente come le entità che vogliamo descrivere.
<div itemscope itemtype="https://schema.org/Florist">
<div>
<p>Vieni a trovarci nel nostro negozio <b itemprop="name">Florindo</b> per scoprire le nostre ultime offerte su piante e fiori.
</p>
</div>
<div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
<p>Ci troverai a <span itemprop="addressLocality">Lucca</span> in
<span itemprop=”streetAddress”>Via Fillungo 5500</span>, <span itemprop="addressRegion">LU</span> <span itemprop="postalCode">55100</span>
</p>
</div>
<div>
<p>Chiamaci al numero <span itemprop="telephone">0583.123456</span> oppure scrivici a <span itemprop="email">info@mediaus.it</span>
</p>
</div>
</div>
Abbiamo aggiunto a normali tag HTML alcuni attributi che ci consentono di comunicare ai motori di ricerca che genere di informazioni troverà nella porzione di codice. Iniziamo con una div contenitore a cui abbiamo aggiunto gli attributi itemscope ed itemtype.
Itemscope non riceve alcun valore e serve ad indicare che in quel tag stiamo per dichiarare un’entità, cosa che faremo con l’attributo itemtype. In quest’ultimo andremo infatti a dichiarare quale entità è soggetto delle informazioni. Il valore fa riferimento direttamente alla url del vocabolario relativo: Florist. In questo modo il crawler del motore di ricerca saprà subito che stiamo parlando di un negozio di fiori e piante.
L’entità Florist eredita le proprietà di LocalBusiness e Organization essendo nella scala gerarchica una loro specifica espressione. Successivamente racchiudiamo il nome del negozio in un tag che avrà come attributo itemprop=“name”: stiamo scoprendo un nuovo attributo che utilizziamo per dichiarare quale proprietà verrà valorizzata all’interno del tag.
Ancora dopo spieghiamo al lettore dove può venire a trovarci, quindi scriveremo un indirizzo.
Utilizzando la proprietà address, valorizzeremo questa utilizzando un’altra entità: PostalAddress, che quindi sarà annidata nella nostra entità principale (Florist). PostalAddress contiene a sua volta le proprietà per città, via, provincia e CAP. Dopo la proprietà address del nostro negozio specifichiamo anche i contatti utilizzando le proprietà telephone e email.
Di fatto, se rimuovessimo i microdati dal codice HTML, l’esperienza dell’utente umano non cambierebbe, continuando a visualizzare sul proprio schermo lo stesso output. Fa molta differenza invece per i motori di ricerca, che non riceverebbero alcune informazioni precise su cosa vende il negozio, qual è il suo nome, il suo indirizzo e i dati di contatto.
Il secondo modo per scrivere i dati strutturati è attraverso JSON-LD, che come ci suggerisce il nome si basa sulla struttura JSON.
Si tratta di porzioni di codice inseriti solitamente nella head del documento all’interno di tag <script>. Declinando l’esempio del negozio di piante visto prima, andremmo a scrivere il JSON in questo modo:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Florist",
“name”: “Florindo”,
“address”: {
“@type”: ”PostalAddress”,
“addressLocality”: “Lucca”,
“addressStreet”: “Via Fillungo 5500”,
“addressRegion”: “LU”,
“postalCode”: “55100”
},
“telephone”: “0583.123456”,
“email”: “info@mediaus.it”
}
</script>
È evidente la differenza sostanziale: mentre utilizzando i microdati i dati strutturati sono compilati insieme al corpo dei contenuti che visualizza l’utente, i JSON-LD vengono compilati in una sezione separata. Il vantaggio dei microdati è che le informazioni che diamo all’utente e al motore di ricerca le ritroviamo insieme e probabilmente è più facile mantenere un’uniformità di dati; di contro, con JSON-LD riusciamo a mantenere il codice più pulito.
Ma arriviamo al dunque: perché abbiamo detto che i dati strutturati sono importanti per la SEO?
Le informazioni che vengono trasmesse in questo modo ai motori di ricerca sono chiare e sicure. Tornando infatti all’esempio del negozio di piante, in mancanza di dati strutturati Google dovrebbe comprendere che stiamo parlando di un negozio di piante basandosi esclusivamente su meta tag, tag e in generale sulla semantica dei testi. Ovviamente questi aspetti continuano ad avere un peso importante; integrando i dati strutturati, però, Google saprebbe con assoluta certezza che il nostro argomento è relativo ad un negozio di piante. E questo non può che essere un punto a nostro favore.
Quando sono utili, o indispensabili, i dati strutturati?
Ogniqualvolta è importante che il motore di ricerca comprenda (davvero!) il significato del contenuto di una pagina. Riprendiamo l’esempio della ricetta: il tempo di cottura “10 minuti” è una keyword che l’utente usa quando ricerca “Ricette pronte in 10 minuti” e vogliamo che la nostra ricetta sia tra i risultati, per questo è indispensabile passare questa informazione come dato strutturato e non basarsi solo sulla keyword density all’interno del testo. Lo stesso succede con gli indirizzi quando si lavora sulla GEO (SEO geolocalizzata), o nella pagina dei contatti qualora avessimo uffici con orari e indirizzi differenti e volessimo che in SERP comparissero in maniera ordinata.
Ecco, in tutti questi casi i dati strutturati diventano imprescindibili!
Capita l’importanza di questo tipo di dati?
Se alla luce di tutto questo vuoi andare in fondo alla questione, contattaci e capiamo insieme come migliorare il posizionamento del tuo sito web!
Tutti i diritti riservati 2019-2024 Mediaus srl Benefit
Dati di contatto del Responsabile della Protezione Dati: dpo@mediaus.it
P.IVA, CF e REA 01768800466 - Codice SDI: SUBM70N
Cap. Soc. €30.000
