Schema markup în WordPress: date structurate și validare

Un test care arată „valid” nu înseamnă automat rezultate îmbogățite, poziții mai bune sau un site corect în toate privințele. Validarea poate confirma numai o parte a problemei: sintaxa, proprietățile recunoscute sau eligibilitatea pentru un anumit tip de rezultat. Conținutul, accesarea și politica motorului de căutare rămân verificări separate.

Acest ghid explică un flux de implementare și control. Pentru o intervenție comercială, consultă serviciul Schema și rezultate îmbogățite. Pentru o problemă generală de vizibilitate, pornește din checklistul SEO tehnic. Aici lucrăm concret cu identități, relații și date care trebuie să corespundă paginii.

Ce descriu datele structurate

Schema.org oferă un vocabular pentru tipuri de entități și proprietăți, iar JSON-LD este unul dintre formatele utilizate pentru exprimarea lor. Google folosește datele structurate pentru a înțelege informații și poate afișa anumite rezultate speciale când sunt îndeplinite cerințele corespunzătoare. Nu orice tip din vocabular produce un rezultat special în Google.^[1]

Gândește pagina ca pe o fișă de informații. Există un articol, un autor, un site și eventual o organizație care publică. Într-un magazin există un produs, o ofertă și o monedă. Descrierea structurată trebuie să facă vizibile aceste relații, nu să inventeze entități suplimentare doar pentru că un generator permite completarea câmpurilor.

Un exemplu simplu: un ghid despre livrarea emailurilor este un articol, nu un produs oferit la vânzare. O pagină despre serviciile agenției nu devine recenzie independentă a agenției. Alegerea tipului pornește din rolul real al paginii. Dacă rolul este neclar, rezolvă întâi structura conținutului și abia apoi descrierea lui tehnică.

Pasul 1: inventariază ce generează deja WordPress

Deschide sursa paginii și caută blocurile application/ld+json. Notează cine le generează: pluginul SEO, WooCommerce, tema sau un modul suplimentar. Nu instala încă un generator înainte să înțelegi graful existent. Două blocuri JSON-LD nu sunt automat o eroare, dar două descrieri incompatibile pentru aceeași entitate necesită investigație.

Verifică un articol, o categorie, homepage-ul și un produs, dacă există. Nu presupune că rezultatul primei pagini reprezintă toate șabloanele. Pentru fiecare notează tipurile principale, identificatorii și informațiile sensibile la actualizare: titlu, autor, imagini, date, preț și stoc. Această hartă îți arată unde trebuie intervenit, fără modificări globale inutile.

Dacă folosești Yoast, urmărește integrarea cu graful său existent. Documentația dezvoltatorului explică relaționarea componentelor Schema, în locul construirii unor descrieri concurente fără legături.^[5] Pentru personalizări, dezvoltarea unui modul compatibil este mai controlabilă decât lipirea unor fragmente diferite în fiecare articol.

Pasul 2: separă identitatea de descriere

Un identificator @id permite referirea la aceeași entitate din mai multe locuri. El nu trebuie confundat cu textul vizibil al numelui. Organizația poate fi menționată ca editor al mai multor articole fără a fi recreată cu alte adrese, alte logo-uri sau nume ușor diferite pe fiecare pagină.

Exemplul următor este demonstrativ, nu un fragment gata de publicat. Domeniul și titlul sunt exemple, iar identificatorii trebuie corelați cu graful real. Nu include date, autori sau imagini inexistente doar pentru a completa un șablon.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://domeniul-tau.example/ghid/#article",
  "headline": "Titlul real al ghidului",
  "mainEntityOfPage": {
    "@id": "https://domeniul-tau.example/ghid/"
  },
  "publisher": {
    "@id": "https://domeniul-tau.example/#organization"
  }
}

În această schiță, referința către organizație presupune că organizația este descrisă coerent în implementare. Nu este suficient să inventezi un identificator cu aspect corect. Verifică unde este definit, cum se numește entitatea și ce URL folosește. JSON Lab poate ajuta la citirea și formatarea structurii, dar nu poate confirma singur adevărul informațiilor.

Un identificator stabil reduce ambiguitatea în mentenanță. Dacă schimbi logo-ul, ar trebui să existe o sursă clară care actualizează referința, nu nouă copii editate manual. Această disciplină este utilă și pentru coerența URL-urilor canonice, deoarece adresele din graf trebuie să reflecte documentele pe care le publici efectiv.

Articole: autor, titlu și date reale

Documentația Google pentru Article descrie proprietăți relevante precum titlul, autorul, imaginile și datele de publicare sau modificare.^[3] Selectează informația din datele reale ale articolului. Nu actualiza artificial data la fiecare încărcare și nu declara un autor care nu are legătură cu materialul doar pentru a arăta mai credibil.

