Schema markup: guida pratica ai dati strutturati SEO

Lo schema markup è un blocco di codice nel sorgente della pagina che dice a Google cosa c’è dentro: chi l’ha scritta, di cosa parla, chi la pubblica. Non è un fattore di ranking e non ti garantisce nessun risultato speciale in SERP.

Prima di scrivere questa guida ho aperto il JSON-LD del mio sito e ci ho trovato cinque errori. Uno è un segnaposto del plugin mai risolto che sta lì in bella vista sulla home, un altro è la mia stessa identità spaccata su tre nodi diversi. Te li faccio vedere tutti, con l’output vero incollato: donatopirolo.dev è in produzione, il markup è pubblico, e mentre leggi puoi rifare il controllo con un curl e vedere se nel frattempo l’ho sistemato.

Sotto trovi sei blocchi JSON, fra cui il pattern @graph completo che nessuna delle guide italiane che ho letto mostra, i criteri per scegliere i profili sameAs e una checklist finale.

Cos’è lo schema markup: i dati strutturati SEO in tre righe

Lo schema markup è un blocco di codice che descrive il contenuto della pagina usando un vocabolario condiviso, schema.org, scritto in un formato che si chiama JSON-LD e infilato in uno <script> dentro il sorgente. Vocabolario, formato, collocazione: lo schema markup finisce lì.

Due precisazioni che quasi nessuno mette in apertura, e sono quelle che ti evitano tre mesi di aspettative sbagliate.

La prima: i dati strutturati SEO non sono un fattore di ranking, e chi te lo racconta sta vendendo un’altra cosa. Servono a rendere esplicito quello che nella pagina è già scritto in italiano, così Google non deve dedurlo. La seconda riguarda le proprietà obbligatorie: dove esistono, sono il minimo per essere idoneo a un risultato avanzato, non il pulsante che te lo fa comparire. Google decide comunque se mostrarlo, e nella maggior parte dei casi non lo mostra.

Il markup è la targhetta con il nome sul citofono. Non ti fa entrare nessuno in casa, ma senza quella il postino suona a caso.

Qui non spiego cosa sia un’entità né come Google costruisca il suo grafo: se ti serve quella parte, sta nel pillar su cos’è un’entità per Google. In questa pagina si scrive codice e si verifica che funzioni.

Attenzione all’omonimia: i «dati strutturati» dell’informatica sono un’altra cosa

I «dati strutturati» di cui parla questa pagina non hanno niente a che vedere con quelli dei database.

In informatica «dato strutturato» si oppone a «dato non strutturato» e riguarda tabelle, SQL, NoSQL, data lake, colonne tipizzate. È un’omonimia pura: stessa etichetta, due mondi che non si toccano. Se sei arrivato qui cercando la differenza fra dati strutturati e non strutturati per un progetto di data engineering, questa non è la pagina giusta e te lo dico subito invece di farti scorrere altre quattromila parole.

Il vocabolario: quali tipi di schema.org servono davvero

I tipi che servono davvero a un sito editoriale o professionale stanno in una mano e mezza: Organization, Person, WebSite, WebPage, BlogPosting, BreadcrumbList, ProfilePage. Tutto il resto del vocabolario esiste, ma se non vendi prodotti, non organizzi eventi e non pubblichi ricette, non ti riguarda.

La colonna di destra è quella che decide dove spendere il tempo, ed è la distinzione che nelle cinque guide che ho analizzato non compare mai. Marcare un tipo senza effetto visibile non è schema markup buttato: WebPage e Person non producono niente in pagina dei risultati, ma sono i nodi che reggono il grafo e permettono a tutto il resto di collegarsi. Il problema nasce quando qualcuno ti vende il secondo gruppo promettendoti il primo.

Product, Recipe, Event, JobPosting, VideoObject e gli altri esistono e funzionano, ognuno con la sua documentazione e i suoi requisiti. Se il tuo sito è un ecommerce o un portale di annunci, quella è la strada, e il posto dove controllarli è la Search Gallery di Google.

Cosa Google supporta davvero oggi: 25 feature, non tutto schema.org

Schema.org contiene centinaia di tipi, ma quelli che producono qualcosa di visibile in Google stanno tutti in una pagina sola, e sono 25. Conteggio mio del 27 agosto 2026, con la regola dichiarata: ho contato le righe della tabella «Structured data features» della Search Gallery, una riga per feature, ciascuna con il suo bottone «Get started». Un totale la pagina non lo dichiara, dice solo «Last updated 2026-06-15».

La regola conta più della cifra, perché se cambi regola cambia il numero. La card Product è una riga sola, ma la guida a cui porta si ramifica in product snippet, merchant listing e varianti: se conti le sotto-pagine il totale sale, se conti le righe resta 25. Rifai il conto con la mia regola e ti torna, oppure scopri che Google ha cambiato la pagina.

Venticinque su centinaia. Il rapporto spiega da solo perché metà delle discussioni sullo schema markup girino a vuoto: si discute di vocabolario quando la domanda operativa è un’altra, cioè quali di questi tipi Google ha deciso di rappresentare in pagina dei risultati.

