Rakenteellinen data kansainvälisesti: Schema.org kielirajojen yli

Johdatus jäsenneltyyn dataan monikielisille verkkosivuille

Schema.orgin mukaiset jäsennellyt tiedot auttavat hakukoneita ymmärtämään verkkosivustosi sisällön – ja tämä toimii kielirajojen yli. Kun käytössä on useita kieliversioita, oikeanlainen merkintä on entistä tärkeämpää. Hakukoneet, kuten Google, hyödyntävät jäsenneltyä dataa rikkaiden tulosten (rich results) näyttämiseen, kuten snippetit, tuotehinnat tai UKK-elementit. Monikielisillä sivuilla näiden merkintöjen on oltava kielikohtaisia, muuten voidaan toimittaa virheellisiä tietoja – esimerkiksi saksankielisen sivun puhelinnumero ranskankielisessä versiossa.

Tyypillinen virhe: yhden kielen schema kopioidaan muihin versioihin muuttamatta kielimerkintöjä. Pelkkä sisällön kääntäminen ei riitä; rakenteen on myös heijastettava kohdekieltä. Esimerkiksi schema-objektin inLanguage-kentässä tulee ilmoittaa kyseisen sivun kieli. Saksalainen tuotesivu saa arvon `inLanguage: 'de'`, englanninkielinen `inLanguage: 'en'`. Lisäksi voit käyttää `translationOfWork`-kenttää viittaamaan alkuperäiseen versioon.

Käytännössä aloita tärkeimmistä sivutyypeistä: Organisaatio, Tuote, UKK. Näitä käytetään eniten rich results -tuloksissa. Selvitä etukäteen, mitkä sivut milläkin kielellä ovat erityisen olennaisia. Kansainväliselle yrityssivustolle sopii Organization-schema, verkkokaupalle Product-schema. Varmista, että jokainen kieliversio saa oman JSON-LD-skriptinsä tai erilliset merkinnät skriptissä. Käytä työkaluja, kuten Google Rich Results Test, validoidaksesi jokaisen kieliversion erikseen. Huomaa, että testi antaa vain tilannekuvan – säännöllinen tarkistus on suositeltavaa.

Oikeudellisesti on huomioitava, että jäsennellyt tiedot eivät saa sisältää henkilötietoja, jotka rikkoisivat GDPR:ää. Eri maiden yhteystietoja ilmoitettaessa varmista, että tiedot ovat oikeita ja ajantasaisia. Ota tarvittaessa yhteyttä lakineuvojaan. Huolellisella monikielisten jäsenneltyjen tietojen toteutuksella parannat mahdollisuuksia tulla löydetyksi eri kielialueilla asiaankuuluvien rich results -tulosten avulla.

Schema.orgin perusteet ja kielimerkintä

Schema.org tarjoaa yhteisen sanastorakenteen, jota hakukoneet tukevat. Monikielisillä verkkosivustoilla oikea kielimerkintä on keskeistä. Jokaisella Schema-objektilla voi olla `inLanguage`-ominaisuus, joka ilmaisee sisällön kielen (esim. `'de'`, `'en'`, `'fr'`). Tämän merkinnän tulisi vastata sivun todellista kieltä. JSON-LD:ssä asetat `@language` joko koko dokumentille tai yksittäisille objekteille, jos kieliä on useita.

Esimerkki: Saksankieliselle tuotteelle käytä: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Jos merkitset saman tuotteen englanninkielisellä sivulla, käytä `"inLanguage": "en"` ja nimi englanniksi. Vältä useiden kieliversioiden sekoittamista yhdessä Schema-objektissa – se aiheuttaa epäjohdonmukaisuuksia. Käytä sen sijaan erillisiä merkintälohkoja kieltä kohti tai työskentele `@language`-taulukoiden kanssa objektin sisällä, jos kokonaisuus on monikielinen.

Verkkosivustokohtaisissa tiedoissa, kuten `WebSite` tai `WebPage`, sinun tulee myös ilmoittaa kieli. Jos sivulla on kielenvaihto, voit viitata muihin kieliversioihin `potentialAction`- tai `translationOfWork`-ominaisuuden avulla. Käytännössä on osoittautunut toimivaksi sijoittaa jokaiselle kielelle oma JSON-LD-lohko sivun vastaavaan head-osioon. Näin yhteys pysyy yksiselitteisenä ja validointityökalut tulkitsevat sen oikein.

Varmista, että kielikoodit noudattavat ISO-639-1-standardia (esim. "de" saksalle, "en" englanniksi). Alueellisille muunnelmille voit lisätä maatunnuksia, kuten "de-CH" sveitsinsaksalle. Tällöin sinun on tarkistettava, tukeeko hakukone tällaista tarkkaa erottelua – yleensä peruskielikoodi riittää. Validoi jokainen kieliversio erikseen Google Structured Data Testing Toolilla tai Rich Results Testillä. Huomioi mahdolliset varoitukset puuttuvista kielimerkinnöistä ja korjaa ne kohdennetusti.

Organization-Schema: Yritystiedot useilla kielillä

Organization-Schema on ihanteellinen yrityksille, joilla on monikielisiä verkkosivustoja, koska se tarjoaa keskeiset tiedot, kuten nimen, osoitteen ja yhteystiedot. Jokaiselle kieliversiolle tulisi luoda oma Organization-objekti, joka on merkitty kyseisellä kielellä. `name` tulee antaa kohdekielellä – eli „Muster GmbH” saksaksi ja „Sample Inc.” englanniksi. Jos yrityksellä on yhtenäinen nimi, riittää kuvauksen (`description`) kääntäminen.

