Strukturált adatok nemzetközileg: Schema.org nyelvi határokon át

Strukturált adatok bevezetése többnyelvű weboldalakhoz

A Schema.org szerint strukturált adatok segítik a keresőmotorokat weboldala tartalmának megértésében – mégpedig nyelvi határokon átívelve. Ha több nyelvi verziót üzemeltet, a helyes jelölés még fontosabbá válik. Az olyan keresőmotorok, mint a Google, strukturált adatokat használnak a Rich Results (például kiemelt részletek, termékárak vagy GYIK-elemek) megjelenítéséhez. Többnyelvű oldalak esetén ezeknek a jelöléseknek nyelvspecifikusaknak kell lenniük, különben hibás információk jelenhetnek meg – például egy német oldal telefonszáma a francia verzióban.

Egy tipikus hiba: az egyik nyelv sémáját egyszerűen átveszik a másik verzióba anélkül, hogy a nyelvi beállításokat módosítanák. Pedig nem elég csak a tartalmat lefordítani; a struktúrának is tükröznie kell a célnyelvet. Például a sémaobjektum inLanguage mezőjének az adott oldal nyelvét kell megadnia. Egy német termékoldal esetében ez `inLanguage: 'de'`, az angol esetében `inLanguage: 'en'`. Ezenkívül a `translationOfWork` segítségével hivatkozhat az eredeti verzióra.

Gyakorlatban a legfontosabb oldaltípusokkal kezdje: Szervezet, Termék, GYIK. Ezeket használják a leggyakrabban Rich Results megjelenítéséhez. Előzetesen ellenőrizze, hogy mely oldalak mely nyelven relevánsak. Nemzetközi vállalati oldalhoz a Organization séma, online áruházhoz a Product séma ajánlott. Ügyeljen arra, hogy minden nyelvi verzió saját JSON-LD szkriptet vagy külön bejegyzést kapjon a szkriptben. Használjon olyan eszközöket, mint a Google Rich Results Test, hogy minden nyelvi verziót külön-külön érvényesítsen. Ne feledje, hogy a teszt csak egy pillanatképet ad – a rendszeres ellenőrzés ajánlott.

Jogi szempontból figyelembe kell venni, hogy a strukturált adatok nem tartalmazhatnak a GDPR-t sértő személyes adatokat. A különböző országok elérhetőségeinek megadásakor győződjön meg arról, hogy az adatok helyesek és naprakészek. Kétség esetén kérje jogi tanácsadó segítségét. A többnyelvű strukturált adatok gondos implementálásával növeli annak esélyét, hogy a különböző nyelvi régiókban releváns Rich Results segítségével megtalálják.

A Schema.org alapjai és a nyelvi jelölés

A Schema.org egy közös szókészletet biztosít, amelyet a keresőmotorok támogatnak. Többnyelvű weboldalak esetében a helyes nyelvi jelölés kulcsfontosságú. Minden sémaobjektum rendelkezhet `inLanguage` tulajdonsággal, amely a tartalom nyelvét adja meg (pl. `'de'`, `'en'`, `'fr'`). Ennek a megadásnak meg kell egyeznie az oldal tényleges nyelvével. JSON-LD-ben a `@language` beállítást alkalmazhatja a teljes dokumentumon vagy egyes objektumokon, ha több nyelv szerepel.

Példa: Német nyelvű termék esetén: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Ha ugyanezt a terméket egy angol oldalon jelöli, akkor `"inLanguage": "en"` szerepel, és a név angolul. Kerülje el, hogy több nyelvi verziót egyetlen sémaobjektumban keverjen – ez inkonzisztenciához vezet. Használjon inkább külön jelölési blokkokat nyelvenként, vagy dolgozzon `@language` tömbökkel egy objektumon belül, ha az entitás többnyelvű.

A weboldal-specifikus adatoknál (pl. `WebSite` vagy `WebPage`) szintén adja meg a nyelvet. Ha az oldalon nyelvváltás van, a `potentialAction` vagy `translationOfWork` segítségével hivatkozhat a többi nyelvi verzióra. A gyakorlatban bevált, hogy minden nyelvhez külön JSON-LD blokkot helyez el a megfelelő oldal fejlécében. Így a hozzárendelés egyértelmű, és az érvényesítő eszközök helyesen értelmezik.

Ügyeljen arra, hogy a nyelvkódok az ISO-639-1 szabványt használják (pl. „de” a némethez, „en” az angolhoz). Regionális változatokhoz hozzáfűzhet országkódokat is, pl. „de-CH” a svájci némethez. Ekkor ellenőriznie kell, hogy a keresőmotor támogatja-e ezt a finom megkülönböztetést – általában az alap nyelvkód elegendő. Minden nyelvi verziót érvényesítsen külön a Google Structured Data Testing Tool vagy a Rich Results Test segítségével. Jegyezze fel a hiányzó nyelvi megadásokra vonatkozó figyelmeztetéseket, és javítsa ki azokat célzottan.

Organization séma: Vállalati adatok több nyelven

Az Organization séma ideális többnyelvű weboldalakkal rendelkező vállalatok számára, mivel központi információkat, például nevet, címet és elérhetőségeket biztosít. Minden nyelvi változathoz külön Organization objektumot kell létrehozni, amely a megfelelő nyelven van megjelölve. A `name` mezőt a célnyelven kell megadni – például „Muster GmbH” németül és „Sample Inc.” angolul. Ha a vállalatnak egységes neve van, elegendő a leírás (`description`) fordítása.

