Bygga en flerspråkig hemsida: lärdomar från åtta marknader samtidigt

En kund kom till oss med ett Excel-ark: åtta språk, en webbplats, ett lanseringsdatum redan utlovat till styrelsen. Första frågan var förstås "hur lång tid tar översättningen?" — som om det var hela projektet. Det är det aldrig. När en webbplats väl ska fungera på flera språk är själva översättningen kanske en tredjedel av arbetet. Resten är arkitektur: hur webbadresserna är strukturerade, hur sökmotorerna vet vilken version som ska visas för vem, vad som händer när en sida finns på svenska men inte ännu på polska, och hur en språkväljare undviker att skicka en besökare från Köpenhamn till en tysk startsida bara för att webbläsaren råkade vara inställd på tyska.

Det mesta av smärtan i ett projekt för en flerspråkig webbplats sitter just i de här besluten, inte i själva skrivandet. Blir strukturen fel från början slutar det ofta med att man byter plattform arton månader senare, efter att Google redan har indexerat röran och man måste reda ut den utan att tappa sina rankningar. Blir det rätt från start är det bara en konfigurationsändring, inte en ombyggnad, att lägga till en nionde marknad längre fram.

Varför "bara översätta texten" inte räcker

Att byta ut engelsk text mot svensk text på samma webbadresser, utan några andra ändringar, ger tekniskt sett en flerspråkig sida. Det ger inte en flerspråkig webbplats. Sökmotorer behöver ett sätt att förstå att /products/shoes och /produkter/skor är samma innehåll på två språk, inte två konkurrerande sidor om skor. Besökare behöver ett sätt att hamna på rätt version utan att behöva gissa. Och innehållet i sig måste läsas som om det var skrivet för dem, inte översatt åt dem — valutasymboler, datumformat, telefonnummerformat och kulturella referenspunkter måste alla anpassas, inte bara ordvalet.

Inget av det här är exotiskt. Det är välkänd, väldokumenterad mark. Men det är också precis den typen av detalj som glöms bort när "flerspråkig" behandlas som en bock i en ruta snarare än som en fråga om informationsarkitektur.

Välja URL-struktur: undermappar, subdomäner eller egna domäner

Det här är det första beslutet, och det är svårare att ändra i efterhand än det verkar. Det finns tre vanliga mönster, och alla har verkliga avvägningar kring SEO och drift.

Struktur	Exempel	Fördelar	Nackdelar
Undermappar	neuraweb.se/sv/, neuraweb.se/en/	Samlar domänens auktoritet på ett ställe; billigast att driva; enklast att underhålla i en och samma kodbas	Kräver disciplinerad routing och konsekventa slug-konventioner per språk
Subdomäner	sv.example.com, en.example.com	Kan driftsättas och hostas relativt oberoende; praktiskt om regionala team sköter sitt eget innehåll	Sökmotorer kan behandla subdomäner som halvt separata enheter, vilket ibland späder ut auktoriteten; mer infrastruktur att underhålla
Separata landsdomäner	example.se, example.de	Starkaste signalen för lokal relevans; bygger upp förtroende per land	Dyrast och långsammast att skala; auktoritet överförs inte mellan domäner; kräver i praktiken separata SEO-satsningar

För de flesta små och medelstora företag som expanderar till ett fåtal marknader är undermappar det pragmatiska standardvalet. De håller alla bakåtlänkar och all domänauktoritet samlad och arbetande för varje språkversion i stället för att sprida den över separata webbplatser, och de gör att ett och samma innehållsteam kan sköta allt från en och samma administrationspanel. Separata landsdomäner är i första hand vettiga för större företag med budget att driva det som i praktiken blir självständiga marknadsföringsverksamheter per land, eller på genuint reglerade marknader där en lokal domän ger ett förtroende som en undermapp inte kan matcha.

Oavsett vilken struktur ni väljer spelar konsekvens större roll än själva valet. Att blanda undermappar för vissa språk och subdomäner för andra, för att beslutet fattats bit för bit under några års tid, är en vanlig källa till den typen av teknisk skuld vi ofta kallas in för att reda ut.

Hreflang-taggar: så vet sökmotorerna vem som ska se vad

Även en perfekt undermappsstruktur talar inte automatiskt om för Google att /en/pricing och /sv/priser är språkvarianter av samma sida. Det är hreflang-attributets uppgift — en tagg i sidans <head> (eller i XML-sitemapen) som uttryckligen kopplar samman varje språkversion av en webbadress med alla de andra, plus en x-default-variant för besökare vars språk inte matchar någon av de versioner ni erbjuder.