Osoitteissa käytä `PostalAddress`-skeemaa, jossa on `addressCountry` ja `addressLocality`. Kansainvälisille toimipisteille voit varata useita `location`-merkintöjä. Varmista, että puhelinnumerot (`telephone`) sisältävät oikean maakoodin. Esimerkki: Saksan sivulle `+49 30 1234567`, Sveitsin sivulle `+41 44 1234567`. Sama koskee sähköpostiosoitteita ja aukioloaikoja. Käytä `areaServed`-ominaisuutta osoittamaan, missä maissa yritys toimii.

Usein unohdettu yksityiskohta on `sameAs`-ominaisuus sosiaalisen median profiileille. Lisää kielikohtaiset profiilit, jos niitä on – esimerkiksi saksankielinen Facebook-sivu ja englanninkielinen Twitter-läsnäolo. Myös `url` tulee viitata kielikohtaiseen etusivuun. Monikielisillä verkkosivustoilla voit käyttää `translationOfWork`-ominaisuutta luodaksesi yhteyden kieliversioiden välille, jos sivut sisältävät saman sisällön eri kielellä.

Käytännön suositus: Toteuta Organization-Schema jokaisen kieliversion etusivulle. Lisää tätä varten JSON-LD-skripti `<head>`-osioon. Vältä päällekkäisyyksiä luomalla jokaiselle kielelle oma lohko, jossa on asianmukainen `inLanguage`. Validoi merkintä Google Rich Results Testillä ja tarkista, että yhteystiedot näkyvät oikein. Oikeudellisesti sinun on huolehdittava, että annetut tiedot ovat täydellisiä ja tietosuojan mukaisia. Erityisesti useiden toimipisteiden tapauksessa: Impressum-velvollisuus voi vaihdella maittain. Ota tarvittaessa yhteyttä asianajajaan. Näiden yksityiskohtien avulla varmistat, että yrityksesi esitetään yhdenmukaisesti ja oikein kaikilla kielialueilla.

Product-Schema: Tuotekuvausten kielikohtainen merkitseminen

Monikielisillä verkkosivuilla tuotteiden merkitseminen Schema.org Product -mallilla kullakin kielellä on olennaista. Jokainen tuotteen kieliversio saa oman Schema-merkinnän, joka sisältää paikallisen nimen, kuvauksen ja ominaisuudet kuten hinnan, valuutan tai saatavuuden. Käytä `inLanguage`-attribuuttia kieltä kohden – esim. `"inLanguage": "de-DE"` saksalle (Saksa). Varmista, että tuotteen nimi ja kuvaus JSON-LD-objektissa ovat todella saksaksi, eikä vain kielitunniste.

Yleinen virhe on merkitä kaikki kieliversiot samalla `@id`:llä (esim. globaalilla tuotetunnuksella). Sen sijaan jokaiselle kielelle tulisi antaa oma `@id`, kuten `https://example.com/de/produkt/123` ja `https://example.com/fr/produit/123`. Näin Google voi näyttää oikean version. Hinnoissa käytä `priceCurrency`-attribuuttia ISO-4217-koodilla (esim. EUR, USD) ja ilmoita hinta kielikohtaisesti – vaikka hinta pysyisi samana, se kuuluu paikalliselle sivulle.

Käytännön suositus: Luo jokaiselle tuotteelle JSON-LD-malli, joka asettaa kieliparametrit dynaamisesti. Testaa jokainen kieliversio erikseen Googlen Rich Results Test -työkalulla. Varmista, että `url`-attribuutti osoittaa kyseiseen kieliversion URL-osoitteeseen. Vältä sekoittamasta kaikkia kieliä yhteen JSON-LD-lohkoon – tämä johtaa usein validointivirheisiin. Kuvien `image`-attribuutin voit pitää kieliriippumattomana, mutta varmista, että kuvien URL-osoitteet ovat oikein.

Lisäksi voit mukauttaa `offers`-osion `availability`-attribuuttia markkinan mukaan (esim. `InStock` Saksassa, `PreOrder` Ranskassa). Käytä `gtin`- tai `mpn`-attribuutteja maailmanlaajuisesti, mutta pidä `sku`-attribuutissa paikalliset variantit. Testaa lopuksi, että jokaisen kieliversion jäsennetyt tiedot indeksoitunevat oikein Search Consolessa.

FAQ-Skeema: Kysymys-vastaussivujen monikielinen optimointi

Monikieliset FAQ-sivut hyötyvät selkeästä, kielikohtaisesta merkinnästä FAQPage-skeemalla. Jokainen FAQ-sivun kieliversio saa oman JSON-LD-objektin. Aseta `inLanguage` vastaavalle kielikoodille (esim. `fr-FR` ranskalle). Kysymysten ja vastausten on oltava objektissa kohdekielellä – konekäännös ei usein riitä; anna äidinkielisen tarkistaa ne, koska vivahteet ovat ratkaisevia.

Tyypillinen virhe: sama `@id` kaikille kieliversioille. Käytä sen sijaan kielikohtaista URL-osoitetta `@id`:nä, esim. `https://example.com/de/faq/` ja `https://example.com/en/faq/`. FAQPage-skeeman sisällä listaa kysymykset `mainEntity`-kentässä `@type: Question` -tyyppisinä ja niihin liittyvät vastaukset `acceptedAnswer`-kentässä. Jokainen kysymys voi lisäksi saada `inLanguage`-attribuutin, mutta se on tarpeeton, jos koko sivu on merkitty. Pidä kysymysten määrä korkeintaan 10–15 sivulla, koska hakukoneet huomioivat vain rajallisen määrän.