Címek esetén használja a `PostalAddress` sémát `addressCountry` és `addressLocality` paraméterekkel. Nemzetközi helyszínekhez több `location` bejegyzést is megadhat. Ügyeljen arra, hogy a telefonszámok (`telephone`) a megfelelő országhívószámmal legyenek ellátva. Például a német oldalon `+49 30 1234567`, a svájci oldalon `+41 44 1234567`. Ugyanez vonatkozik az e-mail címekre és nyitvatartási időkre. Használja az `areaServed` tulajdonságot annak jelzésére, hogy a vállalat mely országokban tevékenykedik.

Gyakran figyelmen kívül hagyott részlet a `sameAs` tulajdonság a közösségi média profilokhoz. Adja meg a nyelvspecifikus profilokat, ha léteznek – például a német Facebook-oldalt és az angol Twitter-jelenlétet. A `url` is a nyelvspecifikus kezdőoldalra mutasson. Többnyelvű weboldalak esetén a `translationOfWork` segítségével kapcsolatot hozhat létre a nyelvi változatok között, feltéve, hogy az oldalak ugyanazt a tartalmat jelenítik meg más nyelven.

Gyakorlati javaslat: Implementálja az Organization sémát minden nyelvi változat kezdőoldalán. Ehhez helyezzen el egy JSON-LD szkriptet a `<head>` szakaszban. Kerülje a duplikációkat azáltal, hogy minden nyelvhez külön blokkot hoz létre a megfelelő `inLanguage` értékkel. Érvényesítse a jelölést a Google Rich Results Test segítségével, és ellenőrizze, hogy a kapcsolattartási adatok helyesen jelennek-e meg. Jogilag ügyeljen arra, hogy a megadott információk teljesek és adatvédelmi szempontból megfelelőek legyenek. Különösen több helyszín esetén: az impresszumkötelezettség országonként eltérő lehet. Kétség esetén kérjen jogi tanácsot. Ezen részletek révén biztosíthatja, hogy vállalata minden nyelvi régióban egységesen és pontosan jelenjen meg.

Termékséma: termékleírások nyelvspecifikus megjelölése

Többnyelvű weboldalak esetén a termékek Schema.org Product sémával történő megjelölése az adott nyelven elengedhetetlen. Minden termék nyelvi változatának saját séma jelölést kell kapnia, amely tartalmazza a helyi nevet, leírást és attribútumokat, mint az ár, pénznem vagy elérhetőség. Ehhez használja az `inLanguage` attribútumot nyelvenként – pl. `"inLanguage": "de-DE"` a német (Németország) esetén. Ügyeljen arra, hogy a terméknév és leírás a JSON-LD objektumban ténylegesen németül szerepeljen, ne csak a nyelvi címke.

Gyakori hiba, hogy az összes nyelvi változatot ugyanazzal a `@id`-vel (pl. globális termékazonosítóval) jelölik. Ehelyett minden nyelvhez adjon meg egyedi `@id`-t, például `https://example.com/de/produkt/123` és `https://example.com/fr/produit/123`. Így a Google a megfelelő változatot jelenítheti meg. Az áraknál használja a `priceCurrency` mezőt ISO-4217 kóddal (pl. EUR, USD), és adja meg az árat nyelvspecifikusan – még ha az ár változatlan is, a helyi oldalhoz tartozik.

Gyakorlati javaslat: Hozzon létre egy JSON-LD sablont minden termékhez, amely dinamikusan állítja be a nyelvi paramétereket. Ellenőrizze minden nyelvi változatot külön-külön a Google Rich Results Test segítségével. Ügyeljen arra, hogy a `url` attribútum a megfelelő nyelvi URL-re mutasson. Kerülje az összes nyelv egyetlen JSON-LD blokkba keverését – ez gyakran érvényesítési hibákhoz vezet. A képek esetén az `image` attribútumot nyelvtől függetlenül tarthatja, de győződjön meg arról, hogy a kép URL-ek helyesek.

Ezenkívül az `offers` részt a `availability` értékkel a piacnak megfelelően módosíthatja (pl. `InStock` Németországban, `PreOrder` Franciaországban). Használja a `gtin` vagy `mpn` értékeket globálisan, de a `sku` esetében tartsa meg a helyi változatokat. Végül ellenőrizze, hogy a strukturált adatok a Search Console-ban minden nyelvi változathoz helyesen indexelődnek-e.

GYIK-séma: kérdés-felelet oldalak többnyelvű optimalizálása

A FAQ-oldalak több nyelven történő megjelenítésénél előnyös a nyelvspecifikus jelölés a FAQPage séma segítségével. Minden nyelvi verzió kap egy saját JSON-LD objektumot. Állítsa be az `inLanguage` értékét a megfelelő nyelvkódra (pl. `fr-FR` a franciához). A kérdéseket és válaszokat az objektumban a célnyelven kell megfogalmazni – a gépi fordítás gyakran nem elegendő; anyanyelvi beszélővel ellenőriztesse, mert a finom részletek kritikusak.

