2026-01-14 · Redacția Baduno · 7 blog.readMin · Blog & Cunoștințe
Date structurate: Schema.org explicat pe înțeles
Informații suplimentare lizibile de mașină transformă rezultatele căutării în rezultate bogate cu evaluări, întrebări frecvente și date despre companii. Așa funcționează.
Ce sunt datele structurate
Blocuri JSON invizibile în codul sursă descriu ce conține pagina: Aceasta este o companie cu această adresă, acesta este un articol cu această dată, aceasta este o listă de întrebări frecvente cu aceste întrebări. Motoarele de căutare nu trebuie să ghicească – ele citesc.
Ce beneficii aduce
Calificare pentru afișări extinse (extrase FAQ, breadcrumbs, panou organizație), o mai bună înțelegere a conexiunilor și intrări mai curate în graficul de cunoștințe. Nu este un turbo de clasare – dar mai mult spațiu și încredere în rezultatul căutării.
Cele mai importante tipuri pentru companii
Organization cu date de înregistrare, WebSite, Service sau Product cu Offer, Article pentru articole tehnice, FAQPage și BreadcrumbList. Pentru multilingv: Fiecare versiune lingvistică poartă propria marcare tradusă.
Nu uitați să validați
Testul Rich-Results arată ce citește Google, validatorul Schema verifică sintaxa. O marcare eronată este mai gravă decât lipsa acesteia – costă încredere și, în cel mai rău caz, afișarea extinsă.
Date structurate și hreflang: Colaborare perfectă pentru site-uri multilingve
O sursă frecventă de erori în site-urile multilingve este utilizarea inconsistentă a datelor structurate și a tag-urilor hreflang. În timp ce hreflang semnalează motoarelor de căutare alternativele lingvistice și regionale ale unei pagini, datele structurate dezvăluie tipul de conținut. Ambele sunt independente, dar se completează reciproc: o pagină de produs în germană ar trebui să aibă atât un tag hreflang către varianta engleză, cât și, în blocul de date structurate, același ID de produs cu oferte și limbi diferite. Important: fiecare versiune lingvistică primește propriul bloc JSON-LD cu valori corespunzătoare – altfel apar contradicții. Testul de rezultate bogate (Rich Results) al Google arată adesea erori atunci când, de exemplu, organizația din versiunea germană conține o adresă engleză. Prin urmare, verificați ambele marcaje în paralel după fiecare lansare lingvistică.
Întreținere și actualizare: Cine întreține datele?
Datele structurate nu sunt un proiect unic. Dacă se modifică prețuri, ore de funcționare sau detalii despre produse, blocurile JSON-LD trebuie actualizate. Ideal, sistemul de gestionare a conținutului ar trebui să asigure popularea dinamică. Dacă această automatizare lipsește, este necesară o persoană responsabilă clară în echipă – de exemplu, redactorul pentru datele articolelor și întrebărilor frecvente (FAQ), dezvoltatorul pentru datele organizaționale. Evitați silozurile de date: un număr de telefon învechit în blocul Organization dăunează încrederii. Planificați analize trimestriale ale tuturor datelor structurate, cel puțin înainte de fiecare relansare majoră. Util este un tablou de bord central care afișează toate paginile marcate și starea lor de validare.
Crearea și verificarea datelor structurate asistate de AI
Instrumentele moderne de AI pot genera automat JSON-LD din text nestructurat – de exemplu, pentru pagini de întrebări frecvente (FAQ) sau articole. Aceasta accelerează munca, dar prezintă riscuri: AI trece adesea cu vederea nuanțe contextuale (de exemplu, preț greșit sau dată învechită). Prin urmare, verificarea de către un redactor nativ este indispensabilă. Folosiți AI pentru versiunea brută, apoi lăsați o persoană să valideze valorile. Și pentru site-urile multilingve, AI ajută la traducerea datelor structurate, dar tag-urile hreflang și ID-urile specifice limbii trebuie setate manual. O abordare dovedită: AI creează blocul standard în engleză, iar un redactor local corectează și completează câmpurile specifice țării.
Informații suplimentare lizibile de mașină transformă rezultatele căutării în rezultate bogate cu evaluări, întrebări frecvente și date despre companii. Așa funcționează.
Marcarea conținutului dinamic: Întrebări frecvente, recenzii și produse
Erorile apar frecvent la conținutul dinamic. Paginile cu întrebări frecvente ar trebui să aibă câte o intrare JSON-LD pentru fiecare întrebare – nu întreaga listă ca un singur obiect Question. La recenzii, scara de evaluare trebuie indicată corect (de exemplu, bestRating și worstRating). Paginile de produs cu variante necesită blocuri AggregateOffer cu toate informațiile despre preț și disponibilitate. Utilizați șabloane în CMS care generează automat tipurile corecte. Testați fiecare pagină dinamică individual în Rich-Results-Test, deoarece erorile devin vizibile doar la valori concrete. O greșeală frecventă: utilizarea 'Review' în loc de 'AggregateRating' pentru evaluări medii.
Combinarea mai multor tipuri Schema.org pe o pagină
Pe o singură pagină puteți marca mai multe tipuri Schema.org în paralel, cu condiția ca acestea să descrie aspecte diferite ale conținutului. O pagină de produs poate conține simultan un bloc Product (cu preț, disponibilitate), un bloc Organization (pentru producător) și un bloc Review (pentru evaluări). Este important ca fiecare tip să fie într-un script JSON-LD propriu sau să fie legat consecvent prin @id. Exemplu: Blocul Product face referire la blocul Organization prin "brand": {"@id": "#organisation"}. Evitați informațiile contradictorii – de exemplu, adrese diferite în blocurile Organization și LocalBusiness. Fiecare tip trebuie marcat corect din punct de vedere al conținutului și specific limbii: O pagină în limba franceză primește valori în franceză în toate blocurile. Folosiți CMS-ul pentru a gestiona tipurile modular, astfel încât să nu fie nevoie să ajustați manual fiecare bloc. Verificați în testul Rich Results dacă toate blocurile sunt acceptate – unele teste afișează doar primul bloc. O combinație curată de mai multe tipuri crește șansele de a obține rezultate îmbogățite precum carusel, casete de produs sau panou al organizației.
Lucrul cu @id și referințe pentru date conexe
Schema.org permite referirea obiectelor prin @id, evitând astfel datele redundante. În loc să repetați organizația completă pe fiecare pagină, definiți un bloc central Organization cu un @id unic (de ex., "https://exemplu.ro/#firma") și faceți referire la el în alte blocuri prin "@id": "https://exemplu.ro/#firma". Acest lucru este util în special pentru site-urile multilingve: Organizația rămâne aceeași, doar câmpurile specifice limbii precum „name” sau „description” diferă. Asigurați-vă că @id-ul este consecvent în toate versiunile lingvistice – adică același URI pentru germană, engleză etc. Referințele pot fi folosite și pentru autori de articole, mărci de produse sau elemente de recenzii. Validați cu Schema Validator că toate referințele @id sunt rezolvabile. O eroare: Dacă @id-ul referit nu este definit în același cod sursă al paginii sau pe altă pagină, validarea eșuează. Prin urmare, stocați entitățile centrale fie într-un fișier global (de ex., organizatie.json) și includeți-l prin JavaScript, fie folosiți CMS-ul pentru includerea dinamică. O structură curată de @id facilitează motoarelor de căutare conectarea informațiilor și îmbunătățește consistența în Knowledge Graph.
Marcarea corectă a BreadcrumbList: Sfaturi și capcane
Marcarea BreadcrumbList poate părea simplă, dar în practică apar frecvent erori care pun în pericol succesul fragmentelor îmbogățite (Rich Snippets). O implementare corectă începe cu înțelegerea ierarhiei: fiecare intrare din listă necesită un obiect ItemListElement, care la rândul său conține un obiect ListItem. Proprietatea Position este esențială: numerotează elementele în ordine crescătoare, începând cu 1 pentru pagina principală. Evitați omiterea paginii principale – chiar dacă nu apare în breadcrumb-ul vizibil, ar trebui să fie inclusă în datele structurate. O greșeală frecventă este utilizarea URL-urilor absolute fără a ține cont de versiunea lingvistică: asigurați-vă că URL-ul din breadcrumb face referire la varianta lingvistică corectă, de exemplu /de/produkte în loc de /en/products. De asemenea, denumirea elementelor trebuie să fie specifică limbii – 'Startseite' în germană, 'Home' în engleză. Utilizați câmpul name pentru textul afișat și evitați abrevierile sau prescurtările pe care motoarele de căutare le-ar putea interpreta greșit. După implementare, verificați fiecare cale cu Rich Results Test, deoarece în special în cazul breadcrumb-urilor generate dinamic se pot inversa pozițiile sau crea intrări duplicate. De asemenea, rețineți că Google afișează maximum zece elemente – o navigare mai scurtă și precisă este de preferat uneia prea lungi.
Obiecte imbricate și referințe: @id și @context
Datele structurate complexe folosesc adesea legătura mai multor tipuri prin referințe @id. Un exemplu tipic este o pagină Product care conține atât un Offer, cât și o Review. În loc să înghesuiți toate datele într-un bloc monolitic, este mai curat să definiți blocuri separate cu valori @id unice și apoi să le referiți. Valoarea @id trebuie să fie unică în cadrul paginii și al întregului domeniu – ideal, utilizați URL-ul absolut al obiectului cu un fragment precum #product-1. Evitați ID-uri generice precum #product, deoarece pot crea conflicte pe mai multe pagini. Un alt aspect important este @context: în mod implicit se utilizează vocabularul Schema.org, dar pentru extensii proprietare se poate specifica un context propriu. Aveți grijă ca extensii verificate precum health-lifesci sau bib să nu ajungă din greșeală pe pagini comerciale. În cazul paginilor multilingve, referințele @id trebuie să fie specifice limbii: pagina de produs în germană face referire la ID-ul Offer-ului german, nu la cel englezesc. O tehnică utilă este utilizarea @reverse pentru relații inverse, de exemplu când un Product face referire la o Organizație, dar organizația nu are o listă directă a tuturor produselor. Testați astfel de înlănțuiri în Schema Validator, deoarece chiar și un singur caracter lipsă (de exemplu, două puncte) poate duce la o eroare de validare. Alocați suficient timp pentru depanarea obiectelor referite – acestea sunt o sursă frecventă de erori în implementările complexe.
blog.faqT
Pot să adaug date structurate ulterior pe paginile vechi?
Da, datele structurate pot fi adăugate oricând. Asigurați-vă că toate informațiile sunt actuale. Utilizați testul Rich-Results de la Google pentru a verifica implementarea corectă. În cazul mai multor pagini, se recomandă o abordare treptată în funcție de tipul de conținut.
Cât de des ar trebui actualizate datele structurate?
Ori de câte ori se schimbă informațiile de bază (prețuri, ore de funcționare, detalii produs). Planificați cel puțin o verificare trimestrială completă. Sistemele dinamice pot completa automat datele – ceea ce reduce efortul de actualizare și sursele de erori.