Toimintasuositus: Käytä sisällönhallintajärjestelmää, joka tarjoaa monikielisyyskentän jokaiselle FAQ-tietueelle. JSON-LD-tulosteessa kysy dynaamisesti nykyistä kieltä. Validoi jokainen kieliversio erikseen Rich Results Test -työkalulla ja huomioi varoitukset puuttuvista `name`-ominaisuuksista kysymyksissä. Lisää jokaiselle kysymykselle `url`, joka osoittaa tarkkaan ankkuriin – näin käyttäjät voivat siirtyä suoraan oikeaan vastaukseen.

Huomio: FAQPage soveltuu vain sivuille, joilla on selkeitä kysymyksiä ja vastauksia. Älä käytä sitä yleisille tukisivuille. Testaa käyttöönoton jälkeen näkyvyys Googlen haussa – FAQ-rikasteiset katkelmat näkyvät usein kysymyspartikkeleita sisältävissä hauissa. Monikielisessä SEO:ssa kannattaa mukauttaa vastaukset kullekin maalle tyypillisiin ilmauksiin (esim. "Kuinka voin?" vs. "Comment puis-je?").

inLanguage-attribuutin hienoudet: Kielikoodi ja lokalisointi

Schema.orgin `inLanguage`-attribuutti ilmaisee sisällön kielen, ja arvon tulisi mielellään koostua kielikoodista (ISO 639-1) ja valinnaisesta aluetoimialueen koodista (ISO 3166-1 Alpha-2) – esim. `en-US` amerikanenglannille. Alue on tärkeä, jos sisällöt eroavat toisistaan: ”colour” vs. ”color” tai eri mittayksiköt. Ilman aluetta koodia tulkitaan yleiskielenä. Käytä siis `de-DE`, `de-AT`, `de-CH` maakohtaisille sivuille, vaikka teksti olisi lähes identtistä.

Käytännön esimerkki: Tuotetta tarjotaan saksalaisella ja itävaltalaisella sivulla. Kieli on saksa, mutta hinnat ja toimitusehdot eroavat. Aseta `inLanguage: "de-DE"` saksalaiselle sivulle ja `"de-AT"` itävaltalaiselle. Näin Google ymmärtää paremmin alueellista relevanssia. Sama koskee `en-GB` ja `en-US` -merkintöjä. Jos alueellista erottelua ei tarvita, riittää `"de"` tai `"en"`. Varmista kuitenkin, että kielikoodi on aina pienaakkosin ja alue isoilla kirjaimilla (esim. `fr-CA`).

Yleinen virhe on käyttää `inLanguage`-attribuuttia ylätason objektissa, kun alaobjekteilla on eri kieli. Esimerkki: WebSite saksaksi, mutta yksittäinen artikkeli englanniksi. Aseta tällöin `inLanguage: "de"` WebSite-objektiin ja `inLanguage: "en"` Article-objektiin. Validoi tämä Schema-validatorilla, sillä jotkut työkalut ilmoittavat ristiriidoista. Monikielisillä sivuilla, joissa on hreflang-tagit, `inLanguage` tulisi vastata kunkin hreflang-arvon kanssa – tämä auttaa Googlea tarjoamaan oikean version.

Käytännön toteutus: Määrittele jokaiselle kieliversiolle yksilöllinen `@id` ja aseta `inLanguage` johdonmukaisesti. Käytä keskitettyä konfiguraatiotiedostoa, joka sisältää oikeat koodit jokaiselle kielelle. Testaa schema.orgin työkalulla, hyväksytäänkö `inLanguage`-tagi. Vinkki: Älä unohda `inLanguage`-attribuuttia AMP-sivuilla tai Microdata-rakenteisissa tiedoissa. JSON-LD:ssä sijoita se ylimmälle tasolle (esim. `WebSite` tai `WebPage`). Dynaamisissa sisällöissä, kuten blogiartikkeleissa, `inLanguage` voi vaihdella artikkelin mukaan – aseta se tällöin jokaiselle kohteelle erikseen.

Monikielisyyden oikea merkitseminen yhdellä URL-osoitteella

Kun yksi URL-osoite sisältää sisältöä useilla kielillä – esimerkiksi kielivalitsimen, välilehtien tai accordionien kautta – sinun on merkittävä jäsennellyissä tiedoissa selkeästi, mikä teksti kuuluu millekin kielelle. Muutoin hakukoneen indeksoija saattaa virheellisesti olettaa, että kaikki sisältö on yhdellä kielellä, mikä johtaa indeksointi- ja esitysvirheisiin.

Perusmenetelmä on käyttää `inLanguage`-attribuuttia asiaankuuluvilla elementeillä. Kun samalla sivulla on FAQ-skeema, jossa on kysymyksiä ja vastauksia saksaksi ja englanniksi, merkitse jokainen kysymys ja vastaus erikseen: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Sama koskee Product-skeemoja: kuvaile `name` ja `description` jokaisella kielellä omassa `Product`-objektissa erillisellä `inLanguage`-attribuutilla, tai käytä `@language` ja `@value` -merkintöjä `multilingualDescription`-ominaisuudessa (jos sanasto tukee tätä).

Organisaatioille, joilla on monikielisiä nimiä, käytä `name`-objektien taulukkoa: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Vältä koko sivun julistamista monikieliseksi. Sen sijaan kielimääritys tulisi tehdä mahdollisimman tarkalla tasolla. Yleinen virhe on asettaa `inLanguage` vain skeeman ylimmälle tasolle merkitsemättä alaelementtejä. Tarkista siksi validointiprosessissasi, että kaikki tekstit on merkitty kielellisesti oikein.

