Starptautiski strukturēti dati: Schema.org pāri valodu robežām

Ievads strukturētajos datos daudzvalodu vietnēm

Strukturētie dati saskaņā ar Schema.org palīdz meklētājprogrammām saprast jūsu vietnes saturu – un tas notiek pāri valodu robežām. Ja jums ir vairākas valodu versijas, pareiza marķēšana kļūst vēl svarīgāka. Meklētājprogrammas, piemēram, Google, izmanto strukturētos datus, lai rādītu Rich Results, piemēram, fragmentus, produktu cenas vai FAQ elementus. Daudzvalodu lapās šiem marķējumiem jābūt valodas specifiskiem, pretējā gadījumā var tikt parādīta nepareiza informācija – piemēram, tālruņa numurs no vācu lapas franču versijā.

Tipiska kļūda: vienkārši pārņemt vienas valodas shēmu citās versijās, nepielāgojot valodas norādes. Ar to nepietiek tikai tulkot saturu; arī struktūrai jāatspoguļo mērķvaloda. Piemēram, Schema objekta laukam inLanguage jānorāda attiecīgās lapas valoda. Vācu produktu lapa saņem inLanguage: 'de', angļu versija – inLanguage: 'en'. Papildus varat izmantot 'translationOfWork', lai norādītu uz oriģinālversiju.

Praktiski sāciet ar svarīgākajiem lapu tipiem: Organization, Product, FAQ. Tie tiek visbiežāk izmantoti Rich Results. Iepriekš pārbaudiet, kuras lapas kurā valodā ir īpaši nozīmīgas. Starptautiskam uzņēmuma tīmeklim piemērots ir Organization shēma, bet tiešsaistes veikalam – Product shēma. Pārliecinieties, ka katrai valodas versijai ir savs JSON-LD skripts vai atsevišķi ieraksti skriptā. Izmantojiet rīkus, piemēram, Google Rich Results Test, lai katru valodas versiju validētu atsevišķi. Ņemiet vērā, ka tests sniedz tikai momentuzņēmumu – regulāra pārbaude ir ieteicama.

Juridiski jāņem vērā, ka strukturētie dati nedrīkst saturēt personas datus, kas pārkāpj VDDR. Norādot kontaktinformāciju dažādās valstīs, pārliecinieties, ka dati ir pareizi un aktuāli. Šaubu gadījumā konsultējieties ar juristu. Tīra daudzvalodu strukturēto datu ieviešana uzlabo iespējas tikt atrastam ar atbilstošiem Rich Results dažādos valodu reģionos.

Schema.org pamati un valodas marķēšana

Schema.org piedāvā kopīgu vārdnīcas struktūru, ko atbalsta meklētājprogrammas. Daudzvalodu tīmekļa vietnēm pareiza valodas norādīšana ir būtiska. Katram Schema objektam var būt īpašība 'inLanguage', kas norāda satura valodu (piem., 'de', 'en', 'fr'). Šai norādei jāatbilst lapas faktiskajai valodai. JSON-LD iestatiet @language vai nu visam dokumentam, vai atsevišķiem objektiem, ja ir vairākas valodas.

Piemērs: vācu valodas produktam izmantojiet: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Ja to pašu produktu marķējat angļu lapā, tad vietā būs "inLanguage": "en" un nosaukums angliski. Izvairieties no vairāku valodu versiju sajaukšanas vienā Schema objektā – tas rada neatbilstības. Tā vietā izmantojiet atsevišķus marķēšanas blokus katrai valodai vai strādājiet ar @language masīviem objekta iekšienē, ja vienība ir daudzvalodu.

Vietnei specifiskām norādēm, piemēram, 'WebSite' vai 'WebPage', arī norādiet valodu. Ja lapā ir valodu pārslēgšana, varat izmantot 'potentialAction' vai 'translationOfWork', lai norādītu uz citām valodu versijām. Praksē ir ieteicams katrai valodai ievietot savu JSON-LD bloku attiecīgās lapas head daļā. Tā asociācija paliek nepārprotama un validācijas rīki to pareizi interpretē.

Pārliecinieties, ka valodu kodi atbilst ISO-639-1 standartam (piem., 'de' vācu, 'en' angļu). Reģionālajiem variantiem var pievienot valsts kodu, piem., 'de-CH' Šveices vācu valodai. Tomēr jāpārbauda, vai meklētājprogramma atbalsta šo smalko atšķirību – parasti pietiek ar pamata valodas kodu. Validējiet katru valodas versiju atsevišķi ar Google Structured Data Testing Tool vai Rich Results Test. Ierakstiet iespējamos brīdinājumus par trūkstošām valodas norādēm un novērsiet tos mērķtiecīgi.

Organization shēma: Uzņēmuma dati vairākās valodās

Organization shēma ir ideāli piemērota uzņēmumiem ar daudzvalodu tīmekļa vietnēm, jo tā sniedz centrālu informāciju, piemēram, nosaukumu, adresi un kontaktinformāciju. Katrai valodas versijai jāizveido savs Organization objekts, kas atzīmēts attiecīgajā valodā. `name` jānorāda mērķa valodā – piemēram, „Muster GmbH“ vācu valodā un „Sample Inc.“ angļu valodā. Ja uzņēmumam ir vienots nosaukums, pietiek ar apraksta (`description`) tulkojumu.

