Date structurate internațional: Schema.org peste granițele lingvistice

Introducere în date structurate pentru site-uri web multilingve

Datele structurate conform Schema.org ajută motoarele de căutare să înțeleagă conținutul site-ului dvs. – și asta peste granițele lingvistice. Când operați mai multe versiuni lingvistice, marcarea corectă devine cu atât mai importantă. Motoarele de căutare precum Google folosesc date structurate pentru a afișa rezultate îmbogățite (Rich Results) precum fragmente, prețuri de produse sau elemente FAQ. În cazul paginilor multilingve, aceste marcări trebuie să fie specifice limbii, altfel pot fi livrate informații greșite – de exemplu, un număr de telefon din pagina germană în versiunea franceză.

O greșeală tipică: se preia schema unei limbi în celelalte versiuni fără a ajusta specificațiile de limbă. Nu este suficient să traducem doar conținutul; structura trebuie să reflecte limba țintă. De exemplu, câmpul inLanguage al obiectului Schema trebuie să indice limba paginii respective. O pagină germană de produs primește `inLanguage: 'de'`, cea engleză `inLanguage: 'en'`. În plus, puteți utiliza `translationOfWork` pentru a face referire la versiunea originală.

În practică, începeți cu cele mai importante tipuri de pagini: Organizație, Produs, FAQ. Acestea sunt cel mai frecvent utilizate pentru rezultate îmbogățite. Verificați în prealabil care pagini în ce limbă sunt deosebit de relevante. Pentru un site corporativ internațional, schema Organizație este potrivită, iar pentru un magazin online, schema Produs. Asigurați-vă că fiecare versiune lingvistică primește un script JSON-LD propriu sau intrări separate în script. Utilizați instrumente precum Google Rich Results Test pentru a valida fiecare versiune lingvistică separat. Rețineți că testul oferă doar o imagine instantanee – o verificare periodică este recomandată.

Din punct de vedere legal, datele structurate nu trebuie să conțină date personale care încalcă GDPR. La specificarea datelor de contact în diferite țări, asigurați-vă că datele sunt corecte și actualizate. În caz de îndoială, consultați un consilier juridic. Printr-o implementare curată a datelor structurate multilingve, vă îmbunătățiți șansele de a fi găsit cu rezultate îmbogățite relevante în diferite regiuni lingvistice.

Bazele Schema.org și marcarea limbii

Schema.org oferă o structură de vocabular comună, susținută de motoarele de căutare. Pentru site-urile multilingve, marcarea corectă a limbii este esențială. Fiecare obiect Schema poate avea o proprietate `inLanguage` care indică limba conținutului (de ex. `'de'`, `'en'`, `'fr'`). Această indicație trebuie să corespundă limbii reale a paginii. În JSON-LD, setați `@language` fie pe întregul document, fie pe obiecte individuale, dacă apar mai multe limbi.

Un exemplu: pentru un produs în limba germană utilizați: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Dacă marcați același produs pe o pagină în engleză, veți folosi `"inLanguage": "en"` și numele în engleză. Evitați să amestecați mai multe versiuni lingvistice într-un singur obiect Schema – acest lucru duce la inconsistențe. În schimb, utilizați blocuri de marcare separate pentru fiecare limbă sau lucrați cu array-uri `@language` în cadrul unui obiect, dacă entitatea este multilingvă.

Pentru specificații la nivel de site, cum ar fi `WebSite` sau `WebPage`, ar trebui să indicați de asemenea limba. La comutarea limbii pe pagină, puteți face referire la celelalte versiuni lingvistice folosind `potentialAction` sau `translationOfWork`. În practică, s-a dovedit util să plasați un bloc JSON-LD separat pentru fiecare limbă în head-ul paginii corespunzătoare. Astfel, atribuirea rămâne clară și este interpretată corect de instrumentele de validare.

Asigurați-vă că codurile de limbă respectă standardul ISO-639-1 (de ex. „de” pentru germană, „en” pentru engleză). Pentru variante regionale, puteți adăuga abrevieri de țară, deci „de-CH” pentru germana elvețiană. În acest caz, trebuie să verificați dacă motorul de căutare suportă această distincție fină – de regulă, este suficient codul de limbă de bază. Validați fiecare versiune lingvistică separat cu Google Structured Data Testing Tool sau Rich Results Test. Notați eventualele avertismente legate de lipsa indicațiilor de limbă și remediați-le specific.

Schema-ul Organization: datele companiei în mai multe limbi

Schema-ul Organization este ideal pentru companiile cu site-uri multilingve, deoarece oferă informații centrale precum numele, adresa și datele de contact. Pentru fiecare versiune lingvistică, ar trebui să creați un obiect Organization propriu, marcat în limba respectivă. `name` trebuie specificat în limba țintă – deci „Muster GmbH” în germană și „Sample Inc.” în engleză. Dacă compania are un nume unitar, este suficientă traducerea descrierii (`description`).