Konkreettisena toimintasuosituksena: Luo jokaiselle kieliversiolle URL-osoitteessa erillinen skeemaobjekti, joka sisältää vain kyseisen kielen tekstit, ja aseta `inLanguage` vastaavalle kielikoodille. Jos sivu näyttää oletuksena pääkielen ja lataa muut kielet JavaScriptillä, tallenna jäsennellyt tiedot kaikille kielille staattisesti HTML:ään. Työkalut, kuten Googlen Rich Results Test, näyttävät, tulkitaanko merkintä oikein. Testaa jokainen kieliversio erikseen pakottamalla indeksoija haluttuun kieleen URL-parametrin tai evästeen avulla.

Hreflang- ja inLanguage-ero: Milloin kumpaakin menetelmää?

`hreflang` ja `inLanguage` palvelevat eri tarkoituksia kansainvälisessä SEO:ssa, eikä niitä pidä sekoittaa keskenään. `hreflang` on HTML-elementti tai HTTP-otsake, joka kertoo hakukoneille, että samasta sivusta on olemassa vaihtoehtoisia kieli- tai alueversioita. Sen avulla varmistetaan, että käyttäjille eri maissa tai tietyillä kieliasetuksilla näytetään oikea sivu. `inLanguage` puolestaan on strukturoidun datan (Schema.org) attribuutti, joka ilmaisee kielen, jolla tietty tekstielementti on kirjoitettu.

Milloin käytät kumpaakin? Käytä `hreflang`-tagia, jos sinulla on erilliset URL-osoitteet eri kieliversioille (esim. `example.com/de/` ja `example.com/en/`). Tällä estät päällekkäisen sisällön ongelmat ja varmistat, että oikea sivu näkyy hakutuloksessa. `inLanguage` on tarpeen, kun merkitset monikielistä sisältöä yhdellä URL-osoitteella tai kun strukturoitu datayksikkö, kuten tuotekuvaus, on saatavilla useilla kielillä. `inLanguage` täydentää siis `hreflang`-tagia yksittäisten tekstilohkojen tasolla.

Yleinen väärinkäsitys: `inLanguage` ei korvaa `hreflang`-tagia. Vaikka merkitsisit jokaisen artikkelin rivin `inLanguage`-attribuutilla, hakukoneet eivät ilman `hreflang`-tagia tiedä, onko koko sivusta olemassa vaihtoehtoisia versioita. Toisaalta `hreflang` ei riitä kuvaamaan monikielistä sisältöä yhden URL:n sisällä hienojakoisesti. Käytännössä tämä tarkoittaa: Jos sinulla on erilliset sivut jokaiselle kielelle, `hreflang` on ensisijaisesti tarpeen, kun taas `inLanguage` ilmoittaa strukturoidussa datassa sivun sisällön varsinaisen kielen. Jos samalla URL:lla on useita kieliä, tarvitset ehdottomasti `inLanguage`-attribuutin jokaiselle kielikohtaiselle elementille.

Konkreettinen suositus: Suunnittele URL-strategiasi ennen käyttöönottoa. Päätä, käytätkö erillistä URL-osoitetta kullekin kielelle (ccTLD, aliverkko, alihakemisto) vai yhteistä URL-osoitetta dynaamisella kielenvaihdolla. Jälkimmäisessä tapauksessa oikea `inLanguage`-merkintä on välttämätön. Varmista joka tapauksessa, että `hreflang`-tagisi viittaavat kaikkiin olennaisiin kieliversioihin eivätkä ole ristiriidassa strukturoidun datan `inLanguage`-merkintöjen kanssa. Näiden kahden signaalin yhteensovittaminen auttaa hakukoneita yhdistämään sisältösi oikein.

Validointityönkulku: Työkalut ja automaattiset tarkistukset

Strukturoidun datan manuaalinen tarkistus jokaisella kieliversiolla on virhealtista ja aikaa vievää. Automaattinen validointityönkulku varmistaa, että Schema.org-merkinnät ovat oikein ja pysyvät sellaisina – myös sisältöpäivitysten tai uusien kielten lisäämisen jälkeen. Tärkeimmät työkalut ovat Google Rich Results Test (Googlen tukemille tyypeille, kuten FAQ ja Product) ja Schema.org Validator (puhtaaseen syntaksitarkistukseen). Lisäksi crawlerit, kuten Screaming Frog SEO Spider, auttavat poimimaan strukturoidun datan koko verkkosivustoltasi ja tarkistamaan virheet.

Sisällytä tarkistus CI/CD-prosessiisi: Jokaisen käyttöönoton tai kielipäivityksen jälkeen suoritetaan automaattinen testiajo. Käytä tähän Google Rich Results Testin API:a tai skriptiä, joka jäsentää sivusi ja tarkistaa JSON-LD-lohkot itse määriteltyä skeemaa vasten. Kiinnitä erityistä huomiota seuraaviin virhelähteisiin: - Puuttuva `inLanguage` kohdissa, joissa esiintyy useita kieliä. - Ristiriitaiset kielikoodit (esim. "de" "de-DE":n sijaan aluekohtaisissa varianteissa). - Puutteelliset pakolliset kentät (esim. `name` tuotteella jokaisella kielellä). - Vanhentuneet `hreflang`-tagit, jotka eivät enää vastaa nykyisiä URL-osoitteitasi.

