Nel sito della tua azienda il nome compare in tre versioni diverse: sulla pagina dei contatti, nel footer e nella scheda di un prodotto. I dati strutturati aiutano i motori di ricerca a interpretare informazioni come queste, purché descrivano ciò che la pagina mostra davvero.
Il markup funziona quando descrive dati già presenti e coerenti
- JSON-LD è spesso il formato più pratico da mantenere, se il tuo sito lo supporta bene.
- Schema.org offre tipi e proprietà per descrivere aziende, prodotti, articoli e altri contenuti.
- Un test valido indica che il markup è leggibile, ma non garantisce un risultato avanzato.
- Per un’azienda, comincia dalle informazioni stabili e verificabili, poi collega il markup ai dati del CMS.
- Dal 7 maggio 2026 Google non mostra più risultati avanzati FAQ nella Ricerca.
I dati strutturati trasformano i campi del sito in informazioni interpretabili
Una pagina può dire “assistenza tecnica”, ma il codice da solo non chiarisce se si tratta di un servizio, di un’organizzazione o del titolo di un articolo. Il markup aggiunge questa etichetta semantica: associa un tipo, come `Organization`, a proprietà quali nome e recapiti.
Per il tuo sito aziendale, la parte utile è rendere più esplicite informazioni che già gestisci: chi è l’impresa, cosa vende, dove opera e come sono collegate le pagine. Questi dati possono aiutare i sistemi di ricerca a comprendere il contenuto; non sono un comando che obbliga Google a mostrare un risultato arricchito.
Schema.org è il vocabolario condiviso che definisce tipi e proprietà. JSON-LD, Microdata e RDFa sono invece tre modi diversi di inserire quel vocabolario nella pagina: confonderli porta spesso a scegliere il markup prima di aver chiarito quale informazione si vuole descrivere.
Organization, LocalBusiness e Product descrivono casi diversi
Una sede fisica con orari e indirizzo non coincide con l’intera azienda, e un prodotto non coincide con la pagina che lo racconta. Per me, scegliere il tipo corretto viene prima di aggiungere proprietà: una descrizione precisa ma aderente alla pagina vale più di un blocco pieno di campi.
Schema.org definisce `Organization` per descrivere un’organizzazione, `LocalBusiness` per un’attività o una sua sede fisica e `Product` per un prodotto. In pratica, un’impresa con più filiali può descrivere l’identità generale dell’azienda e, nelle pagine dedicate, le singole sedi; la scheda di un articolo in vendita può invece usare proprietà proprie del prodotto, come nome e offerte, quando quei dati sono presenti e aggiornati.
Google Search Central distingue anche tra il vocabolario Schema.org e i tipi che possono essere idonei a specifiche presentazioni nella Ricerca. Un tipo valido per Schema.org non implica automaticamente un rich result: prima di implementarlo per ottenere un elemento visivo, controlla che Google supporti quel tipo e che la pagina rispetti i relativi requisiti.
JSON-LD è più semplice da mantenere quando nasce dal CMS
Se il nome aziendale viene aggiornato nel CMS ma resta scritto a mano anche nel markup, prima o poi le due versioni divergono. Google consiglia in generale JSON-LD perché separa le annotazioni dal testo visibile e può essere più facile da gestire; il vantaggio pratico emerge soprattutto quando il codice viene generato dagli stessi campi della pagina.
Un esempio essenziale per una pagina aziendale può assomigliare a questo:
Sostituisci i valori con quelli reali e aggiungi solo proprietà pertinenti e visibili o verificabili sul sito. Per un’organizzazione locale, un prodotto o un articolo serve il tipo adatto; riutilizzare questo esempio cambiando soltanto il nome produrrebbe un markup formalmente plausibile, ma poco descrittivo.
Quando l’anagrafica aziendale, i prodotti e i recapiti sono già governati in modo coerente, il markup può riutilizzare quei dati senza creare copie manuali da mantenere. È un approccio più ordinato anche per i processi digitali sostenibili: meno duplicazioni significano meno correzioni ripetute quando cambia un’informazione.
Il test segnala errori tecnici, non promette visibilità
Un test verde può rassicurare, ma risponde a una domanda limitata: il codice è leggibile e, per le funzioni supportate, soddisfa i requisiti tecnici rilevati? Le linee guida di Google chiariscono che un markup corretto non garantisce la visualizzazione di un risultato avanzato e che un’azione manuale sui dati strutturati toglie l’idoneità a quel risultato, senza modificare il ranking nella Ricerca.
| Situazione | Possibile causa | Cosa fare |
|---|---|---|
| Il test non trova dati | Il codice non viene emesso nella pagina pubblicata oppure il rendering non lo rende accessibile. | Controlla la versione accessibile della pagina con il test e l’ispezione URL. |
| Il codice è valido ma il risultato non appare | La visualizzazione dipende dai sistemi di Google e dai requisiti del tipo di risultato. | Verifica la copertura in Search Console e considera il markup un aiuto all’interpretazione, non una promessa. |
| Il markup contiene prezzi, orari o recensioni diversi dalla pagina | I dati sono duplicati o non aggiornati, oppure descrivono contenuti non visibili. | Allinea il markup alla fonte dati del sito e rimuovi i campi non dimostrabili nella pagina. |
| Il test segnala un errore in una proprietà obbligatoria | Manca un requisito specifico del rich result che si vuole ottenere. | Consulta i requisiti del tipo preciso, correggi il dato e ripeti il test. |
La verifica non finisce con la sintassi: Google richiede che il markup rappresenti fedelmente il contenuto e non descriva informazioni nascoste o fuorvianti. Per questo collegare i campi ai dati effettivi del sito è più robusto che copiare un esempio e riempirlo a mano.
Le FAQ marcate non generano più risultati avanzati su Google
Molte guide meno recenti presentano `FAQPage` come una scorciatoia per ottenere domande espandibili nella pagina dei risultati. Dal 7 maggio 2026, però, Google non mostra più quel rich result nella Ricerca e ha rimosso la relativa documentazione: mantenere il markup per inseguire quell’aspetto non è una strategia utile per un normale sito aziendale.
La modifica riguarda la presentazione di Google, non rende di per sé invalido il vocabolario Schema.org. Google Search Central specifica inoltre che la rimozione del rich result FAQ non incide sul ranking; se le domande frequenti aiutano chi visita il sito, puoi lasciarle nella pagina per le persone, senza investire nel markup con l’aspettativa delle vecchie espansioni.
Questa distinzione è un buon criterio anche per altri tipi: prima controlla che la funzione esista ancora nella Ricerca e poi valuta il costo di implementazione. Un markup semanticamente corretto può restare utile ad altri sistemi, ma il beneficio atteso va deciso in base al caso d’uso, non a schermate o istruzioni superate.
Parti dalle informazioni che l’azienda può mantenere corrette
Per decidere da dove cominciare, scegli una pagina importante e confronta il testo visibile, i campi del CMS e il markup generato: se dicono cose diverse, correggi prima la fonte. Poi verifica i requisiti del tipo selezionato e controlla la pagina pubblicata, non soltanto il frammento di codice nell’editor.
Io partirei dall’identità dell’organizzazione e dalle pagine di prodotto o servizio con dati già aggiornati nel gestionale. Così il markup chiarisce informazioni affidabili e si integra in un processo che il team può davvero mantenere, invece di aggiungere un altro strato di dati destinato a diventare obsoleto.