Date structurate: de care are nevoie cu adevărat site-ul unei firme
Datele structurate nu sunt un factor de clasare. Sunt o traducere: spun mașinilor ce înseamnă un fragment de text, în loc să le lase să ghicească. Exact asta decide tot mai mult dacă o pagină apare sau nu în răspunsuri.
Pe scurt
- Patru tipuri ajung pentru aproape orice site de firmă: Organization, WebPage respectiv Article, BreadcrumbList și FAQPage.
- Se livrează JSON-LD în
<head>– nu ca marcaj în textul curent. - Cea mai frecventă greșeală este tăcută și costisitoare: informații în datele structurate care nu se regăsesc pe pagina însăși.
- Trei tipuri mult discutate pot fi lăsate deoparte de o firmă de servicii – ele funcționează doar cu o ofertă potrivită sau cu evaluări reale.
O mașină care citește o pagină vede la început doar text. Că «Emma Woelk» este un om, «TEISENDA GmbH» o companie, iar «22 august 2026» o dată de publicare, trebuie să ghicească – sau stă scris explicit acolo.
Datele structurate sunt acest scris explicit. Nu îmbunătățesc nicio poziție. Ele decid dacă o pagină intră în discuție pentru afișări extinse și pentru răspunsuri generate.
Cele patru care ajung
1. Organization – o singură dată, pe pagina de start
Cine sunteți: nume, adresă, siglă, anul înființării, profiluri în alte rețele. Aceasta este înregistrarea care face posibil ca o siglă să apară lângă rezultatul căutării – iar cel mai frecvent motiv pentru care lipsește este pur și simplu absența acestei înregistrări.
Important: sigla trebuie să existe ca imagine raster. Un SVG nu este evaluat în acest loc.
2. WebPage sau Article – pe fiecare pagină
Ce este această pagină: titlu, descriere, limbă, data publicării și a ultimei revizuiri. La articole, în plus Article respectiv BlogPosting cu autorul ca înregistrare Person proprie – cu rol, nu doar cu nume.
Important: data modificării trebuie să fie corectă. O dată care se setează din nou la fiecare încărcare a paginii este un semnal care se devalorizează singur.
3. BreadcrumbList – pe toate subpaginile
Unde stă această pagină în structură. Vizibilă ca traseu în partea de sus a paginii, lizibilă pentru mașini în zona de antet. Cele două țin împreună – un traseu în date care nu există pe pagină este o informație falsă.
4. FAQPage – acolo unde există întrebări reale
Secțiunea de întrebări de la finalul unui articol. Pentru motoarele de răspuns, tipul cel mai valoros dintre toate, pentru că livrează întrebarea și răspunsul deja ca pereche – exact forma în care se citează.
Important: doar pentru întrebări efectiv vizibile pe pagină. Întrebările inventate, care stau doar în date, sunt o încălcare a regulilor.
Trei de care vă puteți lipsi
Product și Offer. Pentru servicii cu ofertă la cerere nu aduc nimic – fără preț și disponibilitate nu sunt oricum afișate. Au sens abia la un magazin adevărat.
AggregateRating. Stelele în rezultatul căutării sunt ispititoare și legate de condiții stricte: evaluările trebuie să fie reale, verificabile și vizibile pe pagină. Evaluările acordate de voi înșivă sunt o încălcare a regulilor, cu risc real.
HowTo. A fost restrâns considerabil în afișare și nu mai merită efortul de întreținere pentru majoritatea site-urilor de firmă.
Știai că…?
Datele structurate nu sunt un factor de clasare – Google a clarificat asta de mai multe ori. Ele decid asupra afișării, nu asupra poziției.
Pentru motoarele de răspuns lucrurile stau puțin altfel. Un model care trebuie să construiască un răspuns dintr-o pagină folosește cu precădere ce este marcat fără echivoc: perechi întrebare-răspuns, autor cu rol, data ultimei verificări. Atunci nu mai trebuie să ghicească ce ține împreună. Folosul stă deci mai puțin în clasare, cât în posibilitatea de a fi citat.
Cum se integrează
Trei reguli care evită majoritatea problemelor.
- JSON-LD, în
<head>. Nu ca atribute în textul curent. JSON-LD se poate întreține separat de aspect și nu se pierde la schimbările de design. - Un bloc pe pagină, nu cinci. Mai multe înregistrări se pun într-un
@graphși se leagă între ele prin@id. Astfel articolul trimite la aceeași organizație care stă pe pagina de start, în loc să o repete. - Generați-le din aceeași sursă ca și conținutul vizibil. Dacă titlul, data și autorul vin din aceleași câmpuri ca pagina însăși, nu au cum să se despartă. Aceasta este cea mai eficientă prevenție dintre toate.
Cea mai costisitoare greșeală este cea mai tăcută: datele structurate spun ceva ce nu stă pe pagină. O dată de modificare de ieri la un text din 2023. Un autor care nu apare în zona vizibilă. Întrebări în date care nu există pe pagină.
Asta nu îi sare în ochi niciunui instrument de verificare – datele sunt formal valide. Iese la iveală la o verificare manuală, iar atunci consecința nu privește doar marcajul în cauză. De aceea regula «generați din aceeași sursă» este mai importantă decât orice completitudine.
Verificarea – în această ordine
| Pasul | Cu ce | Ce vedeți |
|---|---|---|
| 1. Sintaxa | Validatorul de marcaj Schema | Dacă JSON-ul este valid și tipul corect |
| 2. Posibilitatea de afișare | Testul pentru rezultate îmbogățite | Dacă ar fi posibilă o afișare extinsă |
| 3. Realitatea | Search Console, zona Îmbunătățiri | Ce a fost recunoscut efectiv, pe toate paginile |
| 4. Concordanța | Citire proprie | Dacă fiecare informație stă și vizibil pe pagină |
Pasul patru este singurul pe care nu îl preia niciun instrument – și singurul la care ies la iveală greșelile serioase.
Verifică datele structurate ale acestei pagini din punctul de vedere al completitudinii și al concordanței cu conținutul vizibil. Conținutul vizibil al paginii: [inserați textul paginii] JSON-LD al paginii: [inserați blocul] Sarcini: 1. Numește fiecare informație din JSON-LD care nu apare în conținutul vizibil. Acesta este punctul cel mai important – fii temeinic aici. 2. Numește fiecare informație vizibilă care ar trebui marcată, dar lipsește (autor cu rol, data modificării, întrebări, traseu). 3. Verifică dacă cele patru tipuri de bază sunt ocupate cu sens: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Numește tipurile din bloc care, pentru o firmă de servicii fără magazin și fără evaluări verificabile, nu au niciun folos. 5. Semnalează orice încălcare a regulilor, în special evaluările acordate de firmă însăși și întrebările care nu există pe pagină. Afișează la final integral JSON-LD corectat. Nu inventa valori – marchează ce lipsește cu [de completat].
Concluzie
Datele structurate sunt repede supraevaluate și la fel de repede făcute greșit. Patru tipuri acoperă nevoia unui site de firmă, iar folosul lor stă mai puțin în poziție, cât în faptul de a putea fi citat.
Regula unică ce susține totul: nu marcați nimic ce nu stă pe pagină. Cine generează datele din aceeași sursă ca și conținutul vizibil a rezolvat structural această problemă – și își poate economisi în bună măsură verificările ulterioare.
Întrebări frecvente
De ce date structurate are nevoie site-ul unei firme?
Patru tipuri ajung: Organization o singură dată pe pagina de start, WebPage respectiv Article pe fiecare pagină, BreadcrumbList pe toate subpaginile și FAQPage peste tot unde există întrebări reale, vizibile. Product, AggregateRating și HowTo nu merită de regulă pentru o firmă de servicii.
Îmbunătățesc datele structurate clasarea?
Nu. Nu sunt un factor de clasare, ci decid asupra afișării – de pildă dacă pot apărea o siglă, un traseu sau întrebări pliabile în rezultatul căutării. Pentru motoarele de răspuns cresc posibilitatea de a fi citat, pentru că perechile întrebare-răspuns, autorul și data sunt marcate fără echivoc, în loc să fie ghicite.
De ce nu ne afișează Google sigla?
Cel mai frecvent motiv este o înregistrare Organization lipsă sau incompletă pe pagina de start. Al doilea motiv ca frecvență: sigla depusă există doar ca SVG – în acest loc este nevoie de o imagine raster. Nici la un marcaj corect nu există un drept la afișare.
Care este cea mai frecventă greșeală la datele structurate?
Informații care stau în date, dar nu în conținutul vizibil: o dată de modificare greșită, un autor nemenționat, întrebări inventate. Instrumentele de verificare nu semnalează asta, pentru că datele sunt formal valide. Se poate evita generând marcajul din aceeași sursă ca și textul vizibil.
JSON-LD sau Microdata?
JSON-LD în <head>. Este forma recomandată de Google, se poate întreține separat de aspect și nu se pierde la schimbările de design. Microdata împrăștie marcajul prin textul curent și se rupe la fiecare reconstrucție a paginii.
Marketing care se configurează singur
Beta Studio Engine este deschisă. Rezervă-ți locul și contribuie de la început.
Participă la beta →