Pentru adrese, utilizați schema `PostalAddress` cu `addressCountry` și `addressLocality`. Pentru locații internaționale, puteți prevedea mai multe intrări `location`. Asigurați-vă că numerele de telefon (`telephone`) includ prefixul internațional corect. Exemplu: pentru pagina germană `+49 30 1234567`, pentru pagina elvețiană `+41 44 1234567`. Același lucru este valabil pentru adresele de e-mail și orele de program. Folosiți `areaServed` pentru a acoperi țările în care activează compania.

Un detaliu adesea trecut cu vederea este proprietatea `sameAs` pentru profilele de social media. Înregistrați profile specifice limbii, dacă există – de exemplu, pagina germană de Facebook și prezența engleză pe Twitter. De asemenea, `url` ar trebui să trimită la pagina de pornire specifică limbii. Pentru site-uri multilingve, puteți utiliza `translationOfWork` pentru a stabili o legătură între versiunile lingvistice, dacă paginile conțin același conținut într-o altă limbă.

Recomandare practică: Implementați schema Organization pe pagina de pornire a fiecărei versiuni lingvistice. Plasați un script JSON-LD în `<head>`. Evitați duplicatele creând un bloc separat pentru fiecare limbă cu `inLanguage` corespunzător. Validați marcarea cu Google Rich Results Test și verificați dacă datele de contact sunt afișate corect. Din punct de vedere legal, trebuie să aveți în vedere că informațiile furnizate sunt complete și conforme cu protecția datelor. În special pentru mai multe locații: obligațiile legale privind amprenta (Impressum) pot diferi în funcție de țară. Dacă aveți îndoieli, solicitați consultanță juridică. Prin aceste detalii, veți asigura că compania dvs. este reprezentată uniform și corect în toate regiunile lingvistice.

Schema-ul Product: marcarea descrierilor produselor specifice limbii

Pentru site-urile multilingve, marcarea produselor cu Schema.org Product în limba respectivă este esențială. Fiecare versiune lingvistică a unui produs ar trebui să primească propria marcare Schema, care să includă denumirea locală, descrierea și atribute precum prețul, valuta sau disponibilitatea. Utilizați atributul `inLanguage` pentru fiecare limbă – de exemplu, `"inLanguage": "de-DE"` pentru germană (Germania). Asigurați-vă că numele produsului și descrierea din obiectul JSON-LD sunt efectiv în limba respectivă, nu doar eticheta lingvistică.

O greșeală frecventă este marcarea tuturor variantelor lingvistice cu același `@id` (de exemplu, un ID global de produs). În schimb, ar trebui să atribuiți un `@id` distinct pentru fiecare limbă, cum ar fi `https://example.com/de/produkt/123` și `https://example.com/fr/produit/123`. Astfel, Google poate afișa versiunea corectă. Pentru prețuri, utilizați `priceCurrency` cu codul ISO-4217 (de exemplu, EUR, USD) și specificați prețul în funcție de limbă – chiar dacă prețul rămâne același, acesta aparține paginii locale.

Recomandare practică: creați pentru fiecare produs un șablon JSON-LD care să seteze dinamic parametrii lingvistici. Testați fiecare versiune lingvistică individual cu Rich Results Test de la Google. Asigurați-vă că atributul `url` indică URL-ul limbii respective. Evitați să amestecați toate limbile într-un singur bloc JSON-LD – acest lucru duce adesea la erori de validare. Pentru imagini, puteți menține atributul `image` independent de limbă, dar verificați corectitudinea URL-urilor imaginilor.

În plus, puteți ajusta `offers` cu `availability` în funcție de piață (de exemplu, `InStock` pentru Germania, `PreOrder` pentru Franța). Utilizați `gtin` sau `mpn` la nivel global, dar păstrați variante locale pentru `sku`. Testați în final dacă datele structurate sunt indexate corect în Search Console pentru fiecare versiune lingvistică.

Schema FAQ: optimizarea paginilor de întrebări și răspunsuri pentru mai multe limbi

Paginile FAQ în mai multe limbi beneficiază de o marcare clară și specifică limbii cu schema FAQPage. Fiecare versiune lingvistică a paginii FAQ primește propriul obiect JSON-LD. Setați `inLanguage` la codul de limbă corespunzător (de exemplu, `fr-FR` pentru franceză). Întrebările și răspunsurile trebuie formulate în obiect în limba țintă – traducerea automată adesea nu este suficientă; verificați-le cu un vorbitor nativ, deoarece nuanțele sunt cruciale.