Egy tipikus hiba: ugyanaz a `@id` minden nyelvváltozathoz. Ehelyett használja a nyelvspecifikus URL-t `@id`-ként, pl. `https://example.com/de/faq/` és `https://example.com/en/faq/`. A FAQPage sémán belül sorolja fel a kérdéseket `mainEntity`-ként `@type: Question`-tel és a hozzá tartozó választ `acceptedAnswer`-ként. Minden kérdés kaphat további `inLanguage`-t, de ez redundáns, ha az egész oldal meg van jelölve. Korlátozza az oldalonkénti kérdések számát maximum 10–15-re, mivel a keresőmotorok csak korlátozott számú bejegyzést vesznek figyelembe.

Ajánlott intézkedés: Használjon olyan tartalomkezelő rendszert, amely FAQ-bejegyzésenként többnyelvű mezőt kínál. A JSON-LD kimenetben dinamikusan kérdezze le az aktuális nyelvet. Érvényesítse minden nyelvi verziót külön a Rich Results Test segítségével, és figyeljen a hiányzó `name` tulajdonságokra vonatkozó figyelmeztetésekre a kérdéseknél. Minden kérdéshez adjon hozzá egy `url`-t, amely a konkrét horgonyra hivatkozik – így a felhasználók közvetlenül a megfelelő válaszhoz ugorhatnak.

Vegye figyelembe: A FAQPage csak olyan oldalakra alkalmas, amelyek explicit kérdéseket és válaszokat tartalmaznak. Ne használja általános támogatási oldalakhoz. Az élesítés után tesztelje a láthatóságot a Google keresőben – a FAQ-rich snippetek gyakran jelennek meg kérdőszavas kereséseknél. A többnyelvű SEO érdekében érdemes a válaszokat az adott országra jellemző megfogalmazásokhoz igazítani (pl. „Hogyan tudok?” vs. „Comment puis-je?”).

Az inLanguage finomságai: nyelvkód és területi séma

Az `inLanguage` attribútum a Schema.org-ban a tartalom nyelvét adja meg, ahol az érték ideális esetben egy nyelvkódból (ISO 639-1) és egy opcionális régiókódból (ISO 3166-1 Alpha-2) áll – pl. `en-US` az amerikai angolhoz. A régió akkor fontos, ha a tartalom eltér: „colour” vs. „color” vagy eltérő mértékegységek. Régió nélkül a kód általános nyelvként értelmezendő. Használja tehát a `de-DE`, `de-AT`, `de-CH` kódokat országspecifikus oldalakhoz, még akkor is, ha a szöveg szinte azonos.

Gyakorlati példa: Egy terméket egy német és egy osztrák oldalon kínálnak. A nyelv német, de az árak és a szállítási feltételek eltérnek. Állítsa be az `inLanguage: "de-DE"` értéket a német oldalhoz, és az `inLanguage: "de-AT"` értéket az osztrák oldalhoz. Így a Google jobban megértheti a regionális relevanciát. Ugyanez érvényes az `en-GB` és `en-US` esetében is. Ha nincs szükség regionális megkülönböztetésre, elegendő a `"de"` vagy `"en"`. Ügyeljen azonban arra, hogy a nyelvkód mindig kisbetűs, a régió pedig nagybetűs legyen (pl. `fr-CA`).

Egy gyakori hiba az `inLanguage` használata egy fölérendelt objektumon, miközben az alobjektumok más nyelvűek. Példa: Egy WebSite német nyelven, de egyetlen cikk angolul. Ekkor állítsa be az `inLanguage: "de"` értéket a WebSite-on és az `inLanguage: "en"` értéket az Article-en. Ellenőrizze ezt egy sémaérvényesítővel, mert egyes eszközök konfliktusokat jelezhetnek. Többnyelvű oldalak esetén hreflang-címkékkel az `inLanguage`-nak meg kell egyeznie a megfelelő hreflang értékkel – ez segít a Google-nak a helyes verzió kiszolgálásában.

Gyakorlati megvalósítás: Minden nyelvi verzióhoz határozzon meg egy egyedi `@id`-t, és az `inLanguage`-t konzisztensen állítsa be. Használjon egy központi konfigurációs fájlt, amely minden nyelvhez a megfelelő kódokat tartalmazza. Tesztelje a schema.org eszközével, hogy az `inLanguage` címke elfogadásra kerül-e. Tipp: Ne felejtse el az `inLanguage`-t AMP-oldalak vagy mikroadat-alapú strukturált adatok esetén sem. JSON-LD esetén helyezze a legfelső szintre (pl. `WebSite` vagy `WebPage`). Dinamikus tartalmak, például blogbejegyzések esetén az `inLanguage` eltérhet – ekkor elemenként állítsa be.

Többnyelvűség helyes jelölése egyetlen URL-en

Ha egy URL több nyelven tartalmaz tartalmat – például nyelvváltó, lapfülek vagy akkordeonok segítségével –, akkor a strukturált adatokban egyértelműen jeleznie kell, hogy melyik szöveg melyik nyelvhez tartozik. Ellenkező esetben a keresőmotorok robotjai tévesen feltételezhetik, hogy minden tartalom egy nyelven elérhető, ami hibákhoz vezethet az indexelésben és a megjelenítésben.

Az alapvető módszer az `inLanguage` attribútum használata a megfelelő elemeken. Ha egy FAQ-sémában kérdések és válaszok szerepelnek németül és angolul ugyanazon az oldalon, minden kérdést és választ külön kell megjelölni: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Ugyanez vonatkozik a terméksémákra is: a `name` és `description` mezőket minden nyelvhez külön `Product` objektumban írja le, külön `inLanguage` attribútummal, vagy használja a `@language` és `@value` párokat egy `multilingualDescription` tulajdonságban (ha a szókészlet ezt támogatja).