Marcare un tipo fuori da quella lista resta legittimo, e in un grafo ben fatto serve. Diventa un problema solo se pensavi che ti facesse comparire qualcosa. Prima di scrivere un blocco nuovo, la Search Gallery è il controllo da trenta secondi che ti dice in quale dei due mestieri sei.

Il cimitero: FAQPage, HowTo, sitelinks searchbox e gli altri tipi morti

Alcuni tipi che le guide italiane consigliano ancora non producono più niente in pagina dei risultati, e per uno di questi la documentazione ufficiale non esiste proprio più.

• FAQPage. Il changelog dell’8 maggio 2026 dice «This feature will no longer appear in Google Search starting May 7, 2026». Il 15 giugno 2026 Google ha rimosso la documentazione del rich result FAQ. Verifica in dieci secondi: apri il vecchio URL developers.google.com/search/docs/appearance/structured-data/faqpage e guarda dove ti porta.
• HowTo. Deprecato dal 2023: «As of September 13, Google Search no longer shows How-to rich results on desktop, which means this result type is now deprecated». Nello stesso annuncio, datato 8 agosto 2023, Google aveva già ristretto le FAQ ai soli «well-known, authoritative government and health websites»: quasi due anni e nove mesi prima di chiuderle del tutto, il 7 maggio 2026.
• Sitelinks searchbox, il cui ritiro è stato annunciato il 21 ottobre 2024, con la sparizione dai risultati dal 21 novembre 2024, globale e in tutte le lingue.
• Course info, estimated salary, learning video, special announcement e vehicle listing, documentazione rimossa il 9 settembre 2025 secondo il changelog.
• Practice problem, deprecato il 5 novembre 2025, documentazione rimossa il 6 gennaio 2026.
• Dataset, che resta valido ma alimenta Dataset Search, non la ricerca normale.

La nota che serve davvero al lettore Google la scrive proprio sulla searchbox: «While you can remove sitelinks search box structured data from your site, there’s no need to do so». Il markup che non produce più niente non fa danno, semplicemente sta lì. Toglierlo è igiene, non emergenza.

Quello che rende questa sezione più utile di quanto sembri: quattro delle cinque guide che ho analizzato per preparare il pezzo consigliano ancora FAQPage come tattica attiva, e una la presenta come il segnale più forte per farsi citare da ChatGPT. Due di queste sono aggiornate a maggio 2026, cioè nelle stesse settimane in cui Google spegneva la feature.

JSON-LD, microdata o RDFa: perché si usa JSON-LD e dove si mette

JSON-LD, e non è una preferenza personale. Lo raccomanda Google nella documentazione introduttiva: «In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale».

L’attenuazione iniziale conta, quindi la lascio dov’è: in general, e if your site’s setup allows it. Google non dice che gli altri due formati siano rotti. Microdata e RDFa sono supportati e continuano a funzionare, solo che vivono attaccati all’HTML della pagina, spalmati dentro gli attributi dei tag. Il giorno che cambi tema, il markup se ne va con il template.

JSON-LD invece è un blocco unico e autonomo. Sta in uno <script type="application/ld+json"> e non tocca il markup visibile: puoi rifare la grafica del sito da zero e quel blocco resta identico. Per la manutenzione a distanza di mesi la differenza è tutta lì.

Dove va messo: nel <head> oppure nel <body>, la documentazione accetta entrambi. La convenzione è il <head>, ma nessuno ti boccia se il tuo CMS lo stampa a fine pagina.

Una nota di lessico per chi cerca in italiano: «microdati» come parola chiave in Italia è occupata dall’ISTAT e non c’entra nulla con questo formato. Si chiamano microdata, e li nomino solo per contrasto tecnico.

Markup iniettato via JavaScript o Google Tag Manager: cosa succede davvero

Google legge il JSON-LD iniettato via JavaScript, compreso quello che arriva da Google Tag Manager. La frase ufficiale è questa: «Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets». Sta nella stessa pagina introduttiva, ed è la fonte che nelle guide dove ho visto la questione trattata non compare mai, motivo per cui una sconsiglia GTM per opinione e un’altra lo promuove senza distinguo.

Chiusa la domanda per Google Search, resta aperto tutto il resto. Il markup scritto lato server arriva nella prima ondata, quello iniettato via JavaScript dipende dal rendering, che avviene dopo e con tempi che non controlli. E i crawler che non sono Googlebot, in larga parte, JavaScript non lo eseguono affatto: se il tuo markup vive solo dentro un tag manager, per loro non esiste. Questa però è una mia osservazione, non una riga di documentazione: se hai una fonte ufficiale che lo dice, scrivimi.

La posizione operativa è secca. Se hai accesso al template, il markup va nel sorgente. GTM è la soluzione per chi non ha accesso al codice, e va bene che esista, ma è un ripiego con un costo: aggiungi un passaggio di rendering fra te e il crawler in cambio di comodità.

Ho aperto il JSON-LD del mio sito e ci ho trovato cinque errori