O eroare tipică: același `@id` pentru toate variantele lingvistice. În schimb, utilizați URL-ul specific limbii ca `@id`, de exemplu, `https://example.com/de/faq/` și `https://example.com/en/faq/`. În cadrul schemei FAQPage, listați întrebările ca `mainEntity` cu `@type: Question` și răspunsul corespunzător ca `acceptedAnswer`. Fiecare întrebare poate primi suplimentar `inLanguage`, dar acest lucru este redundant dacă întreaga pagină este marcată. Mențineți numărul de întrebări pe pagină la maximum 10–15, deoarece motoarele de căutare iau în considerare doar un număr limitat de intrări.

Recomandare practică: utilizați un sistem de gestionare a conținutului care oferă câmpuri multilingve pentru fiecare intrare FAQ. În ieșirea JSON-LD, interogați dinamic limba curentă. Validați fiecare versiune lingvistică individual cu Rich Results Test și acordați atenție avertismentelor privind lipsa proprietăților `name` la întrebări. Adăugați la fiecare întrebare o `url` care să trimită la ancora specifică – astfel, utilizatorii pot sări direct la răspunsul potrivit.

Rețineți: FAQPage este potrivit doar pentru paginile cu întrebări și răspunsuri explicite. Nu îl utilizați pentru pagini generale de asistență. Testați după implementare vizibilitatea în căutarea Google – fragmentele îmbogățite FAQ apar adesea la căutări cu particule de întrebare. Pentru SEO multilingv, merită să adaptați răspunsurile la formulări specifice fiecărei țări (de exemplu, „Wie kann ich?” vs. „Comment puis-je?”).

Subtilitățile lui inLanguage: codul de limbă și setările regionale

Atributul `inLanguage` din Schema.org indică limba unui conținut, iar valoarea ar trebui să fie formată dintr-un cod de limbă (ISO 639-1) și un cod regional opțional (ISO 3166-1 Alpha-2) – de exemplu, `en-US` pentru engleza americană. Regiunea este importantă atunci când conținuturile diferă: „colour” vs. „color” sau unități de măsură diferite. Fără regiune, codul este interpretat ca limbă generală. Așadar, utilizați `de-DE`, `de-AT`, `de-CH` pentru pagini specifice țării, chiar dacă textul este aproape identic.

Un exemplu practic: un produs este oferit pe o pagină germană și una austriacă. Limba este germana, dar prețurile și condițiile de livrare diferă. Setați `inLanguage: "de-DE"` pentru pagina germană și `"de-AT"` pentru cea austriacă. Astfel, Google poate înțelege mai bine relevanța regională. Același lucru este valabil pentru `en-GB` și `en-US`. Dacă nu aveți nevoie de o diferențiere regională, este suficient `"de"` sau `"en"`. Asigurați-vă însă că codul de limbă este scris cu litere mici, iar regiunea cu litere mari (de exemplu, `fr-CA`).

O greșeală frecventă este utilizarea `inLanguage` pe un obiect părinte, în timp ce sub-obiectele au o altă limbă. Exemplu: un site Web în germană, dar un articol individual în engleză. Atunci setați `inLanguage: "de"` pe site și `inLanguage: "en"` pe articol. Validați acest lucru cu un validator de schemă, deoarece unele instrumente raportează conflicte. Pentru paginile multilingve cu etichete hreflang, `inLanguage` ar trebui să corespundă valorii hreflang respective – acest lucru ajută Google să livreze versiunea corectă.

Implementare practică: Definiți un `@id` unic pentru fiecare versiune lingvistică și setați `inLanguage` în mod consecvent. Utilizați un fișier de configurare centralizat care conține codurile corecte pentru fiecare limbă. Testați cu instrumentul schema.org dacă eticheta `inLanguage` este acceptată. Un sfat: nu uitați de `inLanguage` nici în paginile AMP sau în datele structurate prin Microdata. În JSON-LD, plasați-l la nivelul superior (de exemplu, `WebSite` sau `WebPage`). Pentru conținuturi dinamice precum articolele de blog, `inLanguage` poate varia în funcție de articol – atunci setați-l per element.

Marcarea corectă a multilingvismului pe o singură adresă URL

Când o adresă URL conține conținut în mai multe limbi – de exemplu, prin comutatoare de limbă, file sau acordeoane –, trebuie să indicați clar în datele structurate care text aparține cărei limbi. În caz contrar, un crawler al motorului de căutare poate presupune în mod eronat că tot conținutul este într-o singură limbă, ceea ce duce la erori de indexare și afișare.

Metoda de bază este utilizarea atributului `inLanguage` pe elementele corespunzătoare. Într-un schemă FAQ cu întrebări și răspunsuri în germană și engleză pe aceeași pagină, marcați fiecare întrebare și răspuns individual: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Același lucru este valabil pentru schemele de produs: descrieți `name` și `description` pentru fiecare limbă într-un obiect `Product` separat cu propriul `inLanguage`, sau utilizați `@language` și `@value` într-o proprietate `multilingualDescription` (dacă vocabularul dvs. o acceptă).