Adresēm izmantojiet `PostalAddress` shēmu ar `addressCountry` un `addressLocality`. Starptautiskām vietām varat paredzēt vairākus `location` ierakstus. Pārliecinieties, vai tālruņu numuriem (`telephone`) ir pievienots pareizais valsts kods. Piemēram: Vācijas lapai `+49 30 1234567`, Šveices lapai `+41 44 1234567`. Tas pats attiecas uz e-pasta adresēm un darba laiku. Izmantojiet `areaServed`, lai norādītu, kurās valstīs uzņēmums darbojas.

Bieži aizmirsta detaļa ir `sameAs` īpašība sociālo mediju profiliem. Norādiet valodai specifiskus profilus, ja tādi ir – piemēram, vācu Facebook lapu un angļu Twitter profilu. Arī `url` jānorāda uz valodai atbilstošo sākumlapu. Daudzvalodu vietnēs varat izmantot `translationOfWork`, lai izveidotu saikni starp valodu versijām, ja lapās ir vienāds saturs citā valodā.

Praktisks ieteikums: ieviesiet Organization shēmu katras valodas versijas sākumlapā. Ievietojiet JSON-LD skriptu `<head>` daļā. Izvairieties no dublikātiem, izveidojot katrai valodai atsevišķu bloku ar atbilstošu `inLanguage`. Validējiet atzīmēšanu ar Google Rich Results Test un pārbaudiet, vai kontaktinformācija tiek attēlota pareizi. Juridiski ņemiet vērā, ka sniegtajai informācijai jābūt pilnīgai un datu aizsardzības prasībām atbilstošai. Īpaši vairākām vietām: impresuma prasības var atšķirties atkarībā no valsts. Šaubu gadījumā meklējiet juridisku padomu. Ar šīm detaļām jūs nodrošināsiet, ka jūsu uzņēmums visās valodu reģionos tiek vienoti un korekti pārstāvēts.

Produkta shēma: produktu aprakstu atzīmēšana valodai specifiski

Daudzvalodu vietnēm ir būtiski atzīmēt produktus ar Schema.org Product attiecīgajā valodā. Katrai produkta valodas versijai jābūt savai shēmas atzīmei, kas satur lokālo nosaukumu, aprakstu un atribūtus, piemēram, cenu, valūtu vai pieejamību. Izmantojiet `inLanguage` atribūtu katrai valodai – piem., `"inLanguage": "de-DE"` vācu valodai (Vācijai). Pārliecinieties, ka produkta nosaukums un apraksts JSON-LD objektā patiešām ir vācu valodā, nevis tikai valodas tags.

Bieža kļūda ir visu valodu variantu atzīmēšana ar vienu `@id` (piem., globālu produkta ID). Tā vietā katrai valodai jāpiešķir sava `@id`, piem., `https://example.com/de/produkt/123` un `https://example.com/fr/produit/123`. Tādējādi Google var attēlot pareizo versiju. Cenām izmantojiet `priceCurrency` ar ISO-4217 kodu (piem., EUR, USD) un norādiet cenu valodai specifiski – pat ja cena ir vienāda, tā pieder vietējai lapai.

Praktisks ieteikums: izveidojiet katrai produktai JSON-LD veidni, kas dinamiski iestata valodas parametrus. Pārbaudiet katru valodas versiju atsevišķi ar Google Rich Results Test. Pārliecinieties, ka `url` atribūts norāda uz attiecīgās valodas URL. Izvairieties no visu valodu sajaukšanas vienā JSON-LD blokā – tas bieži rada validācijas kļūdas. Attēliem varat atstāt `image` atribūtu valodneatkarīgu, bet pārliecinieties, ka attēlu URL ir pareizi.

Turklāt varat pielāgot `offers` ar `availability` atkarībā no tirgus (piem., `InStock` Vācijai, `PreOrder` Francijai). Globāli izmantojiet `gtin` vai `mpn`, bet `sku` saglabājiet lokālām variācijām. Beigās pārbaudiet, vai strukturētie dati Search Console tiek pareizi indeksēti katrai valodas versijai.

FAQ shēma: jautājumu un atbilžu lapu optimizēšana daudzvalodībai

FAQ lapas vairākās valodās gūst labumu no skaidras, valodai specifiskas marķēšanas ar FAQPage shēmu. Katra FAQ lapas valodas versija saņem savu JSON-LD objektu. Iestatiet `inLanguage` uz atbilstošo valodas kodu (piem., `fr-FR` franču valodai). Jautājumi un atbildes objektā jāformulē mērķa valodā – mašīntulkojums bieži vien nav pietiekams; lieciet tās pārbaudīt dzimtās valodas runātājam, jo nianses ir izšķirošas.

Tipiska kļūda: vienāda `@id` visām valodu variācijām. Tā vietā izmantojiet valodai specifisko URL kā `@id`, piem., `https://example.com/de/faq/` un `https://example.com/en/faq/`. FAQPage shēmā uzskaitiet jautājumus kā `mainEntity` ar `@type: Question` un atbilstošo atbildi kā `acceptedAnswer`. Katram jautājumam papildus var pievienot `inLanguage`, taču tas ir lieki, ja ir marķēta visa lapa. Saglabājiet jautājumu skaitu lapā ne vairāk kā 10–15, jo meklētājprogrammas ņem vērā tikai ierobežotu ierakstu skaitu.