Il sito su cui stai leggendo aveva cinque errori nel JSON-LD, e li ho trovati la settimana in cui scrivevo questa guida. Non li ho scritti io a mano: me li hanno generati un plugin e il mio stesso script di build, il che li rende molto più interessanti, perché vuol dire che qualcosa di simile lo ha probabilmente generato anche a te.

Comincio dal più imbarazzante. Questo è un estratto reale della home di donatopirolo.dev, ripulito delle proprietà che non servono al discorso:

{ "@type": "ImageObject",
  "@id": "{{featured_image key:url}}",
  "url": "{{featured_image key:url}}",
  "width": "200", "height": "200" },

{ "@type": "WebPage",
  "@id": "https://donatopirolo.dev/#webpage",
  "primaryImageOfPage": { "@id": "{{featured_image key:url}}" } },

{ "@type": "Article",
  "@id": "https://donatopirolo.dev/#richSnippet",
  "image": { "@id": "{{featured_image key:url}}" } }

Quel {{featured_image key:url}} è un segnaposto del plugin che non è mai stato risolto. Compare quattro volte: dentro @id e url del nodo ImageObject, dentro primaryImageOfPage della WebPage e dentro image dell’Article. Il risultato è che il nodo immagine principale della home ha come identificatore una stringa che non è un URL, e due nodi puntano a quella stringa credendo di puntare a una foto.

Gli altri quattro, in ordine di gravità:

Il nodo #person, cioè l’entità principale del sito, è ridotto all’osso: {"@type": ["Person","Organization"], "@id": "https://donatopirolo.dev/#person", "name": "Donato Pirolo"}. Nessun sameAs, nessun url, nessuna immagine. Scrivo da anni di knowledge graph e disambiguazione, e il nodo che dovrebbe dire a Google chi sono è agganciato a niente.

La stessa persona esiste in più nodi distinti. Sul pillar del knowledge graph c’è #person e c’è https://donatopirolo.dev/author/donatopirolo/, e il BlogPosting li usa come se fossero due soggetti diversi: author punta al secondo, publisher punta al primo. Sulla home il nodo autore ha ancora un altro identificatore, https://donatopirolo.dev/author/, e per giunta senza nemmeno la proprietà name. Tre nodi per una persona sola.

Sul nodo autore c’è un sameAs autoreferenziale: "sameAs": ["https://donatopirolo.dev"]. Come disambiguazione vale esattamente zero, perché sto dicendo a Google che quell’entità è la stessa cosa del sito in cui l’entità è già dichiarata. È un cane che si morde la coda con la faccia soddisfatta.

E poi il pezzo da museo. Nel nodo WebSite della home c’è ancora la SearchAction della sitelinks searchbox, ventuno mesi dopo che Google l’ha ritirata. Sul pillar c’è un blocco FAQPage rimasto in pagina dopo la deprecazione di maggio 2026. Due tipi morti, in un sito che parla di entità.

Il punto non è che sono stato sciatto, anche se un po’ lo sono stato. Il punto è che il markup marcisce da solo: cambi tema, aggiorni il plugin, sposti un template, e nessuno ti avvisa, perché sintatticamente il JSON è perfetto e ogni validatore ti dà l’ok.

Aggiornamento del 27 agosto 2026: tre di questi cinque errori adesso non ci sono più. Li lascio scritti perché la diagnosi vale a prescindere, e perché quello che li ha causati è più istruttivo degli errori stessi.

• Il nodo Article sulla home è sparito, e con lui il suo image col segnaposto. La causa non era la home: era l’impostazione pt_page_default_rich_snippet, che dichiarava ogni pagina del sito come un articolo. Una pagina contatti non è un Article, e nessuno se ne accorge finché non apre il JSON-LD.
• Il nodo #person adesso ha sameAs, logo e image. Qui la causa è la più insidiosa che abbia trovato: i profili social erano configurati da mesi, ma salvati sotto la chiave additional_profiles mentre il codice del plugin legge social_additional_profiles. Configurazione compilata, campo giusto nell’interfaccia, chiave sbagliata nel database: in pagina non arrivava niente. Se il tuo sameAs è vuoto e giuri di aver messo i link, guarda lì prima di riscriverli.
• Il sameAs autoreferenziale è sparito: veniva dal campo «Sito web» del profilo utente, che il plugin infila nel sameAs dell’autore. Dire «questa persona è anche il mio sito» non è un’identità, è un errore di categoria.

Restano in piedi due cose, e tutte e due per un motivo. Il segnaposto {{featured_image key:url}} è ancora nell’ImageObject della home: si spegnerebbe dando alla home un’immagine in evidenza, ma il template la mostrerebbe anche in pagina, e non è una modifica da fare di nascosto per aggiustare un JSON. La SearchAction si toglie solo con un filtro PHP, perché il plugin non espone l’opzione. Le trovi ancora tutte e due con il curl di prima, insieme al FAQPage su /knowledge-graph/: quello lo tengo apposta, è la prova che stai leggendo.

Come si legge il markup che hai già, in trenta secondi

Si legge con una riga di terminale, con il tasto destro del browser, oppure incollando l’URL in un validatore. Trenta secondi, e prima di questo passaggio qualunque intervento sullo schema markup è alla cieca.