Pentru organizații cu nume multilingve, utilizați un array de obiecte `name`: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Evitați să declarați întreaga pagină ca fiind multilingvă. În schimb, atribuiți limba cât mai granular posibil. O greșeală frecventă este setarea `inLanguage` doar la nivelul superior al unei scheme, fără a marca elementele subiacente. Verificați în fluxul dvs. de validare dacă toate textele sunt marcate corect lingvistic.

Ca recomandare concretă: creați pentru fiecare variantă lingvistică de pe o adresă URL un obiect de schemă separat, care conține doar textele acelei limbi, și setați `inLanguage` la codul de limbă corespunzător. Dacă pagina afișează în mod implicit o limbă principală, iar celelalte sunt încărcate prin JavaScript, includeți datele structurate pentru toate limbile static în HTML. Instrumente precum Google Rich Results Test vă arată dacă marcarea este interpretată corect. Testați fiecare versiune lingvistică separat, forțând crawler-ul să acceseze limba dorită printr-un parametru URL sau control al cookie-urilor.

Delimitarea dintre hreflang și inLanguage: Când se utilizează fiecare metodă?

`hreflang` și `inLanguage` îndeplinesc scopuri diferite în SEO internațional și nu trebuie confundate. `hreflang` este un element HTML sau un antet HTTP care semnalează motoarelor de căutare că există versiuni alternative de limbă sau regiune ale aceleiași pagini. Acesta servește la livrarea corectă a paginii potrivite pentru utilizatorii din diferite țări sau cu setări specifice de limbă. `inLanguage`, pe de altă parte, este un atribut în date structurate (Schema.org) care indică limba în care este redactat un anumit element de text.

Când folosiți fiecare? Utilizați `hreflang` atunci când aveți URL-uri separate pentru diferite versiuni lingvistice (de exemplu, `example.com/de/` și `example.com/en/`). Astfel preveniți problemele de conținut duplicat și vă asigurați că pagina corectă apare în snippet. `inLanguage` este necesar atunci când marcați conținut multilingv pe un singur URL sau când un element de date structurate, cum ar fi o descriere de produs, există în mai multe limbi. `inLanguage` completează `hreflang` la nivelul blocurilor de text individuale.

O neînțelegere frecventă: `inLanguage` nu înlocuiește `hreflang`. Chiar dacă marcați fiecare rând al unui articol cu `inLanguage`, motoarele de căutare nu știu fără `hreflang` dacă există versiuni alternative ale întregii pagini. Invers, `hreflang` nu este suficient pentru a descrie granular conținutul multilingv dintr-un URL. În practică, dacă aveți pagini separate pentru fiecare limbă, `hreflang` este necesar în principal, iar `inLanguage` indică doar limba concretă a conținutului în datele structurate de pe acele pagini. Dacă mai multe limbi coexista pe un URL, aveți neapărat nevoie de `inLanguage` pentru fiecare element specific limbii.

Recomandare concretă: Planificați strategia URL înainte de implementare. Decideți dacă folosiți un URL propriu pentru fiecare limbă (ccTLD, subdomeniu, subdirector) sau un URL comun cu comutare dinamică a limbii. Pentru cea din urmă, o marcare corectă cu `inLanguage` este esențială. Verificați în orice caz dacă etichetele `hreflang` indică toate versiunile lingvistice relevante și nu există contradicții cu specificațiile `inLanguage` din datele structurate. O corelare a acestor două semnale poate ajuta motoarele de căutare să clasifice corect conținutul dumneavoastră.

Flux de lucru de validare: instrumente și verificări automatizate

Verificarea manuală a datelor structurate pe fiecare versiune lingvistică este predispusă la erori și consumă timp. Un flux de lucru automatizat de validare asigură că marcajele Schema.org sunt corecte și rămân așa – chiar și după actualizări de conținut sau adăugarea de noi limbi. Cele mai importante instrumente sunt Google Rich Results Test (pentru tipurile acceptate de Google, cum ar fi FAQ, Product) și Schema.org Validator (pentru verificarea pură a sintaxei). Complementar, crawler-ele precum Screaming Frog SEO Spider ajută la extragerea datelor structurate de pe întreg site-ul și la verificarea erorilor.

Integrați verificarea în procesul CI/CD: după fiecare implementare sau actualizare lingvistică, rulați un test automatizat. Folosiți API-ul Google Rich Results Test sau un script care parsează paginile și verifică blocurile JSON-LD față de un șablon definit personal. Acordați o atenție deosebită următoarelor surse de erori: - Lipsa `inLanguage` acolo unde apar mai multe limbi. - Coduri de limbă contradictorii (de exemplu, „de” în loc de „de-DE” pentru variante regionale). - Câmpuri obligatorii incomplete (de exemplu, `name` la Product în fiecare limbă). - Etichete `hreflang` învechite care nu mai corespund URL-urilor actuale.