Rīcības ieteikums: Izmantojiet satura pārvaldības sistēmu, kas katram FAQ ierakstam nodrošina daudzvalodu lauku. JSON-LD izvadē dinamiski iegūstiet pašreizējo valodu. Validējiet katru valodas versiju atsevišķi ar Rich Results Test un pievērsiet uzmanību brīdinājumiem par trūkstošiem `name` atribūtiem jautājumiem. Katram jautājumam pievienojiet `url`, kas norāda uz konkrēto enkuru – tā lietotāji var pāriet tieši uz atbilstošo atbildi.

Ņemiet vērā: FAQPage ir piemērota tikai lapām ar skaidriem jautājumiem un atbildēm. Neizmantojiet to vispārīgām atbalsta lapām. Pēc izvietošanas pārbaudiet redzamību Google meklēšanā – FAQ bagātinātie fragmenti bieži parādās vaicājumos ar jautājuma partikulām. Daudzvalodu SEO gadījumā ir vērts pielāgot atbildes vietējai valodai (piem., „Kā es varu?” vs. „Comment puis-je?”).

InLanguage nianses: valodas kods un reģiona iestatījums

Atribūts `inLanguage` Schema.org norāda satura valodu, kur vērtība ideālā gadījumā sastāv no valodas koda (ISO 639-1) un neobligāta reģiona koda (ISO 3166-1 Alpha-2) – piem., `en-US` amerikāņu angļu valodai. Reģions ir svarīgs, ja saturs atšķiras: „colour” vs. „color” vai atšķirīgas mērvienības. Bez reģiona kods tiek interpretēts kā vispārīga valoda. Tāpēc izmantojiet `de-DE`, `de-AT`, `de-CH` valstij specifiskām lapām, pat ja teksts ir gandrīz identisks.

Praktisks piemērs: Produkts tiek piedāvāts Vācijas un Austrijas lapās. Valoda ir vācu, bet cenas un piegādes nosacījumi atšķiras. Iestatiet `inLanguage: "de-DE"` Vācijas lapai un `"de-AT"` Austrijas lapai. Tā Google var labāk saprast reģionālo atbilstību. Tas pats attiecas uz `en-GB` un `en-US`. Ja nav nepieciešama reģionālā atšķiršana, pietiek ar `"de"` vai `"en"`. Tomēr pārliecinieties, ka valodas kods vienmēr ir rakstīts ar mazajiem burtiem un reģions ar lielajiem burtiem (piem., `fr-CA`).

Bieža kļūda ir `inLanguage` izmantošana augstāka līmeņa objektā, kamēr apakšobjektiem ir cita valoda. Piemērs: WebSite vācu valodā, bet viens raksts angļu valodā. Tad iestatiet `inLanguage: "de"` uz WebSite un `inLanguage: "en"` uz Article. Validējiet to ar shēmas validatoru, jo daži rīki ziņo par konfliktiem. Daudzvalodu lapām ar hreflang tagiem `inLanguage` jāatbilst attiecīgajai hreflang vērtībai – tas palīdz Google piegādāt pareizo versiju.

Praktiskā īstenošana: Definējiet katras valodas versijai unikālu `@id` un konsekventi iestatiet `inLanguage`. Izmantojiet centrālo konfigurācijas failu, kas satur pareizos kodus katrai valodai. Pārbaudiet ar schema.org rīku, vai `inLanguage` tags tiek pieņemts. Padoms: Neaizmirstiet `inLanguage` arī AMP lapās vai strukturētajos datos, izmantojot mikro-datus. JSON-LD novietojiet to augstākajā līmenī (piem., `WebSite` vai `WebPage`). Dinamiskiem saturiem, piemēram, emuāra rakstiem, `inLanguage` var atšķirties atkarībā no ieraksta – tad iestatiet to katram vienumam.

Pareizi marķēt daudzvalodu vienā URL

Ja URL satur saturu vairākās valodās – piemēram, izmantojot valodu pārslēdzējus, cilnes vai akordeonu –, strukturētajos datos ir skaidri jānorāda, kurš teksts pieder kurai valodai. Pretējā gadījumā meklētājprogrammas indeksēšanas robots var kļūdaini pieņemt, ka viss saturs ir vienā valodā, kas rada kļūdas indeksēšanā un attēlošanā.

Pamatmetode ir `inLanguage` atribūta izmantošana atbilstošajos elementos. Ja lapā ir FAQ shēma ar jautājumiem un atbildēm vācu un angļu valodā, katrs jautājums un atbilde tiek atzīmēti atsevišķi: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Tas pats attiecas uz produktu shēmām: aprakstiet `name` un `description` katrai valodai atsevišķā `Product` objektā ar atsevišķu `inLanguage`, vai izmantojiet `@language` un `@value` `multilingualDescription` rekvizītā (ja jūsu vārdu krājums to atbalsta).

Organizācijām ar daudzvalodu nosaukumiem izmantojiet `name` objektu masīvu: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Izvairieties deklarēt visu lapu kā daudzvalodu. Tā vietā veiciet valodas piešķiršanu pēc iespējas detalizētāk. Bieži sastopama kļūda ir `inLanguage` iestatīšana tikai shēmas augstākajā līmenī, neatzīmējot apakšējos elementus. Tāpēc validācijas darbplūsmā pārbaudiet, vai visi teksti ir pareizi atzīmēti pēc valodas.