Többnyelvű nevekkel rendelkező szervezetek esetén használjon `name` objektumokból álló tömböt: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Kerülje a teljes oldal többnyelvűként való deklarálását. Ehelyett a nyelvi hozzárendelést a lehető legrészletesebben végezze el. Gyakori hiba, hogy az `inLanguage` attribútumot csak a séma legfelső szintjén állítják be, anélkül hogy az alsóbb szintű elemeket megjelölnék. Ezért az érvényesítési munkafolyamat során ellenőrizze, hogy minden szöveg nyelvi címkéje helyes legyen.

Konkrét javaslatként: hozzon létre egy külön sémaobjektumot minden nyelvi változathoz egy URL-en belül, amely csak az adott nyelv szövegeit tartalmazza, és állítsa be az `inLanguage` attribútumot a megfelelő nyelvkódra. Ha az oldal alapértelmezetten egy főnyelvet jelenít meg, a többi nyelvet pedig JavaScript segítségével tölti be, akkor az összes nyelv strukturált adatait statikusan ágyazza be a HTML-be. Olyan eszközök, mint a Google Rich Results Test, megmutatják, hogy a címkézést helyesen értelmezik-e. Tesztelje minden nyelvi verziót külön, például úgy, hogy URL-paraméter vagy süti segítségével a kívánt nyelvre kényszeríti a robotot.

A hreflang és az inLanguage elhatárolása: Mikor melyik módszert használjuk?

A `hreflang` és az `inLanguage` különböző célokat szolgál a nemzetközi SEO-ban, és nem szabad összekeverni őket. A `hreflang` egy HTML-elem vagy HTTP-fejléc, amely jelzi a keresőmotorok számára, hogy léteznek az oldal alternatív nyelvi vagy regionális változatai. Ez biztosítja, hogy a felhasználók a megfelelő oldalt kapják a különböző országokban vagy nyelvi beállításokkal. Ezzel szemben az `inLanguage` egy attribútum a strukturált adatokban (Schema.org), amely megadja, hogy egy adott szövegelem milyen nyelven íródott.

Mikor használja melyiket? A `hreflang`-et akkor alkalmazza, ha külön URL-ekkel rendelkezik a különböző nyelvi változatokhoz (pl. `example.com/de/` és `example.com/en/`). Ezzel elkerüli a duplikált tartalom problémáit, és biztosítja, hogy a megfelelő oldal jelenjen meg a snippetben. Az `inLanguage` akkor szükséges, ha egyetlen URL-en belül jelöl meg többnyelvű tartalmat, vagy ha egy strukturált adatelem, például egy termékleírás több nyelven érhető el. Az `inLanguage` tehát kiegészíti a `hreflang`-et az egyes szövegblokkok szintjén.

Gyakori félreértés: az `inLanguage` nem helyettesíti a `hreflang`-et. Még ha minden egyes sort meg is jelöl `inLanguage`-lel, a keresőmotorok a `hreflang` nélkül nem tudják, hogy léteznek-e az egész oldal alternatív változatai. Fordítva, a `hreflang` önmagában nem elegendő a többnyelvű tartalom finom szemcséjű leírásához egy URL-en belül. A gyakorlatban ez azt jelenti: ha külön oldalai vannak minden nyelvhez, akkor elsősorban a `hreflang` szükséges, míg az `inLanguage` csak a strukturált adatokban adja meg az adott oldalon lévő tartalom konkrét nyelvét. Ha egy URL-en több nyelv található, akkor feltétlenül szükség van az `inLanguage` attribútumra minden egyes nyelvspecifikus elemnél.

Konkrét javaslat: Tervezze meg az URL-stratégiáját a megvalósítás előtt. Döntse el, hogy nyelvenként külön URL-t (ccTLD, aldomain, alkönyvtár) vagy egy közös URL-t használ dinamikus nyelvváltással. Utóbbi esetben elengedhetetlen a helyes `inLanguage` címkézés. Mindenképpen ellenőrizze, hogy a `hreflang` címkék az összes releváns nyelvi változatra mutatnak-e, és nincsenek-e ellentmondásban a strukturált adatok `inLanguage` beállításaival. E két jelzés összehangolása segíthet a keresőmotoroknak a tartalmak helyes besorolásában.

Érvényesítési munkafolyamat: Eszközök és automatikus ellenőrzések

A struktúrált adatok manuális ellenőrzése minden nyelvi verzióban hibalehetőséget rejt és időigényes. Az automatizált érvényesítési munkafolyamat biztosítja, hogy a Schema.org-jelölések helyesek és azok is maradjanak – a tartalomfrissítések vagy új nyelvek hozzáadása után is. A legfontosabb eszközök a Google Rich Results Test (a Google által támogatott típusokhoz, mint a FAQ, Product) és a Schema.org Validator (a tiszta szintaxis ellenőrzéséhez). Kiegészítőként a Screaming Frog SEO Spider-hez hasonló felderítők segítenek a struktúrált adatok kinyerésében a teljes weboldalról és a hibák ellenőrzésében.

