Monikielisen WordPress-verkkosivuston rakentaminen: mitä yritysten on otettava huomioon

Johdanto

Verkkosivuston laajentaminen palvelemaan monikielistä yleisöä kuulostaa periaatteessa yksinkertaiselta. Käytännössä se edellyttää kuitenkin joukkoa teknisiä, sisältöön liittyviä ja strategisia päätöksiä, jotka yllättävät monet yritykset. Virheet noudattavat yleensä ennustettavia kaavoja, ja suurin osa niistä on helpompi välttää suunnitteluvaiheessa kuin korjata sivuston rakentamisen ja julkaisun jälkeen.

WordPress-kehitysyhtiö Cude Designin perustaja Wesley Cude on rakentanut monikielisiä WordPress-sivustoja asiakkaille ympäri Yhdistynyttä kuningaskuntaa ja kansainvälisesti. ”Monikielisen WordPress-sivuston teknistä puolta tukevat hyvin saatavilla olevat laajennukset”, hän sanoo. ”Projektit menevät yleensä pieleen juuri niissä päätöksissä, jotka tehdään ennen kuin yhtään riviä koodia on kirjoitettu. Mitkä kielet valitaan, millainen URL-rakenne otetaan käyttöön, kuka omistaa käännökset, miten sivusto käsittelee valuutta- ja alueellisia eroja. Näiden päätösten tekeminen oikein alusta alkaen säästää huomattavasti jälkikäteen tehtävää työtä.”

Tässä artikkelissa käsitellään monikielisen WordPress-verkkosivuston rakentamiseen liittyviä keskeisiä päätöksiä, käytettävissä olevia teknisiä lähestymistapoja sekä jatkuvia huomioitavia seikkoja, jotka määrittävät, palveleeko monikielinen sivusto todella kohdeyleisöjään tehokkaasti.

Oikean URL-rakenteen valinta

Ensimmäinen merkittävä päätös monikielisessä WordPress-projektissa on se, miten kunkin kieliversion URL-osoitteet rakennetaan. On olemassa kolme pääasiallista lähestymistapaa, ja jokaisella on vaikutuksia hakukoneoptimointiin (SEO), isännöintiin ja jatkuvaan hallintaan.

Alihakemistoissa kieliversiot erotetaan toisistaan kansiorakenteella, jossa pääkieli sijaitsee juurikansiossa ja muut kielet alihakemistoissa. Esimerkiksi britti-englanninkielinen versio voi sijaita osoitteessa domain.com, kun taas ranskankielinen versio sijaitsee osoitteessa domain.com/fr/. Tämä lähestymistapa pitää kaiken yhdellä verkkotunnuksella, mikä tarkoittaa, että verkkotunnuksen koko auktoriteetti koskee kaikkia kieliversioita. Se on yleisin lähestymistapa yrityksille, jotka laajentavat toimintaansa uusille kielille ilman vahvaa syytä käsitellä kutakin markkinaa täysin erillisenä kokonaisuutena.

Aliverkkotunnuksissa kukin kieliversio sijoitetaan omalle aliverkkotunnukselleen, kuten ranskankielinen versio osoitteeseen fr.domain.com. Hakukoneet käsittelevät aliverkkotunnuksia erillisinä kokonaisuuksina, joilla on oma auktoriteettinsa, mikä tarkoittaa, että uusi aliverkkotunnus aloittaa ilman kertynyttä auktoriteettia, vaikka pääverkkotunnuksella olisi vahvat sijoitukset. Tämän lähestymistavan hallinta on teknisesti monimutkaisempaa, ja se on yleensä järkevää vain silloin, kun on vahvoja syitä käsitellä kutakin kieltä aidosti erillisenä, kuten merkittävästi erilaiset sisältöstrategiat kullekin markkina-alueelle.