Kā konkrētu rīcības ieteikumu: katrai valodas versijai vienā URL izveidojiet atsevišķu shēmas objektu, kas satur tikai šīs valodas tekstus, un iestatiet `inLanguage` uz atbilstošo valodas kodu. Ja lapa pēc noklusējuma rāda galveno valodu, bet pārējās ielādē, izmantojot JavaScript, ievietojiet strukturētos datus visām valodām statiski HTML. Tādi rīki kā Google Rich Results Test parādīs, vai atzīmēšana ir pareizi interpretēta. Pārbaudiet katru valodas versiju atsevišķi, piespiežot indeksēšanas robotu uz vēlamo valodu, izmantojot URL parametru vai sīkfailu vadību.

Hreflang un inLanguage atšķirība: Kad izmantot kuru metodi?

`hreflang` un `inLanguage` kalpo dažādiem mērķiem starptautiskajā SEO un tos nevajadzētu jaukt. `hreflang` ir HTML elements vai HTTP galvene, kas meklētājprogrammām signalizē par alternatīvām valodas vai reģiona versijām tai pašai lapai. Tas nodrošina pareizas lapas piegādi lietotājiem dažādās valstīs vai ar noteiktiem valodas iestatījumiem. Savukārt `inLanguage` ir atribūts strukturētajos datos (Schema.org), kas norāda valodu, kurā ir uzrakstīts konkrēts teksta elements.

Kad izmantot ko? Izmantojiet `hreflang`, ja jums ir atsevišķi URL dažādām valodas versijām (piem., `example.com/de/` un `example.com/en/`). Tādējādi novēršat dublēta satura problēmas un nodrošināt, ka fragmentā tiek rādīta pareizā lapa. `inLanguage` ir nepieciešams, ja vienā URL atzīmējat daudzvalodu saturu vai ja strukturēts datu elements, piemēram, produkta apraksts, ir vairākās valodās. Tātad `inLanguage` papildina `hreflang` atsevišķu teksta bloku līmenī.

Bieži sastopams pārpratums: `inLanguage` neaizstāj `hreflang`. Pat ja atzīmējat katru raksta rindiņu ar `inLanguage`, meklētājprogrammas bez `hreflang` nezina, vai ir alternatīvas visas lapas versijas. Un otrādi, `hreflang` nav pietiekams, lai detalizēti aprakstītu daudzvalodu saturu viena URL ietvaros. Praksē tas nozīmē: ja jums ir atsevišķas lapas katrai valodai, primāri nepieciešams `hreflang`, savukārt `inLanguage` šajās lapās norāda konkrēto satura valodu strukturētajos datos. Ja vienā URL ir vairākas valodas, obligāti nepieciešams `inLanguage` katram valodas specifiskam elementam.

Konkrēts ieteikums: Plānojiet savu URL stratēģiju pirms ieviešanas. Izlemiet, vai katrai valodai izmantot atsevišķu URL (ccTLD, apakšdomēnu, apakšdirektoriju) vai kopīgu URL ar dinamisku valodas maiņu. Pēdējā gadījumā ir būtiska pareiza `inLanguage` atzīmēšana. Jebkurā gadījumā pārbaudiet, vai jūsu `hreflang` tagi norāda uz visām atbilstošajām valodas versijām un nav pretrunu ar `inLanguage` norādēm strukturētajos datos. Šo divu signālu saskaņošana var palīdzēt meklētājprogrammām pareizi klasificēt jūsu saturu.

Validācijas darbplūsma: Rīki un automatizētas pārbaudes

Manuāla strukturēto datu pārbaude katrā valodas versijā ir kļūdaina un laikietilpīga. Automatizēts validācijas darbplūsma nodrošina, ka jūsu Schema.org marķējumi ir pareizi un paliek tādi – arī pēc satura atjauninājumiem vai jaunu valodu pievienošanas. Svarīgākie rīki ir Google Rich Results tests (Google atbalstītajiem tipiem, piemēram, FAQ, Product) un Schema.org Validators (tīrai sintakses pārbaudei). Papildus palīdz tīmekļa pārlūkošanas rīki, piemēram, Screaming Frog SEO Spider, lai iegūtu strukturētos datus visā jūsu vietnē un pārbaudītu kļūdas.

Iekļaujiet pārbaudi savā CI/CD procesā: pēc katra izvietošanas vai valodas atjauninājuma veiciet automatizētu testa palaišanu. Izmantojiet Google Rich Results testa API vai skriptu, kas analizē jūsu lapas un pārbauda JSON-LD blokus pret jūsu definēto shēmu. Īpaši pievērsiet uzmanību šādiem kļūdu avotiem: - Trūkstošs `inLanguage` vietās, kur sastopamas vairākas valodas. - Pretrunīgi valodu kodi (piem., “de” nevis “de-DE” reģionālām variācijām). - Nepilnīgi obligātie lauki (piem., `name` produktam katrā valodā). - Novecojuši `hreflang` tagi, kas vairs neatbilst jūsu aktuālajiem URL.

Konkrēta rīcības rekomendācija: Katram Schema tipam (Organization, Product, FAQ) izveidojiet kontrolsarakstu ar nepieciešamajiem atribūtiem katrai valodai. Izmantojiet testēšanas rīku, piem., `json-schema`, lai automātiski validētu savus datus. Regulāri (piem., reizi mēnesī) veiciet pilnu pārlūkošanu ar Schema.org Validatoru un ģenerējiet pārskatus par kļūdainām lapām. Dokumentējiet kļūdu kategorijas un norīkojiet atbildīgos par labojumiem. Ņemiet vērā, ka strukturētie dati jāpārbauda tiešsaistes lapās – tests testa vidē nav pietiekams, jo tur var būt atšķirīgs saturs. Tikai tā nodrošināsiet, ka meklētājprogrammu kļūdas tiek savlaicīgi novērstas.