Konkreettinen toimintasuositus: Laadi jokaiselle skeematyypille (Organization, Product, FAQ) tarkistuslista tarvittavista attribuuteista kielittäin. Käytä testityökalua, kuten `json-schema`, datasi automaattiseen validointiin. Suorita lisäksi säännöllisesti (esim. kuukausittain) täydellinen crawlaus Schema.org-validatorilla ja luo raportteja virheellisistä sivuista. Dokumentoi virheluokat ja nimeä vastuuhenkilöt korjauksille. Huomaa, että strukturoitu data on tarkistettava live-sivuilta – testaus staging-ympäristössä ei riitä, koska siellä voi olla eri sisältöjä. Vain tällä tavoin varmistat, että hakukoneille tärkeät virheet korjataan ajoissa.

Yleiset virheet kansainvälisissä jäsennellyissä tiedoissa

Monikielisten verkkosivustojen merkitseminen Schema.orgilla sisältää tyypillisiä sudenkuoppia. Yleinen virhe on kielimääritteen `inLanguage` puuttuminen tai virheellinen ilmoittaminen. Jos esimerkiksi tarjoat tuotetta saksaksi, mutta et aseta merkintään `inLanguage: "de-DE"`, hakukoneet saattavat tulkita tiedot kielineutraaleiksi. Toinen perustavanlaatuinen virhe on kielten sekoittaminen saman Schema-lohkon sisällä. Vältä asettamasta `Product`-objektissa `name`-ominaisuutta englanniksi ja `description`-ominaisuutta saksaksi. Sen sijaan jokaiselle kieliversiolle tulee luoda oma lohko oikealla `inLanguage`-arvolla.

Toinen yleinen virhe on sopimattomien Schema-tyyppien käyttö. Monikielisessä yrityksessä monet käyttävät virheellisesti `LocalBusiness`-tyyppiä, vaikka `Organization` on oikea valinta, jos fyysistä osoitetta ei ole jokaisella kielellä. Myös tuotteiden kohdalla unohdetaan usein merkitä `offers`-ominaisuus kielikohtaisesti. Lisäksi jätetään päivittämättä rakenteiset tiedot käännösten jälkeen: uudelleenkäännetty tuoteteksti on päivitettävä myös merkintöihin – muuten hakutulokset näyttävät vanhentunutta tai virheellistä tietoa.

Validointilaiminlyönti on toinen kardinaalivirhe. Jokaisen muutoksen jälkeen tarkista merkinnät sopivilla työkaluilla. Virheelliset tai puuttuvat `@id`-viittaukset entiteeteissä, jotka ovat samat eri kielillä (esim. organisaatio), johtavat kaksoiskappaleisiin tai puutteellisiin tietoihin. Lisäksi usein jätetään huomioimatta yhteys `hreflang`-attribuuttiin: jos vaihtoehtoisia URL-osoitteita ei ole, sinun täytyy käyttää `inLanguage` samalla sivulla.

Toimenpidesuositukset: Tarkista jokaisesta merkinnästä oikea kielimääritys. Käytä jokaiselle kieliversiolle erillisiä Schema-lohkoja yksilöllisillä `@id`-tunnuksilla. Vältä sekoituksia – myös `aggregateRating`- tai `review`-ominaisuuden kielen on oltava oikea. Suorita jokaisen käännöksen jälkeen uusi validointi ja vertaa tietoja näkyvään sisältöön. Vain näin varmistat, että hakukoneet ymmärtävät monikieliset tarjouksesi oikein.

Testaa Google Rich Results, Bing Webmaster Tools ja Yandex

Monikielisten Schema.org-merkintöjen tarkistaminen ei pitäisi rajoittua yhteen työkaluun. Jokaisella hakukoneella on omat tulkintansa ja validointikriteerinsä. Google Rich Results Test on ensimmäinen paikka: syötä URL-osoite, jossa on merkintäsi, tai liitä koodi suoraan. Kiinnitä huomiota kaikkiin virheisiin ja varoituksiin – erityisesti siihen, tunnistetaanko `inLanguage`-määritykset oikein. Yleinen ongelma on, että Google hyväksyy `de-DE`:n, mutta antaa varoituksen, jos aluetunnus puuttuu (`de`). Testaa jokainen kieliversio erikseen.

Bing Webmaster Tools tarjoaa URL-tarkistuksen, jossa on rakenteisen datan näkymä. Täällä voit nähdä, tulkitseeko Bing merkinnät odotetusti. Bing on usein tiukempi `inLanguage`-validoinnissa ja saattaa edellyttää ehdottomasti kaksikirjaimista kielikoodia ilman aluetta (esim. `de` eikä `de-DE`). Suorita live-testi ja korjaa poikkeamat. Bing näyttää myös mahdolliset kaksoiskappaleet, jos `@id`-arvoja käytetään useita kertoja.

Yandex Webmasterilla on oma validaattori, joka on erityisen tärkeä venäjänkielisille sivustoille. Täälläkin voit testata rakenteista dataa. Yandex tukee useimpia Schema.org-tyyppejä, mutta virheiden käsittely eroaa. Erityisesti `Product`-merkinnöissä usein moititaan `availability`-ominaisuutta. Testaa siksi myös täällä jokainen kieliversio. Huomioi, että Yandex saattaa painottaa alueellisia kielikoodeja kuten `de-DE` eri tavalla.

Toimenpidesuositukset: Testaa jokainen kieliversio kaikissa kolmessa työkalussa toteutuksen jälkeen ja jokaisen muutoksen jälkeen. Merkitse poikkeamat ja säädä merkinnät niin, että kaikki kolme hakukonetta hyväksyvät ne. Käytä mieluiten kaksikirjaimista kielikoodia (`de`, `en`) `inLanguage`-kentässä, koska useimmat järjestelmät ymmärtävät sen samalla tavalla. Automatisoi testit CI-työkaluilla, jotta pysyt kärryillä monikielisillä sivustoilla, joilla on paljon sivuja.