Maakooditason ylätason verkkotunnukset käyttävät erillisiä verkkotunnusrekisteröintejä jokaiselle maalle, kuten domain.fr Ranskalle tai domain.de Saksalle. Tämä lähettää hakukoneille vahvimman maantieteellisen signaalin ja voi olla tehokas ratkaisu yrityksille, joilla on merkittävä läsnäolo kullakin markkinalla. Se on myös kustannuksiltaan ja monimutkaisuudeltaan kallein vaihtoehto, sillä jokainen verkkotunnus tarvitsee käytännössä oman SEO-strategiansa ja linkkien rakentamisohjelmansa.

Useimmille yrityksille, jotka rakentavat monikielisen WordPress-sivuston ensimmäistä kertaa, alihakemistot ovat oikea lähtökohta. Ne ovat yksinkertaisimpia toteuttaa, pitävät kaiken auktoriteetin yhdellä verkkotunnuksella ja niitä on helppo laajentaa, kun uusia kieliä lisätään.

Laajennusten valinta ja konfigurointi

WordPressissä on kaksi hallitsevaa monikielistä laajennusta: WPML ja Polylang. Molemmat pystyvät käsittelemään monimutkaisia monikielisiä sivustoja, mutta niiden toteutustavat eroavat toisistaan, ja niillä on erilaiset vaikutukset sivuston suorituskykyyn ja jatkuvaan hallintaan.

WPML on monipuolisempi vaihtoehto. Se hoitaa käännösten hallinnan, teemojen ja laajennusten tekstien merkkijonojen käännökset, WooCommerce-yhteensopivuuden sekä monimutkaiset monikieliset asetukset, mukaan lukien oikealta vasemmalle kirjoitettavat kielet. Se integroituu käännöspalveluihin ammattimaisten käännösten tuottamiseksi ja tarjoaa yksityiskohtaisen hallinnan siitä, mikä sisältö käännetään ja miten. Haittapuolena on, että se on yksi raskaimmista laajennuksista tietokantakyselyjen kannalta ja voi vaikuttaa sivuston suorituskykyyn, ellei sitä konfiguroida huolellisesti suurilla sivustoilla.

Polylang on kevyempi vaihtoehto, joka hoitaa monikielisyyden ydintoiminnot vähemmällä kuormituksella. Sivustoille, jotka eivät tarvitse WPML:n kaikkia ominaisuuksia, se hoitaa käännöshallinnan suorituskykyä vähemmän rasittaen. Siitä on saatavilla ilmainen versio, jossa on merkittävät toiminnot, mikä tekee siitä järkevän lähtökohdan yksinkertaisemmille monikielisille projekteille.

Valinta näiden välillä riippuu sivuston monimutkaisuudesta, WooCommerce-integraatiovaatimuksista sekä käännöstyönkulusta, jota asiakas aikoo käyttää. Sivustolla, jolla on vain muutama staattinen sivu kahdella kielellä, on erilaiset vaatimukset kuin WooCommerce-verkkokaupalla, joka myy tuotteita viidellä eurooppalaisella markkinalla, joilla on kussakin erilaiset hinnat, arvonlisäverokannat ja maksuportaalivaatimukset.

Hreflang-toteutus

Hreflang on HTML-attribuutti, joka kertoo hakukoneille, mitä kieltä ja alueellista versiota sivusta kullekin käyttäjälle tulisi näyttää. Oikea hreflang-toteutus on olennaisen tärkeää monikieliselle hakukoneoptimoinnille (SEO) ja se on yksi alueista, joilla monikielisissä sivustoissa esiintyy yleisimmin virheitä.

Jokaisella monikielisen sivuston sivulla tulisi olla hreflang-tunnisteet, jotka viittaavat kaikkiin sivun muihin kieliversioihin, mukaan lukien itse sivun. Sivulla, joka on saatavilla englanniksi, ranskaksi ja saksaksi, tarvitaan hreflang-tunnisteet kaikille kolmelle kieliversiolle jokaisella sivun versiolla. Puuttuvat tai virheellisesti muotoillut hreflang-tunnisteet voivat johtaa siihen, että hakukoneet tarjoavat käyttäjille väärän kieliversion tai käsittelevät eri kieliversioita päällekkäisenä sisältönä.