Recomandare concretă: Creați pentru fiecare tip de Schema (Organization, Product, FAQ) o listă de verificare cu atributele necesare pentru fiecare limbă. Utilizați un instrument de testare precum `json-schema` pentru validarea automată a datelor. Efectuați periodic (de exemplu, lunar) un crawl complet cu Schema.org Validator și generați rapoarte despre paginile cu erori. Documentați categoriile de erori și atribuiți responsabili pentru corecturi. Rețineți că datele structurate trebuie verificate pe paginile live – testarea în staging nu este suficientă, deoarece acolo pot exista alte conținuturi. Numai astfel vă asigurați că erorile relevante pentru motoarele de căutare sunt remediate prompt.

Erori frecvente în datele structurate internaționale

Marcarea site-urilor multilingve cu Schema.org implică capcane tipice. O greșeală frecventă este absența sau specificarea incorectă a atributului lingvistic `inLanguage`. De exemplu, dacă oferiți un produs în germană, dar în marcaj nu setați `inLanguage: "de-DE"`, motoarele de căutare ar putea interpreta datele ca neutre din punct de vedere lingvistic. O altă eroare fundamentală este amestecarea limbilor într-un singur bloc Schema. Astfel, ar trebui să evitați să setați proprietatea `name` în engleză și `description` în germană într-un obiect `Product`. În schimb, pentru fiecare versiune lingvistică trebuie creat un bloc separat cu `inLanguage` corect.

O altă greșeală răspândită este utilizarea unor tipuri Schema nepotrivite. Pentru o companie multilingvă, mulți aleg greșit `LocalBusiness`, deși `Organization` este alegerea corectă atunci când nu există o adresă fizică în fiecare limbă. De asemenea, la produse se uită adesea să se marcheze proprietatea `offers` specific limbii. În plus, se neglijează actualizarea datelor structurate după traduceri: un text de produs nou tradus trebuie ajustat și în marcaj – altfel, rezultatele căutării afișează informații învechite sau incorecte.

Neglijarea validării este o altă greșeală capitală. După fiecare modificare, ar trebui să verificați marcajele cu instrumente adecvate. Referințele `@id` incorecte sau lipsă pentru entitățile care sunt aceleași în toate limbile (de exemplu, o organizație) duc la duplicate sau date incomplete. De asemenea, se ignoră adesea interacțiunea cu `hreflang`: acolo unde nu există URL-uri alternative, trebuie să lucrați cu `inLanguage` pe aceeași pagină.

Recomandări: Verificați fiecare marcaj pentru atribuirea corectă a limbii. Utilizați blocuri Schema separate pentru fiecare versiune lingvistică, cu `@id` unice. Evitați amestecurile – și în `aggregateRating` sau `review` limba trebuie să fie corectă. După fiecare traducere, efectuați o nouă validare și corelați datele cu conținutul vizibil. Numai astfel vă asigurați că motoarele de căutare înțeleg corect ofertele dvs. multilingve.

Testează cu Google Rich Results, Bing Webmaster Tools și Yandex

Verificarea marcajelor Schema.org multilingve nu ar trebui limitată la un singur instrument. Fiecare motor de căutare are propriile interpretări și criterii de validare. Google Rich Results Test este primul punct de contact: introduceți un URL cu marcajul dvs. sau lipiți codul direct. Fiți atenți la toate erorile și avertizările – în special dacă indicațiile `inLanguage` sunt recunoscute corect. O problemă frecventă este că Google acceptă `de-DE`, dar emite totuși o avertizare atunci când partea de regiune lipsește (`de`). Testați fiecare versiune lingvistică separat.

Bing Webmaster Tools oferă o verificare URL cu o vizualizare a datelor structurate. Aici puteți vedea dacă Bing interpretează marcajele așa cum vă așteptați. Bing este adesea mai strict la validarea `inLanguage` și poate aștepta obligatoriu codul lingvistic de două litere fără regiune (de exemplu, `de` în loc de `de-DE`). Efectuați un test live și corectați abaterile. Bing afișează, de asemenea, posibile duplicate atunci când valorile `@id` sunt utilizate de mai multe ori.

Yandex Webmaster are propriul validator, relevant în special pentru site-urile în limba rusă. Și aici puteți testa datele structurate. Yandex suportă majoritatea tipurilor Schema.org, dar tratarea erorilor diferă. În special la marcajele `Product`, proprietatea `availability` este adesea criticată. Prin urmare, testați și aici fiecare versiune lingvistică. Rețineți că Yandex poate pondera diferit codurile lingvistice regionale precum `de-DE`.

Recomandări: Testați fiecare versiune lingvistică în toate cele trei instrumente după implementare și după fiecare modificare. Notați abaterile și ajustați marcajele astfel încât să fie acceptate de toate cele trei motoare de căutare. Ideal, utilizați codul lingvistic de două litere (`de`, `en`) în `inLanguage`, deoarece este înțeles la fel de bine de majoritatea sistemelor. Automatizați testele cu instrumente CI pentru a menține controlul asupra site-urilor multilingve cu multe pagini.