Építse be az ellenőrzést a CI/CD-folyamatba: Minden telepítés vagy nyelvi frissítés után futtasson egy automatikus tesztet. Ehhez használja a Google Rich Results Test API-ját vagy egy olyan szkriptet, amely elemzi az oldalakat és a JSON-LD-blokkokat egy saját maga által definiált séma ellenőrzi. Különösen figyeljen a következő hibaforrásokra: - Hiányzó `inLanguage` ott, ahol több nyelv előfordul. - Ellentmondó nyelvkódok (pl. „de” a „de-DE” helyett regionális változatoknál). - Hiányos kötelező mezők (pl. `name` a Product esetében minden nyelven). - Elavult `hreflang`-címkék, amelyek már nem illeszkednek a jelenlegi URL-ekhez.

Konkrét cselekvési javaslat: Készítsen minden sématípushoz (Organization, Product, FAQ) egy ellenőrzőlistát a szükséges attribútumokkal nyelvenként. Használjon egy teszteszközt, például a `json-schema`-t az adatok automatikus érvényesítéséhez. Emellett végezzen rendszeresen (pl. havonta) egy teljes bejárást a Schema.org-Validator segítségével, és kérjen jelentéseket a hibás oldalakról. Dokumentálja a hibakategóriákat és rendeljen felelősöket a javításokhoz. Vegye figyelembe, hogy a struktúrált adatokat az élő oldalakon kell ellenőrizni – a staging környezetben végzett teszt nem elegendő, mert ott más tartalmak lehetnek. Csak így biztosíthatja, hogy a keresőmotorok számára releváns hibák időben kijavításra kerüljenek.

Gyakori hibák a nemzetközi struktúrált adatokban

A többnyelvű weboldalak Schema.org-jelölése tipikus buktatókat rejt. Gyakori hiba a `inLanguage` nyelvi attribútum hiánya vagy helytelen megadása. Ha például egy terméket németül kínál, de a jelölésben nem adja meg a `inLanguage: "de-DE"` értéket, a keresőmotorok semleges nyelvűként értelmezhetik az adatokat. Egy másik alapvető hiba a nyelvek keverése egyetlen Schema-blokkon belül. Kerülje el, hogy egy `Product` objektumban a `name` tulajdonság angol, a `description` pedig német legyen. Ehelyett minden nyelvi verzióhoz külön blokkot kell létrehozni a helyes `inLanguage` értékkel.

Szintén gyakori hiba a nem megfelelő sématípusok használata. Egy többnyelvű vállalkozás esetében sokan tévesen a `LocalBusiness`-t használják, holott az `Organization` a helyes választás, ha nincs fizikai cím minden nyelven. A termékeknél gyakran elfelejtik a `offers` tulajdonságot nyelvspecifikusan jelölni. Ezen felül a struktúrált adatok frissítésének elmulasztása fordítások után: egy újonnan lefordított termékszöveget a jelölésben is módosítani kell – ellenkező esetben a keresési eredmények elavult vagy hibás információkat mutatnak.

Az érvényesítés elhanyagolása egy további fő hiba. Minden változtatás után ellenőrizze a jelöléseket megfelelő eszközökkel. A hibás vagy hiányzó `@id`-hivatkozások a nyelven átívelően azonos entitásoknál (pl. egy szervezet) duplikátumokhoz vagy hiányos adatokhoz vezetnek. Ezenkívül gyakran figyelmen kívül hagyják a `hreflang`-gel való együttműködést: ahol nincsenek alternatív URL-ek, ott ugyanazon az oldalon kell dolgozni az `inLanguage` segítségével.

Cselekvési javaslatok: Ellenőrizze minden jelölés helyes nyelvi hozzárendelését. Használjon minden nyelvi verzióhoz külön Schema-blokkokat egyedi `@id`-kkel. Kerülje a keveredést – az `aggregateRating` vagy `review` esetében is helyesnek kell lennie a nyelvnek. Minden fordítás után végezzen újabb érvényesítést, és egyeztesse az adatokat a látható tartalommal. Csak így biztosíthatja, hogy a keresőmotorok helyesen értelmezzék többnyelvű kínálatát.

Tesztelés a Google Rich Results, Bing Webmaster Tools és Yandex segítségével

A többnyelvű Schema.org-jelölések ellenőrzése nem korlátozódhat egyetlen eszközre. Minden keresőmotor saját értelmezéssel és validálási kritériumokkal rendelkezik. A Google Rich Results Test az első állomás: adja meg a jelölést tartalmazó URL-t, vagy illessze be közvetlenül a kódot. Figyeljen minden hibára és figyelmeztetésre – különösen arra, hogy a `inLanguage` megadások helyesen kerülnek-e felismerésre. Gyakori probléma, hogy a Google elfogadja a `de-DE`-t, de hiányzó régió (`de`) esetén figyelmeztetést ad. Tesztelje az egyes nyelvi verziókat külön-külön.

A Bing Webmaster Tools URL-ellenőrzést kínál strukturált adatnézettel. Itt láthatja, hogy a Bing a várt módon értelmezi-e a jelöléseket. A Bing gyakran szigorúbb a `inLanguage` validálásában, és elvárhatja a kétjegyű nyelvkódot régió nélkül (pl. `de` a `de-DE` helyett). Végezzen élő tesztet, és javítsa az eltéréseket. A Bing emellett lehetséges duplikációkat is jelez, ha az `@id` értékek többször használatosak.

A Yandex Webmaster saját validátorral rendelkezik, amely elsősorban az orosz nyelvű oldalak esetében releváns. Itt is tesztelheti a strukturált adatokat. A Yandex a Schema.org-típusok többségét támogatja, de a hibakezelés eltérő. Különösen a `Product` jelöléseknél gyakran kifogásolja az `availability` tulajdonságot. Ezért itt is tesztelje az egyes nyelvi verziókat. Vegye figyelembe, hogy a Yandex a regionális nyelvkódokat (pl. `de-DE`) eltérően súlyozhatja.