Utan det tvingas sökmotorerna gissa, och de gissar ofta fel: en tysk besökare kan få se den engelska sidan för att den har fler bakåtlänkar, eller ännu värre — sidor som liknar varandra över språkgränserna kan tolkas som lågkvalitativt duplicerat innehåll och tryckas ner i resultaten trots att de egentligen borde ranka bra. Med rätt uppsättning konkurrerar i stället varje språkversion i sin egen marknads sökresultat, i stället för att äta upp trafik från varandra.

Det tekniska kravet som flest snubblar på är ömsesidigheten: varje sida i hreflang-uppsättningen måste referera till alla andra sidor i uppsättningen, inklusive sig själv. Länkar den svenska sidan till den engelska och den norska versionen, men den engelska sidan glömmer att länka tillbaka till svenskan, blir hela annoteringen opålitlig och sökmotorerna kan välja att ignorera den helt. Det här är precis den typ av sak som är trivial att få rätt i ett mallbaserat system, men lätt att få subtilt fel när sidor hanteras för hand eller läggs till inkonsekvent över tid.

Översättning är inte samma sak som lokalisering

Översättning omvandlar ord från ett språk till ett annat. Lokalisering anpassar hela upplevelsen — valuta, datumformat, måttenheter, adressformat, bildval, idiom och kulturella referenspunkter — så att sidan känns som att den är byggd på plats för den marknaden, inte återanvänd för den.

Några konkreta exempel: talformatet 1,000.50 på engelska motsvaras av 1 000,50 på svenska — punkt och kommatecken byter helt enkelt roll. Datum skrivna månad/dag/år i USA läses som dag/månad/år nästan överallt annars, och ett formulärfält som inte tar hänsyn till det kan tyst tolka 03/04 som 4 mars när en svensk besökare menade 3 april. Priser måste visas i lokal valuta, inte bara översättas som en siffra med en annan symbol påklistrad. Idiom och talesätt som översätts ordagrant uppfattas ofta som konstiga, eller oavsiktligt komiska, av en modersmålstalare — det engelska uttrycket "hit the ground running" betyder ingenting ord för ord på de flesta andra språk, och en alltför bokstavlig översättning avslöjar direkt att webbplatsen inte är byggd med den lokala publiken i åtanke. Även färg- och bildval bär olika associationer mellan kulturer, även om det är ett mer subtilt lager än vad de flesta projekt behöver bry sig om i ett första skede.

Maskinöversättning har verkligen blivit bättre, och den kan fungera som en rimlig utgångspunkt för innehåll med hög volym, som produktkataloger. Men den bör aldrig vara sista steget för något som är kundvänt — landningssidor, tjänstebeskrivningar, call to actions, allt där ton och precision spelar roll. Att en modersmålstalare granskar och justerar resultatet, inte bara kontrollerar att grammatiken stämmer, är det som skiljer en webbplats som känns naturlig från en som känns översatt.

Vad händer när en sida inte finns på alla språk än

Ingen webbplats lanserar med varje sida fullt översatt till varje språk från dag ett, och de flesta når aldrig hundra procent paritet — ett nischat blogginlägg eller en säsongsbetonad kampanjsida är helt enkelt inte alltid värt att översätta till alla åtta marknader. Frågan är vad som händer när en besökare i en språkversion efterfrågar en sida som bara finns i en annan.

Det finns några försvarbara reservlösningar, och fel val här skapar trasig navigering eller tunna, förvirrande sidor:

• Visa sidan på webbplatsens standardspråk, tydligt märkt, i stället för en 404-sida. Det håller kvar besökaren på webbplatsen och ger dem något användbart, även om det inte är på deras förstaspråk.
• Dölj oöversatta sidor helt från den språkversionens navigering och sitemap, så att besökare bara ser innehåll som faktiskt finns på deras språk, och sökmotorer inte skickas till tunna eller dubblettliknande sidor.
• Undvik halvöversatta sidor — en sida som är hälften på målspråket och hälften på reservspråket, för att bara vissa fält blivit översatta, ser trasig ut snarare än medveten. Det är bättre att inte visa sidan alls på det språket än att visa den halvfärdig.

Det är också här som tidiga beslut om innehållsarkitektur lönar sig — som att hålla en ren, språkoberoende koppling mellan "den här sidan på språk A motsvarar den här sidan på språk B". Att bygga in den strukturen i efterhand, när några hundra sidor redan skapats på måfå, är ett mycket större jobb än att göra det från början.

Språkväljare och detektering som inte irriterar någon