Listă de verificare pentru implementarea marcajelor Schema.org multilingve

O abordare structurată previne erorile tipice în internaționalizare. Înainte de implementare, stabiliți strategia lingvistică: utilizați adrese URL separate pe limbă (de ex., `/de/produkt` și `/en/product`) sau o singură adresă URL cu comutare de limbă? Pentru adrese URL separate, folosiți `hreflang` și un marcaj propriu pentru fiecare adresă URL. În cazul unei singure adrese URL, utilizați mai multe blocuri `inLanguage` cu coduri de limbă diferite. Planificați, de asemenea, ce tipuri de scheme sunt necesare: companie (Organization), produse (Product), întrebări frecvente (FAQPage) etc.

La implementare, acordați atenție următoarelor aspecte: fiecare obiect Schema primește un `@id` unic care identifică entitatea independent de limbă. Pentru fiecare versiune lingvistică, creați un obiect separat care indică limba prin `inLanguage`. Utilizați coduri de limbă consistente – de preferință codul ISO din două litere (de ex., `de`, `en`) completat cu regiunea, dacă este necesar. Faceți legături corecte în cadrul marcajelor: la `Organization` utilizați `url` și `logo` cu căi specifice limbii. Verificați dacă textele precum `name` și `description` corespund conținuturilor vizibile.

După implementare urmează validarea: testați fiecare versiune lingvistică cu Google Rich Results Test, Bing Webmaster Tools și Yandex. Corectați erorile și avertismentele. Acordați atenție deosebită absenței `inLanguage` sau codurilor de limbă greșite. Folosiți suplimentar instrumentul de validare Schema.org de la Google pentru a verifica sintaxa. Documentați toate modificările și efectuați teste repetate după fiecare traducere.

În final, monitorizarea face parte din proces: urmăriți performanța în Search Console, în special rapoartele privind datele structurate. Reacționați la noi erori sau avertismente. Actualizați marcajele prompt atunci când modificați sau traduceți conținuturi. Efectuați audituri regulate pentru a asigura consistența în toate versiunile lingvistice. O implementare bine întreținută a Schema.org îmbunătățește vizibilitatea în rezultatele căutării – fără garanții, dar cu beneficii practice.

Mențiuni legale: Răspunderea proprie pentru traducerea automată

Traducerea automată a datelor structurate implică riscuri juridice pe care, în calitate de operator al unui site web multilingv, trebuie să le verificați pe propria răspundere. În special în cazul marcajelor Schema.org care conțin conținuturi relevante din punct de vedere juridic, precum instrucțiuni de siguranță a produselor, termeni și condiții sau denumiri de mărci, o traducere inexactă poate duce la cazuri de răspundere. De exemplu, un nume de produs tradus greșit sau o descriere înșelătoare a produsului poate încălca legislația privind concurența. Prin urmare, recomandăm ca toate traducerile generate automat să fie corectate de un specialist vorbitor nativ. Acest lucru este valabil mai ales pentru câmpuri precum „description” în Schema Product sau „answer” în Schema FAQ, unde nuanțele sunt decisive.

Pe lângă corectitudinea conținutului, aspectele legate de protecția datelor joacă, de asemenea, un rol: dacă Schema dvs. conține date cu caracter personal (de ex., evaluări ale clienților în Schema Review), trebuie să vă asigurați că traducerea respectă GDPR. Serviciile de traducere automată ar trebui utilizate numai dacă serviciul oferă garanții suficiente de protecție a datelor. Nu există o interdicție generală, dar responsabilitatea pentru prelucrarea datelor vă revine dvs., ca operator al site-ului web. Consultați un consilier juridic cu privire la cerințele specifice din țările dvs. țintă.

O altă capcană juridică: utilizarea „inLanguage” cu coduri de limbă nepermise. Folosiți întotdeauna codurile oficiale BCP-47 (de ex., „de-DE” în loc de „deutsch”). Codurile eronate pot face ca marcajele dvs. să fie ignorate de motoarele de căutare – ceea ce nu reprezintă o problemă juridică, dar afectează găsibilitatea. Efectuați, așadar, înainte de lansare o validare cu instrumente precum Google Rich Results Test și verificați suplimentar dacă traducerile acoperă corect toate câmpurile relevante din punct de vedere juridic.

Recomandare de acțiune: definiți un flux de lucru în care fiecare marcaj Schema tradus automat este verificat de un redactor sau jurist vorbitor nativ. Documentați acest proces pentru a putea demonstra, în caz de litigiu, că v-ați îndeplinit obligația de diligență. Evitați traducerea automată a blocurilor de text cu caracter juridic (de ex., condiții de garanție, clauze de limitare a răspunderii); traduceți-le manual sau printr-un serviciu specializat.

Perspective: Localizare asistată de inteligență artificială și evoluții viitoare ale Schemei