Ajánlott eljárás: Tesztelje az egyes nyelvi verziókat mindhárom eszközben a megvalósítás után és minden módosítás után. Jegyezze fel az eltéréseket, és igazítsa a jelöléseket úgy, hogy mindhárom keresőmotor elfogadja. Ideális esetben használja a kétjegyű nyelvkódot (`de`, `en`) az `inLanguage`-ban, mivel ezt a legtöbb rendszer egyformán értelmezi. Automatizálja a teszteket CI-eszközökkel, hogy a többnyelvű webhelyeken sok oldal esetén áttekintést nyerjen.

Ellenőrzőlista többnyelvű Schema.org-jelölések bevezetéséhez

A strukturált megközelítés megakadályozza a tipikus hibákat a nemzetköziesítés során. A bevezetés előtt határozza meg a nyelvi stratégiát: külön URL-eket használjon nyelvenként (pl. `/de/produkt` és `/en/product`), vagy egyetlen URL-t nyelvváltással? Külön URL-ek esetén használjon `hreflang`-et és URL-enként saját jelölést. Egyetlen URL esetén helyezzen el több `inLanguage` blokkot különböző nyelvkódokkal. Tervezze meg azt is, hogy mely Schema-típusokra van szükség: vállalat (Organization), termék (Product), GYIK (FAQPage) stb.

A megvalósítás során ügyeljen a következőkre: Minden Schema-objektum kapjon egyedi `@id`-t, amely nyelvtől függetlenül azonosítja az entitást. Minden nyelvi verzióhoz hozzon létre egy külön objektumot, amely az `inLanguage` segítségével adja meg a nyelvet. Használjon konzisztens nyelvkódokat – lehetőleg a kétjegyű ISO-kódot (pl. `de`, `en`) kiegészítve a régióval, ha szükséges. Hivatkozzon helyesen a jelöléseken belül: `Organization` esetén használja a `url` és `logo` elemeket nyelvspecifikus elérési utakkal. Ellenőrizze, hogy a szövegek (pl. `name`, `description`) megegyeznek-e a látható tartalommal.

A bevezetést követi a validálás: Tesztelje az egyes nyelvi verziókat a Google Rich Results Test, a Bing Webmaster Tools és a Yandex segítségével. Javítsa a hibákat és figyelmeztetéseket. Különösen figyeljen a hiányzó `inLanguage`-ra vagy a hibás nyelvkódokra. Használja emellett a Google Schema.org-validáló eszközét a szintaxis ellenőrzésére. Dokumentáljon minden változtatást, és minden fordítás után végezzen újabb teszteket.

Végezetül a folyamat része a monitorozás: Kövesse nyomon a teljesítményt a Search Console-ban, különösen a strukturált adatokra vonatkozó jelentésekben. Reagáljon az új hibákra vagy figyelmeztetésekre. Frissítse a jelöléseket időben, ha módosítja vagy lefordítja a tartalmakat. Végezzen rendszeres auditokat a konzisztencia biztosítása érdekében az összes nyelvi verzióban. Egy jól karbantartott Schema.org-megvalósítás javítja a láthatóságot a keresési eredményekben – garancia nélkül, de gyakorlati haszonnal.

Jogi nyilatkozat: Önálló felelősség automatikus fordítás esetén

A strukturált adatok automatikus fordítása jogi kockázatokkal jár, amelyeket Önnek, mint többnyelvű weboldal üzemeltetőjének saját felelősségére kell ellenőriznie. Különösen a jogilag releváns tartalmakat (pl. termékbiztonsági figyelmeztetések, ÁSZF, védjegyek) tartalmazó Schema.org-jelölések esetében a pontatlan fordítás felelősségre vonáshoz vezethet. Például egy hibásan lefordított terméknév vagy félrevezető termékleírás sérti a versenyjogot. Ezért javasoljuk, hogy minden automatikusan generált fordítást ellenőriztessen egy anyanyelvi szakemberrel. Ez különösen vonatkozik a Product séma „description” mezőjére vagy a FAQ séma „answer” mezőjére, ahol az árnyalatok döntőek.

A tartalmi helyesség mellett adatvédelmi szempontok is szerepet játszanak: Ha a séma személyes adatokat tartalmaz (pl. vélemények a Review sémában), gondoskodnia kell arról, hogy a fordítás GDPR-konform legyen. Automatikus fordítási szolgáltatásokat csak akkor használjon, ha azok megfelelő adatvédelmi garanciákat nyújtanak. Nincs általános tiltás, de az adatkezelésért Ön, mint weboldal-üzemeltető felel. Kérjen jogi tanácsadót a célországok speciális követelményeiről.

További jogi buktató: Az „inLanguage” használata érvénytelen nyelvkódokkal. Mindig a hivatalos BCP-47 kódokat használja (pl. „de-DE” és ne „deutsch”). A hibás kódok miatt a keresők figyelmen kívül hagyhatják a jelöléseket – ami bár nem jogi probléma, de rontja a megtalálhatóságot. Ezért az élesítés előtt végezzen validálást olyan eszközökkel, mint a Google Rich Results Test, és ellenőrizze, hogy a fordítások minden jogi szempontból releváns mezőt helyesen fednek-e le.