Biežākās kļūdas starptautiskajos strukturētajos datos

Vairākvalodu vietņu marķēšana ar Schema.org satur tipiskas kļūmes. Bieža kļūda ir valodas atribūta `inLanguage` trūkums vai nepareiza norāde. Piemēram, ja piedāvājat produktu vācu valodā, bet marķējumā nenorādāt `inLanguage: "de-DE"`, meklētājprogrammas var interpretēt datus kā valodneitrālus. Vēl viena pamatkļūda ir valodu sajaukšana vienā Schema blokā. Tāpēc jāizvairās no `Product` objektā `name` īpašības iestatīšanas angļu valodā un `description` vācu valodā. Tā vietā katrai valodas versijai jāizveido atsevišķs bloks ar pareizu `inLanguage`.

Vēl viena izplatīta kļūda ir nepiemērotu Schema tipu izmantošana. Daudzi vairākvalodu uzņēmumi kļūdaini izvēlas `LocalBusiness`, lai gan pareizā izvēle ir `Organization`, ja nav fiziskās adreses katrā valodā. Arī produktiem bieži tiek aizmirsts marķēt `offers` īpašību valodas specifikā. Turklāt pēc tulkojumiem netiek atjaunināti strukturētie dati: jauns tulkots produkta teksts ir jāpielāgo arī marķējumā – pretējā gadījumā meklēšanas rezultātos tiks rādīta novecojusi vai nepareiza informācija.

Validācijas neievērošana ir vēl viena galvenā kļūda. Pēc katrām izmaiņām marķējumi jāpārbauda ar atbilstošiem rīkiem. Kļūdainas vai trūkstošas `@id` atsauces entitātēm, kas ir vienādas visās valodās (piem., organizācija), noved pie dublikātiem vai nepilnīgiem datiem. Tāpat bieži tiek ignorēta mijiedarbība ar `hreflang`: ja nav alternatīvu URL, jāstrādā ar `inLanguage` tajā pašā lapā.

Rīcības rekomendācijas: Pārbaudiet katru marķējumu, vai tam ir pareiza valodas piešķire. Katrai valodas versijai izmantojiet atsevišķus Schema blokus ar unikāliem `@id`. Izvairieties no sajaukšanas – arī `aggregateRating` vai `review` valodai jābūt pareizai. Pēc katra tulkojuma veiciet atkārtotu validāciju un salīdziniet datus ar redzamo saturu. Tikai tā nodrošināsiet, ka meklētājprogrammas pareizi saprot jūsu vairākvalodu piedāvājumus.

Testēšana ar Google Rich Results, Bing Webmaster Tools un Yandex

Daudzvalodu Schema.org iezīmju pārbaude nedrīkst aprobežoties tikai ar vienu rīku. Katrai meklētājprogrammai ir savas interpretācijas un validācijas kritēriji. Google Rich Results tests ir pirmais solis: ievadiet URL ar savu iezīmi vai iekopējiet kodu tieši. Pievērsiet uzmanību visām kļūdām un brīdinājumiem – īpaši, vai `inLanguage` norādes tiek pareizi atpazītas. Bieža problēma ir, ka Google pieņem `de-DE`, bet, ja trūkst reģiona daļas (`de`), tomēr izdod brīdinājumu. Pārbaudiet katru valodas versiju atsevišķi.

Bing Webmaster Tools piedāvā URL pārbaudi ar strukturēto datu skatu. Šeit varat redzēt, vai Bing interpretē iezīmes kā paredzēts. Bing bieži ir stingrāks attiecībā uz `inLanguage` validāciju un, iespējams, obligāti pieprasa divburtu valodas kodu bez reģiona (piemēram, `de`, nevis `de-DE`). Veiciet tiešsaistes testu un labojiet novirzes. Bing arī parāda iespējamos dublējumus, ja `@id` vērtības tiek izmantotas vairākkārt.

Yandex Webmaster ir savs validatoris, kas ir īpaši svarīgs krievu valodas lapām. Arī šeit varat pārbaudīt strukturētos datus. Yandex atbalsta lielāko daļu Schema.org tipu, bet kļūdu apstrāde atšķiras. Īpaši `Product` iezīmēm bieži tiek kritizēts `availability` rekvizīts. Tāpēc pārbaudiet arī šeit katru valodas versiju. Ņemiet vērā, ka Yandex var atšķirīgi vērtēt reģionālos valodu kodus, piemēram, `de-DE`.

Rīcības ieteikumi: pēc ieviešanas un pēc katrām izmaiņām pārbaudiet katru valodas versiju visos trijos rīkos. Pierakstiet novirzes un pielāgojiet iezīmes tā, lai tās pieņemtu visas trīs meklētājprogrammas. Ideālā gadījumā izmantojiet divburtu valodas kodu (`de`, `en`) `inLanguage`, jo tas ir vienādi saprotams lielākajai daļai sistēmu. Automatizējiet testus ar CI rīkiem, lai daudzvalodu vietnēs ar daudzām lapām saglabātu pārskatu.