Localizarea marcajelor Schema.org este din ce în ce mai facilitată de instrumente bazate pe inteligență artificială. Sistemele actuale pot crea traduceri mai precise din punct de vedere contextual, pe baza rețelelor neuronale, față de metodele statistice mai vechi. Pentru site-urile multilingve, aceasta înseamnă că puteți transfera rapid cantități mari de date despre produse sau conținut FAQ în mai multe limbi. Cu toate acestea, asigurarea calității rămâne esențială, deoarece modelele AI nu captează întotdeauna corect termenii specifici industriei sau nuanțele regionale. O abordare practică este utilizarea AI pentru traducerea brută, urmată de o verificare umană. Instrumente precum Baduno combină traducerea AI cu verificarea nativă, oferind astfel o soluție scalabilă.

Paralel cu dezvoltarea AI, Schema.org își extinde continuu vocabularul. Tipurile viitoare ar putea aborda mai mult conținutul generat de AI, de exemplu o schemă „AIContent” pentru marcarea textelor create automat. De asemenea, legătura cu Knowledge Graph-urile devine mai importantă: marcajele multilingve ar putea fi generate automat din baze de cunoștințe centralizate în viitor. Deja există proprietatea „translationOfWork”, care face explicită relația dintre conținuturile traduse. Vă recomandăm să includeți din timp astfel de proprietăți noi în strategia dvs. pentru a fi pregătiți pentru actualizările motoarelor de căutare.

Un alt trend sunt marcajele dinamice specifice limbii, care sunt afișate pe baza contextului utilizatorului. De exemplu, o schemă Product ar putea conține moneda și unitatea de măsură locală în funcție de locația utilizatorului. Provocarea constă în utilizarea corectă a „inLanguage” și evitarea conflictelor cu hreflang. Versiunile viitoare ale Schemei ar putea defini mai clar cum se pot reprezenta variantele regionale în cadrul unei scheme. Pentru a vă pregăti, construiți marcajele modular: utilizați blocuri separate pentru fiecare limbă în același JSON-LD sau utilizați taguri script separate pentru fiecare versiune lingvistică – în funcție de infrastructura tehnică.

Recomandare: Testați soluțiile de traducere bazate pe AI cu un set reprezentativ de date Schema și măsurați rata de eroare. Urmăriți notele de lansare Schema.org pentru a identifica noile proprietăți. Pilotati afișarea dinamică a marcajelor pentru diferite audiențe și validați rezultatele cu Search Console ale principalelor motoare de căutare. Astfel, vă asigurați că site-ul dvs. multilingv beneficiază de evoluțiile viitoare, fără a-și asuma riscuri legale sau tehnice.

Exemplu practic: Implementarea pas cu pas a unei pagini de produs multilingve

Pentru a transpune fundamentele teoretice în practică, să luăm în considerare un site web de comerț electronic fictiv care oferă un smartphone în limbile germană, engleză și franceză. Să presupunem că pagina de produs este disponibilă sub un singur URL cu comutator de limbă (de exemplu, example.com/smartphone). Scopul este de a marca Schema.org Product cu informații specifice limbii.

1. **Stabilirea codurilor de limbă**: Pentru fiecare variantă lingvistică se va folosi o valoare inLanguage unică. Exemplu: Germană: "de-DE", Engleză: "en-US", Franceză: "fr-FR".