Javaslat: Határozzon meg egy munkafolyamatot, amelyben minden automatikusan lefordított séma-jelölést egy anyanyelvi szerkesztő vagy jogász ellenőriz. Dokumentálja ezt a folyamatot, hogy vitás esetben igazolni tudja a gondossági kötelezettségének teljesítését. A jogi jellegű szövegblokkok (pl. garanciális feltételek, felelősségi nyilatkozatok) automatikus fordításától tekintsen el; ezeket fordíttassa manuálisan vagy szakfordítóval.

Kitekintés: MI-alapú lokalizáció és jövőbeli sémafejlesztések

A Schema.org-jelölések lokalizációját egyre inkább megkönnyítik a MI-alapú eszközök. A jelenlegi rendszerek neurális hálók segítségével kontextusban pontosabb fordításokat készítenek, mint a régebbi statisztikai eljárások. Többnyelvű weboldalak esetében ez azt jelenti, hogy nagy mennyiségű termékadatot vagy GYIK-tartalmat gyorsabban tud több nyelvre átültetni. A minőségbiztosítás azonban továbbra is kulcsfontosságú, mivel a MI-modellek nem mindig ismerik fel helyesen az iparág-specifikus kifejezéseket vagy regionális árnyalatokat. Praktikus megközelítés a MI használata a nyersfordításhoz, amelyet emberi ellenőrzés követ. Az olyan eszközök, mint a Baduno, kombinálják a MI-fordítást az anyanyelvi ellenőrzéssel, így skálázható megoldást kínálnak.

A MI fejlődésével párhuzamosan a Schema.org folyamatosan bővíti szókészletét. A jövőbeli típusok jobban reagálhatnak a MI által generált tartalmakra, például egy „AIContent” séma a gépi szövegek jelölésére. A Knowledge Graphokkal való kapcsolat is fontosabbá válik: a többnyelvű jelölések a jövőben automatikusan generálódhatnak központi tudásbázisokból. Már most létezik a „translationOfWork” tulajdonság, amely explicité teszi a lefordított tartalmak közötti kapcsolatot. Javasoljuk, hogy ezeket az új tulajdonságokat időben építse be stratégiájába, hogy felkészült legyen a keresőmotorok frissítéseire.

További trend a dinamikus, nyelvspecifikus jelölés, amely a felhasználói kontextus alapján jelenik meg. Például egy Product séma a felhasználó tartózkodási helye szerint tartalmazhatja a helyi valutát és mértékegységet. A kihívást az „inLanguage” helyes használata és a hreflanggal való ütközések elkerülése jelenti. A jövőbeli sémaverziók tisztábban definiálhatják, hogyan jeleníthetők meg a regionális variánsok egy sémán belül. Ennek előkészítéséhez építse modulárisan a jelöléseket: használjon nyelvenként külön blokkokat ugyanazon JSON-LD-n belül, vagy külön script tageket nyelvi verzióként – a technikai infrastruktúrától függően.

Javaslat: Tesztelje a MI-alapú fordítási megoldásokat egy reprezentatív sémamintán, és mérje a hibaszázalékot. Kövesse nyomon a Schema.org kiadási jegyzeteit az új tulajdonságok azonosítása érdekében. Pilótázza a jelölések dinamikus megjelenítését különböző célcsoportok számára, és validálja az eredményeket a legfontosabb keresőmotorok Search Console-jában. Így biztosíthatja, hogy többnyelvű oldala profitáljon a jövőbeli fejlesztésekből, anélkül hogy jogi vagy technikai kockázatot vállalna.

Gyakorlati példa: Többnyelvű termékoldal lépésről lépésre történő implementációja

Az elméleti alapok gyakorlatba ültetéséhez vegyünk egy fiktív e-kereskedelmi weboldalt, amely egy okostelefont kínál német, angol és francia nyelven. Tegyük fel, hogy a termékoldal egyetlen URL-en érhető el nyelvváltóval (pl. example.com/smartphone). Célunk a Schema.org Product markup nyelvspecifikus adatokkal történő ellátása.

1. **Nyelvkódok meghatározása**: Minden nyelvváltozathoz egyedi inLanguage értéket rendelünk. Például: német: "de-DE", angol: "en-US", francia: "fr-FR".