Kontrolsaraksts daudzvalodu Schema.org iezīmju ieviešanai

Strukturēta pieeja novērš tipiskas kļūdas internacionalizācijā. Pirms ieviešanas jānosaka valodas stratēģija: vai izmantot atsevišķus URL katrai valodai (piemēram, `/de/produkt` un `/en/product`) vai vienu URL ar valodas pārslēgšanu? Atsevišķiem URL izmantojiet `hreflang` un katram URL atsevišķu iezīmi. Vienam URL iestatiet vairākus `inLanguage` blokus ar dažādiem valodu kodiem. Plānojiet arī, kādi Schema veidi ir nepieciešami: uzņēmums (Organization), produkti (Product), FAQ (FAQPage) utt.

Ieviešanas laikā pievērsiet uzmanību šādiem punktiem: katrs Schema objekts saņem unikālu `@id`, kas identificē entitāti neatkarīgi no valodas. Katrai valodas versijai izveidojiet atsevišķu objektu, kas ar `inLanguage` norāda valodu. Izmantojiet konsekventus valodu kodus – vēlams divburtu ISO kodu (piemēram, `de`, `en`) papildinot ar reģionu, ja nepieciešams. Pareizi saistiet iezīmes: `Organization` izmantojiet `url` un `logo` ar valodai specifiskiem ceļiem. Pārbaudiet, vai teksti, piemēram, `name` un `description`, atbilst redzamajam saturam.

Pēc ieviešanas seko validācija: pārbaudiet katru valodas versiju ar Google Rich Results testu, Bing Webmaster Tools un Yandex. Labojiet kļūdas un brīdinājumus. Īpaši pievērsiet uzmanību trūkstošajiem `inLanguage` vai nepareiziem valodu kodiem. Izmantojiet arī Google Schema.org validācijas rīku, lai pārbaudītu sintaksi. Dokumentējiet visas izmaiņas un pēc katras tulkošanas veiciet atkārtotus testus.

Visbeidzot, process ietver arī monitoringu: sekojiet līdzi sniegumam Search Console, īpaši strukturēto datu pārskatiem. Reaģējiet uz jaunām kļūdām vai brīdinājumiem. Atjauniniet iezīmes savlaicīgi, ja maināt vai tulkojat saturu. Veiciet regulāras revīzijas, lai nodrošinātu konsekvenci visās valodas versijās. Labi uzturēta Schema.org ieviešana uzlabo redzamību meklēšanas rezultātos – bez garantijām, bet ar praktisku ieguvumu.

Juridiski paziņojumi: Pašatbildība automātiskā tulkojumā

Strukturētu datu automātiskā tulkošana rada juridiskus riskus, kas jums kā daudzvalodu vietnes operatoram ir jāpārbauda pašatbildīgi. Jo īpaši Schema.org iezīmējumos, kas satur juridiski nozīmīgu saturu, piemēram, produktu drošības norādījumus, vispārīgos noteikumus vai preču zīmju apzīmējumus, neprecīzs tulkojums var izraisīt atbildības gadījumus. Piemēram, nepareizi tulkots produkta nosaukums vai maldinošs produkta apraksts var pārkāpt konkurences tiesības. Tāpēc mēs iesakām visus automātiski izveidotos tulkojumus likt pārlasīt dzimtās valodas speciālistam. Tas īpaši attiecas uz laukiem, piemēram, "description" Product shēmā vai "answer" FAQ shēmā, kur nianses ir izšķirošas.

Papildus satura pareizībai svarīgi ir arī datu aizsardzības aspekti: ja jūsu shēma satur personas datus (piemēram, klientu atsauksmes Review shēmā), jums jānodrošina, ka tulkojums atbilst VDAR prasībām. Automātiskos tulkošanas pakalpojumus drīkst izmantot tikai tad, ja pakalpojums sniedz pietiekamas datu aizsardzības garantijas. Vispārēja aizlieguma nav, taču atbildība par datu apstrādi gulstas uz jums kā vietnes operatoru. Konsultējieties ar juridisko konsultantu par īpašajām prasībām jūsu mērķa valstīs.

Vēl viens juridisks slazds: "inLanguage" izmantošana ar neatļautiem valodu kodiem. Vienmēr izmantojiet oficiālos BCP-47 kodus (piemēram, "de-DE", nevis "deutsch"). Kļūdaini kodi var novest pie tā, ka meklētājprogrammas ignorē jūsu iezīmējumus – tas gan nav juridiska problēma, bet ietekmē atrodamību. Tāpēc pirms publicēšanas veiciet validāciju ar rīkiem, piemēram, Google Rich Results Test, un papildus pārbaudiet, vai tulkojumi pareizi aptver visus juridiski nozīmīgos laukus.

Rīcības ieteikums: definējiet darbplūsmu, kurā katru automātiski tulkoto shēmas iezīmējumu pārbauda dzimtās valodas redaktors vai jurists. Dokumentējiet šo procesu, lai strīda gadījumā varētu pierādīt, ka esat pildījis savu pienākumu. Atturieties no automātiskas tulkošanas tekstu blokiem ar juridisku raksturu (piemēram, garantijas nosacījumi, atbildības atrunas); tulkojiet tos manuāli vai ar speciālista palīdzību.

Perspektīva: uz mākslīgo intelektu balstīta lokalizācija un nākotnes shēmas izstrādes

