Schema.org și JSON-LD pentru articole și FAQ-uri: ghid practic

Datele structurate nu schimbă ce vede cititorul, dar îi spun motorului de căutare, pe înțelesul lui, ce este pagina: un articol, cine l-a scris, când a apărut, în ce secțiune se află. Aici găsești ce merită adăugat la articole și FAQ-uri, cu cod gata de adaptat.

Ce sunt Schema.org și JSON-LD, pe scurt

Schema.org este un vocabular comun, menținut public, care definește tipuri de lucruri (un articol, o organizație, o întrebare) și proprietățile lor (titlu, autor, dată). JSON-LD este formatul în care scrii aceste informații: un bloc de text în sintaxă JSON, pus în pagină, separat de conținutul afișat.

Diferența contează: Schema.org răspunde la întrebarea „ce cuvinte folosesc?”, iar JSON-LD la „cum le scriu în pagină?”. Google recomandă JSON-LD, pentru că nu cere să împletești marcajul cu HTML-ul vizibil. Poți modifica codul fără să atingi designul și invers. Google are și o documentație oficială despre datele structurate, în secțiunea Search Central.

De ce merită și la ce nu te poți aștepta de la ele

Marcajul nu este o metodă de a „păcăli” motoarele, ci o clarificare. Beneficiile realiste sunt:

• motoarele de căutare înțeleg mai ușor tipul paginii și relația dintre părțile ei;
• unele tipuri pot da afișări îmbogățite în rezultate (în funcție de politicile Google, care se schimbă);
• sistemele care rezumă pagini, inclusiv cele bazate pe AI, pot avea un punct de sprijin în plus pentru autor, dată și subiect, deși nimeni nu garantează că îl folosesc;
• îți disciplinează propria pagină: dacă nu poți completa autorul sau data, ai descoperit o lacună reală.

La ce nu te poți aștepta: o creștere garantată a pozițiilor sau afișări îmbogățite pentru orice pagină. Google decide singur ce afișează. Iar dacă marcajul descrie ceva ce nu se vede pe pagină, riști să încalci regulile motorului. Principiul simplu: ce e în cod trebuie să existe și în conținutul vizibil.

Article sau BlogPosting: ce tip alegi pentru un articol

Pentru un text de blog sau de presă, tipurile uzuale sunt Article, BlogPosting (un subtip pentru bloguri) și NewsArticle (pentru știri). Diferențele sunt mici; important e să rămâi consecvent. Pentru un articol de blog corporativ, BlogPosting sau Article sunt alegeri firești; pentru un anunț de presă datat, NewsArticle.

Conform documentației Google despre datele structurate pentru articole, tipul nu are proprietăți strict obligatorii, dar se recomandă să le completezi pe cele relevante. Cele mai utile sunt:

• headline – titlul articolului, fără să fie trunchiat;
• image – una sau mai multe imagini reprezentative, cu adresă completă;
• datePublished și dateModified – în format ISO 8601, cu fus orar;
• author – persoana (sau organizația) care semnează, cu nume și, dacă există, o pagină proprie;
• publisher – organizația care publică.

Exemplu ipotetic, pentru un articol al unui service auto fictiv:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Când schimbi uleiul: ghid pentru șoferul de oraș",
  "image": "https://www.exemplu.ro/img/schimb-ulei.jpg",
  "datePublished": "2026-09-14T09:00:00+03:00",
  "dateModified": "2026-09-20T11:30:00+03:00",
  "author": {
    "@type": "Person",
    "name": "Ioana Exemplu"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Service Auto Exemplu",
    "url": "https://www.exemplu.ro/"
  },
  "mainEntityOfPage": "https://www.exemplu.ro/blog/schimb-ulei/"
}
</script>

Observă că dateModified este mai nou decât datePublished. Actualizezi data de modificare doar când ai schimbat cu adevărat conținutul, nu ca să creezi impresia de proaspăt.

Organization și autorul: cine se află în spatele textului

Un articol în care nu se vede cine l-a scris și cine îl publică are mai puține repere pentru cititor și pentru sisteme. Marcajul Organization descrie firma: nume, adresă web, logo și, opțional, adresele oficiale ale profilurilor ei publice. Marcajul Person descrie autorul.