Sekä WPML että Polylang hoitavat hreflang-tunnisteiden luomisen automaattisesti, kun ne on määritetty oikein, mutta automaattista toteutusta ei pidä olettaa, vaan se on tarkistettava. Yleisiä virheitä ovat puuttuvat x-default-tunnisteet, hreflang-tunnisteet, jotka viittaavat uudelleenohjattuihin URL-osoitteisiin kanonisten URL-osoitteiden sijaan, sekä hreflang-tunnisteiden toteutukset, jotka eivät vastaa käytettävää URL-rakennetta.

Sekä Rank Math että Yoast SEO tarjoavat lisäominaisuuksia hreflang-tunnisteiden hallintaan, kun niitä käytetään yhdessä monikielisten laajennusten kanssa. Tärkeää on varmistaa, että SEO-laajennus ja monikielinen laajennus on määritetty toimimaan yhdessä oikein sen sijaan, että ne tuottavat ristiriitaisia merkintöjä.

Sisältöstrategia ja käännösten laatu

Monikielisen WordPress-sivuston tekninen toteutus on projektin suoraviivaisempi osa. Sisältöstrategia on se osa, jossa monet monikieliset sivustot epäonnistuvat saavuttamaan tavoitettaan.

Koneellinen käännös on parantunut merkittävästi, ja joidenkin sisältötyyppien kohdalla se tuottaa hyväksyttäviä tuloksia. Kaupallisen sisällön, erityisesti palvelukuvauksien, tuotekuvauksien ja liiketoiminnan kannalta tärkeimpien konversiolähtöisten sivujen kohdalla koneellinen käännös riittää harvoin ilman ihmisen suorittamaa tarkistusta ja muokkausta. Teksti, joka kuulostaa kömpelöltä tai sisältää kulttuurisesti sopimattomia ilmaisuja, heikentää monikielisen sivuston tavoittelemaa uskottavuutta.

Jatkuva käännöstyönkulku on seikka, jota aliarvioidaan usein suunnitteluvaiheessa. Uuden blogikirjoituksen tai tuotesivun lisääminen monikieliseen sivustoon tarkoittaa kyseisen sisällön käännösversioiden tuottamista, mikä vie aikaa ja aiheuttaa kustannuksia. Sivustot, jotka lanseerataan kattavalla käännetyllä sisällöllä mutta joiden käännöksiä ei myöhemmin ylläpidetä, päätyvät kieliversioihin, jotka ovat vanhentuneita verrattuna pääkieliversioon. Tämä luo huonomman käyttökokemuksen kuin se, ettei käännöksiä olisi lainkaan.

Monikielisen sivuston realistiseen sisältöstrategiaan tulisi kuulua selkeä vastuu käännösprosessista, määritelty työnkulku uutta sisältöä varten sekä rehelliset päätökset siitä, mikä sisältö todella tarvitsee käännöstä. Kaikille sivuston sivuille ei tarvita käännettyä versiota. Kansainvälisille käyttäjille tärkeimpien sivujen priorisointi ja näiden käännösten asianmukainen ylläpito on tehokkaampaa kuin kattavan käännöksen yrittäminen ilman, että sitä pidetään ajan tasalla.

WooCommerce ja monikielinen verkkokauppa

Monikieliset WooCommerce-sivustot tuovat mukanaan lisämonimutkaisuutta, joka ylittää tavalliset monikielisen WordPressin huomioitavat seikat. Hinnat, toimitussäännöt, maksuportaalit ja verokokoonpanot voivat vaihdella markkinoittain. Valuutan näyttötapa on sovitettava kunkin alueen käyttäjien odotuksiin. Tuotteiden saatavuus voi vaihdella markkinoittain. Asiakaskommunikaatio, mukaan lukien tilausvahvistukset ja toimitusilmoitukset, on lähetettävä asiakkaan kielellä.