La via più rapida da riga di comando:

curl -s https://tuosito.it/ | grep -A5 'application/ld+json'

Da browser, Ctrl+U per il sorgente e poi cerchi application/ld+json. Attenzione a una differenza che conta: il sorgente ti mostra quello che il server ha spedito, l’ispettore degli strumenti per sviluppatori ti mostra il DOM dopo il JavaScript. Se il tuo markup arriva via GTM, nel primo non lo trovi e nel secondo sì. Il markup è lo stesso, cambia dove lo stai guardando.

Terza via, quella che ti dà anche gli errori: incolli l’URL nello Schema Markup Validator e leggi l’albero dei nodi.

Diagnosi prima della cura. La domanda a cui rispondere prima di scrivere qualunque cosa è «cosa mi sta già generando il CMS, e quante volte».

Organization: le proprietà che contano (e quelle che servono in Italia)

Lo schema markup Organization non ha proprietà obbligatorie. La documentazione di Google lo scrive senza giri di parole: «There are no required properties; instead, add the properties that apply to your organization».

Vale la pena fermarsi un attimo, perché almeno una delle guide che ho analizzato costruisce una tassonomia a tre livelli in cui @type, name e url risultano required. Non lo sono. Esiste una sola lista, ed è quella delle raccomandate, che nella documentazione Organization sono ventitré: address, alternateName, contactPoint, description, duns, email, foundingDate, globalLocationNumber, hasMerchantReturnPolicy, hasMemberProgram, hasShippingService, iso6523Code, legalName, leiCode, logo, naics, name, numberOfEmployees, sameAs, taxID, telephone, url, vatID.

Nella pratica ne metti sempre tre: name, url, logo. Sul logo c’è il vincolo tecnico più secco della sezione, e va rispettato alla lettera: almeno 112×112 pixel, in un formato che Google Immagini sappia leggere, e leggibile su fondo bianco. Un logo bianco su PNG trasparente tecnicamente passa e visivamente sparisce.

Poi c’è la parte che nelle due guide in inglese che ho letto non c’è, e si capisce perché: a chi scrive dagli Stati Uniti non serve. vatID è la partita IVA, taxID il codice fiscale, legalName la ragione sociale completa con la forma giuridica, leiCode il Legal Entity Identifier, iso6523Code l’identificativo secondo lo standard ISO, duns il numero D-U-N-S, naics il codice di classificazione settoriale. Stanno tutte nella lista ufficiale delle raccomandate, e sono il modo previsto per dichiarare nel markup che quell’azienda è quell’azienda lì, quella con quel numero al registro imprese.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://esempio.it/#organization",
  "name": "Esempio",
  "legalName": "Esempio S.r.l.",
  "url": "https://esempio.it/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://esempio.it/wp-content/uploads/logo.png",
    "width": 512,
    "height": 512
  },
  "vatID": "IT01234567890",
  "taxID": "01234567890",
  "foundingDate": "2014-03-01",
  "email": "info@esempio.it",
  "telephone": "+39 051 0000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via Roma 1",
    "postalCode": "40121",
    "addressLocality": "Bologna",
    "addressRegion": "BO",
    "addressCountry": "IT"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "telephone": "+39 051 0000000",
    "email": "info@esempio.it",
    "availableLanguage": ["Italian", "English"]
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/esempio"
  ]
}

Ultima cosa, ed è quella che i plugin sbagliano più spesso: questo blocco non va su tutte le pagine del sito. Google indica la home o la singola pagina che descrive l’organizzazione, tipo «chi siamo». Testuale: «You don’t need to include it on every page of your site».

Person, WebSite e ProfilePage: gli altri nodi dell’entity home

Person descrive te, WebSite descrive il sito, ProfilePage descrive la pagina che parla di te. Se sei un professionista e non una società, questi tre nodi più la home sono la tua entity home, e Organization diventa opzionale. È il minimo sindacale di schema markup per un sito personale.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://donatopirolo.dev/#person",
      "name": "Donato Pirolo",
      "alternateName": "donatopirolo",
      "url": "https://donatopirolo.dev/",
      "jobTitle": "Esperto SEO e AI",
      "sameAs": [
        "https://www.linkedin.com/in/donatopirolo",
        "https://www.instagram.com/donatopirolo/",
        "https://www.facebook.com/pirolodonato"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://donatopirolo.dev/#website",
      "url": "https://donatopirolo.dev/",
      "name": "Donato Pirolo",
      "inLanguage": "it-IT",
      "publisher": { "@id": "https://donatopirolo.dev/#person" }
    }
  ]
}

Su WebSite serve un avvertimento. La variante con potentialAction e SearchAction, quella della sitelinks searchbox, è morta, e io ce l’ho ancora addosso. Il nodo WebSite in sé resta utile: la sua funzione per il nome del sito nei risultati è viva, ed è la ragione per cui non si butta.

