Sätta upp flerspråkiga webbplatser rätt

Q: Vilken adresstruktur är bäst för flerspråkiga webbplatser?

Underkataloger som /en/ för nästan alla företag: alla språkversioner drar nytta av samma domäns styrka, och förvaltningen förblir enkel. Egna landsdomäner lönar sig först vid självständiga marknadsuppträdanden med eget team; språkparametrar i adressen bör undvikas.

Det viktigaste

Underkataloger (/en/) är rätt val för de flesta företag – enklare än egna domäner, verksammare än parametrar.
hreflang måste vara ömsesidigt: varje version hänvisar till alla andra, till sig själv och till en standardversion.
Adresserna hör med i översättningen. En engelsk text under en svensk adress är en halv översättning.
Automatisk vidarestyrning efter webbläsarspråk är det vanligaste allvarliga felet – den stänger ute både sökrobotar och användare.

Den tekniska delen av en flerspråkig sida är överskådlig om man sätter upp den rätt en gång – och mödosam om man rättar den i efterhand. Därför lönar sig den halvtimmen i förväg.

Adresstrukturen

Variant	Exempel	Lämpar sig för
Underkatalog	`exempel.se/en/`	nästan alla – en domän, en styrka
Underdomän	`en.exempel.se`	åtskilda system eller operatörer
Egen landsdomän	`exempel.de`	självständiga marknadsuppträdanden med eget team
Parameter	`exempel.se/?lang=en`	ingenting – undvik

Underkataloger vinner nästan alltid, eftersom alla språkversioner drar nytta av samma domäns styrka. Egna landsdomäner kräver att var och en byggs upp för sig – det lönar sig först med ett team per marknad.

Att sätta hreflang rätt

Fyra regler som måste gälla tillsammans. Är en av dem bruten ignoreras ofta hela gruppen.

Ömsesidigt. Om den svenska versionen hänvisar till den engelska måste den engelska också hänvisa till den svenska. Ensidiga angivelser förkastas.
Självhänvisning. Varje sida hänvisar också till sig själv. Glöms ofta bort och är inte valfritt.
Ange en standardversion. Ett x-default för alla språk som inte täcks.
Absoluta adresser. Fullständigt med protokoll och domän, inga relativa sökvägar.

Tips Språkkoden är först språket, sedan valfritt regionen: de för tyska allmänt, de-CH för tyska i Schweiz. Den som bara har en tyskspråkig version tar de – inte de-CH. Annars får tyska och österrikiska besökare ingen version tilldelad.

Sex fel som gör en flerspråkig sida osynlig

1. Automatisk vidarestyrning efter webbläsarspråk

Det allvarligaste felet. Sökrobotar kommer oftast med amerikansk språkinställning och ser då aldrig de andra versionerna. Även användare kommer inte längre dit de ville.

Rätt: Visa en upplysning med förslag, men styr inte om. Kom ihåg valet.

2. Adresserna inte översatta

/en/impressum/ i stället för /en/legal-notice/. Verkar som en halvfärdig version – och slösar bort sökbegreppet i adressen.

Rätt: Översätt adressegmenten per språk, lägg fast dem varaktigt och ändra dem inte mer.

3. Canonical pekar på huvudspråket

Om den engelska sidan anger den svenska som kanonisk adress säger ni: den här sidan är en dubblett, ta den andra. Den försvinner ur indexet.

Rätt: Varje språkversion är sin egen kanoniska adress.

4. Saknat lang-attribut

<html lang="de"> saknas eller står likadant i alla versioner. Berör inte bara sökmotorer, utan också uppläsningsprogram – där leder det till obegripligt uttal.

Rätt: Rätt kod per version, satt automatiskt.

5. En webbplatskarta för allt, utan språkangivelser

Utan hreflang-angivelser i webbplatskartan saknas förbindelsen mellan versionerna på det ställe där den lättast skulle kännas igen.

Rätt: hreflang antingen i webbplatskartan eller i <head> – konsekvent på ett ställe.

6. Delvis översatta sidor

Rubriker översatta, brödtext på svenska. För sökmotorer är det en sida utan tydligt språk – och för besökare ett förtroendeproblem.

Rätt: Hellre färre sidor fullständigt än alla till hälften.

Visste du att…?

Att översätta räcker inte – fyra saker måste anpassas till landet, inte bara till språket: belopp i landets valuta, det gällande rättsläget, exempel som är vanliga på orten och datumformat.