Pentru o bibliotecă editorială, verifică de unde vine fiecare câmp. Titlul poate fi preluat din WordPress, autorul din contul atribuit, iar imaginea din resursa socială sau imaginea reprezentativă. Dacă există un titlu SEO diferit, stabilește relația dintre acesta și titlul editorial. Nu lăsa șabloanele să descrie două articole aparent diferite.

Actualizarea unui ghid merită consemnată atunci când schimbă efectiv informația. Corectarea unui link și rescrierea unei secțiuni importante nu trebuie mascate printr-o cronologie inventată. Cititorul și motorul de căutare ar trebui să primească o descriere coerentă a aceleiași publicații, nu o dată aleasă exclusiv pentru impresia de noutate.

Produse: datele trebuie să urmeze catalogul

Google are documentație separată pentru date structurate de produs și pentru experiențele comerciale asociate.^[4] Într-un magazin, informațiile despre ofertă trebuie corelate cu pagina și cu sistemele care le generează. Un preț actualizat în WooCommerce, dar rămas vechi într-un fragment scris manual, este o problemă de sincronizare, nu una de sintaxă JSON.

Verifică o variație disponibilă, una indisponibilă și un produs cu reducere. Urmărește informația efectiv prezentată, nu doar valorile din panoul administrativ. Dacă pagina se personalizează după selecție, trebuie înțeles ce document este descris și ce ofertă vede utilizatorul. Nu simplifica artificial o familie de produse într-o singură ofertă fără context.

Merchant Center și feedurile folosesc alte fluxuri de verificare, chiar dacă se intersectează cu datele din pagină. Gestionarea feedurilor și consistența catalogului trebuie să pornească de la aceeași sursă comercială. Nu folosi Schema ca să „corectezi” doar pentru robot un preț pe care clientul nu îl poate obține.

Pasul 3: validează pe trei niveluri

Primul nivel este sintaxa. Un document JSON cu virgulă suplimentară sau ghilimele nepotrivite poate să nu fie interpretat corect. Formatează codul în validatorul și formatorul JSON, apoi repară strict eroarea observată. O validare sintactică nu spune însă că tipul ales sau informația comercială este corectă.

Al doilea nivel este vocabularul: tipurile, proprietățile și relațiile trebuie să aibă sens. Verifică dacă referințele către alte entități sunt coerente. Un număr poate fi valid în JSON, dar greșit ca monedă, dată sau adresă. Citește și semnificația câmpurilor, nu doar avertismentele colorate din interfață.

Al treilea nivel privește cerințele motorului de căutare pentru rezultatul urmărit. Un markup valid Schema.org poate să nu fie eligibil pentru o funcție Google. Nici eligibilitatea nu garantează afișarea. Politicile Google cer, între altele, concordanța cu conținutul vizibil și interzic informațiile înșelătoare.^[2]

Pasul 4: testează răspunsul public, nu doar fragmentul

După integrare, verifică pagina completă. Un fragment corect în editor poate fi dublat de temă sau eliminat de o transformare ulterioară. Copia din cache poate păstra o versiune veche. Testul pe URL trebuie să urmărească ceea ce este livrat efectiv unui vizitator nelogat, în același mod în care verifici celelalte metadate.

Folosește analiza paginii în SEO Lab pentru informațiile pe care instrumentul le poate observa și compară cu testele oficiale relevante. Dacă apare o eroare, identifică mai întâi generatorul responsabil. Nu șterge toate blocurile structurate doar pentru că unul dintre ele este nepotrivit. O intervenție țintită păstrează relațiile valide.

Pentru cache, aplică verificarea din ghidul Cloudflare numai adreselor afectate. Nu transforma paginile publice în răspunsuri necacheabile ca metodă permanentă de depanare. Obiectivul este o versiune corectă care poate fi livrată eficient, nu eliminarea cache-ului pentru a evita responsabilitatea invalidării.

De ce stelele și întrebările frecvente nu se inventează

Un câmp disponibil într-un generator nu justifică inventarea unei evaluări, a numărului de recenzii sau a unei experiențe de client. Informațiile trebuie să existe și să fie reprezentate corect. Pentru orice tip de rezultat urmărit, consultă documentația specifică, deoarece condițiile diferă și se pot modifica. Nu presupune că toate șabloanele vechi mai corespund funcțiilor actuale.

Întrebările frecvente pot fi utile cititorului chiar fără un rezultat special în Google. Scrie-le pentru a clarifica obiecții reale, nu ca pretext pentru încă un bloc Schema. Dacă pagina are răspunsuri scurte și utile, păstrează-le în HTML accesibil. Conținutul editorial nu trebuie subordonat posibilității de a umple câmpuri tehnice.

În mod similar, un testimonial despre companie nu trebuie transformat automat în evaluarea fiecărui produs din catalog. Stabilește ce entitate este evaluată, cine a furnizat informația și unde este afișată. O structură de date precisă poate avea mai puține proprietăți decât un exemplu spectaculos găsit online, dar este mai ușor de apărat și menținut.

Un plan de mentenanță pentru date structurate