ProfilePage è il tipo che nelle cinque guide che ho analizzato non compare mai, e per il cluster entità è il più adatto di tutti. Ha una sola proprietà richiesta, mainEntity, cioè «The person or organization that this profile page is about». La documentazione la indica esplicitamente anche per le pagine autore dei siti editoriali e per le pagine «About Me» dei blog, e fra le raccomandate della Person o Organization che ci metti dentro c’è sameAs, descritto come «The URL to other external profiles or home pages for the profile».

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://donatopirolo.dev/chi-sono/#profilepage",
  "url": "https://donatopirolo.dev/chi-sono/",
  "dateModified": "2026-08-26T10:00:00+02:00",
  "mainEntity": { "@id": "https://donatopirolo.dev/#person" }
}

Nota il mainEntity che richiama per @id il nodo Person definito altrove, invece di ridefinirlo. È il meccanismo di tutta la sezione successiva.

Regola sui nomi, breve e disattesa ovunque: in name va il nome vero, in alternateName la handle social. «donatopirolo» è come mi chiamo su LinkedIn, non come mi chiamo.

@id e @graph: come si collegano i nodi fra loro

@id è l’identificatore univoco di un nodo, e @graph è il contenitore che ti permette di dichiarare più nodi in un blocco solo e collegarli fra loro invece di ripeterli. Insieme sono la differenza fra un markup che descrive una pagina e un markup che descrive un sito.

Google documenta il meccanismo nelle linee guida generali sui dati strutturati, dove spiega le due strategie per gestire più elementi nella stessa pagina, annidarli oppure tenerli separati e collegarli: «If there are items that are more helpful when they are linked together (for example, a recipe and a video), use @id in both the recipe and the video items to specify that the video is about the recipe on the page».

Esiste quindi una fonte ufficiale, ed è la stessa che una delle guide italiane cita a parole per poi pubblicare un blocco di codice in cui @id non compare da nessuna parte.

Il pattern completo per una pagina di articolo è questo, ed è copiabile così com’è cambiando dominio e valori:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://esempio.it/#person",
      "name": "Nome Cognome",
      "url": "https://esempio.it/",
      "sameAs": ["https://www.linkedin.com/in/nomecognome"]
    },
    {
      "@type": "WebSite",
      "@id": "https://esempio.it/#website",
      "url": "https://esempio.it/",
      "name": "Nome Cognome",
      "inLanguage": "it-IT",
      "publisher": { "@id": "https://esempio.it/#person" }
    },
    {
      "@type": "WebPage",
      "@id": "https://esempio.it/schema-markup/#webpage",
      "url": "https://esempio.it/schema-markup/",
      "name": "Titolo della pagina",
      "isPartOf": { "@id": "https://esempio.it/#website" },
      "about": { "@id": "https://esempio.it/#person" },
      "primaryImageOfPage": { "@id": "https://esempio.it/schema-markup/#primaryimage" },
      "breadcrumb": { "@id": "https://esempio.it/schema-markup/#breadcrumb" },
      "inLanguage": "it-IT"
    },
    {
      "@type": "ImageObject",
      "@id": "https://esempio.it/schema-markup/#primaryimage",
      "url": "https://esempio.it/wp-content/uploads/copertina.png",
      "width": 1200,
      "height": 675
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://esempio.it/schema-markup/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://esempio.it/" },
        { "@type": "ListItem", "position": 2, "name": "Schema markup" }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://esempio.it/schema-markup/#article",
      "headline": "Titolo dell'articolo",
      "datePublished": "2026-08-27T09:00:00+02:00",
      "dateModified": "2026-08-27T09:00:00+02:00",
      "author": { "@id": "https://esempio.it/#person" },
      "publisher": { "@id": "https://esempio.it/#person" },
      "isPartOf": { "@id": "https://esempio.it/schema-markup/#webpage" },
      "mainEntityOfPage": { "@id": "https://esempio.it/schema-markup/#webpage" },
      "image": { "@id": "https://esempio.it/schema-markup/#primaryimage" },
      "inLanguage": "it-IT"
    }
  ]
}

Leggilo dal basso: il BlogPosting dice chi lo ha scritto e chi lo pubblica puntando allo stesso nodo Person, dice di quale pagina fa parte, e usa l’immagine dichiarata una volta sola più su. La WebPage dice di quale sito fa parte e qual è il suo percorso di navigazione. Nessun dato è ripetuto due volte, e se domani cambi il tuo profilo LinkedIn lo modifichi in un punto.

La regola d’oro sta in una riga: un @id per entità, stabile nel tempo, identico su tutte le pagine del sito. https://esempio.it/#person deve essere quella stringa lì, uguale, sulla home e sull’ultimo articolo del blog. Il giorno che diventa #person-1 su una pagina sola, hai due persone.

Gli errori di collegamento più frequenti

Il grafo si rompe quasi sempre allo stesso modo, e cioè con due nodi che descrivono la stessa cosa senza saperlo. Quattro casi, due dei quali li ho trovati addosso al mio sito.

