Dati strutturati: Google ora toglie un solo livello
Il 21 agosto 2026 Google ha comunicato di aver cambiato il modo in cui legge i dati strutturati: applica un solo passaggio di rimozione degli escape HTML invece di due. L'annuncio è uscito su LinkedIn e, al 26 agosto, non compare in nessuna pagina della documentazione di Google. C'è anche un dettaglio ironico: l'esempio scelto per spiegare la modifica è l'unica cosa dell'annuncio che non sopravvive alla citazione, ed è il motivo per cui quasi tutti cercheranno la cosa sbagliata nel proprio markup.
La modifica. L'estrattore di JSON-LD di Google applica un passaggio di rimozione degli escape invece di due. Le entità con un solo livello continuano a risolversi. Quelle doppie no: restano nel valore come caratteri letterali, e il campo in cui finiscono diventa sbagliato.
Perché quasi tutti i consigli saranno sbagliati. L'esempio dell'annuncio attraversa tre livelli di escape prima di arrivarvi sotto gli occhi: il post di Google, il sito che lo riporta, il vostro browser. Abbiamo scaricato i byte grezzi del resoconto per capire quale livello stavamo guardando, e la risposta cambia che cosa dovete cercare.
Che cosa mettiamo di nostro. Abbiamo fatto il controllo su 441 pagine costruite nostre e sulle home di sei siti che gestiamo. Le entità saltano fuori da entrambe le parti, e niente di quello che abbiamo trovato è davvero rotto: il motivo per cui non lo è vale più di tutto il resto.
- Avete il test in tre passaggi, valido comunque abbiate letto l'annuncio.
- Sapete distinguere un'entità che si risolve ancora da una che non si risolve più.
- Sapete dove Google ha e non ha documentato la cosa, con le pagine che abbiamo controllato.
- Avete una regola da aggiungere a ciò che gira prima della pubblicazione.
I dati strutturati sono l'unica parte di una pagina scritta soltanto per le macchine. Nessuno li rilegge, sullo schermo non cambia niente quando sono sbagliati, e il guasto è silenzioso: un prezzo con caratteri di troppo, il nome di un prodotto che sembra un file corrotto. Questa modifica produce esattamente quel tipo di guasto, ed è stata annunciata nel posto meno adatto a raggiungere chi la subisce.
Il test, in tre passaggi
Mettiamo il metodo prima della spiegazione, perché funziona a prescindere da quale livello di escape avete letto nell'annuncio.
- Estraete il blocco. Codice sorgente della pagina, tutto ciò che sta fra il tag di apertura e quello di chiusura del blocco JSON-LD. Non la pagina renderizzata: il sorgente.
- Viene interpretato come JSON? Incollatelo in un validatore. Se fallisce qui avete un problema che precede questa modifica e che vi costa ogni risultato avanzato della pagina.
- Togliete un livello di escape e riguardate. Ogni sequenza di entità ancora presente dopo un solo passaggio aveva un doppio escape, ed è quella che adesso è rotta.
Il terzo passaggio è quello che non fa nessuno, ed è l'unico che distingue i due casi. È anche banale da automatizzare, che è ciò che abbiamo fatto noi.
Che cosa ha cambiato Google
L'estrazione del JSON-LD è il momento in cui Google prende il testo dentro un tag <script type="application/ld+json"> e lo trasforma nei campi che usa per i risultati avanzati: un prezzo, una valutazione, un elenco di domande frequenti.
Le parole di Google, riportate il 21 agosto 2026: "To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping." Gary Illyes ha aggiunto un rimando invece di una spiegazione: "If you're wondering what *proper* escaping is in JSON, I have good news for you! It's very, very well defined in RFC 8259, specifically section 7."
Due passaggi sono diventati uno. È tutta qui la modifica, e tutto il resto ne è una conseguenza.
L'esempio che non sopravvive alla citazione
Google ha illustrato la conseguenza con una frase riprodotta ovunque: le entità con doppio escape non verranno più srotolate, con due esempi fra parentesi.
Il problema di leggere quella frase altrove che nell'originale è questo. Gli esempi sono sequenze di entità, e una sequenza di entità cambia forma ogni volta che attraversa qualcosa che prepara del testo per la visualizzazione. Il post di Google è un livello. Il sito che lo riporta è il secondo — e quel sito pubblica il corpo dei propri articoli dentro il proprio JSON-LD, che è il terzo.
Così abbiamo fatto l'unica cosa che scioglie il dubbio: abbiamo scaricato i byte grezzi del resoconto invece della pagina renderizzata. Nel sorgente il primo esempio è scritto &amp;. Toglietegli un livello, che è quello che fa il browser di chi legge, e sullo schermo diventa &.
Se leggete la frase renderizzata e andate a cercare & nel vostro markup, lo troverete su moltissimi siti — e quasi tutte quelle occorrenze vanno bene. Le entità con un solo livello si risolvono ancora. Cercarle produce un elenco lungo di falsi allarmi e nasconde l'elenco corto che conta davvero. La cosa da trovare è un'entità che è ancora un'entità dopo un giro di rimozione.
Che cosa significa doppio escape
Quattro modi di scrivere lo stesso nome di prodotto, e che cosa diventa ciascuno adesso:
"name": "Pesce &amp; patatine" ← doppio escape: ora resta & nel valore
"name": "Pesce & patatine" ← escape singolo: si risolve ancora in &
"name": "Pesce & patatine" ← carattere nudo: corretto, e lo è sempre stato
"name": "Pesce \u0026 patatine" ← escape JSON: corretto e senza ambiguitàSolo la prima riga ha cambiato comportamento il 21 agosto. Prima sopravviveva perché due passaggi la srotolavano fino in fondo; con un passaggio si ferma a metà e i caratteri letterali finiscono nel valore. Un negozio con quel markup adesso ha, nell'indice di Google, un prodotto che si chiama Pesce & patatine, e sulla pagina non si vede nulla di diverso.
La seconda riga funziona ancora, e qui l'onestà vale più di un allarme. Funziona perché Google continua a fare un passaggio di rimozione degli escape HTML: una cortesia, non uno standard. Il rimedio indicato da Google punta altrove — usare "escape JSON standard o escape esadecimali Unicode". Le entità HTML non sono mai state il modo in cui JSON scrive un carattere speciale; funzionavano perché il parser era indulgente, e l'annuncio parla proprio di un parser meno indulgente di prima.
441 pagine nostre e sei siti che gestiamo
Il 26 agosto 2026 abbiamo eseguito il controllo su ogni pagina costruita di cittago.com che emette dati strutturati. Risultato: 441 pagine, 441 blocchi JSON-LD, zero che non vengono interpretati, e sei sequenze di entità distribuite su tre di essi.
Tutte e sei hanno un solo livello di escape, quindi si risolvono tutte, e nessuna delle tre pagine è rotta. È lo stesso verdetto a cui arriviamo più avanti su un sito di un cliente, raggiunto dalla direzione opposta — e preferiamo dirlo prima su di noi. Due delle tre sono nostri articoli in italiano, dove una È e una é sono state scritte a mano dentro il testo delle FAQ e sono passate dal file di contenuto al markup generato. La terza è una landing di un cliente servita dal nostro dominio.
Lo pubblichiamo invece di sistemarlo prima in silenzio, perché un audit che viene raccontato solo quando è pulito non è un audit, è un comunicato stampa. La distinzione che conta è da dove arrivano quelle entità: non le ha inventate il generatore. Un markup costruito dai dati, invece che assemblato da stringhe già passate per l'escape, non può produrre da solo un doppio escape. Quello che può fare è trasportare un'entità che una persona ha scritto nel contenuto — ed è esattamente la strada per cui la maggior parte dei siti si ritrova la versione disordinata e, uno strato di distrazione dopo, quella rotta.
Sei sequenze innocue e nessun errore di interpretazione su 441 pagine non sono fortuna. Sono quello che vi compra un controllo di interpretazione ed entità che gira prima di ogni pubblicazione: un annuncio uscito su LinkedIn di venerdì non ci è costato niente entro il lunedì, perché il test era già lì da molto prima e il peggio che ha trovato era disordinato, non sbagliato. Quella metà poco appariscente è la parte della nostra consulenza SEO e AI search che continua a ripagare.
L'altra metà del controllo sta fuori dal nostro sito. Abbiamo controllato le home di sei siti che amministriamo — la regola di selezione è stata semplicemente che li gestiamo noi — contando blocchi, errori di interpretazione e sequenze di entità:
| Sito | Blocchi JSON-LD | Non interpretati | Sequenze di entità |
|---|---|---|---|
| cinque dei sei | 1 ciascuno, uno zero | 0 | 0 |
| un sito WordPress | 1 | 0 | 7 |
Sette sequenze su un sito: cinque di una e commerciale dentro URL di avatar, due di un trattino lungo dentro il titolo della pagina. Tutte e sette con un solo livello di escape. Il che significa — ed è la parte che una lettura frettolosa avrebbe sbagliato — che quel sito non è rotto. Un passaggio risolve tutte e sette. Se ci fossimo fermati a «contiene entità, quindi è colpito», avremmo aperto una segnalazione contro un plugin che si comporta in modo accettabile.
Che sia un sito WordPress non è una coincidenza e non è nemmeno un'accusa. I plugin che assemblano il JSON-LD concatenando stringhe già preparate per la visualizzazione sono la via classica al doppio escape. Questo ne mette uno solo: poco elegante e, per ora, innocuo.
Dove Google lo ha documentato: da nessuna parte
Un annuncio su un social non è documentazione, quindi siamo andati a cercare quella vera. Il 24 agosto 2026 abbiamo scaricato cinque proprietà di Google e cercato in ciascuna i termini unescap, single pass, double-escaped, RFC 8259 ed escape:
- la pagina degli aggiornamenti della documentazione di Search Central;
- l'introduzione ai dati strutturati;
- le linee guida generali sui dati strutturati;
- la pagina sulla generazione di dati strutturati con JavaScript;
- l'indice del blog di Search Central.
Zero risultati, su tutte e cinque, per tutti e cinque i termini. Per essere sicuri di aver letto contenuto e non un guscio vuoto renderizzato da JavaScript, abbiamo cercato anche termini di controllo che dovevano esserci per forza: l'introduzione ai dati strutturati ha restituito 64 occorrenze di «structured data» e 7 di «JSON-LD»; la pagina degli aggiornamenti 144 e 8. Le pagine erano reali. La modifica semplicemente non c'è.
Stiamo affermando un'assenza, quindi ne dichiariamo anche i confini: abbiamo controllato cinque proprietà in una data. Google può documentarla più avanti, può averla documentata dove non abbiamo guardato, e il centro assistenza è grande. La mattina del 26 agosto abbiamo ripetuto la ricerca su quattro delle cinque — la pagina degli aggiornamenti, l'introduzione ai dati strutturati, le linee guida generali e la pagina su JavaScript — e il conteggio era ancora zero. Quello che possiamo dire è che il 26 agosto 2026 uno sviluppatore che la cerchi nei posti ovvi non la trova.
Che cosa vi serve
- Il sorgente, non la pagina renderizzata. Gli strumenti per sviluppatori del browser mostrano una versione normalizzata del documento, e le sequenze di entità sono esattamente ciò che la normalizzazione nasconde. Usate «mostra sorgente» o una richiesta HTTP semplice.
- Un validatore JSON. Uno qualsiasi. Il secondo passaggio intercetta più problemi reali del terzo.
- Una pagina rappresentativa per ogni modello. Prodotto, articolo, servizio, home. I dati strutturati si generano per modello, quindi un campione di ciascuno copre un sito di qualsiasi dimensione.
- Un posto stabile dove mettere il controllo. Il nostro gira sul sito costruito, prima che qualcosa venga pubblicato. Aggiungerlo è costato un pomeriggio e si è già ripagato due volte.
Che cosa non si rompe
- Non rompe le entità con un solo livello. Un passaggio le risolve ancora. Restano poco eleganti, non urgenti.
- Non rompe i caratteri scritti nudi. Una e commerciale scritta come se stessa dentro JSON è corretta, e lo è sempre stata.
- Non tocca Microdata e RDFa. Vivono nel corpo dell'HTML, dove le entità le gestisce il parser del browser. L'annuncio parlava dell'estrazione del JSON-LD, e degli altri non ha detto niente.
- Non toglie le pagine dall'indice. I dati strutturati sono un arricchimento, non un requisito. Quello che si perde è l'arricchimento, sul campo che è stato rovinato.
- Non si annuncia. Nessun avviso, nessuna email, nessun errore. Un valore sbagliato resta un campo valido, ed è per questo che il controllo dev'essere qualcosa che eseguite, non qualcosa che aspettate.
Prima e adesso, in tabella
| Scritto nel markup come | Prima | Adesso |
|---|---|---|
nudo & | & | & — invariato, corretto |
\u0026 | & | & — invariato, corretto |
un livello & | & | & — invariato, si risolve ancora |
doppio &amp; | & | & — letterale, sbagliato |
Le parole, in tabella
| Termine | Che cosa significa |
|---|---|
| JSON-LD | Dati strutturati scritti come oggetto JSON dentro un tag script. È il formato consigliato da Google e l'unico toccato da questa modifica. |
| Entità HTML | Un modo di scrivere un carattere che in HTML sarebbe speciale, come la e commerciale o le parentesi angolari. Dentro JSON non ha alcuno statuto. |
| Passaggio di rimozione | Un giro di conversione delle sequenze di entità nei caratteri che rappresentano. Google ne faceva due, adesso ne fa uno. |
| Doppio escape | Un carattere preparato due volte, che quindi ha bisogno di due passaggi per tornare com'era. Sono questi ad aver cambiato comportamento. |
| Escape JSON | Il modo in cui JSON scrive i caratteri speciali: barra rovesciata e una lettera, oppure barra rovesciata, u e quattro cifre esadecimali. Definito in RFC 8259, sezione 7. |
| Risultato avanzato | Il dettaglio in più che Google può mostrare sotto un risultato: stelle, un prezzo, delle domande. Si costruisce da questi campi, ed è per questo che un campo rovinato lo vedono tutti tranne voi. |
Dove siete, in tre soglie
Prima soglia — non sapete se il vostro sito emetta dati strutturati. Allora questa modifica non può farvi male, e la cosa utile non c'entra con lei: una pagina senza dati strutturati è invisibile a ogni arricchimento che Google offre, il che è un buco più grande di quello descritto qui.
Seconda soglia — avete dati strutturati generati da un plugin o dal tema e non li avete mai aperti. Portate una pagina per modello attraverso i tre passaggi. Aspettatevi che il secondo sia pulito e che lo sia anche il terzo; se uno dei due non lo è, avete trovato qualcosa che vale più dell'ora che è costato.
Terza soglia — il markup lo genera il vostro codice. Allora la soluzione non è una riparazione ma un test: verificate che ogni blocco JSON-LD venga interpretato e che nessuno contenga entità dopo un passaggio, ed eseguitelo prima di ogni pubblicazione. È lì che sta il nostro, ed è il motivo per cui l'audit qui sopra è stato noioso.
Se i dati strutturati fanno parte di come contate di farvi trovare dagli assistenti AI e non solo dalla ricerca, il discorso è un altro e lo abbiamo scritto a parte: farsi citare dalla ricerca AI e llms.txt e cats.txt.
Domande che nessuno ci ha fatto
Nessuna è arrivata via email. Sono le domande a cui abbiamo dovuto rispondere noi per poter scrivere l'articolo, e le risposte sono brevi perché l'annuncio era breve.
In due minuti: come controllo il mio sito?
Aprite il codice sorgente della pagina, prendete il blocco dentro script type=application/ld+json e incollatelo in un validatore JSON qualsiasi. Se non viene interpretato, avete un problema che esisteva già prima di questa modifica. Se viene interpretato, togliete un livello di escape e cercate le entità rimaste: quelle erano doppie.
Rischio di perdere i risultati avanzati?
Solo se il vostro JSON-LD contiene entità che avevano bisogno di più di un passaggio. Un'entità con un solo livello continua a risolversi. Una doppia adesso resta nel valore come caratteri letterali, e il campo in cui finisce diventa sbagliato: un prezzo, un nome, una data.
Un'entità nel JSON-LD è sbagliata anche se funziona?
Il rimedio indicato da Google suggerisce di sì: dice di usare «escape JSON standard o escape esadecimali Unicode», che sono il modo in cui JSON scrive i caratteri speciali. Le entità HTML non lo sono mai state; funzionavano perché il parser era indulgente, e adesso lo è meno.
Dove è stato annunciato?
Su LinkedIn, riportato il 21 agosto 2026 da Search Engine Roundtable. Lo abbiamo cercato su cinque proprietà di Google — la pagina degli aggiornamenti della documentazione, l'introduzione ai dati strutturati, le linee guida generali, la pagina sulla generazione via JavaScript e il blog di Search Central — e non lo abbiamo trovato in nessuna.
Ho un sito WordPress. Sono a rischio?
Dipende dal plugin, non da WordPress. I plugin che costruiscono il JSON-LD concatenando stringhe già preparate per la visualizzazione sono la via classica al doppio escape. Uno dei siti WordPress che gestiamo contiene sette sequenze di entità nel suo JSON-LD; tutte e sette a un solo livello, quindi tutte e sette continuano a risolversi.
Search Console mi avvisa se qualcosa si rompe?
Non direttamente, ed è la parte scomoda. Un campo con un valore rovinato resta un campo valido. Il test dei risultati avanzati vi mostra il valore che Google ha estratto, ed è il modo più rapido di vedere il danno — ma dovete guardare, perché nessuno alza la mano.
Riguarda anche Microdata e RDFa?
L'annuncio parla dell'estrazione del JSON-LD in modo specifico. Microdata e RDFa stanno nel corpo dell'HTML, dove le entità le gestisce il parser del browser, quindi il meccanismo descritto qui non si applica allo stesso modo. Google non ha detto nulla né in un senso né nell'altro.
Che cos'è RFC 8259?
È la specifica che definisce JSON. La sezione 7 è quella che dice esattamente come una stringa scrive i caratteri speciali: una barra rovesciata seguita da una lettera, oppure barra rovesciata, u e quattro cifre esadecimali. Citarla è un modo educato di dire che le regole non sono mai state ambigue.
Conviene sistemare anche le entità a un solo livello?
Se costa una modifica di configurazione, sì. Se significa riscrivere un plugin che non controllate, misurate prima: oggi funzionano. Quello che conviene fare subito è aggiungere il controllo a ciò che gira prima della pubblicazione, così una doppia non arriva mai in produzione senza che ve ne accorgiate.
La cosa più piccola che posso fare oggi?
Prendete una pagina sola — quella che vale di più, di solito un prodotto o un servizio — e validate il suo JSON-LD come JSON. Quel controllo intercetta sia questa modifica sia tutti i problemi di markup malformato che la precedono, e richiede circa un minuto.
Ultimo aggiornamento: 26 agosto 2026. Le citazioni attribuite a Google e a Gary Illyes provengono dal resoconto di Search Engine Roundtable del 21 agosto 2026, che cita un post di Google su LinkedIn; il post su LinkedIn non lo abbiamo letto direttamente, e lo diciamo perché la differenza conta per una modifica che non ha altre tracce pubbliche. L'analisi degli escape dell'esempio è stata fatta sui byte grezzi di quel resoconto, scaricati il 24 agosto 2026, non sul suo testo renderizzato. L'audit delle pagine costruite è stato rieseguito il 26 agosto 2026 su una build statica fresca di cittago.com: 441 pagine, 441 blocchi, zero errori di interpretazione, sei sequenze di entità con un solo livello di escape su tre pagine. Una prima esecuzione del 24 agosto riportava 435 pagine e nessuna entità; quel conteggio non è stato riprodotto il 26 agosto, quindi valgono i numeri del 26 e i precedenti sono ritirati. Il controllo sui sei siti è stato eseguito lo stesso giorno, una richiesta HTTP per ogni home, leggendo il sorgente grezzo. La ricerca sulle proprietà di Google è stata eseguita il 24 agosto 2026 su cinque indirizzi, con termini di controllo a confermare che le pagine avessero contenuto; abbiamo controllato cinque proprietà in una data e non affermiamo nulla oltre a questo. Aggiorneremo la pagina se Google documenterà la modifica o se chiarirà se il passaggio singolo è definitivo.
Fonti: Search Engine Roundtable — JSON-LD Extraction For Googlebot Now Does One Pass Of HTML Unescaping (21 agosto 2026) · RFC 8259, sezione 7 — Escape delle stringhe in JSON · Google Search Central — Intro to how structured data markup works
