Datele structurate sunt o traducere controlată a unor informații de pe pagină într-un format pe care sistemele software îl pot procesa mai ușor. Ele pot spune că pagina descrie un produs, o organizație, un articol sau un eveniment și pot lega acea entitate de proprietăți precum numele, autorul, prețul ori data publicării.
În era răspunsurilor generate de AI, utilitatea lor este reală, dar mai îngustă decât promit multe prezentări comerciale. Schema nu repară un site neindexabil, nu transformă o afirmație generică în dovadă și nu garantează nici ranking, nici rich result, nici citare într-un răspuns AI. Este un strat de claritate și eligibilitate, nu un motor autonom de vizibilitate.
Acest ghid te ajută să alegi ce merită implementat, să modelezi entitățile fără contradicții și să verifici rezultatul. Documentația tehnică a fost reverificată la 3 august 2026, tocmai pentru că funcțiile acceptate de motoarele de căutare se schimbă.
Trei lucruri diferite ascunse sub cuvântul schema
În conversațiile de marketing, „schema” ajunge să însemne simultan vocabular, cod și rezultat vizual. Separarea lor previne majoritatea deciziilor greșite.
Schema.org este vocabularul: o colecție de tipuri și proprietăți care permite descrierea lucrurilor într-o formă comună. Organization, Product, Person și Article sunt tipuri; name, url, author și offers sunt proprietăți. Ghidul Schema.org explică relația dintre item, tip și proprietate, dar nu stabilește singur ce afișează Google.
JSON-LD, Microdata și RDFa sunt formate de exprimare. Pentru majoritatea site-urilor, JSON-LD este alegerea practică deoarece păstrează modelul într-un bloc separat de HTML-ul vizibil. Specificația JSON-LD 1.1 a W3C definește mecanismul de linked data; nu promite rezultate SEO.
Rich result este o prezentare posibilă într-un motor de căutare. Google acceptă doar anumite tipuri și propriile cerințe pot fi mai restrictive decât vocabularul general. De aceea, introducerea Google în date structurate recomandă ca documentația Search Central, nu lista completă Schema.org, să fie reperul pentru comportamentul Google Search.
Aceste trei straturi pot avea verdicte diferite. Un bloc poate fi JSON valid, conform vocabularului Schema.org, dar neeligibil pentru un rich result Google. Invers, un cod valid și eligibil poate să nu fie afișat pentru o anumită interogare.
Ce problemă rezolvă pentru un motor de căutare
Un document HTML conține text, navigație, etichete, prețuri și elemente de interfață. Un om deduce din context ce este principal și ce este auxiliar. Un parser trebuie să identifice această relație cu un grad de incertitudine. Datele structurate oferă indicii explicite: aceasta este organizația, acesta este produsul, acesta este autorul, iar această ofertă îi aparține produsului.
Google spune că folosește markupul pentru a înțelege conținutul paginii și informația despre lucrurile descrise. Asta nu înseamnă că motorul acceptă orbește codul. Îl compară cu textul vizibil, cu informația din alte pagini și cu regulile funcției. Un preț diferit în HTML și JSON-LD nu creează claritate; creează conflict.
Valoarea crește când pagina are informație structurabilă cu sens economic: disponibilitate, preț, autor, dată, locație, program, imagine, eveniment sau relații între entități. Pe o pagină de opinie generică, adăugarea a zeci de proprietăți nu compensează lipsa unui autor credibil ori a unei idei distincte.
Pentru o echipă care oferă servicii de AI SEO, implementarea trebuie privită ca parte dintr-un sistem mai mare: crawling, indexare, conținut vizibil, entități coerente, legături interne și măsurare. Dacă una dintre condițiile din amonte lipsește, markupul rămâne un strat corect peste o fundație defectă.
Datele structurate nu sunt un factor de ranking garantat
Mitul apare dintr-o observație incompletă: unele rezultate îmbogățite ocupă mai mult spațiu și pot atrage mai multe interacțiuni. De aici se sare la concluzia că simpla prezență a codului ridică poziția. Documentația Google nu face această promisiune.
Regulile generale pentru structured data spun că o implementare corectă face pagina eligibilă, nu obligă algoritmul să afișeze funcția. Istoricul, locația, dispozitivul, intenția și calitatea paginii pot conduce la o prezentare diferită. Chiar o acțiune manuală pentru markup abuziv afectează eligibilitatea pentru rich results, nu este descrisă ca o penalizare automată a rankingului web obișnuit.
O formulare onestă este aceasta: datele structurate pot reduce ambiguitatea și pot deschide accesul la anumite prezentări documentate. Aceste prezentări pot schimba rata de interacțiune. Efectul comercial trebuie măsurat pe site-ul tău. Nu există un multiplicator universal pe care să-l introduci într-un forecast.
De aceea, ordinea corectă nu începe cu „ce plugin instalăm?”, ci cu „ce rezultat ori proces vrem să susținem?”. Pentru ecommerce poate fi consistența produsului între pagină și feed. Pentru publishing poate fi reprezentarea autorului și articolului. Pentru o afacere locală poate fi o entitate LocalBusiness coerentă cu datele publice, fără a confunda acest cod cu administrarea Profilului de Companie Google.
Ce s-a întâmplat cu FAQPage în 2026
FAQPage este exemplul perfect pentru motivul în care o implementare nu trebuie tratată ca activ permanent. În 2023, Google redusese afișarea FAQ rich results în principal la site-uri guvernamentale și medicale cu autoritate. În 2026, funcția a fost retrasă complet din rezultatele Google Search.
Jurnalul oficial Search Central notează că funcția nu mai apare în Search începând cu 7 mai 2026 și că documentația a fost eliminată în iunie. Asta înseamnă că un backlog care promite „FAQ schema pentru mai mult spațiu în Google” este depășit, chiar dacă pluginul încă produce cod valid conform Schema.org.
Nu trebuie să ștergi automat orice FAQPage. Poate fi folosit de alte sisteme sau poate rămâne o reprezentare semantică validă. Dar trebuie să-i retragi justificarea falsă. Pentru Google Search, nu mai poți promite FAQ rich result. Iar întrebările trebuie păstrate în pagină numai dacă ajută cititorul, nu pentru că un generator a adăugat un bloc de cod.
Această schimbare oferă o regulă de guvernanță: fiecare tip implementat trebuie să aibă proprietar, scop, documentație de referință și dată de reverificare. Dacă funcția dispare, echipa trebuie să poată modifica templateul central, nu să caute manual în sute de pagini.
Tipurile care pot avea sens pentru afaceri
Nu există o listă universală. Alegerea pornește de la entitatea principală și de la funcția pe care motorul o documentează în prezent.
Organization ori subtipul potrivit descrie entitatea care publică și poate lega logo-ul, URL-ul și identificatori publici. Person poate clarifica autorul real. Article ori BlogPosting descrie o piesă editorială, cu autor, date și imagine. BreadcrumbList exprimă poziția paginii în arhitectură. Aceste tipuri sunt de obicei implementate la nivel de template, unde consistența contează mai mult decât densitatea proprietăților.
Pentru magazine, Product și Offer au valoare atunci când prețul, moneda, disponibilitatea și variantele sunt actuale. Documentația Google pentru produse explică faptul că datele din pagină și feedul Merchant Center pot fi folosite împreună. Nu trata JSON-LD ca substitut pentru feed, stoc sau politica de actualizare.
Pentru evenimente, joburi, rețete ori videoclipuri există cerințe specifice. Implementează-le numai când pagina chiar este despre acel obiect și toate proprietățile obligatorii pot fi menținute. Un articol care menționează un eveniment nu devine automat pagină Event. O pagină de categorie cu zece produse nu trebuie modelată mecanic ca un singur Product.
Mai important, datele din cod nu înlocuiesc informația vizibilă. În România, OUG 34/2014 cere ca informații precontractuale precum caracteristicile principale, identitatea profesionistului și prețul să fie oferite vizibil, lizibil și ușor de înțeles în situațiile acoperite. Schema poate descrie prețul; nu îl poate ascunde de cumpărător.
Entitatea începe înaintea blocului JSON-LD
O entitate nu se naște pentru că ai scris @type. Ea trebuie să aibă o identitate stabilă în site și în operațiunile afacerii. Numele, URL-ul canonic, datele de contact, autorii, produsele și relațiile dintre ele trebuie să fie consecvente în conținut, navigație, feeduri și profiluri publice.
În modelul JSON-LD, un @id stabil poate conecta reprezentări ale aceluiași lucru. De exemplu, articolul poate indica autorul printr-un identificator care duce la entitatea Person, iar publisherul prin identificatorul organizației. Pe altă pagină, aceeași organizație folosește același @id, nu o copie ușor diferită.
Nu transforma sameAs într-un sertar cu orice URL care conține numele brandului. Folosește profiluri și identificatori care reprezintă aceeași entitate. Un articol de presă despre firmă nu este identic cu firma. O pagină de serviciu nu este identică cu organizația. Relația corectă este mai importantă decât numărul de linkuri.
Înainte de cod, creează un registru simplu: entitate, URL canonic, identificator, proprietar intern, sursă a datelor și frecvență de actualizare. Acest registru reduce situațiile în care pluginul SEO, tema și o extensie ecommerce publică trei grafuri contradictorii.
JSON-LD bun descrie pagina, nu fantezia marketerului
Un bloc bun este restrâns, complet și derivat din adevărul vizibil. Dacă pagina nu afișează evaluări autentice, nu adăuga aggregateRating. Dacă articolul nu are autor identificabil, inventarea unei persoane în markup nu creează expertiză. Dacă produsul este indisponibil, sincronizează starea în HTML, schema și feed.
Regulile Google interzic markupul irelevant, înșelător sau ascuns față de utilizator. Ele recomandă proprietăți complete și exacte, chiar dacă sunt mai puține. Practic, un graf mic pe care îl poți menține este mai valoros decât un șablon spectaculos copiat de la un competitor.
Tutorialul video terț analizat pentru acest articol recomandă copierea JSON-LD din sursa competitorilor și schimbarea câmpurilor. Tehnic, codul public poate fi văzut și formatat. Editorial, rețeta este riscantă: poți prelua tipuri care nu se aplică, identificatori străini, proprietăți neverificabile sau presupuneri legate de un alt CMS. Verdictul nostru este să folosești implementările concurente ca indiciu de audit, nu ca specificație.
Minificarea nu „ascunde” markupul de un competitor și nu îi dă valoare SEO suplimentară. Un parser poate formata din nou JSON-ul. Optimizează dimensiunea când există o problemă reală de payload, dar nu construi strategia în jurul secretizării unui vocabular public.
Schema și AI Search: ce știm și ce presupunem
Google este neobișnuit de explicit aici. În documentația despre funcțiile AI din Search, compania spune că nu este necesar un fișier nou, un „AI text” ori un markup special și că nu există schema specială pentru apariția în aceste funcții. Datele structurate existente trebuie să corespundă textului vizibil.
Putem spune deci că schema ajută la exprimarea unor entități și proprietăți și că unele sisteme o pot procesa. Nu putem transforma această posibilitate într-o afirmație universală despre ponderea ei în selecția citărilor. Modelele, indexurile și conductele de retrieval diferă; furnizorii nu publică o formulă completă.
Analiza Search Engine Land despre schema și AI Search ajunge la o delimitare similară: markupul poate susține dezambiguizarea și consistența, dar dovezile publice nu justifică promisiunea că schema determină direct vizibilitatea generativă. Este o analiză editorială, nu documentație de produs, așa că o folosim pentru contradicție și context, nu ca autoritate asupra algoritmului.
Concluzia practică este să nu creezi tipuri inventate precum AIReadyArticle și să nu umfli FAQ-uri pentru LLM-uri. Construiește conținut verificabil, entități stabile și arhitectură clară. Pentru detaliile despre acces și user-agenți, ghidul despre GPTBot, robots.txt și llms.txt păstrează granița corectă: schema descrie; regulile de crawling controlează accesul.
Un graf coerent este mai util decât zece blocuri independente
Pe un site matur, entitățile se repetă. Organizația publică articole, angajează persoane, oferă servicii, operează locații și vinde produse. Dacă fiecare template produce un bloc izolat, motorul trebuie să deducă dacă „Amplify”, „Amplify Marketing” și o altă versiune sunt același lucru.
Folosește identificatori interni stabili și relații explicite. Articolul are author; autorul poate avea o pagină și un @id; articolul are publisher; serviciul este provider de organizație; locația poate fi legată de organizația care o operează. Nu este nevoie să modelezi întreaga afacere pe fiecare URL. Pagina descrie obiectul principal și legăturile strict relevante.
Evită și conflictul de autoritate tehnică. Tema poate produce WebSite și Organization, pluginul SEO poate produce aceleași noduri, iar aplicația ecommerce adaugă un alt Product. Auditul trebuie să inventarieze outputul randat, nu doar setările din admin. Consolidarea la nivel de graf previne dubluri și câmpuri care se suprascriu.
Pentru companii cu mai multe locații, nu folosi un singur LocalBusiness cu toate adresele amestecate. Fiecare locație reală are URL, adresă, program și identificator propriu, conectate organizației. Aceeași disciplină ajută atât SEO-ul local, cât și mentenanța datelor din site.
Implementarea pe CMS trebuie să aibă o singură sursă de adevăr
WordPress, Shopify, Wix și platformele custom pot adăuga JSON-LD prin temă, plugin, aplicație sau cod propriu. Problema nu este metoda, ci proprietatea datelor. Dacă prețul vine din catalog, markupul trebuie generat din același câmp, nu introdus manual într-un editor separat.
Începe cu un inventar al generatoarelor. Deschide codul randat pe câteva șabloane: homepage, articol, serviciu, produs, categorie și locație. Caută application/ld+json, notează fiecare tip, sursa probabilă și dublurile. Apoi decide cine deține fiecare nod.
Pentru un site mic, un plugin bine configurat poate fi suficient. Pentru ecommerce ori multiple integrări, un strat custom poate fi mai sigur. Dar custom nu înseamnă automat mai bun; introduce cost de testare, release și actualizare. Cerința este ca schimbarea unui preț, autor sau program să se propage fără intervenții paralele.
Separă configurarea globală de datele paginii. Numele organizației și logo-ul nu trebuie rescrise la fiecare articol. Datele articolului vin din CMS. Informația produsului vine din catalog. Relațiile sunt compuse în template. Astfel, auditul găsește defectul la sursă, nu repară manual simptomele URL cu URL.
Validarea are trei niveluri, nu un singur buton verde
Primul nivel este sintaxa și vocabularul. Schema Markup Validator verifică markupul Schema.org fără să decidă eligibilitatea pentru funcțiile Google. Aici găsești JSON invalid, proprietăți cu tip greșit și relații neînțelese de vocabular.
Al doilea nivel este funcția Google. Rich Results Test arată tipurile recunoscute pentru rich results, erorile obligatorii și unele avertismente. Un rezultat valid înseamnă că instrumentul a putut procesa implementarea pentru funcția acceptată, nu că acea prezentare va apărea în SERP.
Al treilea nivel este URL-ul public și indexat. URL Inspection arată versiunea cunoscută de Google și oferă un test live. Transcriptul oficial Google citit pentru acest articol subliniază diferența: raportul inițial descrie ultima indexare, în timp ce testul live verifică accesul curent. După un release, ai nevoie de ambele perspective.
Completează instrumentele cu verificare editorială. Compară fiecare câmp important cu pagina vizibilă, sursa internă și feedurile externe. Un validator poate accepta un preț formatat corect, dar nu știe că este vechi. Nu poate decide dacă autorul este real sau dacă o recenzie aparține produsului.
Monitorizarea începe după publicare
Erorile apar frecvent după un update de temă, plugin, catalog ori design. De aceea, o captură verde la lansare nu este control suficient. Include șabloanele critice într-un set de teste recurente și urmărește rapoartele Search Console pentru tipurile acceptate.
Un registru de schimbări ajută la diagnostic. Notează data releaseului, șabloanele afectate, tipurile modificate și exemplele de URL. Dacă impresiile pentru o apariție se schimbă, compară mai întâi cu releaseul și cu documentația Google, apoi cu sezonalitatea și cererea. Nu atribui automat variația unei singure linii JSON-LD.
Definește severitatea. JSON invalid pe toate produsele este incident. O proprietate recomandată lipsă poate fi îmbunătățire. Un tip rămas fără funcție în Google, cum este FAQ după mai 2026, este decizie de produs: îl păstrezi pentru alte consumuri ori îl elimini pentru a reduce complexitatea.
Leagă monitorizarea tehnică de serviciile de măsurare. Nu urmări doar numărul de elemente valide. Urmărește paginile eligibile, impresiile funcției unde există raport, clicurile, conversia post-clic și costul de mentenanță. Un markup care consumă ore lunar și nu susține nicio experiență ori integrare are nevoie de o nouă justificare.
Auditul care separă defectul de oportunitate
Un audit util nu produce doar o listă de erori dintr-un crawler. El răspunde, în această ordine, la întrebări de business și tehnice.
- Ce tip de pagină este și care este entitatea principală?
- Ce informații sunt vizibile și cine le deține în sistem?
- Ce date structurate sunt randate acum și de câte componente?
- Sunt sintactic valide și conforme cu vocabularul?
- Există o funcție documentată care justifică implementarea?
- Câmpurile corespund HTML-ului, feedului și realității operaționale?
- Pagina este crawlabilă, indexabilă și canonică?
- Cum se testează după release și cine răspunde la alerte?
- Ce rezultat măsurabil ar justifica efortul?
Clasifică descoperirile în trei coșuri. Defectele creează contradicții ori neeligibilitate: JSON invalid, preț greșit, markup ascuns, tip irelevant. Oportunitățile adaugă o funcție cu sens: Product complet pe pagini eligibile, VideoObject pentru demonstrații sau autori legați corect. Zgomotul este tot ce sună sofisticat, dar nu are consumator, scop ori proprietar.
Această separare protejează bugetul. Nu orice avertisment merită sprint imediat, iar absența unui tip nu este automat problemă. Prioritizează după numărul de pagini afectate, riscul pentru utilizator, valoarea funcției și costul remedierii.
Plan de implementare în patru săptămâni
În prima săptămână inventariezi. Selectezi șabloanele reprezentative, extragi markupul randat, identifici generatoarele și notezi contradicțiile. În paralel, stabilești registrul entităților principale: organizație, autori, produse, servicii și locații.
În a doua săptămână proiectezi modelul țintă. Alegi tipurile care corespund paginilor și funcțiilor curente, proprietățile obligatorii, @id-urile și sursa fiecărui câmp. Scoți din plan proprietățile care nu pot fi menținute. Scrii exemple de acceptare pentru fiecare template.
În a treia săptămână implementezi într-un mediu controlat și testezi pe exemple. Verifici sintaxa, eligibilitatea, outputul randat pe mobil și consistența cu feedurile. Incluzi scenarii de margine: produs fără stoc, autor retras, eveniment anulat, pagină paginată și variantă de produs.
În a patra săptămână publici gradual, inspectezi URL-urile și activezi monitorizarea. Compari un grup înainte–după numai unde există suficient volum și unde alte schimbări nu distrug comparația. Documentezi limitările; nu transformi o corelație de scurtă durată într-o promisiune comercială.
Dacă ai nevoie de ajutor, un audit SEO tehnic poate integra markupul în crawl, indexare, canonicalizare, rendering și arhitectură. Datele structurate izolate de restul sistemului produc rapoarte frumoase, dar rareori rezolvă problema reală.
Întrebări frecvente
Datele structurate mă ajută să apar în răspunsurile AI?
Pot reduce ambiguitatea și pot descrie entități într-un format procesabil, dar Google spune că nu există schema specială pentru AI Overviews sau AI Mode. Apariția depinde de sistemele Search, eligibilitate, relevanță și calitatea informației; markupul nu o garantează.
Este JSON-LD obligatoriu pentru SEO?
Nu. Google acceptă JSON-LD, Microdata și RDFa pentru tipurile documentate și recomandă de regulă JSON-LD pentru implementare și mentenanță. O pagină poate fi indexată și clasată fără date structurate, dar poate rata anumite rich results.
Mai merită să păstrez FAQPage după retragerea Google?
Numai dacă ai un scop verificabil în alt sistem ori vrei să păstrezi reprezentarea semantică. Pentru Google Search, FAQ rich results nu mai apar din mai 2026, deci nu mai justifica implementarea prin promisiunea acelui rezultat.
Ce diferență este între Schema.org și Rich Results Test?
Schema.org definește vocabularul general. Schema Markup Validator verifică acel vocabular. Rich Results Test verifică tipurile și cerințele pe care Google le folosește pentru propriile rezultate îmbogățite. Un cod poate trece primul test și să nu fie eligibil pentru o funcție Google.
Pot copia schema unui concurent care se clasează bine?
Poți inspecta public codul pentru a înțelege o implementare, dar copierea nu demonstrează că tipurile, identificatorii și proprietățile se aplică site-ului tău. Folosește documentația și propriile date drept specificație; altfel riști markup fals sau contradictoriu.
Cât de des trebuie reverificate tipurile implementate?
La fiecare schimbare de template și cel puțin trimestrial pentru funcțiile importante. Urmărește și jurnalul Search Central: retragerea FAQ rich results din 2026 arată că o funcție acceptată poate fi restrânsă sau eliminată.
Decizia corectă este mai mică decât pare
Nu ai nevoie de cel mai mare graf, ci de cel mai mic model care descrie corect pagina și poate fi întreținut. Alege tipurile după entitatea reală și funcția documentată, alimentează-le din sursa de adevăr, leagă nodurile stabile și verifică outputul public.
Pentru AI Search, păstrează concluzia modestă: datele structurate pot clarifica, dar nu controlează crawlerul și nu cumpără citarea. Avantajul vine din combinarea lor cu pagini accesibile, informație distinctă, surse vizibile și o arhitectură în care fiecare entitate are locul ei.