WPML tarjoaa erityistä monikielistä tukea WooCommercelle, joka hoitaa tuotteiden käännökset, valuutan vaihdon ja kassaprosessin lokalisoinnin. Asetusten määrittäminen on monimutkaisempaa kuin tavallisella monikielisellä sivustolla, ja sitä tulisi käsitellä erillisenä projektina eikä tavallisen WooCommerce-rakennelman laajennuksena.

Maksuportaalien saatavuus vaihtelee huomattavasti maittain. Stripe ja PayPal ovat käytettävissä useimmilla markkinoilla, mutta tietyillä alueilla paikalliset maksutavat ovat tärkeitä. iDEAL on hallitseva maksutapa Alankomaissa, Sofort Saksassa ja Carte Bancaire Ranskassa. Euroopan markkinoille suunnattu WooCommerce-verkkokauppa, joka tarjoaa vain kansainvälisiä korttimaksuvaihtoehtoja, jää suorituskyvyltään jälkeen paikallisista kilpailijoista, jotka tukevat kyseisen markkinan suosituimpia maksutapoja.

Suorituskykyyn liittyvät seikat

Monikieliset sivustot ovat luonnostaan suurempia kuin yksikieliset vastineensa. Lisää sivuja, lisää tietokantatietueita ja lisää laajennusten aiheuttamaa kuormitusta lisäävät kaikki palvelimen kuormitusta ja voivat aiheuttaa suorituskykyongelmia. Nämä seikat tulisi ottaa huomioon suunnitteluvaiheessa sen sijaan, että niihin reagoitaisiin vasta julkaisun jälkeen.

Välimuistin konfiguraatiossa on otettava huomioon kielen tunnistus, jotta käyttäjille ei toimiteta välimuistissa olevia sivuja väärällä kielellä. Palvelinpuolen kielen tunnistus, joka toimii ennen välimuistin sisällön toimittamista, on yleensä luotettavampaa kuin asiakaspuolen tunnistus, mutta tarkka lähestymistapa riippuu käytetystä hosting-ympäristöstä ja välimuistilisäosasta.

Useissa maissa toimivien sivustojen osalta sisältöjakeluverkko, joka tallentaa sisältöä välimuistiin maantieteellisesti lähellä kutakin kohdemarkkinaa sijaitsevissa reuna-asemissa, vähentää kansainvälisten käyttäjien viivettä. Tämä on erityisen merkityksellistä sivustoille, jotka kohdistuvat markkinoille, jotka ovat maantieteellisesti kaukana pääasiallisesta isännöintipaikasta.

Tietokannan optimointi on entistä tärkeämpää monikielisillä sivustoilla, koska WPML:n kaltaisten laajennusten käyttämät käännöstabelit lisäävät merkittävästi tietokannan kuormitusta sisällön määrän kasvaessa. Säännöllinen tietokannan ylläpito ja asianmukainen indeksointi ovat suuremmilla monikielisillä sivustoilla kriittisempiä kuin vastaavilla yksikielisillä sivustoilla.

Testaus ennen julkaisua

Monikieliset sivustot vaativat perusteellisempaa testausta kuin yksikieliset sivustot, koska tarkistettavia kielen, URL-osoitteen ja sisällön yhdistelmiä on enemmän. Järjestelmällisen testauslähestymistavan tulisi kattaa kielenvaihtotoiminnallisuus kaikilla sivuilla, oikea hreflang-toteutus, joka tarkistetaan Google Search Consolen avulla julkaisun jälkeen, kaikkien kaupallisten sivujen käännösten täydellisyys, oikea valuutan näyttö ja kassaprosessi jokaiselle markkina-alueelle WooCommerce-toteutuksissa sekä mobiilisuorituskyky jokaisella kieliversiolla.

Panostus perusteelliseen julkaisua edeltävään testaukseen on perusteltua, kun otetaan huomioon ongelmien korjaamisen kustannukset ja monimutkaisuus tuotantokäytössä olevalla monikielisellä sivustolla, jossa muutokset URL-rakenteeseen tai hreflang-toteutukseen voivat vaikuttaa hakusijoituksiin useilla markkinoilla samanaikaisesti.