Att automatiskt omdirigera besökare baserat på webbläsarspråk eller IP-baserad geolokalisering låter smart i teorin och är en vanlig källa till irritation i praktiken. En svensktalande person som reser i Spanien vill inte omdirigeras till den spanska versionen bara för att IP-adressen råkar peka dit. En besökare som medvetet skrivit in den engelska webbadressen vill inte studsas tillbaka till webbläsarens standardspråk vid varje besök. Och alltför aggressiva automatiska omdirigeringar kan aktivt skada SEO, eftersom även sökmotorernas robotar kan omdirigeras och därmed hindras från att indexera de språkversioner de faktiskt försöker nå.

Ett mer pålitligt mönster: använd webbläsarspråk eller geolokalisering som ett mjukt förslag, inte en tvingande omdirigering. Visa en liten banderoll som går att stänga ("Det ser ut som att du är i Sverige — vill du se sidan på svenska?") i stället för en automatisk knuff, respektera besökarens val när det väl gjorts (via en cookie eller webbadressen), och gör själva språkväljaren lätt att hitta — vanligtvis i sidhuvudet, med språken listade under sina egna namn ("Svenska", inte "Swedish", när den visas för en svensktalande besökare) snarare än att förlita sig enbart på flaggikoner, eftersom flaggor representerar länder och inte språk, och kopplingen mellan de två inte är så självklar som den ser ut (spanska talas till exempel i många länder med olika flaggor).

Vanliga misstag som är lätta att undvika

Några mönster återkommer gång på gång i flerspråkiga projekt som inte planerades som flerspråkiga från början:

• Maskinöversätta allt utan mänsklig granskning. Snabbt och billigt i det korta loppet, men det syns, särskilt i sådant som ska övertyga — rubriker, call to actions, tjänstebeskrivningar — där tonen väger lika tungt som korrektheten.
• Översätta det synliga innehållet men glömma metadata. Sidtitlar, metabeskrivningar, alt-texter på bilder och url-slugs blir ofta kvar på originalspråket eftersom de inte syns på själva sidan. Sökmotorer indexerar allt detta, och en engelsk metabeskrivning på en svensk sida underminerar precis den lokala sökbarhet som översättningen var tänkt att bygga upp.
• Inkonsekventa url-slugs mellan språken. Om den engelska versionen av en sida ligger på /en/services/web-design och den svenska motsvarigheten skapas inkonsekvent — ibland översatt, ibland kvar på engelska, ibland helt omstrukturerad — går interna länkar sönder, hreflang-kopplingarna blir svårare att underhålla, och navigeringen mellan språkversioner av samma sida slutar fungera rent.
• Behandla språkväljaren som en efterkonstruktion. Klistrar man in den i sidhuvudet sent i projektet, efter att url-struktur och mallar redan är byggda, blir resultatet oftast att den inte faktiskt bevarar den aktuella sidan vid byte — besökaren skickas till startsidan i stället för till den översatta motsvarigheten av sidan de faktiskt läste.

Alla de här misstagen går att undvika med planering, men blir dyra att åtgärda i efterhand när några hundra sidor och ett års sökmotorindexering redan är inblandade.

Planera för det här från start

Inget av det här behöver vara på plats för varje marknad från dag ett. Ett förnuftigt angreppssätt är att designa arkitekturen — url-struktur, hreflang-uppsättning, innehållsmodell, reservregler — för det antal språk ni förväntar er att stödja på sikt, och sedan lansera med färre och lägga till marknader efter hand utan att bygga om. Det dyra misstaget är inte att lansera med två språk i stället för åtta, utan att bygga ett system som från grunden bara klarar ett enda språk rent, och sedan försöka klistra på fler i efterhand. Om ni utvärderar en webbyrå för ett projekt som det här är det värt att direkt fråga hur de hanterat flerspråkig arkitektur tidigare, i stället för att ta ett "ja, det gör vi" för givet — vår artikel om hur man väljer rätt webbyrå går igenom de konkreta frågor som är värda att ställa för att skilja genuin teknisk erfarenhet från ett påstående på en tjänstesida.

Planerar ni en webbplats som behöver fungera på fler än ett språk eller för fler än en marknad är det värt att få arkitekturen rätt innan den första sidan byggs, snarare än efteråt. Vårt arbete med skräddarsydd webbdesign innehåller precis den här typen av flerspråkig planering — url-struktur, hreflang, lokaliseringsflöde och en innehållsmodell som skalar när nya marknader läggs till. Hör av dig om du vill prata igenom vad ditt projekt behöver.