Schema.org iezīmējumu lokalizāciju arvien vairāk atvieglo uz mākslīgo intelektu balstīti rīki. Pašreizējās sistēmas, izmantojot neironu tīklus, var izveidot tulkojumus, kas ir kontekstuāli precīzāki nekā vecākas statistikas metodes. Daudzvalodu vietnēm tas nozīmē: jūs varat ātrāk pārnest lielus produktu datu vai FAQ satura apjomus vairākās valodās. Tomēr kvalitātes nodrošināšana joprojām ir izšķiroša, jo MI modeļi ne vienmēr pareizi uztver nozarei specifiskus terminus vai reģionālās nianses. Praktiska pieeja ir izmantot MI neapstrādātam tulkojumam, kam seko cilvēka pārbaude. Tādi rīki kā Baduno apvieno MI tulkošanu ar dzimtās valodas pārbaudi, piedāvājot mērogojamu risinājumu.

Paralēli MI attīstībai Schema.org nepārtraukti paplašina savu vārdnīcu. Nākotnes veidi varētu vairāk pievērsties MI ģenerētam saturam, piemēram, "AIContent" shēmai, lai apzīmētu mašīnveidotus tekstus. Arī sasaiste ar zināšanu grafiem kļūs svarīgāka: nākotnē daudzvalodu iezīmējumus varētu automātiski ģenerēt no centrālajām zināšanu bāzēm. Jau tagad ir pieejams "translationOfWork" rekvizīts, kas skaidri norāda saistību starp tulkotajiem saturiem. Mēs iesakām šādas jaunas īpašības laikus iekļaut savā stratēģijā, lai būtu gatavi meklētājprogrammu atjauninājumiem.

Vēl viena tendence ir dinamiski, valodai specifiski iezīmējumi, kas tiek rādīti, pamatojoties uz lietotāja kontekstu. Piemēram, Product shēma atkarībā no lietotāja atrašanās vietas var ietvert vietējo valūtu un mērvienību. Izaicinājums ir pareizi lietot "inLanguage" un izvairīties no konfliktiem ar hreflang. Nākotnes shēmas versijas varētu skaidrāk definēt, kā shēmas ietvaros attēlot reģionālās variācijas. Lai tam sagatavotos, jums jāveido iezīmējumi modulāri: katrai valodai izmantojiet atsevišķus blokus vienā JSON-LD vai atsevišķus skriptu tagus katrai valodas versijai – atkarībā no tehniskās infrastruktūras.

Rīcības ieteikums: testējiet uz MI balstītus tulkošanas risinājumus ar reprezentatīvu savu shēmas datu kopu un izmēriet kļūdu īpatsvaru. Sekojiet līdzi Schema.org laidienu piezīmēm, lai identificētu jaunas īpašības. Pilotprojektā izmēģiniet dinamisku iezīmējumu rādīšanu dažādām mērķauditorijām un validējiet rezultātus, izmantojot svarīgāko meklētājprogrammu Search Console. Tādējādi jūs nodrošināsiet, ka jūsu daudzvalodu vietne gūst labumu no nākotnes attīstības, neuzņemoties juridiskus vai tehniskus riskus.

Praktisks piemērs: daudzvalodu produkta lapas pakāpeniska ieviešana

Lai teorētiskos pamatus pielietotu praksē, apskatīsim fiktīvu e-komercijas vietni, kas piedāvā viedtālruni vācu, angļu un franču valodā. Pieņemsim, ka produkta lapa ir pieejama zem viena URL ar valodas pārslēdzēju (piem., example.com/smartphone). Mērķis ir iezīmēt Schema.org Product iezīmējumu ar valodai specifisku informāciju.

1. **Valodu kodu noteikšana**: Katrai valodas versijai tiek izmantots unikāls inLanguage vērtības. Piemērs: vācu: "de-DE", angļu: "en-US", franču: "fr-FR".