2. **Marcarea numelui și descrierii specifice limbii**: În marcajul JSON-LD se utilizează un array @graph. Fiecărei variante lingvistice i se atribuie un obiect Product propriu cu inLanguage corespunzător. Exemplu: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "de-DE", "name": "Smartphone Pro Max", "description": "Leistungsstarkes Smartphone mit 128 GB Speicher", "offers": { ... } }, { "@type": "Product", "inLanguage": "en-US", "name": "Smartphone Pro Max", "description": "Powerful smartphone with 128 GB storage", "offers": { ... } }, { "@type": "Product", "inLanguage": "fr-FR", "name": "Smartphone Pro Max", "description": "Smartphone puissant avec 128 Go de stockage", "offers": { ... } } ] } ```

3. **Validarea marcajului**: Cu Google Rich Results Test se verifică pentru fiecare versiune lingvistică dacă marcajul este acceptat. Trebuie avut grijă ca specificațiile inLanguage să corespundă limbii reale a paginii.

4. **Integrarea pe server sau prin JavaScript**: În practică, marcajul este generat cel mai bine pe partea de server, astfel încât codul sursă al paginii să conțină JSON-LD complet. În cazul schimbărilor dinamice de limbă prin JavaScript, marcajul poate fi încărcat ulterior, dar acest lucru poate să nu fie detectat de motoarele de căutare.

5. **Testarea vizibilității**: După implementare, se verifică dacă datele structurate sunt raportate ca valide în Google Search Console și dacă rezultatele îmbogățite apar în căutări.

Acest exemplu pas cu pas arată cum puteți proceda concret. Adaptați structura la tehnologia dvs. și testați fiecare variantă lingvistică separat.

Colaborarea cu furnizorii de servicii de traducere și localizare

Când implementați date structurate multilingve, lucrați adesea cu traducători sau agenții de localizare. Este important ca marcajele Schema.org să facă parte din procesul de localizare. Discutați cu furnizorul dvs. de servicii că nu numai conținutul vizibil, ci și valorile din JSON-LD (de ex., „name”, „description”) trebuie traduse. O greșeală frecventă: agenția primește doar textul paginii, nu și datele structurate. Prin urmare, furnizați un document separat cu toate câmpurile Schema – ideal în format JSON – și stabiliți care câmpuri trebuie traduse în funcție de limbă (de ex., „offers” sau „review” pot rămâne globale, în timp ce „name” variază în funcție de limbă).

Sfat practic: Folosiți glosare și memorii de traducere și pentru datele dvs. structurate. Astfel vă asigurați că numele produselor și termenii tehnici apar uniform în toate marcajele. Solicitați, de asemenea, furnizorului să seteze codurile lingvistice (inLanguage) conform specificațiilor dvs. – de exemplu „de-DE” în loc de doar „de”. După livrare, verificați prin sondaj dacă toate valorile de câmp traduse sunt corect inserate în marcaje. Un test automatizat cu Rich Results Test de la Google poate oferi primele indicații.

Un alt aspect: colaborarea în asigurarea calității. Stabiliți ca datele Schema traduse să fie revizuite de un redactor nativ înainte de publicare. Deoarece atributele de produs sau instrucțiunile din întrebările frecvente traduse incorect pot afecta clasamentul internațional. Documentați întregul proces – de la extragerea textelor sursă până la implementare – și actualizați lista de verificare pentru fiecare versiune lingvistică. Astfel evitați ca datele structurate să devină învechite la actualizări ulterioare de conținut.

Aviz juridic: Responsabilitatea pentru traduceri corecte vă aparține. Solicitați confirmarea scrisă a respectării specificațiilor dvs. și clarificați contractual chestiunile legate de răspundere pentru traduceri greșite. Se recomandă consultanță juridică independentă.

Planificarea bugetului și estimarea efortului pentru implementarea Schema multilingvă

Introducerea datelor structurate în mai multe limbi generează costuri unice și recurente. Pe lângă traducerea conținutului marcajelor, apar eforturi pentru integrarea tehnică, testare și întreținere. Pentru o planificare bugetară realistă, trebuie să luați în considerare următoarele elemente:

1. Traducerea câmpurilor Schema: Pe versiune lingvistică apar costuri pentru traducerea tuturor elementelor JSON-LD relevante (titluri, descrieri, întrebări, răspunsuri etc.). Deoarece sunt texte scurte, adesea tehnice, agențiile de traducere pot oferi prețuri speciale. Calculați o suprataxă de 10–20% pentru familiarizarea cu definițiile Schema.

2. Adaptarea tehnică: Marcajele trebuie realizate fie în blocuri JSON-LD separate pentru fiecare limbă, fie prin câmpuri multilingve. În funcție de sistem, echipa de dezvoltare are nevoie de timp suplimentar pentru a implementa logica de schimbare a limbii și de fallback. Experiența arată că efortul inițial pentru un site web cu cinci versiuni lingvistice este între 15 și 25 de zile-om în dezvoltare.

3. Testare și asigurare a calității: Fiecare versiune lingvistică trebuie validată individual – cu Rich Results Test de la Google, validatori Schema.org și verificări manuale prin sondaj. Planificați aproximativ 1–2 zile pentru configurarea inițială și o jumătate de oră per modificare.

4. Întreținere continuă: La actualizările sortimentului de produse sau ale conținutului FAQ, marcajele trebuie ajustate prompt. Stabiliți dacă echipa de traducere livrează întotdeauna și datele Schema pentru conținut nou. Un sistem de gestionare a conținutului care generează automat date structurate reduce efortul pe termen lung, dar necesită o configurare corespunzătoare.

5. Instrumente și licențe: Dacă utilizați instrumente speciale pentru monitorizarea datelor structurate (de ex., API-uri Webmaster Tools sau tablouri de bord proprii), pot apărea taxe de abonament.

Ca regulă generală, pentru întregul proces (introducere în trei limbi principale) ar trebui să bugetați între 5.000 și 15.000 de euro, în funcție de amploarea site-ului și numărul de produse. Pentru proiecte mici cu câteva pagini FAQ, suma poate fi mai mică.

Aviz juridic: Cifrele menționate sunt doar orientative. Solicitați oferte individuale de la dezvoltatori și traducători și rețineți că costurile reale pot varia în funcție de complexitate. Pentru declarații obligatorii, adresați-vă consultanței dvs. juridice și fiscale.