• Entità spaccata su due nodi. Il caso #person contro /author/donatopirolo/: il CMS crea un nodo per il sito e un altro per l’archivio autore, e l’articolo li tratta come soggetti diversi. La cura è far puntare author e publisher allo stesso @id.
• @id che cambiano da una pagina all’altra. Se l’identificatore del nodo persona non è identico ovunque, ogni pagina dichiara un’entità nuova. Il grafo diventa una folla di sconosciuti con la stessa faccia.
• Doppio nodo Organization. Lo genera il tema, lo rigenera il plugin SEO, e ti ritrovi due aziende con lo stesso nome e proprietà diverse. Si controlla nel validatore, dove i due nodi si vedono uno sotto l’altro.
• @id trattato come un URL da visitare. È un identificatore, non un indirizzo: non è tenuto a rispondere 200. La convenzione del frammento (/#person) esiste proprio per questo, e va benissimo che quel frammento non porti da nessuna parte.

sameAs: quali profili metterci, quanti e in che ordine

In sameAs va l’URL di una pagina, su un altro sito, che identifica senza ambiguità la stessa entità del nodo. La definizione di schema.org è questa: «URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website». Google, nella pagina di Organization, la traduce in termini pratici: «The URL of a page on another website with additional information about your organization», per esempio il profilo su un social o su un sito di recensioni, e ne puoi indicare più di uno.

L’ordine che uso, argomentato e non alfabetico:

1. Wikidata, se l’entità ce l’ha. È un identificatore stabile e indipendente dalla lingua, e questo risolve alla radice il dilemma «Wikipedia italiana o inglese» che si porta dietro qualunque sito non anglofono. Wikidata è una sola per tutte le lingue, gli esempi della pagina schema.org usano proprio URI Wikidata.
2. Sito ufficiale o entity home, quando il nodo che stai marcando vive su un dominio diverso da quello ufficiale.
3. Profili professionali che controlli e che linkano indietro: LinkedIn, GitHub, Crunchbase, un profilo relatore su un sito di conferenze. La reciprocità del link è quello che li rende utili.
4. Social, per ultimi e senza esagerare con il numero.

"sameAs": [
  "https://www.wikidata.org/wiki/Q00000000",
  "https://www.linkedin.com/in/nomecognome",
  "https://github.com/nomecognome",
  "https://www.crunchbase.com/organization/nome"
]

Se un ID Wikidata non ce l’hai, quella prima riga si toglie. Non si inventa e non si mette l’ID di un omonimo: un identificatore sbagliato è peggio di un identificatore assente, perché stai dichiarando di essere un’altra persona.

Criteri di selezione, tutti verificabili prima di incollare:

• Solo profili attivi e che controlli. Un account fermo dal 2019 con la biografia di due lavori fa non aiuta a disambiguare, descrive qualcun altro.
• URL canonico, non redirect. Se linkedin.com/in/nome risponde 301 verso un’altra forma, ci va la forma finale.
• Informazioni coerenti fra il profilo e il markup. Se nel markup sei «Esperto SEO e AI» e su LinkedIn sei «Digital Marketing Manager», l’unica cosa che stai disambiguando è la tua incoerenza.
• Reciprocità dove possibile. Il profilo deve linkare il sito. È il segnale che rende la coppia verificabile da fuori.

Cosa non metterci, e il primo lo scrivo per esperienza diretta perché ce l’ho ancora addosso: un sameAs verso il tuo stesso dominio. Poi profili morti, account di omonimi trovati cercando il proprio nome, ed elenchi gonfiati con dieci social per fare volume. Quattro URL solidi valgono più di dodici a caso.

Se ti interessa il perché di tutto questo, e cioè come Google costruisca la sua idea di chi sei, sta nel pillar su cos’è un’entità per Google.

Quanto vale sameAs davvero (senza vendere fuffa)

sameAs serve a togliere ambiguità su chi sei, e di effetti sul posizionamento non ho trovato prove. Detta così sembra poco: è già molto, ed è tutto quello che si può affermare onestamente.

I due numeri che circolano nelle guide che ho letto non reggono a una verifica. Uno è un case study che parla di siti che avrebbero guadagnato posizioni, senza campione e senza metodologia. L’altro è un «+20-30% di CTR» attribuito a «studies show», ripetuto due volte nello stesso articolo e mai collegato a uno studio. Non aggiungo una sesta cifra inventata al mucchio: preferisco dirti che di cifre verificabili, su questo, non ne ho.

Sulle AI Overviews e su AI Mode, Google è esplicito nella guida alle AI features: «You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add». Chi ti vende uno schema speciale per farti citare dalle AI ti sta vendendo qualcosa che Google dichiara non esistere. Fra le raccomandazioni tecniche della stessa pagina c’è però una riga che vale la pena tenere a mente, ed è «Making sure your structured data matches the visible text on the page».

Il markup ben fatto rende esplicito quello che sei. Poi Google decide da solo cosa farne, e la parte del riquadro in pagina dei risultati è un’altra storia, che sta nel pezzo su come si ottiene una scheda informativa in SERP. Qui si scrive codice.

Coerenza dei dati: NAP e naming fra sito, markup e piattaforme

La coerenza NAP non è una regola di Google, ed è giusto saperlo prima di trattarla come un obbligo. La documentazione LocalBusiness elenca name e address come uniche proprietà richieste, con telephone, url, geo, openingHoursSpecification e altre fra le raccomandate, e non contiene una riga sulla coerenza fra markup, sito e Google Business Profile.

Resta una pratica di igiene professionale, e funziona per una ragione meccanica: nome, indirizzo e telefono sono le tre stringhe con cui un sistema automatico decide se due schede parlano della stessa attività. Se il tuo indirizzo è «Via Roma 1» nel markup, «via Roma, 1» sul sito e «V.le Roma 1» su Business Profile, stai chiedendo a un algoritmo di fare un salto di fede.

Quello che Google scrive davvero, sempre nella guida alle AI features, è di tenere aggiornate le informazioni di Business Profile e di Merchant Center. Che è la stessa idea vista dall’altro lato: le tue schede devono dire la verità corrente.

La regola operativa sta in una riga. Lo stesso nome, lo stesso indirizzo, lo stesso telefono, scritti nello stesso identico modo, in markup, sito, Google Business Profile e directory.

Vale anche per chi una sede fisica non ce l’ha, e qui ho un altro caso mio da consegnare. Il nodo WebSite del mio sito si chiama «Esperto SEO e AI», il nodo Person si chiama «Donato Pirolo». Sono due stringhe diverse per la stessa cosa, una è una qualifica travestita da nome, e nessuna delle due è sbagliata di per sé. Il problema è che il naming del sito racconta una storia e il naming dell’entità ne racconta un’altra. La qualifica sta bene in jobTitle o in description, non in name.

Organization o LocalBusiness: quale dei due (e mai a caso tutti e due)

LocalBusiness se hai una sede fisica con orari di apertura, Organization in tutti gli altri casi. Uno solo dei due, mai entrambi.

LocalBusiness è un sottotipo di Organization, quindi eredita tutte le sue proprietà e ne aggiunge di specifiche, come gli orari e la geolocalizzazione. Dichiararli tutti e due significa creare due nodi che descrivono la stessa azienda con due tipi diversi, ed è esattamente il doppione che tema e plugin generano insieme senza dirtelo.

La regola generale di Google, nelle linee guida sui dati strutturati, è questa: «Try to use the most specific applicable type and property names defined by schema.org for your markup». Più specifico applicabile, quindi: se gli orari ce li hai, LocalBusiness. Se lavori da casa e non ricevi clienti, Organization e amen.

Come si verifica che Google lo legga davvero: i quattro test dei dati strutturati

I test dati strutturati sono quattro e non sono intercambiabili: ognuno risponde a una domanda diversa, e usarne uno solo è il motivo per cui la gente si convince che «il markup è a posto» mentre non lo è. Chi ne cerca uno di solito ha in mente il Rich Results Test, e la risposta scomoda è che di test ne servono almeno due, più due controlli che test non sono.

• Rich Results Test. Risponde a una domanda sola: questa pagina è idonea a un risultato avanzato di Google? Per costruzione ignora i tipi che un rich result non ce l’hanno, quindi se ci incolli una pagina piena di Person e WebPage ti dirà che non ha trovato niente. Non è un errore, è il suo mestiere.
• Schema Markup Validator. Valida l’intero vocabolario schema.org, anche i tipi che Google non mostra. È lo strumento con cui si controlla un grafo, perché ti disegna l’albero dei nodi e ti fa vedere i collegamenti @id che tornano e quelli che non tornano.
• Controllo URL in Search Console. Ti dice cosa Google ha visto sulla tua pagina reale dopo il rendering, che è un’altra cosa rispetto a quello che ha visto un test su richiesta.
• Rapporto Risultati avanzati. Ti dice cosa succede in produzione su tutto il sito, non su una pagina. È il test dei dati strutturati che conta davvero, perché è l’unico che parla di quello che Google sta effettivamente elaborando adesso.

Nel rapporto due parole vanno lette con attenzione. L’elemento non valido è quello che ti esclude: «An invalid item has at least one critical issue preventing it from appearing as a rich result». I problemi non critici finiscono sotto «Improve item appearance», e sono suggerimenti: non ti tolgono da niente, migliorano quello che c’è. La documentazione del rapporto lo distingue in modo netto, e la differenza vale ore di lavoro sprecate a rincorrere avvisi innocui mentre un errore bloccante ti aspetta due righe più sotto.

Il Rich Results Test passa ma la Search Console no: le tre cause

Le cause sono tre, e nessuna delle tre è un difetto del test. Il Rich Results Test guarda la pagina adesso, su richiesta; Search Console riporta quello che il crawler ha raccolto l’ultima volta che è passato. Sono due orologi diversi.

Causa uno: la pagina non è ancora stata ricrawlata. I dati stanno sul tuo sito, non sui server di Google, quindi una correzione si vede al passaggio successivo del crawler e non un minuto prima. Nella documentazione del rapporto c’è anche una regola che spiazza chi guarda le date: «If all issues of this type are resolved, but a new instance of this issue appears within 90 days, the date will be the original first detected date». Se lo stesso tipo di problema ricompare entro novanta giorni, la data resta quella della prima rilevazione, e tu ti convinci di non aver corretto niente.

Causa due: stai testando un URL diverso dal canonico. Search Console ragiona sulla pagina canonica, il tuo test sull’indirizzo che hai incollato. Le linee guida raccomandano, se hai pagine duplicate dello stesso contenuto, di «placing the same structured data on all page duplicates, not just on the canonical page». Se il markup lo hai messo solo sulla versione che stai testando, il canonico ne è privo.

Causa tre: il markup arriva dal rendering. Il test esegue il JavaScript e lo vede, il tuo curl no. Search Console non sbaglia: stavi guardando due sorgenti diversi convinto che fossero lo stesso.

Generatori, plugin e scorciatoie: cosa risolvono e cosa rompono

Il generatore ti fa il primo blocco, il plugin te lo mantiene e ogni tanto te lo rompe, il template lato server è la strada giusta se hai accesso al codice. Le tre strade non si equivalgono e servono a momenti diversi del lavoro sui dati strutturati SEO.

Un generatore online di schema markup è perfetto per capire la forma di un tipo che non conosci: ci metti i valori, ti sputa il JSON, lo incolli. Poi finisce lì, perché non mantiene niente. Il markup generato una volta e incollato a mano è un markup che fra sei mesi dirà cose false sulle date, sull’autore o sulle immagini.

Un plugin del CMS genera da solo su tutte le pagine, ed è il motivo per cui va controllato invece che dimenticato. È lui che decide quanti nodi Person esistono nel tuo grafo, ed è lui che lascia i segnaposto irrisolti.

Il template lato server è la strada che consiglio a chi tocca il codice: scrivi tu il grafo, sai cosa contiene, arriva nella prima ondata di HTML e non dipende dal rendering.

Il caso che tiene insieme la sezione l’hai già letto qualche schermata più su. Il {{featured_image key:url}} sulla mia home non l’ho scritto io, me l’ha messo il plugin, e nessuno degli strumenti che uso me lo aveva segnalato, per una ragione banale: il JSON è sintatticamente perfetto. Una stringa è una stringa, il validatore non ha modo di sapere che quella doveva essere l’URL di una foto. Gli strumenti trovano gli errori di forma, non le bugie.

Chiudo con la posizione ufficiale di Google del 5 giugno 2026 sui servizi SEO di terze parti, che vale per i generatori come per i plugin come per chiunque ti prometta visibilità sulle AI: «Google doesn’t evaluate third-party services, so be wary of such claims and those making them. Keep in mind that using a service or tool doesn’t guarantee ranking success».

La checklist

Si controlla in quest’ordine, perché ogni passo dipende dal precedente.

1. Guarda cosa hai già. Un curl con grep o Ctrl+U, prima di scrivere qualunque riga nuova.
2. Scegli i tipi dalla Search Gallery di oggi, non da una guida dell’anno scorso: al 27 agosto 2026 le feature elencate sono 25, una per riga della tabella, e la pagina porta la data dell’ultimo aggiornamento in fondo.
3. Un solo @graph per pagina, con dentro tutti i nodi, invece di quattro blocchi separati che non si parlano.
4. Un @id per entità, stabile e identico su tutto il sito. Se cambia da una pagina all’altra, hai due entità.
5. sameAs solo verso profili che controlli, attivi, in URL canonico, e che linkano indietro. Mai verso il tuo stesso dominio.
6. Metti le proprietà raccomandate che ti riguardano, comprese vatID, taxID e legalName se sei un’azienda italiana.
7. Controlla il logo: almeno 112×112 px, formato leggibile da Google Immagini, visibile su fondo bianco.
8. Markup nel sorgente, non solo via tag manager, se hai accesso al template.
9. Valida con entrambi gli strumenti: Rich Results Test per l’idoneità, Schema Markup Validator per il grafo.
10. Conferma con Controllo URL in Search Console, e rimettilo in calendario fra sei mesi, perché il markup marcisce da solo.

Il markup non è un lavoro che finisce. È una cosa che si guasta in silenzio mentre tu fai altro: aggiorni il tema e sparisce un nodo, cambi plugin e ne compare uno doppio, Google ritira una feature e il tuo blocco resta lì a marcire per ventuno mesi come la mia SearchAction. Nessun alert ti avvisa, perché dal punto di vista della sintassi non è successo niente di male. Per questo l’ultima riga della checklist è un promemoria a sei mesi: è l’unico modo che ho trovato per accorgermene prima che se ne accorga qualcun altro.

Adesso tocca a te. Apri il sorgente del tuo sito, cerca application/ld+json e guarda cosa ci trovi. Se ci trovi qualcosa di peggio dei miei cinque errori, scrivimi che lo guardiamo insieme, e se è un caso italiano interessante ne facciamo un pezzo. Per la parte teorica, cioè cos’è un’entità per Google, c’è il pillar; per il riquadro in pagina dei risultati, come si ottiene una scheda informativa in SERP.

Domande frequenti

Le domande qui sotto hanno la risposta nella prima riga. Sotto non c’è nessun markup FAQPage, e la ragione sta nel cimitero qualche schermata più su: quel rich result non esiste più dal 7 maggio 2026, quindi il blocco servirebbe solo a farmi contraddire da solo. Questa sezione è scritta per te e per chi estrae il testo, non per la SERP.