En engelsk version som nämner schweizerfranc och den reviderade schweiziska dataskyddslagen är ingen version för den brittiska marknaden, utan en översättning av den schweiziska sidan. Det kan vara medvetet så – men det bör vara ett beslut och inget förbiseende.

Skötseln är det egentliga problemet

Uppbyggnaden är ett engångsarbete. Skötseln är varaktig – och där stupar flerspråkiga sidor oftare än på tekniken.

Från praktiken

Efter ett år ser den typiska bilden ut så här: huvudspråket har 40 sidor, det andra 31, det tredje 22. Ändringar gjordes i huvudspråket och glömdes i de andra – och ingen vet längre vilken version som är aktuell.

Mot det hjälper bara ett byggnadsbeslut: en ändring räknas som färdig först när den är efterdragen i alla språk. Den som inte klarar av det bör erbjuda färre språk – tre skötta slår åtta föråldrade med bred marginal.

Checklista före start

Varje sida hänvisar via hreflang till alla versioner, till sig själv och till x-default
Varje version är sin egen kanoniska adress
<html lang> är korrekt satt per version
Adressegmenten är översatta och varaktigt fastlagda
Ingen automatisk vidarestyrning efter webbläsarspråk
Språkvalet är synligt och fungerar utan JavaScript
Belopp, rättsliga uppgifter och exempel är anpassade, inte bara översatta
Det finns ett fast förlopp som drar efter ändringar i alla språk

Prompt

Pröva den flerspråkiga uppsättningen på min webbplats.

Uppgifter:
- Domän: [Adress]
- Språk: [Lista med språkkoder]
- Adresstruktur: [underkatalog / underdomän / egen domän]
- hreflang-block från en exempelsida:
  [Klistra in block]
- Canonical-angivelse för samma sida: [klistra in]
- lang-attribut för samma sida: [klistra in]
- Finns det en automatisk vidarestyrning efter webbläsarspråk?
  [ja / nej]
- Är adressegmenten översatta? [Exempel per språk]

Uppgifter:
1. Pröva de fyra hreflang-reglerna: ömsesidighet, självhänvisning,
   x-default finns, absoluta adresser. Nämn varje brott
   för sig.
2. Pröva om språkkoderna är rätt valda – särskilt
   om en regionsangivelse är för snävt fattad.
3. Pröva canonical och lang-attribut mot motsägelser till
   språkversionen.
4. Nämn de punkter i min uppgift som kan göra en språkversion
   osynlig, sorterade efter allvar.
5. Ge mig det rättade hreflang-blocket i sin helhet.

Hitta inte på adresser – märk det som saknas som [att komplettera].

Slutsats

Tekniskt avgörs en flerspråkig sida på fyra ställen: adresstruktur, ömsesidigt hreflang, egen kanonisk adress per version, ingen automatisk omstyrning. Är de fyra rätt fungerar resten.

Den egentliga frågan därefter är organisatorisk: klarar ni av att dra efter varje ändring i alla språk? Om inte är färre språk det bättre beslutet.

Vanliga frågor

Vilken adresstruktur är bäst för flerspråkiga webbplatser?

Underkataloger som /en/ för nästan alla företag: alla språkversioner drar nytta av samma domäns styrka, och förvaltningen förblir enkel. Egna landsdomäner lönar sig först vid självständiga marknadsuppträdanden med eget team; språkparametrar i adressen bör undvikas.

Vad måste man tänka på med hreflang?

Fyra regler samtidigt: angivelserna måste vara ömsesidiga, varje sida måste också hänvisa till sig själv, det behövs ett x-default för språk som inte täcks, och alla adresser måste anges absolut. Är en regel bruten ignoreras ofta hela gruppen.

Bör man automatiskt styra besökare till sitt språk?

Nej. Sökrobotar kommer oftast med amerikansk språkinställning och ser då aldrig de andra versionerna; användare hamnar inte där de ville. Rätt är en upplysning med förslag som kommer ihåg det gjorda valet – utan automatisk omstyrning.

Måste adresserna översättas?

Ja. En engelsk text under en svensk adress verkar halvfärdig och slösar bort sökbegreppet i adressen. Adressegmenten bör översättas per språk och sedan läggas fast varaktigt – senare ändringar kostar den uppbyggda synligheten.

Hur många språk är rimligt?

Så många som varaktigt går att sköta. Det vanligaste tillståndet efter ett år är olika fullständiga versioner där ingen längre vet vilken som är aktuell. Tre skötta språk verkar betydligt bättre än åtta föråldrade – avgörande är ett fast förlopp som drar efter varje ändring i alla versioner.