2. **Nosaukuma un apraksta valodai specifiska iezīmēšana**: JSON-LD iezīmējumā tiek izmantots @graph masīvs. Katrai valodas versijai tiek piešķirts savs produkta objekts ar attiecīgo inLanguage. Piemērs: ```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. **Iezīmējuma validēšana**: Ar Google Rich Results Test tiek pārbaudīts, vai katrai valodas versijai iezīmējums tiek pieņemts. Jāuzmanās, lai inLanguage norādes atbilstu lapas faktiskajai valodai.

4. **Iekļaušana, izmantojot servera pusi vai JavaScript**: Praksē iezīmējumu vislabāk ģenerēt servera pusē, lai lapas pirmkods saturētu pilnu JSON-LD. Dinamisku valodas maiņu gadījumā, izmantojot JavaScript, iezīmējumu var ielādēt vēlāk, taču meklētājprogrammas to, iespējams, neuztvers.

5. **Redzamības pārbaude**: Pēc ieviešanas tiek pārbaudīts, vai Google Search Console ziņo par strukturētajiem datiem kā derīgiem un vai bagātinātie rezultāti parādās meklēšanā.

Šis soli pa solim piemērs parāda, kā rīkoties konkrēti. Pielāgojiet struktūru savai tehnoloģijai un pārbaudiet katru valodas versiju atsevišķi.

Sadarbība ar tulkošanas un lokalizācijas pakalpojumu sniedzējiem

Ieviešot daudzvalodu strukturētos datus, bieži sadarbojaties ar tulkotājiem vai lokalizācijas aģentūrām. Ir svarīgi, lai arī Schema.org iezīmējumi kļūtu par lokalizācijas procesa daļu. Pārrunājiet ar savu pakalpojumu sniedzēju, ka ir jātulko ne tikai redzamais saturs, bet arī vērtības JSON-LD (piem., "name", "description"). Bieža kļūda: aģentūra saņem tikai lapas tekstu, nevis strukturētos datus. Tāpēc nodrošiniet atsevišķu dokumentu ar visiem shēmas laukiem – ideālā gadījumā JSON formātā – un nosakiet, kuri lauki ir jātulko valodai specifiski (piem., "offers" vai "review" var palikt globāli, kamēr "name" atšķiras atkarībā no valodas).

Praktisks padoms: Izmantojiet glosārijus un tulkošanas atmiņas arī saviem strukturētajiem datiem. Tādējādi nodrošināsiet, ka produktu nosaukumi un tehniskie termini ir vienoti visos iezīmējumos. Lūdziet pakalpojumu sniedzējam iestatīt valodu kodus (inLanguage) atbilstoši jūsu norādēm – piemēram, "de-DE" nevis tikai "de". Pēc piegādes veiciet izlases pārbaudi, lai pārliecinātos, ka visi tulkotie lauku vērtības iezīmējumos ir pareizi. Automatizēts tests ar Google Rich Results Test var sniegt pirmās norādes.

Vēl viens aspekts: sadarbība kvalitātes nodrošināšanā. Vienojieties, ka pirms publicēšanas tulkotos shēmas datus pārlasa dzimtās valodas redaktors. Jo nepareizi tulkoti produktu atribūti vai norādījumi FAQ jautājumos var kaitēt starptautiskajam rangam. Dokumentējiet visu procesu – no avota tekstu izguves līdz ievietošanai – un atjauniniet savu kontrolsarakstu katrai valodas versijai. Tādējādi izvairīsieties no situācijas, kad vēlākos satura atjauninājumos strukturētie dati kļūst novecojuši.

Juridisks paziņojums: Atbildība par pareiziem tulkojumiem ir jūsu ziņā. Lūdziet rakstisku apstiprinājumu par jūsu norādījumu ievērošanu un vienojieties līgumiski par atbildību nepareizu tulkojumu gadījumā. Ieteicama neatkarīga juridiskā konsultācija.

Budžeta plānošana un izmaksu novērtēšana daudzvalodu shēmu ieviešanai

Strukturētu datu ieviešana vairākās valodās rada vienreizējas un pastāvīgas izmaksas. Papildus tīrajam iezīmēšanas satura tulkojumam rodas izmaksas par tehnisko integrāciju, testēšanu un uzturēšanu. Reālistiskai budžeta plānošanai jāņem vērā šādas pozīcijas:

1. Shēmas lauku tulkošana: Par katru valodas versiju rodas izmaksas par visu attiecīgo JSON-LD elementu (nosaukumi, apraksti, jautājumi, atbildes utt.) tulkošanu. Tā kā tie ir īsi, bieži vien tehniski teksti, tulkošanas aģentūras var piedāvāt īpašas cenas. Plānojiet 10–20% piemaksu par iedziļināšanos shēmas definīcijās.

2. Tehniskā pielāgošana: Iezīmēšana ir jāveic katrai valodai vai nu atsevišķos JSON-LD blokos, vai izmantojot daudzvalodu laukus. Atkarībā no sistēmas jūsu izstrādātāju komandai būs nepieciešams papildu laiks, lai ieviestu valodas maiņas un atkāpšanās loģiku. Pieredze rāda, ka sākotnējais darbs vietnei ar piecām valodas versijām ir no 15 līdz 25 cilvēkdienām izstrādē.

3. Testēšana un kvalitātes nodrošināšana: Katra valodas versija ir jāvalidē atsevišķi – ar Google Rich Results Test, Schema.org validatoriem un manuālām pārbaudēm. Plānojiet aptuveni 1–2 dienas katrai valodai sākotnējai iestatīšanai un pusstundu par katrām izmaiņām.

4. Pastāvīgā uzturēšana: Atjauninot produktu sortimentu vai FAQ saturu, arī iezīmēšana ir operatīvi jāpielāgo. Nosakiet, vai tulkošanas komanda vienmēr piegādā arī shēmas datus jaunajam saturam. Satura pārvaldības sistēma, kas automātiski ģenerē strukturētus datus, samazina ilgtermiņa izmaksas, taču tā ir attiecīgi jākonfigurē.

5. Rīki un licences: Ja izmantojat īpašus rīkus strukturēto datu uzraudzībai (piemēram, Webmaster Tools API vai savus informācijas paneļus), var rasties abonēšanas maksas.

Kā īkšķa likums, visam procesam (ieviešana trīs galvenajās valodās) jārēķinās ar budžetu no 5000 līdz 15 000 eiro atkarībā no vietnes apjoma un produktu skaita. Maziem projektiem ar dažām FAQ lapām summa var būt mazāka.

Juridisks paziņojums: Norādītie skaitļi ir tikai orientējoši. Lūdziet individuālus piedāvājumus no izstrādātājiem un tulkotājiem, un ņemiet vērā, ka faktiskās izmaksas var atšķirties atkarībā no sarežģītības. Lai iegūtu saistošus apgalvojumus, sazinieties ar savu juridisko un nodokļu konsultantu.