Google mai scoate un singur nivel din datele structurate
Pe 21 august 2026 Google a comunicat că a schimbat felul în care citește datele structurate: aplică o singură trecere de scoatere a escapărilor HTML în loc de două. Anunțul a ieșit pe LinkedIn și, la 26 august, nu apare în nicio pagină din documentația proprie. Iar exemplul ales ca să explice schimbarea e singurul lucru din anunț care nu supraviețuiește citării — motiv pentru care aproape toată lumea va căuta lucrul greșit în propriul marcaj.
Ce s-a schimbat. Extractorul de JSON-LD al Google aplică o trecere de scoatere a escapărilor în loc de două. Entitățile cu un singur nivel se rezolvă în continuare. Cele duble, nu: rămân în valoare ca simple caractere, iar câmpul în care ajung devine greșit.
De ce aproape toate sfaturile vor fi greșite. Exemplul din anunț trece prin trei straturi de escapare până să-ți ajungă sub ochi — postarea Google, site-ul care o relatează și browserul tău. Am descărcat octeții bruți ai relatării ca să vedem la ce strat ne uitam, iar răspunsul schimbă ce trebuie să cauți.
Ce punem noi pe masă. Am rulat verificarea pe 441 de pagini construite ale noastre și pe paginile de start a șase site-uri pe care le administrăm. Entitățile apar de ambele părți și nimic din ce am găsit nu e cu adevărat stricat, iar motivul pentru care nu e stricat valorează cât tot restul.
- Ai testul în trei pași, valabil indiferent cum ai citit anunțul.
- Știi să deosebești o entitate care încă se rezolvă de una care nu se mai rezolvă.
- Știi unde a documentat și unde n-a documentat Google, cu paginile pe care le-am verificat.
- Ai o regulă de adăugat la ce rulează înainte de publicare, ca să nu se mai repete.
Datele structurate sunt singura parte a unei pagini scrisă doar pentru mașini. Nimeni nu le recitește, pe ecran nu se schimbă nimic când sunt greșite, iar defectul e tăcut: un preț cu caractere în plus, un nume de produs care arată ca un fișier corupt. Schimbarea asta produce exact genul ăla de defect și a fost anunțată în locul cel mai puțin potrivit ca să ajungă la cine o suportă.
Ce a schimbat Google
Extragerea JSON-LD e pasul în care Google ia textul dintr-o etichetă <script type="application/ld+json"> și îl transformă în câmpurile pe care le folosește pentru rezultate îmbogățite: un preț, o notă, un set de întrebări frecvente.
Cuvintele Google, relatate pe 21 august 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 a adăugat o trimitere în loc de o explicație: "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."
Două treceri au devenit una. Asta e toată schimbarea, iar tot ce urmează e o consecință a ei.
441 de pagini ale noastre și șase site-uri
Pe 26 august 2026 am rulat verificarea pe fiecare pagină construită de pe cittago.com care emite date structurate. Rezultatul: 441 de pagini, 441 de blocuri JSON-LD, zero care nu se interpretează, și șase secvențe de entități împrăștiate pe trei dintre ele.
Toate șase au un singur nivel de escape, deci toate șase se rezolvă, și niciuna dintre cele trei pagini nu e stricată. E același verdict la care ajungem mai jos despre site-ul unui client, doar că din direcția opusă — și preferăm să-l spunem întâi despre noi. Două din cele trei sunt articolele noastre în italiană, unde un È și un é au fost tastate de mână în textul întrebărilor frecvente și au călătorit din fișierul de conținut în marcajul generat. A treia e o pagină de campanie a unui client, servită de pe domeniul nostru.
O publicăm în loc s-o reparăm întâi în liniște, pentru că un audit povestit doar după ce e curat nu e audit, e comunicat de presă. Distincția care contează e de unde vin entitățile alea: nu le-a inventat generatorul. Un marcaj construit din date, nu asamblat din șiruri deja trecute prin escape, nu poate produce singur un dublu escape. Ce poate face e să ducă mai departe o entitate pe care a scris-o un om în conținut — exact drumul pe care cele mai multe site-uri ajung la varianta dezordonată și, un strat de neatenție mai târziu, la cea stricată.
Șase secvențe inofensive și zero erori de interpretare pe 441 de pagini nu e noroc. E ce îți cumpără o verificare de interpretare și entități care rulează înainte de fiecare publicare: un anunț apărut pe LinkedIn într-o vineri nu ne-a costat nimic până luni, pentru că testul rula de mult înainte de el, iar ce a găsit în cel mai rău caz era dezordonat, nu greșit. Jumătatea aia nespectaculoasă e partea din serviciile noastre de SEO și optimizare pentru căutarea AI care continuă să plătească.
Cealaltă jumătate a verificării e în afara site-ului nostru. Am verificat paginile de start a șase site-uri pe care le administrăm — regula de selecție fiind pur și simplu că le ținem noi — numărând blocuri, erori de interpretare și secvențe de entități:
| Site | Blocuri JSON-LD | Neinterpretate | Secvențe de entități |
|---|---|---|---|
| cinci din șase | 1 fiecare, unul zero | 0 | 0 |
| un site WordPress | 1 | 0 | 7 |
Șapte secvențe pe un singur site: cinci de ampersand în adrese de avatar, două de linie de dialog în titlul paginii. Toate șapte cu un singur nivel de escapare. Ceea ce înseamnă — și asta e partea pe care o citire grăbită ar fi greșit-o — că site-ul ăla nu e stricat. O trecere le rezolvă pe toate șapte. Dacă ne opream la „conține entități, deci e afectat", deschideam o sesizare împotriva unui plugin care se poartă acceptabil.
Că e site WordPress nu e o coincidență și nici o acuzație. Pluginurile care asamblează JSON-LD lipind șiruri deja pregătite pentru afișare sunt calea clasică spre dubla escapare. Ăsta pune un singur nivel: neîngrijit și, deocamdată, inofensiv.
Ce înseamnă dublu escapat
Patru moduri de a scrie același nume de produs și ce devine fiecare acum:
"name": "Pește &amp; cartofi" ← dublu escapat: acum rămâne & în valoare
"name": "Pește & cartofi" ← escapat o dată: încă se rezolvă în &
"name": "Pește & cartofi" ← caracter simplu: corect, și a fost mereu
"name": "Pește \u0026 cartofi" ← escapare JSON: corect și fără ambiguitateDoar primul rând și-a schimbat comportamentul pe 21 august. Înainte supraviețuia pentru că două treceri îl desfăceau până la capăt; cu o singură trecere se oprește la jumătate, iar caracterele rămân în valoare. Un magazin cu marcajul ăla are acum, în indexul Google, un produs numit Pește & cartofi, iar pe pagină nu se vede nimic diferit.
Al doilea rând funcționează în continuare, și aici onestitatea valorează mai mult decât o alarmă. Funcționează pentru că Google face în continuare o trecere de scoatere a escapărilor HTML — o amabilitate, nu un standard. Remediul indicat de Google arată în altă direcție: „escapări JSON standard sau escapări hexazecimale Unicode". Entitățile HTML n-au fost niciodată modul în care JSON scrie un caracter special; funcționau pentru că interpretorul era îngăduitor, iar anunțul e chiar despre un interpretor mai puțin îngăduitor.
Exemplul care nu supraviețuiește citării
Google a ilustrat consecința cu o propoziție reprodusă peste tot: entitățile dublu escapate nu vor mai fi desfăcute, cu două exemple în paranteză.
Problema cu citirea acelei propoziții altundeva decât în original e următoarea. Exemplele sunt secvențe de entități, iar o secvență de entități își schimbă forma de fiecare dată când trece prin ceva care pregătește text pentru afișare. Postarea Google e un strat. Site-ul care o relatează e al doilea — iar site-ul ăla își publică textul articolelor chiar în propriul JSON-LD, care e al treilea.
Am făcut singurul lucru care lămurește: am descărcat octeții bruți ai relatării, nu pagina randată. În sursă, primul exemplu e scris &amp;. Scoate-i un nivel, ceea ce face browserul cititorului, și pe ecran devine &.
Dacă citești propoziția randată și te apuci să cauți & în marcajul tău, o să-l găsești pe foarte multe site-uri — și aproape toate aparițiile alea sunt în regulă. Entitățile cu un singur nivel se rezolvă în continuare. Căutarea lor produce o listă lungă de alarme false și ascunde lista scurtă care contează. Lucrul de găsit e o entitate care e încă entitate după o rundă de scoatere.
Testul, în trei pași
- Extrage blocul. Codul sursă al paginii, tot ce e între eticheta de deschidere și cea de închidere a blocului JSON-LD. Nu pagina randată — sursa.
- Se interpretează ca JSON? Lipește-l într-un validator. Dacă pică aici, ai o problemă care precede schimbarea asta și care te costă fiecare rezultat îmbogățit al paginii.
- Scoate un nivel de escapare și uită-te din nou. Orice secvență de entități rămasă după o singură trecere era dublu escapată, și aia e cea stricată acum.
Pasul al treilea e cel pe care nu-l face nimeni și singurul care deosebește cele două cazuri. E și banal de automatizat, ceea ce am și făcut.
Unde a documentat Google: nicăieri
Un anunț pe o rețea socială nu e documentație, așa că am căutat-o pe cea adevărată. Pe 24 august 2026 am descărcat cinci proprietăți Google și am căutat în fiecare termenii unescap, single pass, double-escaped, RFC 8259 și escape:
- pagina de actualizări ale documentației Search Central;
- introducerea în marcajul de date structurate;
- ghidul general pentru date structurate;
- pagina despre generarea datelor structurate cu JavaScript;
- indexul blogului Search Central.
Zero potriviri, pe toate cinci, pentru toți cei cinci termeni. Ca să fim siguri că am citit conținut, nu un schelet randat de JavaScript, am căutat și termeni de control care trebuiau să existe: introducerea în date structurate a întors 64 de apariții pentru „structured data" și 7 pentru „JSON-LD"; pagina de actualizări, 144 și 8. Paginile erau reale. Schimbarea pur și simplu nu e în ele.
Afirmăm o absență, deci îi declarăm și limitele: am verificat cinci proprietăți într-o singură zi. Google poate s-o documenteze mai târziu, poate s-o fi documentat unde n-am căutat, iar centrul de ajutor e mare. Pe dimineața zilei de 26 august am repetat căutarea pe patru dintre cele cinci — pagina de actualizări, introducerea în datele structurate, ghidul general și pagina despre JavaScript — și numărătoarea era tot zero. Ce putem spune e că pe 26 august 2026 un dezvoltator care o caută în locurile evidente n-o găsește.
Ce-ți trebuie
- Codul sursă, nu pagina randată. Uneltele de dezvoltator ale browserului îți arată o versiune normalizată a documentului, iar secvențele de entități sunt exact ce ascunde normalizarea. Folosește „vezi sursa" sau o cerere HTTP simplă.
- Un validator JSON. Oricare. Pasul al doilea prinde mai multe probleme reale decât al treilea.
- O pagină reprezentativă pentru fiecare șablon. Produs, articol, serviciu, pagină de start. Datele structurate se generează per șablon, deci un eșantion din fiecare acoperă un site de orice mărime.
- Un loc stabil pentru verificare. A noastră rulează pe site-ul construit, înainte să se publice ceva. A costat o după-amiază și s-a plătit deja de două ori.
Ce nu se strică
- Nu strică entitățile cu un singur nivel. O trecere le rezolvă în continuare. Rămân neîngrijite, nu urgente.
- Nu strică nici caracterele scrise simplu. Un ampersand scris ca el însuși în JSON e corect și a fost mereu.
- Nu atinge Microdata și RDFa. Alea stau în corpul HTML, unde entitățile le gestionează interpretorul browserului. Anunțul era despre extragerea JSON-LD și n-a spus nimic despre celelalte.
- Nu-ți scoate paginile din index. Datele structurate sunt o îmbogățire, nu o cerință. Ce pierzi e îmbogățirea, pe câmpul care s-a stricat.
- Nu se anunță singură. Nicio avertizare, niciun e-mail, nicio eroare. O valoare greșită rămâne un câmp valid, de-aia verificarea trebuie să fie ceva ce rulezi, nu ceva ce aștepți.
Înainte și acum, în tabel
| Scris în marcaj ca | Înainte | Acum |
|---|---|---|
simplu & | & | & — neschimbat, corect |
\u0026 | & | & — neschimbat, corect |
un nivel & | & | & — neschimbat, încă se rezolvă |
dublu &amp; | & | & — literal, greșit |
Cuvintele, în tabel
| Termen | Ce înseamnă |
|---|---|
| JSON-LD | Date structurate scrise ca obiect JSON într-o etichetă script. E formatul recomandat de Google și singurul atins de schimbarea asta. |
| Entitate HTML | Un mod de a scrie un caracter care în HTML ar fi special, ca ampersandul sau parantezele unghiulare. În JSON n-are niciun statut. |
| Trecere de scoatere | O rundă de transformare a secvențelor de entități în caracterele pe care le reprezintă. Google făcea două, acum face una. |
| Dublu escapat | Un caracter pregătit de două ori, care are nevoie de două treceri ca să revină. Astea sunt cele care și-au schimbat comportamentul. |
| Escapare JSON | Modul în care JSON scrie caracterele speciale: bară oblică inversă și o literă, sau bară inversă, u și patru cifre hexazecimale. Definit în RFC 8259, secțiunea 7. |
| Rezultat îmbogățit | Detaliul în plus pe care Google îl poate arăta sub un rezultat: stele, un preț, întrebări. Se construiește din câmpurile astea, de-aia un câmp stricat îl văd toți în afară de tine. |
Unde ești, în trei praguri
Primul prag — nu știi dacă site-ul tău emite date structurate. Atunci schimbarea asta nu-ți poate face rău, iar lucrul util n-are legătură cu ea: o pagină fără date structurate e invizibilă pentru orice îmbogățire oferită de Google, ceea ce e un gol mai mare decât cel descris aici.
Al doilea prag — ai date structurate dintr-un plugin sau din temă și nu le-ai deschis niciodată. Treci o pagină per șablon prin cei trei pași. Așteaptă-te ca pasul doi să fie curat și pasul trei la fel; dacă vreunul nu e, ai găsit ceva ce valorează mai mult decât ora pe care a costat-o.
Al treilea prag — marcajul îl generează codul tău. Atunci soluția nu e o reparație, e un test: verifici că fiecare bloc JSON-LD se interpretează și că niciunul nu conține entități după o trecere, și îl rulezi înainte de fiecare publicare. Acolo stă al nostru, și de-aia auditul de mai sus a fost plictisitor.
Dacă datele structurate fac parte din felul în care te aștepți să fii găsit de asistenții AI, nu doar de căutare, discuția e alta și am scris-o separat: cum ajungi citat de căutarea AI și llms.txt și cats.txt.
Întrebări pe care nu ni le-a pus nimeni
Niciuna n-a venit pe e-mail. Sunt întrebările la care a trebuit să răspundem noi ca să putem scrie articolul, iar răspunsurile sunt scurte pentru că anunțul a fost scurt.
Îmi pierd rezultatele îmbogățite?
Doar dacă JSON-LD-ul tău conține entități care aveau nevoie de mai mult de o trecere. O entitate cu un singur nivel se rezolvă în continuare. Una dublă rămâne acum în valoare ca simple caractere, iar câmpul în care ajunge devine greșit: un preț, un nume, o dată.
Cum verific în două minute?
Deschide codul sursă al paginii, ia blocul dintre etichetele script type=application/ld+json și lipește-l într-un validator JSON. Dacă nu se interpretează, ai o problemă care exista și înainte de schimbarea asta. Dacă se interpretează, scoate un nivel de escapare și caută entitățile rămase: alea erau duble.
O entitate în JSON-LD e greșită chiar dacă funcționează?
Remediul indicat de Google sugerează că da: spune să folosești „escapări JSON standard sau escapări hexazecimale Unicode”, adică modul în care JSON scrie caracterele speciale. Entitățile HTML n-au fost niciodată modul ăla; funcționau pentru că interpretorul era îngăduitor, iar acum e mai puțin.
Unde a fost anunțată schimbarea?
Pe LinkedIn, relatată pe 21 august 2026 de Search Engine Roundtable. Am căutat-o pe cinci proprietăți Google — pagina de actualizări a documentației, introducerea în date structurate, ghidul general, pagina despre generarea cu JavaScript și blogul Search Central — și n-am găsit-o în niciuna.
Am site pe WordPress. Sunt afectat?
Depinde de plugin, nu de WordPress. Pluginurile care construiesc JSON-LD lipind șiruri deja pregătite pentru afișare sunt calea clasică spre dubla escapare. Unul dintre site-urile WordPress pe care le administrăm are șapte secvențe de entități în JSON-LD; toate șapte cu un singur nivel, deci toate șapte se rezolvă în continuare.
Search Console mă anunță dacă se strică ceva?
Nu direct, și asta e partea incomodă. Un câmp cu valoare stricată rămâne un câmp valid. Testul de rezultate îmbogățite îți arată valoarea pe care a extras-o Google și e cel mai rapid mod de a vedea paguba — dar trebuie să te uiți, pentru că nimeni nu ridică mâna.
Ce este RFC 8259?
E specificația care definește JSON. Secțiunea 7 e cea care spune exact cum scrie un șir caracterele speciale: o bară oblică inversă urmată de o literă, sau bară inversă, u și patru cifre hexazecimale. Citarea ei e un mod politicos de a spune că regulile n-au fost niciodată ambigue.
Atinge și Microdata sau RDFa?
Anunțul vorbește despre extragerea JSON-LD în mod specific. Microdata și RDFa stau în corpul HTML, unde entitățile le gestionează interpretorul browserului, deci mecanismul descris aici nu li se aplică la fel. Google n-a spus nimic despre ele nici într-un sens, nici în celălalt.
Merită reparate și entitățile cu un singur nivel?
Dacă te costă o schimbare de configurare, da. Dacă înseamnă rescrierea unui plugin pe care nu-l controlezi, măsoară întâi: azi funcționează. Ce merită făcut imediat e să adaugi verificarea la ce rulează înainte de publicare, ca una dublă să nu ajungă niciodată în producție neobservată.
Cel mai mic lucru pe care îl pot face azi?
Ia o singură pagină — cea care valorează cel mai mult, de obicei un produs sau un serviciu — și validează-i JSON-LD-ul ca JSON. Verificarea aia prinde și schimbarea asta, și orice problemă de marcaj stricat care o precede, și durează cam un minut.
Ultima actualizare: 26 august 2026. Citatele atribuite Google și lui Gary Illyes provin din relatarea Search Engine Roundtable din 21 august 2026, care citează o postare Google de pe LinkedIn; postarea de pe LinkedIn n-am citit-o direct, și o spunem pentru că diferența contează la o schimbare fără alte urme publice. Analiza escapărilor din exemplu a fost făcută pe octeții bruți ai acelei relatări, descărcați pe 24 august 2026, nu pe textul ei randat. Auditul paginilor construite a fost rerulat pe 26 august 2026 pe o buildă statică proaspătă a cittago.com: 441 de pagini, 441 de blocuri, zero erori de interpretare, șase secvențe de entități cu un singur nivel de escape pe trei pagini. O rulare anterioară, pe 24 august, raporta 435 de pagini și nicio entitate; numărătoarea aia nu s-a reprodus pe 26 august, deci valabile sunt cifrele de pe 26, iar cele dinainte se retrag. Verificarea celor șase site-uri a fost rulată în aceeași zi, o cerere HTTP per pagină de start, citind codul sursă brut. Căutarea pe proprietățile Google a fost rulată pe 24 august 2026 pe cinci adrese, cu termeni de control care confirmă că paginile aveau conținut; am verificat cinci proprietăți într-o zi și nu afirmăm nimic dincolo de atât. Actualizăm pagina dacă Google documentează schimbarea sau dacă lămurește dacă trecerea unică e definitivă.
Surse: Search Engine Roundtable — JSON-LD Extraction For Googlebot Now Does One Pass Of HTML Unescaping (21 august 2026) · RFC 8259, secțiunea 7 — Escaparea șirurilor în JSON · Google Search Central — Intro to how structured data markup works