Tarkistuslista monikielisten Schema.org-merkintöjen toteuttamiseen

Jäsennelty lähestymistapa estää tyypilliset kansainvälistymisen virheet. Ennen toteutusta tulee määrittää kielistrategia: käytätkö erillisiä URL-osoitteita kieltä kohti (esim. `/fi/tuote` ja `/en/product`) vai yhtä URL-osoitetta kielen vaihdolla? Erillisissä URL-osoitteissa käytä `hreflang`-attribuuttia ja omaa merkintää jokaiselle URL:lle. Yhdessä URL-osoitteessa käytä useita `inLanguage`-lohkoja eri kielikoodeilla. Suunnittele lisäksi, mitä skeematyyppejä tarvitaan: yritys (Organization), tuotteet (Product), UKK (FAQPage) jne.

Toteutuksessa kiinnitä huomiota seuraaviin seikkoihin: Jokainen skeemaobjekti saa yksilöllisen `@id`:n, joka tunnistaa entiteetin kielestä riippumatta. Luo jokaiselle kieliversiolle oma objekti, jossa `inLanguage` määrittää kielen. Käytä johdonmukaisia kielikoodeja – mieluiten kaksikirjaimista ISO-koodia (esim. `fi`, `en`) tarvittaessa täydennettynä alueella. Linkitä merkintöjen sisällä oikein: `Organization`-skeemassa käytä `url` ja `logo` -kenttiä kielikohtaisilla poluilla. Tarkista, että tekstit, kuten `name` ja `description`, vastaavat näkyvää sisältöä.

Toteutuksen jälkeen tulee validointi: testaa jokaista kieliversiota Google Rich Results Testillä, Bing Webmaster Toolsilla ja Yandexilla. Korjaa virheet ja varoitukset. Kiinnitä erityistä huomiota puuttuviin `inLanguage`-kenttiin tai virheellisiin kielikoodeihin. Käytä lisäksi Googlen Schema.org-validointityökalua syntaksin tarkistamiseen. Dokumentoi kaikki muutokset ja suorita uudet testit jokaisen käännöksen jälkeen.

Lopuksi seuranta kuuluu prosessiin: seuraa suorituskykyä Search Console -työkalussa, erityisesti raportteja jäsennellystä datasta. Reagoi uusiin virheisiin tai huomautuksiin. Päivitä merkintöjä ajoissa, kun muutat tai käännät sisältöä. Suorita säännöllisiä auditointeja varmistaaksesi yhdenmukaisuuden kaikissa kieliversioissa. Hyvin hoidettu Schema.org-toteutus parantaa näkyvyyttä hakukoneissa – ilman takuita, mutta käytännön hyödyin.

Oikeudelliset huomautukset: Oma vastuu automaattisessa käännöksessä

Jäsennellyn datan automaattinen kääntäminen sisältää oikeudellisia riskejä, jotka sinun monikielisen verkkosivuston ylläpitäjänä on omalla vastuullasi tarkistettava. Erityisesti Schema.org-merkintöjen kohdalla, jotka sisältävät oikeudellisesti merkityksellistä sisältöä kuten tuoteturvallisuustietoja, käyttöehtoja tai tuotemerkkejä, epätarkka käännös voi johtaa vastuutapauksiin. Esimerkiksi väärin käännetty tuotenimi tai harhaanjohtava tuotekuvaus voi rikkoa kilpailulainsäädäntöä. Suosittelemme siksi, että kaikki automaattisesti laaditut käännökset tarkistuttaa äidinkielisellä asiantuntijalla. Tämä koskee erityisesti kenttiä kuten "description" Product-skeemassa tai "answer" FAQ-skeemassa, joissa vivahteet ovat ratkaisevia.

Sisällön oikeellisuuden lisäksi myös tietosuojanäkökohdat ovat tärkeitä: Jos skeemasi sisältää henkilötietoja (esim. asiakasarvostelut Review-skeemassa), sinun on varmistettava, että käännös on GDPR:n mukainen. Automaattisia käännöspalveluita tulee käyttää vain, jos palvelu tarjoaa riittävät tietosuojatakuut. Yleistä kieltoa ei ole, mutta vastuu tietojenkäsittelystä on sinulla verkkosivuston ylläpitäjänä. Pyydä lakimieheltä neuvoja kohdemaidesi erityisvaatimuksista.

Toinen oikeudellinen kompastuskivi: "inLanguage"-kentän käyttö kielletyillä kielikoodeilla. Käytä aina virallisia BCP-47-koodeja (esim. "fi-FI" eikä "suomi"). Virheelliset koodit voivat johtaa siihen, että hakukoneet ohittavat merkintäsi – mikä ei sinänsä ole oikeudellinen ongelma, mutta heikentää löydettävyyttä. Suorita siksi ennen julkaisua validointi työkaluilla, kuten Google Rich Results Testillä, ja tarkista lisäksi, että käännökset kattavat kaikki oikeudellisesti merkitykselliset kentät oikein.

Toimenpidesuositus: Määrittele työnkulku, jossa jokainen automaattisesti käännetty skeemamerkintä tarkistetaan äidinkielisellä toimittajalla tai juristilla. Dokumentoi prosessi, jotta voit riitatilanteessa osoittaa noudattaneesi huolellisuusvelvollisuuttasi. Vältä oikeudellisen luonteen omaavien tekstilohkojen (esim. takuuehdot, vastuuvapauslausekkeet) automaattista kääntämistä; käännä ne manuaalisesti tai ammattipalvelun avulla.

