Dacă te uiți la Search Console și vezi date ok, dar CTR este sub așteptări, de multe ori nu e „conținutul slab”. E faptul că Google nu înțelege suficient de clar *ce* e pagina ta și *ce merită afișat* în SERP.
Schema markup e una dintre puținele optimizări care pot schimba modul în care arăți în rezultate fără să-ți schimbe poziția. Și da, în 2026 contează mai mult, pentru că AI Overviews și rezultatele îmbogățite au ridicat standardul: cine are date structurate curate, are șanse mai bune să fie „ales” pentru afișări.
Semrush explică foarte bine baza (ce e, tipuri, cum o adaugi) în ghidul lor despre SCHEMA MARKUP și implementare. Ce mi se pare important, dincolo de definiții, e partea practică: schema nu e un boost, ci un limbaj pe care îl vorbești cu motoarele de căutare. Dacă îl vorbești prost, nu te ajută. Dacă îl vorbești bine, îți poate ridica CTR-ul și calitatea traficului.
Ce merită să reții: când e făcută corect, e că îți poate aduce rich results (recenzii, preț, stoc, breadcrumbs, FAQ, evenimente etc.), îți poate clarifica entități (brand, organizație, autor) și îți poate reduce ambiguitatea în pagini unde Google se chinuie prea mult.
Schema markup: de ce contează și pentru Google, și pentru AI Search
Schema markup = un set de etichete (structured data) care descriu explicit conținutul paginii. Nu e pentru oameni, e pentru sisteme: Google, Bing, dar și pentru componentele AI care încearcă să înțeleagă „cine e cine” și „ce e ce” într-o pagină.
Gândește-te așa: tu ai o pagină de produs cu „iPhone 16 Pro, 256GB, 5.499 lei”. Un om vede imediat că e produs, preț, monedă, disponibilitate stoc, etc.. Un crawler vede text, niște div-uri, poate un tabel. Schema e scheletul în care îi spui clar: `Product`, `Offer`, `price`, `priceCurrency`, `availability`, `brand`, `gtin`. Iar motoarele înțeleg.
Schema markup este structured data (de obicei în format JSON-LD) care descrie explicit ce reprezintă o pagină: produs, articol, companie, eveniment, recenzie, etc. Ajută motoarele de căutare să înțeleagă conținutul și poate debloca rich results (preț, stoc, breadcrumbs, FAQ), crescând CTR-ul fără să schimbi neapărat poziția.
Cum funcționează în practică:
Cea mai sănătoasă implementare în 2026 rămâne JSON-LD (script în `<head>` sau în body), pentru că e mai ușor de întreținut și nu-ți cere să „împachetezi” HTML-ul cu microdata. Google recomandă în general JSON-LD pentru majoritatea tipurilor, iar documentația oficială e aici: Google Search Central – structured data.
Ce contează, din experiență, nu e doar să „ai schema”, ci să fie:
- validă (fără erori de sintaxă, tipuri greșite, câmpuri lipsă obligatorii)
- aliniată cu conținutul vizibil (dacă zici „în stoc”, pe pagină trebuie să fie în stoc)
- consistentă între pagini (aceleași câmpuri, aceeași logică)
- scalabilă (să nu depindă de copy-paste manual pe 500 de pagini)
Unde se rupe filmul, de obicei
Aici multe business-uri greșesc: pun schema cu un plugin, văd „Valid” în test, apoi uită de ea. După 2-3 luni schimbă tema, schimbă modul de afișare a prețului, adaugă reduceri dinamice, și rămâne în urmă. Rezultatul: warnings, rich results care dispar, sau mai rău, markup considerat „misleading”.
Ce tipuri de schema merită prioritate (în ordinea impactului)
Nu toate tipurile sunt la fel de utile. Dacă ai resurse limitate, aș prioritiza așa:
Pentru eCommerce:
- Product + Offer (preț, monedă, disponibilitate, condiție, brand, GTIN)
- BreadcrumbList (îți curăță snippet-ul și ajută la structură)
- Organization + WebSite (brand, logo, social profiles, search action)
- Review / AggregateRating doar dacă ai review-uri reale, vizibile și colectate corect
Pentru servicii locale (clinici, service auto, saloane):
- LocalBusiness (NAP, program, geo, servicii)
- Service (unde are sens, mai ales pe pagini dedicate)
- FAQPage (doar pentru întrebări reale, nu „SEO bait”)
Pentru publisheri / blog:
- Article / BlogPosting (autor, dată, imagine, headline)
- Organization / Person (entități clare pentru autor și brand)
- BreadcrumbList
Dacă vrei să verifici rapid ce tipuri de rich results sunt suportate și ce câmpuri sunt obligatorii, Google are lista actualizată în Rich Results Test și documentația aferentă.
Implementare:
Nu-ți dau „pasul 1, pasul 2” ca la rețetă, dar logica e simplă:
1) Alege sursa de adevăr pentru date.
Prețul vine din WooCommerce/Shopify? Stocul vine din ERP? Autorul vine din CMS? Schema trebuie să tragă din aceleași câmpuri, nu din texte hardcodate.
2) Definește template-uri pe tip de pagină.
- pagină produs: Product + Offer + BreadcrumbList
- categorie: de obicei doar BreadcrumbList (și eventual ItemList cu grijă, nu mereu merită)
- articol: Article + BreadcrumbList
- contact/despre: Organization/ LocalBusiness
3) Validează și monitorizează.
Nu doar o dată. La fiecare release de temă/plugin, mai ales dacă ai reduceri, bundle-uri, prețuri dinamice.
Tool-uri pe care le folosim și noi (și de ce)
– Rich Results Test – îți spune dacă e eligibil pentru rich results, nu doar dacă JSON-ul e „valid”.
– Schema Markup Validator – bun pentru validare generală, inclusiv tipuri care nu sunt rich results în Google.
– Google Search Console – îți arată erori/warnings la nivel de site și trend în timp.
Un detaliu mic, dar important: Rich Results Test îți poate arăta „valid”, dar Search Console să-ți raporteze probleme pe URL-uri specifice. De obicei e din cauza datelor dinamice (stoc/preț) sau a paginilor generate diferit (variații, parametri).
Impact real: unde vezi rezultate și unde schema e doar „nice to have”
Schema nu îți garantează rich results. Google decide. Dar când ai eligibilitate și date curate, ai două efecte pe care le-am văzut repetat:
1) CTR mai bun pe aceleași poziții, pentru că snippet-ul e mai informativ (preț, stoc, breadcrumbs, FAQ).
2) Trafic mai calificat, pentru că utilizatorul vede din SERP detalii care filtrează intenția (ex: prețul). Uneori traficul scade ușor, dar conversia crește. Și asta e un trade-off bun.
Când ajută cel mai mult
- eCommerce cu multe produse: preț/stoc/brand sunt diferențiatori direcți în SERP.
- site-uri locale: program, adresă, servicii, FAQ – reduc întrebările repetitive și cresc apelurile.
- site-uri cu conținut evergreen: Article + autor + date corecte ajută la încredere și la claritate.
Când nu merită să te complici (încă)
- Ai un site de prezentare cu 5 pagini și fără trafic organic semnificativ: mai întâi rezolvă indexarea, conținutul, paginile de servicii, viteza.
- Ai date instabile (prețuri care se schimbă de 10 ori pe zi, stocuri incerte) și nu poți sincroniza schema: mai bine simplu decât greșit.
- Vrei FAQPage peste tot doar ca să ocupi mai mult spațiu în SERP: în 2026, Google e mult mai selectiv cu afișarea FAQ, iar abuzul nu ajută.
Greșeli frecvente care te încurcă fără să-ți dai seama
Nu o să ruineze tot, dar… schema greșită e genul de problemă care te face să pierzi oportunități fără să fie evident. Uite ce văd cel mai des în audituri.
1) Schema nu reflectă ce e pe pagină
Dacă în schema zici 99 lei, iar pe pagină e 129 lei, Google poate ignora markup-ul. La fel cu stocul, rating-ul, numărul de review-uri. În special la Product, diferențele astea apar când:
- prețul e afișat cu JS după load
- ai prețuri diferite pe variații, dar schema ia doar primul preț
- ai reduceri și rămâne pe prețul vechi
2) AggregateRating fără review-uri reale
Asta e clasic. Plugin-uri care pun stele „din burtă” sau importă rating-uri fără să fie vizibile utilizatorului. Google e destul de strict aici: dacă utilizatorul nu vede review-urile, nu prea ai ce căuta cu `Review`/`AggregateRating`.
3) Markup duplicat sau conflict între plugin-uri
WooCommerce + un plugin SEO + un plugin de schema = trei surse care injectează `Product`. Rezultatul: câmpuri diferite, entități diferite, warnings.
4) Folosești tipuri care nu sunt suportate ca rich results
Schema.org are sute de tipuri. Google folosește o parte pentru rich results. Restul pot ajuta la înțelegere semantică, dar nu te aștepta să apară „badge-uri” în SERP doar pentru că ai pus Service sau ItemList. E util, dar nu e garantat vizibil.
5) Nu monitorizezi după implementare
Schema nu e „set and forget”. Dacă ai:
- migrare de domeniu
- schimbare de temă
- schimbare de structură URL
- trecere la headless
… e printre primele lucruri care se strică subtil.
Ce aș monitoriza lunar (10 minute, nu mai mult):
- Search Console – Enhancements (erori noi, trend)
- Rich Results Test pe 3-5 URL-uri cheie (produse top, servicii top)
- un crawl cu Screaming Frog (dacă ai licență) ca să vezi markup-ul la scară
FAQ (întrebări pe care le primim des)
Cât durează să văd rezultate după implementarea schema?
Depinde de cât de des îți recrawlează Google paginile și cât de „curat” e markup-ul. În practică, pe site-uri cu trafic decent, am văzut schimbări în 1–3 săptămâni pentru pagini importante (produse, servicii). Pe site-uri mici, poate dura 4–8 săptămâni. Important: faptul că ai schema validă nu înseamnă automat rich results. Google poate testa, poate afișa intermitent, apoi stabiliza. Monitorizează în Search Console la Enhancements și uită-te la CTR pe paginile unde ai implementat.
Merge schema markup pe Shopify fără să scriu cod?
Da, de cele mai multe ori. Shopify are deja structured data în teme moderne, iar multe aplicații adaugă schema suplimentară. Problema e controlul: dacă ai nevoie de `Offer` corect pe variații, `availability` sincronizat, sau vrei să eviți markup duplicat, ajungi să atingi tema (Liquid) sau să folosești o aplicație bună, configurată atent. Ce am observat: „merge” rapid, dar „merge corect” cere verificare în Rich Results Test și, uneori, ajustări mici în theme.liquid sau în template-ul de produs.
Pot să pun FAQ schema pe toate paginile ca să ocup mai mult spațiu în Google?
Poți, dar nu e o idee bună. În 2026, Google afișează FAQ rich results mult mai selectiv decât acum câțiva ani, iar abuzul (FAQ identic pe zeci de pagini, întrebări artificiale) nu-ți aduce beneficii reale. Mai eficient e să pui FAQ schema doar unde întrebările sunt specifice paginii și chiar ajută utilizatorul: livrare/retur pe categorie, compatibilitate pe produs, programări pe servicii. Dacă vrei „spațiu” în SERP, de obicei Product/Offer și breadcrumbs sunt pariul mai sigur.
Ce aleg: microdata, RDFa sau JSON-LD?
JSON-LD, aproape mereu. E mai ușor de întreținut, nu-ți murdărește HTML-ul și e mai simplu de generat din template-uri. Microdata/RDFa pot avea sens în proiecte vechi sau în situații foarte specifice, dar costul de mentenanță e mai mare (mai ales când schimbi layout-ul). Dacă ai un site cu multe update-uri (promoții, stoc, preț), JSON-LD îți reduce riscul să rămâi cu markup „în urmă” față de ce vede utilizatorul.
Schema markup nu e un „hack”, e infrastructură. În 2026, când SERP-ul e tot mai aglomerat (AI Overviews, rich results, carusele), infrastructura asta face diferența între „o pagină pe care Google o înțelege” și „o pagină pe care Google o ghicește”. Iar ghicitul nu e strategia ta.
Dacă ai eCommerce, primul quick win e Product + Offer + BreadcrumbList pe toate paginile de produs, cu preț/stoc sincronizate. Azi. Săptămâna asta, nu „când ai timp”. După aceea, verifică în Search Console dacă apar erori și urmărește CTR-ul pe paginile unde ai implementat.
