La maggior parte dei siti che usa JSON-LD oggi non supererebbe un controllo di buon senso elementare: incollare i propri dati strutturati in un validatore e vedere cosa esce davvero. Non "è ottimizzato". Semplicemente: viene interpretato correttamente. Punta a un'unica entità o a tre entità in conflitto tra loro. È markup per un rich result che Google concede ancora.
Lo schema è diventato una casella da spuntare — si installa un plugin, si copia un template da un post di blog, e tutti danno per scontato che funzioni perché visivamente sulla pagina non è cambiato nulla. I malfunzionamenti dei dati strutturati sono invisibili per natura. Non c'è un layout rotto da notare. C'è solo un Knowledge Graph che non capisce mai del tutto chi sei, e rich result che non compaiono mai, e nessuno che va a fare debug perché in apparenza non c'è nulla che non va.
Cosa fa davvero il JSON-LD nel 2026
Sotto l'etichetta "schema markup" convivono due compiti distinti, e confonderli è la fonte di gran parte dello sforzo sprecato.
Il primo compito sono i rich result: i miglioramenti visivi nella SERP — valutazioni a stelle, fasce di prezzo, date di eventi, annunci di lavoro, breadcrumb, miniature video. Solo un insieme ristretto di `@type` è ammesso, e Google modifica quell'insieme senza troppo preavviso.
Il secondo compito è la chiarezza dell'entità: dire a Google chi sei, di cosa fai parte e come le tue pagine si relazionano tra loro. `Organization`, `WebSite`, `Person` e `WebPage` svolgono soprattutto questo ruolo. Raramente producono da soli uno snippet visibile, ma sono ciò da cui attingono il Knowledge Panel, la sitelinks search box e la disambiguazione del brand.
La maggior parte degli errori di schema che vale la pena correggere rientra in una di tre categorie, e nessuna è sottile una volta che sai dove guardare.
Errore 1: JSON rotto per problemi di escaping nel template
Questo è il malfunzionamento più comune e il meno visibile. Avviene nel punto di giunzione tra il tuo CMS e il tag `<script type="application/ld+json">`.
Una citazione di recensione con una virgoletta doppia isolata al suo interno. Una descrizione prodotto incollata da una scheda tecnica con un'interruzione di riga grezza nel mezzo. Ognuno di questi casi, inserito in un template JSON-LD tramite semplice concatenazione di stringhe invece che con una serializzazione corretta, produce qualcosa del genere:
```json { "@type": "Product", "name": "Editor's Choice Desk Lamp", "description": "The reviewer called it "the best lamp under $50"" } ```
Quella virgoletta doppia interna non sottoposta a escaping interrompe il parser JSON esattamente in quel punto. Il Rich Results Test di Google la segnalerà come non valida — ma quel test di norma viene eseguito una sola volta, al lancio, su un URL scelto a mano. Nessuno lo rilancia sulle 400 pagine prodotto pubblicate sei mesi dopo con le abitudini di punteggiatura di un nuovo copywriter.
La correzione non è complicata: non costruire mai la stringa JSON a mano. Costruisci l'oggetto nel tuo linguaggio di templating e serializzalo correttamente (`JSON.stringify` in JS, `json_encode` in PHP, l'equivalente in qualunque cosa renderizzi le tue pagine), così l'escaping viene gestito da codice che sa cos'è il JSON, non da chi scrive il template e non lo sa. Poi valida l'HTML renderizzato — la risposta reale che vede un crawler — non il sorgente del template. Un template può sembrare perfetto e comunque generare JSON rotto per qualsiasi stringa che contenga un carattere speciale.
Errore 2: Entità Organization duplicate senza un @id condiviso
Questo caso emerge quasi sempre quando un sito è passato per un redesign, una migrazione di CMS, o più di un plugin SEO usato contemporaneamente.
Il tema emette un blocco `Organization` nel footer. Un plugin ne emette un altro su ogni pagina, con un `logo` e una lista `sameAs` leggermente diversi. Uno sviluppatore ne ha aggiunto un terzo, a mano, sulla homepage, due anni fa, per un test dello schema markup mai ripulito dopo. Nessuno di questi condivide un `@id`.
Per Google, tre oggetti `Organization` senza un identificatore condiviso non si leggono come "la stessa azienda descritta tre volte". Si leggono come ambigui — possibilmente tre entità diverse, possibilmente segnali duplicati che si annullano a vicenda. Ed è esattamente quell'ambiguità che il markup di entità dovrebbe prevenire.
La correzione è un unico `@id` canonico, coniato una volta e referenziato ovunque:
```json { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co", "url": "https://example.com", "logo": "https://example.com/logo.png", "sameAs": ["https://www.linkedin.com/company/example"] } ```
Ogni altra pagina fa poi riferimento a quell'`@id` invece di ripetere l'oggetto — il `publisher` di un `WebSite`, l'`author` o il `publisher` di un `Article`, l'`isPartOf` di una `WebPage`. Un'unica entità, un unico insieme di fatti, referenziato in modo coerente. Questa è modellazione di un grafo, non decorazione, ed è la differenza tra Google che unifica i tuoi segnali e Google che non sa di quale versione di te fidarsi.
Errore 3: Tipi di schema che hanno smesso di ripagare
Google ha ridotto i rich result FAQ nell'agosto 2023 a una ristretta cerchia di siti governativi e sanitari, per poi rimuovere del tutto la funzionalità dalla Ricerca — anche quell'eccezione ormai non esiste più. Il markup `FAQPage` continua però a essere copiato e incollato nelle librerie di template e nei plugin CMS come pratica predefinita, e molti siti B2B ed e-commerce continuano a pubblicarlo, senza ottenere nulla in cambio, e in certi casi esponendosi a un rischio reale: se il testo delle FAQ segnato in markup non corrisponde a ciò che è visibile sulla pagina, si tratta di una violazione delle linee guida sui dati strutturati, non di semplice markup sprecato. I rich result `HowTo` sono spariti nello stesso modo — rimossi dal mobile nel 2023, poi dal desktop, senza alcuna superficie in cui il tipo continui a produrre un risultato visibile.
Il segnale da tenere d'occhio non è solo "questo tipo è deprecato". È il markup copiato da un template tre anni fa e mai più rivisto rispetto a cosa fa davvero oggi quel tipo. Il vocabolario di Schema.org è stabile; la disponibilità di Google a mostrare un dato tipo come rich result non lo è, e cambia secondo tempistiche per cui nessuno ti manda una notifica.
Cosa continua a generare un rich result
L'elenco che ripaga in modo affidabile nel 2026: `Product` con prezzo reale, disponibilità e `AggregateRating` proveniente da recensioni autentiche di quello specifico prodotto (la policy di Google sugli snippet di recensione vieta esplicitamente le recensioni autoreferenziali — un'azienda che recensisce il proprio prodotto — quindi le recensioni devono essere vere recensioni di clienti, non fabbricate); `BreadcrumbList`; `VideoObject`; `JobPosting`; `Event`; `Recipe`; e `SoftwareApplication` con un `applicationCategory` valido. Accanto a questi, `Organization` e `WebSite` con una struttura di `@id` pulita e deduplicata continuano a svolgere il loro compito più silenzioso di chiarezza dell'entità e idoneità alla sitelinks search box, anche senza produrre uno snippet visibile proprio.
Un audit minimo da eseguire trimestralmente
- Valida la risposta HTML renderizzata, non il file di template — i bug di escaping emergono solo dopo il rendering.
- Fai una ricerca nel codebase per ogni punto in cui viene emesso `Organization` o `WebSite`. Se sono più di uno, consolidali dietro un `@id` condiviso.
- Confronta ogni `@type` che pubblichi con la documentazione attuale di Google sui dati strutturati, non con il post di blog da cui l'hai copiato.
- Controlla mensilmente i report Enhancements di Search Console — un picco di errori "JSON-LD non valido" o "Campo mancante" di solito è dovuto a un deploy, non a un cambio di policy di Google.
- Conferma che ogni affermazione segnata in markup (un punteggio di recensione, una risposta FAQ, un prezzo) sia visibile sulla pagina nella stessa forma. Un markup non supportato da contenuto visibile è una violazione delle linee guida in attesa di essere notata.
In sintesi
I dati strutturati sono infrastruttura, non decorazione — e falliscono come fallisce l'infrastruttura: silenziosamente, finché un audit o un'azione manuale non li fa emergere. I siti che ottengono rich result nel 2026 non sono quelli con più schema. Sono quelli il cui JSON viene effettivamente interpretato correttamente, le cui entità si risolvono in un unico `@id`, e il cui markup corrisponde a ciò che una persona vede sulla pagina.
Se vuoi che questo venga verificato a dovere — output renderizzato, non sorgente del template — il nostro team SEO esegue la validazione dei dati strutturati come parte standard di ogni audit tecnico, insieme al lavoro su crawlability e Core Web Vitals che di solito si trova proprio lì accanto.