Näkymät: Tekoälyavusteinen lokalisointi ja tulevat skeemakehitykset

Schema.org-merkintöjen lokalisointi helpottuu yhä enemmän tekoälypohjaisten työkalujen avulla. Nykyiset järjestelmät pystyvät neuroverkkojen avulla luomaan käännöksiä, jotka ovat kontekstuaalisesti tarkempia kuin vanhemmat tilastolliset menetelmät. Monikielisille verkkosivustoille tämä tarkoittaa: voit siirtää suuria määriä tuotetietoja tai usein kysyttyjä kysymyksiä nopeammin useille kielille. Laadunvarmistus on kuitenkin edelleen ratkaisevaa, koska tekoälymallit eivät aina tunnista alakohtaisia termejä tai alueellisia vivahteita oikein. Käytännöllinen lähestymistapa on käyttää tekoälyä raakakäännökseen, jota seuraa ihmisen tarkistus. Työkalut kuten Baduno yhdistävät tekoälykäännöksen äidinkielen tarkistukseen ja tarjoavat näin skaalautuvan ratkaisun.

Rinnakkain tekoälyn kehityksen kanssa Schema.org laajentaa jatkuvasti sanastoaan. Tulevaisuuden tyypit saattavat keskittyä enemmän tekoälyn tuottamaan sisältöön, esimerkiksi 'AIContent'-skeema, joka merkitsee koneellisesti luotuja tekstejä. Myös linkitys tietograafeihin tulee tärkeämmäksi: monikieliset merkinnät voitaisiin tulevaisuudessa luoda automaattisesti keskitetyistä tietokannoista. Jo nyt on olemassa 'translationOfWork'-ominaisuus, joka tekee käännössisältöjen välisen suhteen näkyväksi. Suosittelemme sisällyttämään tällaiset uudet ominaisuudet strategiaanne ajoissa, jotta olette valmiita hakukoneiden päivityksiin.

Toinen trendi ovat dynaamiset, kielikohtaiset merkinnät, jotka tarjoillaan käyttäjän kontekstin perusteella. Esimerkiksi tuoteskeema voi sisältää käyttäjän sijainnin mukaan paikallisen valuutan ja mittayksikön. Haasteena on 'inLanguage'-ominaisuuden oikea käyttö ja ristiriitojen välttäminen hrelflangin kanssa. Tulevat skeemaversiot saattavat määritellä selkeämmin, miten alueellisia variantteja voidaan esittää yhden skeeman sisällä. Valmistautuaksesi tähän, rakenna merkintäsi modulaarisesti: käytä jokaiselle kielelle erillisiä lohkoja samassa JSON-LD:ssä tai käytä erillisiä script-tageja kieliversioittain – teknisestä infrastruktuurista riippuen.

Toimenpidesuositus: testaa tekoälypohjaisia käännösratkaisuja edustavalla otoksella skeematietojasi ja mittaa virheprosentti. Pysy ajan tasalla Schema.org-julkaisutiedoista tunnistaaksesi uudet ominaisuudet. Pilotoi merkintöjen dynaamista tarjoilua eri kohderyhmille ja validoi tulokset tärkeimpien hakukoneiden Search Consoleilla. Näin varmistat, että monikielinen sivustosi hyötyy tulevista kehityksistä ilman oikeudellisia tai teknisiä riskejä.

Käytännön esimerkki: Monikielisen tuotesivun asteittainen toteutus

Jotta teoreettiset perusteet saadaan käytäntöön, tarkastelemme kuvitteellista verkkokauppasivustoa, joka tarjoaa älypuhelimen kielillä saksa, englanti ja ranska. Oletetaan, että tuotesivu on saatavilla yhdellä URL-osoitteella kielivalitsimella (esim. example.com/smartphone). Tavoitteena on merkitä Schema.org Product -merkintä kielikohtaisilla tiedoilla.

1. **Kielikoodien määrittäminen**: Jokaiselle kieliversiolle käytetään yksilöllistä inLanguage-arvoa. Esimerkki: Saksa: "de-DE", Englanti: "en-US", Ranska: "fr-FR".