2. **Név és leírás nyelvspecifikus kijelölése**: A JSON-LD markupban @graph tömböt használunk. Minden nyelvváltozathoz egy külön Termék objektumot rendelünk a hozzá tartozó inLanguage értékkel. Példa: ```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. **Markup érvényesítése**: A Google Rich Results Test segítségével minden nyelvváltozatnál ellenőrizzük, hogy a markup elfogadásra kerül-e. Ügyeljünk arra, hogy az inLanguage megadások egyezzenek az oldal tényleges nyelvével.

4. **Beépítés szerveroldalon vagy JavaScript segítségével**: A gyakorlatban a markupot legjobb szerveroldalon generálni, hogy az oldal forráskódja a teljes JSON-LD-t tartalmazza. Dinamikus nyelvváltás esetén JavaScript segítségével betölthető a markup, ezt azonban a keresőmotorok esetleg nem érzékelik.

5. **Láthatóság tesztelése**: A megvalósítás után ellenőrizzük, hogy a strukturált adatok érvényesként jelennek-e meg a Google Search Console-ban, és hogy a Rich Results megjelennek-e a keresésben.

Ez a lépésről lépésre bemutatott példa segít a konkrét megvalósításban. Igazítsa a struktúrát a technológiájához, és tesztelje minden nyelvváltozatot külön-külön.

Együttműködés fordító- és lokalizációs szolgáltatókkal

Többnyelvű strukturált adatok implementálásakor gyakran dolgozik együtt fordítókkal vagy lokalizációs ügynökségekkel. Fontos, hogy a Schema.org markupok is a lokalizációs folyamat részévé váljanak. Beszélje meg szolgáltatójával, hogy nemcsak a látható tartalmat, hanem a JSON-LD-ben szereplő értékeket (pl. „name”, „description”) is le kell fordítani. Gyakori hiba: az ügynökség csak az oldal szövegét kapja meg, a strukturált adatokat nem. Ezért külön dokumentumot készítsen az összes Schema mezőről – ideális esetben JSON formátumban –, és határozza meg, mely mezők nyelvspecifikusak (pl. az „offers” vagy a „review” globális maradhat, míg a „name” nyelvenként változhat).

Gyakorlati tipp: Használjon glossary-kat és translation memory-kat a strukturált adatokhoz is. Így biztosíthatja, hogy a terméknevek és szakkifejezések egységesen jelenjenek meg minden markupban. Kérje meg a szolgáltatót, hogy a nyelvi kódokat (inLanguage) az Ön előírásai szerint állítsa be – például „de-DE” és ne csak „de”. A szállítás után szúrópróbaszerűen ellenőrizze, hogy az összes lefordított mezőérték helyesen szerepel-e a markupokban. A Google Rich Results Test automatikus tesztje itt első jelzéseket adhat.

Egy másik szempont: a minőségbiztosítási együttműködés. Egyezzenek meg abban, hogy a lefordított sémaadatokat közzététel előtt egy anyanyelvi szerkesztő átnézze. A helytelenül lefordított termékattribútumok vagy FAQ-kérdések ugyanis károsíthatják a nemzetközi rangsorolást. Dokumentálja a teljes folyamatot – a forrásszövegek kinyerésétől a beillesztésig –, és frissítse az ellenőrzőlistát minden nyelvváltozathoz. Így elkerülheti, hogy későbbi tartalomfrissítések során a strukturált adatok elavulttá váljanak.

Jogi nyilatkozat: A helyes fordításokért Ön a felelős. Kérje a szolgáltatótól az előírások betartásának írásbeli megerősítését, és szerződésben rögzítsék a felelősségi kérdéseket hibás fordítások esetén. Független jogi tanácsadás javasolt.

Költségvetés-tervezés és erőfeszítés-becslés többnyelvű séma implementációhoz

A strukturált adatok több nyelven történő bevezetése egyszeri és folyamatos költségekkel jár. A markup tartalmak puszta fordításán kívül felmerülnek a technikai integráció, tesztelés és karbantartás költségei is. A reális költségvetés-tervezéshez az alábbi tételeket kell figyelembe vennie:

1. A séma mezőinek fordítása: Nyelvi verzióként felmerülnek az összes releváns JSON-LD elem (címek, leírások, kérdések, válaszok stb.) fordításának költségei. Mivel rövid, gyakran technikai szövegekről van szó, a fordítási ügynökségek speciális árakat kínálhatnak. Számoljon 10–20%-os felárral a séma-definíciókba való betanulásért.

2. Technikai adaptáció: A jelölést nyelvenként külön JSON-LD blokkokban vagy többnyelvű mezőkön keresztül kell elvégezni. Rendszertől függően a fejlesztőcsapatnak további időre van szüksége a nyelvváltás és a tartalék logika implementálásához. Tapasztalat szerint egy öt nyelvi verziót tartalmazó weboldal kezdeti ráfordítása a fejlesztésben 15 és 25 személynap között van.

3. Tesztelés és minőségbiztosítás: Minden nyelvi verziót egyenként kell validálni – a Google Rich Results Testtel, Schema.org-validátorokkal és manuális mintavételezéssel. Tervezzen nyelvenként kb. 1–2 napot az első beállításra és fél órát minden változtatásra.

4. Folyamatos karbantartás: A termékkínálat vagy GYIK-tartalmak frissítésekor a markupokat is időben kell módosítani. Határozza meg, hogy a fordítási csoport új tartalmak esetén mindig szállítsa a séma adatokat is. Egy olyan tartalomkezelő rendszer, amely automatikusan generálja a strukturált adatokat, csökkenti a hosszú távú erőfeszítéseket, de megfelelő beállítást igényel.

5. Eszközök és licencek: Ha speciális eszközöket használ a strukturált adatok nyomon követésére (pl. Webmaster Tools API-k vagy saját irányítópultok), esetleg előfizetési díjak merülhetnek fel.

Ökölszabályként a teljes folyamatra (három fő nyelv bevezetése) 5.000 és 15.000 euró közötti költségvetéssel számoljon, az oldal terjedelmétől és a termékek számától függően. Kisebb, néhány GYIK-oldalt tartalmazó projekteknél az összeg alacsonyabb is lehet.

Jogi nyilatkozat: A megadott számok csak tájékoztató jellegűek. Kérjen egyedi ajánlatokat fejlesztőktől és fordítóktól, és vegye figyelembe, hogy a tényleges költségek az összetettségtől függően eltérhetnek. Kötelező érvényű nyilatkozatokért forduljon jogi és adótanácsadóihoz.