Pentru autor, câteva reguli practice:

1. folosește numele real, același cu cel afișat pe pagină;
2. dacă autorul are o pagină proprie pe site, trimite spre ea prin proprietatea url;
3. nu inventa titluri sau calificări care nu apar nicăieri;
4. dacă textul este semnat de o echipă, folosește Organization ca autor, nu un nume fictiv.

Organizația poate fi descrisă o singură dată, pe pagina principală sau pe pagina „Despre noi”, și apoi referită din articole prin același nume și aceeași adresă. Consecvența numelui, a siglei și a adresei poate ajuta motoarele să lege paginile de aceeași entitate.

BreadcrumbList: poteca din pagină

Breadcrumbs sunt linkurile de tip „Acasă > Blog > Titlul articolului”. Marcajul BreadcrumbList le descrie ca listă ordonată; fiecare element are poziție, nume și adresă. Motorul vede astfel ierarhia site-ului, iar în unele situații poate afișa poteca în rezultate în loc de adresa brută; afișarea depinde de dispozitiv și de politicile Google, care se schimbă.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Acasă",
      "item": "https://www.exemplu.ro/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://www.exemplu.ro/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Când schimbi uleiul"
    }
  ]
}
</script>

Ultimul element (pagina curentă) poate lipsi din proprietatea item. Ordinea numerelor de poziție trebuie să respecte ordinea reală din navigare, nu una „ideală” de pe hârtie.

FAQPage: ce mai oferă, de fapt, Google

Marcajul FAQPage descrie o pagină cu întrebări și răspunsuri scrise de același autor, fără ca utilizatorii să poată adăuga variante (pentru forumuri există alt tip). Structura este simplă: o listă de elemente Question, fiecare cu un acceptedAnswer.

Atenție la o schimbare importantă: Google a restrâns afișarea îmbogățită a întrebărilor frecvente în rezultate. La data scrierii, ea este rezervată în principal unor site-uri guvernamentale și de sănătate, bine cunoscute, așa că pentru un site obișnuit este mai prudent să nu contezi pe ea. Verifică întotdeauna documentația actuală despre FAQPage, pentru că regulile se pot schimba.

Atunci de ce l-ai folosi? Pentru că structura rămâne validă și clarifică pagina pentru sisteme care citesc conținutul. Condiția rămâne aceeași: întrebările și răspunsurile din cod trebuie să fie vizibile pe pagină, cu același text. Exemplu minimal:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Cât durează o schimbare de ulei?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "În mod obișnuit, aproximativ o oră, în funcție de mașină și de programări."
      }
    }
  ]
}
</script>

Despre cum alegi întrebările, cum formulezi răspunsurile și cum eviți duplicarea, vorbim separat, în articolul despre pagina de întrebări frecvente. Aici ne oprim doar la partea de cod.

Unde pui codul și cum combini mai multe tipuri

Blocul JSON-LD poate sta în head sau în body; motoarele îl citesc în ambele locuri. Pentru o pagină de articol ai două variante de organizare:

• mai multe blocuri separate, câte unul pentru fiecare tip (Article, BreadcrumbList, FAQPage). Sunt ușor de întreținut și de verificat;
• un singur bloc cu @graph, unde tipurile sunt listate împreună și se pot referi între ele prin identificatori. E mai compact, dar mai greu de depanat.