2. **Nimen ja kuvauksen kielikohtainen merkintä**: JSON-LD-merkinnässä käytetään @graph-taulukkoa. Jokaiselle kieliversiolle luodaan oma tuoteobjekti vastaavalla inLanguage-arvolla. Esimerkki: ```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. **Merkinnän validointi**: Google Rich Results Testillä tarkistetaan jokaiselle kieliversiolle, hyväksytäänkö merkintä. On varmistettava, että inLanguage-arvot vastaavat sivun todellista kieltä.

4. **Sisällyttäminen palvelinpuolella tai JavaScriptillä**: Käytännössä merkintä on parasta luoda palvelinpuolella, jotta sivun lähdekoodi sisältää koko JSON-LD:n. Dynaamisissa kielenvaihdoissa JavaScriptin avulla merkintä voidaan ladata myöhemmin, mutta hakukoneet eivät välttämättä havaitse sitä.

5. **Näkyvyyden testaus**: Toteutuksen jälkeen tarkistetaan, ilmoitetaanko jäsennellyt tiedot Google Search Consolessa kelvollisina ja näkyvätkö rich results -tulokset haussa.

Tämä vaiheittainen esimerkki osoittaa, miten voit konkreettisesti edetä. Mukauta rakenne teknologiaasi ja testaa jokainen kieliversio erikseen.

Yhteistyö käännös- ja lokalisointipalveluntarjoajien kanssa

Kun toteutat monikielisiä jäsenneltyjä tietoja, teet usein yhteistyötä kääntäjien tai lokalisointitoimistojen kanssa. On tärkeää, että myös Schema.org-merkinnät sisällytetään lokalisointiprosessiin. Keskustele palveluntarjoajasi kanssa siitä, että pelkän näkyvän sisällön lisäksi myös JSON-LD-arvot (esim. "name", "description") on käännettävä. Yleinen virhe: toimisto saa vain sivun tekstin, mutta ei jäsenneltyjä tietoja. Toimita siksi erillinen asiakirja, jossa on kaikki Schema-kentät – mieluiten JSON-muodossa – ja määrittele, mitkä kentät käännetään kielikohtaisesti (esim. "offers" tai "review" voivat pysyä globaaleina, kun taas "name" vaihtelee kielen mukaan).

Käytännön vinkki: Käytä sanastoja ja käännösmuisteja myös jäsennellyille tiedoillesi. Näin varmistat, että tuotenimet ja ammattitermit esiintyvät yhtenäisesti kaikissa merkinnöissä. Pyydä lisäksi palveluntarjoajaa asettamaan kielikoodit (inLanguage) määrittelemäsi mukaisesti – esimerkiksi "de-DE" pelkän "de" sijaan. Toimituksen jälkeen sinun tulee pistokokein tarkistaa, että kaikki käännetyt kenttäarvot on tallennettu oikein merkintöihin. Googlen Rich Results Test -testi voi antaa ensimmäisiä viitteitä.

Toinen näkökohta: yhteistyö laadunvarmistuksessa. Sovi, että käännetyt Schema-tiedot luetetaan ennen julkaisua äidinkielisellä toimittajalla. Väärin käännetyt tuoteattribuutit tai FAQ-kysymysten ohjeet voivat vahingoittaa kansainvälistä sijoitusta. Dokumentoi koko prosessi – lähdetekstien erottamisesta käyttöönottoon – ja päivitä tarkistuslistasi jokaista kieliversiota varten. Näin vältät jäsenneltyjen tietojen vanhenemisen myöhemmissä sisältöpäivityksissä.

Oikeudellinen huomautus: Vastuu oikeista käännöksistä on sinulla. Pyydä kirjallinen vahvistus vaatimustesi noudattamisesta ja selvitä vastuukysymykset virheellisistä käännöksistä sopimuksella. Itsenäistä oikeudellista neuvontaa suositellaan.

Budjettisuunnittelu ja kustannusarvio monikieliselle Schema-toteutukselle

Jäsenneltyjen tietojen käyttöönotto useilla kielillä aiheuttaa kertaluonteisia ja jatkuvia kustannuksia. Pelkän merkintäsisällön kääntämisen lisäksi syntyy kuluja teknisestä integraatiosta, testauksesta ja ylläpidosta. Realistista budjettisuunnittelua varten sinun on otettava huomioon seuraavat erät:

1. Schema-kenttien käännös: Jokaisesta kieliversiosta aiheutuu kustannuksia kaikkien asiaankuuluvien JSON-LD-elementtien (otsikot, kuvaukset, kysymykset, vastaukset jne.) kääntämisestä. Koska kyse on lyhyistä, usein teknisistä teksteistä, käännöstoimistot voivat tarjota erikoishintoja. Varaa 10–20 % lisämaksu Schema-määritelmiin perehtymiseen.

2. Tekninen mukautus: Merkinnät on toteutettava kielikohtaisesti joko erillisinä JSON-LD-lohkoina tai monikielisten kenttien avulla. Järjestelmästä riippuen kehittäjätiimisi tarvitsee lisäaikaa kielenvaihto- ja varalogiikan toteuttamiseen. Kokemuksen mukaan viiden kieliversion verkkosivuston alkuasennus vie 15–25 henkilötyöpäivää kehityksessä.

3. Testaus ja laadunvarmistus: Jokainen kieliversio on validoitava erikseen – Google Rich Results Testillä, Schema.org-validaattoreilla ja manuaalisilla pistokokeilla. Varaa kieltä kohti noin 1–2 päivää ensimmäiseen asennukseen ja puoli tuntia muutosta kohden.

4. Jatkuva ylläpito: Tuotevalikoiman tai FAQ-sisällön päivitysten yhteydessä myös merkintöjä on mukautettava ajoissa. Päätä, toimittaako käännösryhmä uuden sisällön mukana aina Schema-tiedot. Sisällönhallintajärjestelmä, joka tuottaa jäsenneltyjä tietoja automaattisesti, vähentää pitkän aikavälin työmäärää, mutta vaatii asianmukaisen asennuksen.

5. Työkalut ja lisenssit: Jos käytät erityisiä työkaluja jäsenneltyjen tietojen seurantaan (esim. Webmaster Tools -rajapintoja tai omia hallintapaneeleja), niistä voi aiheutua tilausmaksuja.

Nyrkkisääntönä koko prosessille (käyttöönotto kolmella pääkielellä) kannattaa varata 5 000–15 000 euron budjetti sivuston laajuudesta ja tuotteiden määrästä riippuen. Pienissä projekteissa, joissa on vain muutama FAQ-sivu, summa voi olla pienempikin.

Oikeudellinen huomautus: Mainitut luvut ovat vain suuntaa-antavia. Pyydä kehittäjiltä ja kääntäjiltä yksilöllisiä tarjouksia ja ota huomioon, että todelliset kustannukset voivat vaihdella monimutkaisuuden mukaan. Sitoakseen lausuntoja varten käänny oikeudellisen ja veroneuvonnan puoleen.