Sette opp flerspråklige nettsteder riktig: hreflang, adresser, fallgruver
Et andrespråk er den rimeligste måten å vinne rekkevidde på – substansen finnes jo allerede. Det er også stedet der de fleste tekniske feilene oppstår, fordi fire ting må stemme samtidig og tre av dem er usynlige.
Det viktigste kort
- Underkataloger (
/en/) er det riktige valget for de fleste bedrifter – enklere enn egne domener, mer virksomt enn parametere. - hreflang må være gjensidig: hver versjon viser til alle de andre, til seg selv og til en standardversjon.
- Adressene hører med i oversettelsen. En engelsk tekst under en norsk adresse er en halv oversettelse.
- Automatisk videresending etter nettleserspråk er den vanligste alvorlige feilen – den stenger både roboter og brukere ute.
Den tekniske delen av et flerspråklig nettsted er oversiktlig når man setter den riktig opp én gang – og tungvint når man må rette den i ettertid. Derfor lønner den halvtimen på forhånd seg.
Adressestrukturen
| Variant | Eksempel | Egnet for |
|---|---|---|
| Underkatalog | eksempel.no/en/ | nesten alle – ett domene, én styrke |
| Underdomene | en.eksempel.no | atskilte systemer eller drivere |
| Eget landsdomene | eksempel.de | selvstendige markedsopptredener med eget team |
| Parameter | eksempel.no/?lang=en | ingenting – unngå |
Underkataloger vinner nesten alltid, fordi alle språkversjonene drar nytte av styrken til det samme domenet. Egne landsdomener krever at hvert av dem bygges opp for seg – det lønner seg først med ett team per marked.
Sette hreflang riktig
Fire regler som må gjelde samtidig. Er én av dem brutt, blir ofte hele gruppen ignorert.
- Gjensidig. Viser den norske versjonen til den engelske, må den engelske også vise til den norske. Ensidige angivelser forkastes.
- Selvhenvisning. Hver side viser også til seg selv. Blir ofte glemt og er ikke valgfritt.
- Angi standardversjon. En
x-defaultfor alle språk som ikke er dekket. - Absolutte adresser. Fullstendig med protokoll og domene, ingen relative stier.
de for tysk generelt, de-CH for tysk i Sveits. Den som bare har én tysk versjon, bruker de – ikke de-CH. Ellers blir versjonen ikke tilordnet tyske og østerrikske besøkende.
Seks feil som gjør et flerspråklig nettsted usynlig
1. Automatisk videresending etter nettleserspråk
Den alvorligste feilen. Roboter kommer som regel med amerikansk språkinnstilling og ser da aldri de andre versjonene. Brukere kommer heller ikke lenger dit de ville.
Riktig: Vis et hint med forslag, men ikke omdiriger. Husk valget.
2. Adressene ikke oversatt
/en/impressum/ i stedet for /en/legal-notice/. Virker som en halvferdig versjon – og kaster bort søkeordet i adressen.
Riktig: Oversett adressesegmentene per språk, fastsett dem varig og endre dem ikke igjen.
3. Canonical peker på hovedspråket
Når den engelske siden oppgir den norske som kanonisk adresse, sier dere: denne siden er et duplikat, ta den andre. Den forsvinner ut av indeksen.
Riktig: Hver språkversjon er sin egen kanoniske adresse.
4. Manglende lang-attributt
<html lang="nb"> mangler eller står likt i alle versjoner. Berører ikke bare søkemotorer, men også opplesingsprogrammer – der fører det til uforståelig uttale.
Riktig: Riktig kode per versjon, satt automatisk.
5. Ett nettstedskart for alt, uten språkangivelser
Uten hreflang-angivelser i nettstedskartet mangler forbindelsen mellom versjonene nettopp der den enklest ville blitt oppdaget.
Riktig: hreflang enten i nettstedskartet eller i <head> – konsekvent ett sted.
6. Delvis oversatte sider
Overskrifter oversatt, brødtekst på norsk. For søkemotorer er det en side uten tydelig språk – og for besøkende et tillitsproblem.
Riktig: Heller færre sider fullstendig enn alle halvveis.
Visste du at …?
Å oversette alene holder ikke – fire ting må tilpasses landet, ikke bare språket: beløp i landets valuta, den gjeldende rettstilstanden, stedsvanlige eksempler og datoformater.
En engelsk versjon som nevner sveitsiske franc og den reviderte sveitsiske personvernloven, er ingen versjon for det britiske markedet, men en oversettelse av den sveitsiske siden. Det kan være bevisst ønsket – men det bør være en beslutning og ingen forglemmelse.
Vedlikeholdet er det egentlige problemet
Oppbyggingen er en engangsinnsats. Vedlikeholdet er varig – og der strander flerspråklige nettsteder oftere enn på teknikken.
Etter et år ser det typiske bildet slik ut: hovedspråket har 40 sider, det andre 31, det tredje 22. Endringer ble gjort på hovedspråket og glemt i de andre – og ingen vet lenger hvilken versjon som er oppdatert.
Mot det hjelper bare en strukturell beslutning: en endring regnes først som ferdig når den er etterjustert på alle språk. Den som ikke klarer å holde det ut, bør tilby færre språk – tre vedlikeholdte slår åtte foreldede med god margin.
Sjekkliste før start
- Hver side viser via hreflang til alle versjoner, til seg selv og til x-default
- Hver versjon er sin egen kanoniske adresse
<html lang>er korrekt satt per versjon- Adressesegmentene er oversatt og varig fastsatt
- Ingen automatisk videresending etter nettleserspråk
- Språkvalget er synlig og fungerer uten JavaScript
- Beløp, rettsangivelser og eksempler er tilpasset, ikke bare oversatt
- Det finnes et fast forløp som etterjusterer endringer på alle språk
Kontroller det flerspråklige oppsettet på nettstedet mitt. Opplysninger: - Domene: [adresse] - Språk: [liste med språkkoder] - Adressestruktur: [underkatalog / underdomene / eget domene] - hreflang-blokken på en eksempelside: [sett inn blokk] - Canonical-angivelsen på samme side: [sett inn] - lang-attributtet på samme side: [sett inn] - Finnes det en automatisk videresending etter nettleserspråk? [ja / nei] - Er adressesegmentene oversatt? [eksempel per språk] Oppgaver: 1. Kontroller de fire hreflang-reglene: gjensidig, selvhenvisning, x-default til stede, absolutte adresser. Nevn hvert brudd for seg. 2. Kontroller om språkkodene er riktig valgt – særlig om en regionsangivelse er for snevert satt. 3. Kontroller canonical og lang-attributt for motstrid med språkversjonen. 4. Nevn punktene i opplysningene mine som kan gjøre en språkversjon usynlig, sortert etter alvorlighet. 5. Gi meg den korrigerte hreflang-blokken fullstendig. Ikke finn på adresser – merk det som mangler som [må fylles ut].
Konklusjon
Teknisk avgjøres et flerspråklig nettsted på fire steder: adressestruktur, gjensidig hreflang, egen kanonisk adresse per versjon, ingen automatisk omdirigering. Er disse fire riktige, fungerer resten.
Det egentlige spørsmålet er deretter organisatorisk: klarer dere å etterjustere hver endring på alle språk? Hvis ikke, er færre språk den bedre beslutningen.
Vanlige spørsmål
Hvilken adressestruktur er best for flerspråklige nettsteder?
Underkataloger som /en/ for nesten alle bedrifter: alle språkversjonene drar nytte av styrken til det samme domenet, og forvaltningen forblir enkel. Egne landsdomener lønner seg først ved selvstendige markedsopptredener med eget team; språkparametere i adressen bør unngås.
Hva må man passe på ved hreflang?
Fire regler samtidig: angivelsene må være gjensidige, hver side må også vise til seg selv, det trengs en x-default for språk som ikke er dekket, og alle adresser må være oppgitt absolutt. Er én regel brutt, blir ofte hele gruppen ignorert.
Bør man videresende besøkende automatisk til deres språk?
Nei. Roboter kommer som regel med amerikansk språkinnstilling og ser da aldri de andre versjonene; brukere havner ikke der de ville. Riktig er et hint med forslag som husker det valget som er gjort – uten automatisk omdirigering.
Må adressene oversettes?
Ja. En engelsk tekst under en norsk adresse virker halvferdig og kaster bort søkeordet i adressen. Adressesegmentene bør oversettes per språk og deretter fastsettes varig – senere endringer koster den synligheten som er bygd opp.
Hvor mange språk er fornuftig?
Så mange som kan vedlikeholdes varig. Den vanligste tilstanden etter et år er versjoner med ulik grad av fullstendighet, der ingen lenger vet hvilken som er oppdatert. Tre vedlikeholdte språk virker langt bedre enn åtte foreldede – avgjørende er et fast forløp som etterjusterer hver endring i alle versjoner.
Markedsføring som setter seg opp selv
Betaen for Studio Engine er åpen. Sikre deg en plass og bidra fra starten.
Bli med i betaen →