Pentru început, alege blocurile separate. Contează să nu apară același tip de două ori cu informații diferite pe aceeași pagină, pentru că rezultă semnale contradictorii. De asemenea, fiecare adresă din cod trebuie să fie completă (cu https://) și să ducă într-un loc care există.

Cum validezi markup-ul înainte și după publicare

Un cod JSON-LD cu o virgulă în plus nu este vizibil pentru cititor, dar poate fi ignorat de motor. De aceea, validarea face parte din procesul de lucru. Folosește două instrumente, care răspund la întrebări diferite:

1. Rich Results Test – verifică dacă pagina sau codul lipit poate genera afișări îmbogățite în Google și semnalează erorile și avertismentele relevante pentru acestea;
2. Schema Markup Validator – verifică sintaxa și tipurile Schema.org în general, indiferent de afișările Google.

Fluxul recomandat: pregătești codul, îl lipești în validator, repari erorile, îl pui în pagină, apoi testezi adresa publică a paginii. După publicare, urmărești raportul de îmbunătățiri din Search Console pentru tipurile detectate. Dacă vrei să generezi codul fără să-l scrii de mână, poți folosi generatorul de Schema JSON-LD, apoi verifici rezultatul în instrumentele de mai sus.

Greșeli frecvente pe care le poți evita

• Markup pentru conținut inexistent. Întrebări în cod care nu se află pe pagină, recenzii inventate, autori fictivi. Google poate trata astfel de practici drept încălcare a politicilor sale.
• Date incoerente. Titlul din cod diferă de titlul din pagină, iar data publicării de data afișată.
• Imagini inexistente sau inaccesibile. O adresă de imagine blocată sau ștearsă anulează un câmp util. Despre alegerea imaginilor ai un ghid separat, imagini pentru advertoriale.
• Copiere oarbă a unui șablon. Rămân numele și adresele altui site în codul tău.
• Sintaxă JSON greșită. Ghilimele tipografice în loc de ghilimele drepte, virgule rămase la final, acolade neînchise.
• Lipsa actualizării. Schimbi textul, dar uiți dateModified sau titlul din cod.

Lista de verificare înainte de publicare

Dacă ai parcurs ghidul și vrei un test rapid, răspunde la aceste întrebări, în ordine. Fiecare „nu” indică un loc de reparat.

1. Tipul ales (Article, BlogPosting, NewsArticle) corespunde naturii textului?
2. Titlul din cod este identic cu cel afișat deasupra articolului?
3. Data publicării și, dacă ai modificat textul, data actualizării sunt corecte și în format ISO 8601?
4. Autorul din cod apare și pe pagină, cu același nume?
5. Adresele de imagini, de organizație și de pagină sunt complete și funcționează?
6. Întrebările marcate cu FAQPage se văd toate pe pagină, cu aceleași răspunsuri?
7. Validatorul nu raportează erori, iar avertismentele au fost citite și înțelese?

Merită să faci această verificare și după redesign sau după schimbarea unei teme, pentru că aceste operații modifică uneori marcajele generate automat de sistemul de administrare. Un site care a avut date structurate corecte poate pierde, fără ca cineva să observe, un câmp important, doar pentru că un șablon nou nu îl mai completează. Un control trimestrial, cu 10–15 pagini luate la întâmplare, ajută de obicei să prinzi aceste derapaje la timp.

Și un advertorial publicat pe alt site?

Când plătești un articol pe un site care nu îți aparține, codul paginii este al publicației. De regulă nu poți cere un marcaj anume și nici nu e nevoie: publicațiile folosesc de obicei propriile șabloane. Ce poți controla este calitatea materialului: un titlu clar, un rezumat la început, un autor sau o semnătură corectă, subtitluri logice, o listă acolo unde are sens. Toate acestea fac ca textul să fie ușor de „citit” de oameni și de mașini, indiferent de marcaj.

Pe propriul site, însă, ai tot controlul. Acolo merită să marchezi articolele de blog, pagina de contact, organizația și potecile de navigare. Dacă nu ai timp sau resurse, un redactor poate structura textul astfel încât să fie ușor de marcat ulterior; vezi și cum arată redactarea articolelor SEO.

Pasul următor

Începe mic: un articol-test, cu BlogPosting, BreadcrumbList și, dacă are sens, o secțiune de întrebări. Validează, publică, apoi urmărește în Search Console ce raportează Google. Dacă totul e curat, extinzi la restul site-ului.

Iar dacă textele în sine sunt cele care cer atenție, adică lipsesc rezumatele, subtitlurile sau răspunsurile directe, sprijinul vine din redactare. Poți afla mai multe pe pagina serviciului de redactare de articole. Pentru decizia de a aloca timp sau buget acestor lucruri, ajută și articolul despre împărțirea bugetului de PR digital.

Întrebări frecvente