Leagă actualizarea markupului de aceeași sursă care modifică pagina. Pentru articole, sursa este în mod normal conținutul și metadatele editoriale. Pentru produse, sursa este catalogul. Pentru organizație, stabilește un profil central. Evită copii manuale care nu sunt atinse când informația principală se schimbă.

Pregătește un eșantion permanent de pagini: un articol publicat, unul actualizat, o categorie și câteva produse reprezentative. După actualizarea pluginului SEO, a temei sau a catalogului, verifică același eșantion. Compară identificatorii, tipurile și proprietățile esențiale. O schimbare de format nu este neapărat un defect; o contradicție de conținut merită investigată.

Documentează și ce ai ales să nu implementezi. Dacă un anumit tip de markup nu este justificat de conținut, consemnează decizia. Astfel, o persoană nouă în echipă nu va reactiva automat un generator redundant doar pentru că găsește un câmp gol. Mentenanța tehnică include și păstrarea acestor decizii, nu doar actualizarea fișierelor.

Exercițiu: urmărește un preț de la catalog la pagină

Presupunem un produs demonstrativ al cărui preț a fost schimbat de administrator. Pagina vizibilă arată noul preț, însă un test detectează o ofertă cu valoarea anterioară. Nu modifica imediat JSON-LD cu un fragment suplimentar. Notează URL-ul exact, variația selectată, momentul probei și locul unde apare valoarea veche. Problema poate fi limitată la un singur generator sau la o copie a întregii pagini.

Compară trei dovezi: sursa comercială din catalog, textul livrat în HTML și datele structurate din același răspuns. Dacă toate sunt vechi, investighezi actualizarea sau cache-ul. Dacă numai JSON-LD este vechi, investighezi sursa generatorului. Dacă două blocuri declară valori diferite, investighezi suprapunerea componentelor. Această separare reduce numărul intervențiilor și împiedică mascarea defectului printr-un al treilea bloc.

Repetă verificarea cu un produs care nu a fost modificat. Acesta este un control util pentru regresii: o corecție aplicată reducerilor nu trebuie să schimbe moneda sau disponibilitatea produselor obișnuite. Apoi testează revenirea produsului în stoc și eliminarea reducerii. Nu este necesar ca toate schimbările să fie făcute în producție; o copie de test cu date demonstrative permite validarea fluxului fără a afecta clienții.

Raportul final ar trebui să arate unde a fost corectată sursa, ce pagini au fost regenerate și ce răspuns a fost verificat. Nu trebuie să conțină o promisiune despre momentul apariției în rezultatele Google. Implementarea se poate confirma imediat în propriul răspuns; afișarea externă este o etapă separată, pe care o monitorizezi.

Cum păstrezi implementarea ușoară

Datele structurate nu justifică încărcarea unei biblioteci vizuale pe fiecare pagină. Preferă generarea pe server din informațiile deja disponibile și evită solicitările către servicii externe la fiecare vizită doar pentru a afla titlul sau autorul propriului articol. Într-un proiect bine delimitat, markupul poate fi livrat împreună cu HTML-ul normal, fără o interacțiune suplimentară a utilizatorului.

Stabilește și limitele personalizării. Nu construi zeci de tipuri pentru pagini care nu le justifică și nu duplica același obiect complet în fiecare secțiune. Urmărește claritatea relațiilor și costul de mentenanță. O structură mică, coerentă și alimentată din surse reale este preferabilă unui document imens, dificil de actualizat și imposibil de verificat rapid după fiecare schimbare.

Întrebări frecvente despre Schema în WordPress

Trebuie să adaug JSON-LD manual la fiecare articol?

De regulă, o integrare centralizată este mai ușor de verificat decât fragmente independente. Mai întâi identifică ce generează pluginul existent. Adaugă extensii numai pentru informații reale pe care implementarea nu le descrie suficient și testează compatibilitatea cu graful deja prezent.

Pot garanta rezultate îmbogățite după validare?

Nu. Raportul de validare și afișarea în căutare sunt lucruri diferite. Folosește rapoartele Search Console pentru monitorizare, dar nu atribui orice schimbare de trafic markupului. Contează și conținutul, accesarea, cererea și celelalte semnale ale paginii.

Ce fac dacă două pluginuri descriu aceeași organizație?

Compară identificatorii și informațiile, apoi stabilește un generator principal. Nu dezactiva în grabă întregul plugin SEO. Soluția poate fi o integrare sau eliminarea unui modul redundant. Păstrează o copie a configurației și verifică după intervenție atât homepage-ul, cât și articolele și produsele relevante.

Surse și documentație

Pașii și scenariile de lucru sunt explicații editoriale. Documentația de mai jos susține comportamentele tehnice indicate. Exemplele numerice sunt ipotetice, nu rezultate KEPA.

1. Google — introducere în date structurate
2. Google — politici pentru date structurate
3. Google — date structurate pentru articole
4. Google — date structurate pentru produse
5. Yoast — integrarea în graful Schema