Hreflang

Hreflang är en HTML-tagg som talar om för Google vilket språk och vilken landsversion en sida gäller. Har du samma innehåll på svenska och engelska hjälper taggen sökmotorn att förstå att sidorna hör ihop, så att rätt version visas för rätt besökare i sökresultatet i stället för att versionerna konkurrerar med varandra om samma ranking.

Säg att du driver en butik med en svensk och en engelsk version av samma produktsida. Utan den kopplingen visar Google ofta fel version för fel person, så att den svenska sidan dyker upp för en kund i Storbritannien som inte förstår ett ord av den. Rätt uppsatt tagg löser precis det, och den är en av grundbultarna i flerspråkig SEO. Samtidigt minskar risken att dina språkversioner tolkas som duplicerat innehåll.

Vad hreflang faktiskt är

En hreflang-tagg är en kort kodrad som lever i sidans HTML-head, i en XML-sitemap eller i HTTP-headers, och den består av två delar: en språkkod och, om du vill, en landskod. I head-sektionen bor redan din metabeskrivning och dina Open Graph-taggar, så hreflang är ännu en instruktion i samma utrymme. Tillsammans berättar delarna för Google vem sidan är skriven för. Saknas informationen får sökmotorn gissa, och gissar den fel hamnar fel sida framför fel person.

Tänk på det som en skylt vid varje dörr. Skylten säger att den här versionen är på svenska för Sverige eller på engelska för USA, och Googles algoritm läser skyltarna innan sökresultatet serveras, beroende på var besökaren finns och vilket språk hen använder. System som RankBrain tolkar dessutom avsikten bakom sökningen, medan skylten bara svarar på frågan om vem sidan riktar sig till.

Så ser taggen ut i koden

En typisk rad i HTML-head följer mönstret nedan, där sv-SE står för svenska i Sverige och en-US för engelska i USA:

<link rel="alternate" hreflang="sv-SE" href="https://exempel.se/" />
<link rel="alternate" hreflang="en-US" href="https://exempel.se/en/" />
<link rel="alternate" hreflang="x-default" href="https://exempel.se/" />

Raden ser enkel ut, men varje del har en bestämd roll och egna regler. Den skiljer sig från strukturerad data, som du lägger in enligt vår guide om schema markup: hreflang beskriver publiken, schema beskriver innehållet. Vi tar dem en i taget.

Språkkoden enligt ISO 639-1

Språkkoden är obligatorisk, följer standarden ISO 639-1 och är alltid två bokstäver som beskriver språket och inte landet. Den säger däremot ingenting om hur bra texten är - kvaliteten på översättningen hör till din innehållsstrategi, inte till koden. Några vanliga koder att känna igen:

• sv för svenska
• en för engelska (English)
• de för tyska (German)
• es för spanska (Spanish)

Landskoden enligt ISO 3166-1

Vill du rikta ett språk mot en specifik marknad lägger du till en landskod enligt ISO 3166-1, exempelvis en-GB för Storbritannien eller en-AU för den australiska publiken. Landskoden är frivillig och används bara när det behövs, och den ersätter inte den konkurrentanalys du behöver göra på varje ny marknad:

• SE för Sverige
• US för USA (The US)
• GB för United Kingdom
• MX för Mexiko (Mexico)

Värdet x-default

Värdet x-default är en särskild rad för besökare som inte matchar någon av dina versioner, och den fångar upp trafik du annars skulle skicka fel. Väljer du att peka den mot en språkväljare är mobilanpassning extra viktig, eftersom de flesta möter valet på en liten skärm. Du använder den när:

• en besökare i Japan inte matchar någon språk- eller landsversion
• du vill peka mot en global engelsk startsida eller landningssida
• du hellre visar en språkväljare än en slumpmässig version, där varje länks ankartext skriver ut språket i klartext

Var taggen kan bo

Du kan placera taggen på tre ställen, och valet beror på sajtens storlek och på vilken typ av filer du vill täcka. Ligger sajten bakom ett CDN sätts HTTP-headers ofta där i stället för på ursprungsservern:

• i sidans HTML-head, enklast för vanliga sidor
• i en XML-sitemap, smidigast för stora sajter
• i HTTP-headers, enda vägen för filer som PDF:er

När du inte behöver hreflang

Har du bara en enda språkversion och riktar dig mot ett enda land, kanske med fokus på lokal SEO, ska du strunta i taggen helt, eftersom den då löser ett problem du inte har och felaktigt uppsatt skapar den nya. Räkna alltså dina versioner innan du börjar: noll eller en version betyder att du hoppar över det här, två eller fler betyder att du sätter upp kopplingen ömsesidigt. Ett företag som bara vänder sig till kunder i Stockholm, Göteborg eller Västerås har i regel mer att hämta i kartan och i sina recensioner än i språktaggar.

En språkversion räcker långt

Ett svenskt företag som bara säljer i Sverige på svenska klarar sig utan taggen, och energin gör betydligt mer nytta någon annanstans:

• din interna länkning mellan sidorna, där anchor text styr vad Google förstår
• ditt innehåll, dina rubriker och din sökordsanalys
• teknisk SEO som laddtid, Core Web Vitals och indexering

Samma sak gäller den som jobbar mot en enda ort. Vi har egna genomgångar för Borås, Borlänge, Falun, Gävle, Halmstad, Kalmar och Karlskrona, och där handlar arbetet oftare om Google recensioner och lokala kataloger än om språkkoder.

Därför spelar taggen roll i sökresultaten

Många tror att det här är ett rankingverktyg, ett missförstånd som lever sida vid sida med idén om en Google Sandbox. Det stämmer inte: taggen styr inte hur högt du rankar, den styr vilken version som visas. En korrekt sida på rätt språk ger däremot en bättre upplevelse, och det märks i siffror som klickfrekvens och konvertering. Taggen flyttar heller ingen auktoritet mellan dina versioner - den byggs av länkar och omdömen, inte av kodrader.

Hreflang ersätter inte en canonical-tagg. De två löser olika problem och kan användas tillsammans, men en sida ska aldrig peka sin canonical mot en annan språkversion.

Vad taggen gör för dina besökare

Nyttan blir tydligast när du bryter ner den i konkreta effekter för den som faktiskt sitter och söker med en tydlig sökintention. Den intentionen kan skilja sig mellan marknader, något ditt content marketing-arbete behöver ta höjd för.

Rätt sida för rätt person

En kund i Tyskland ska se den tyska sidan och inte den svenska, och det är precis den kopplingen taggen gör möjlig. Detsamma gäller de sammanfattningar som numera dyker upp i AI Overviews, eftersom de hämtar text från den version Google valt. Några typiska matchningar:

• en besökare i Tyskland får den tyska versionen
• en besökare i USA får den engelska versionen
• en besökare i Japan faller tillbaka på x-default

Mindre risk för duplicerat innehåll

När du har nästan identiskt innehåll på flera URL:er kan Google bli osäker på vilken sida som ska visas. Taggen förklarar att det handlar om språkversioner och inte kopior, vilket i regel minskar risken för duplicerat innehåll och gör att Google slår ihop signalerna i stället för att låta sidorna konkurrera med varandra, ungefär som en genomtänkt pillar page samlar signaler i stället för att splittra dem. Att visa olika språkversioner är för övrigt inte cloaking: cloaking är när du visar en sak för Google och något helt annat för besökaren, medan hreflang bara pekar ut vem varje version är skriven för.

Bättre synlighet på varje marknad

Visas rätt version i rätt land ökar chansen att besökaren stannar kvar och till slut gör en konvertering, och en engelsktalande som hamnar på en svensk sida lämnar oftast direkt. Resten av det jobbet hör till konverteringsoptimering, och mätningen blir dessutom renare när trafiken landar rätt från början, vilket gör din attribution mindre grumlig. Rätt språkversion spelar också roll utanför själva sökresultatet, till exempel i flödet Google Discover. Det brukar synas i:

• högre andel som stannar kvar på sidan och längre sessionslängd
• fler som hittar rätt språk direkt
• starkare synlighet på varje enskild marknad, både organiskt och i Google Ads

Vanliga missförstånd som ställer till det

Det här är området där flest fel smyger sig in, ofta för att koden ser enkel ut men har strikta regler bakom sig. Det vanligaste missförståndet handlar om ranking, som nämnts ovan, och hör hemma bland de vanligaste SEO-myterna, tillsammans med idéer om att keyword density eller ett visst ordantal avgör placeringen. En annan miss är att tro att taggen fixar innehållet: en maskinöversatt sida är fortfarande maskinöversatt, AI-genererat innehåll behöver samma redigering som allt annat, och ChatGPT för SEO hjälper med utkast men inte med tonen på en marknad du inte känner. Tätt därefter kommer de rent tekniska misstagen.

Reglerna för URL:er och returlänkar

Reglerna kring adresser och ömsesidiga länkar är hårda, och det är här de flesta uppsättningar går sönder utan att någon märker det. En detalj till: en sida ska aldrig peka sin canonical mot en annan språkversion, för då säger du åt Google att versionen inte ska indexeras alls, med nästan samma effekt som ett noindex. Låt varje version ha sin egen canonical som pekar på sig själv.

Absoluta URL:er är ett krav

Du måste alltid använda absoluta URL:er, alltså fullständiga adresser med https://, som förutsätter ett SSL-certifikat, eftersom relativa länkar helt enkelt inte fungerar här. Har du gamla adresser kvar ska taggen peka på slutmålet, inte in i en kedja av redirects:

• rätt: https://exempel.se/en/
• fel: /en/
• fel: exempel.se/en/ utan protokoll

Ömsesidiga returlänkar

Kopplingen måste vara ömsesidig, så om den svenska sidan pekar på den engelska måste den engelska peka tillbaka på den svenska. Saknas returlänken på bara en version faller hela uppsättningen, och det syns inte i sökresultatet förrän fel sida börjar dyka upp för fel besökare:

• varje version pekar på alla andra versioner
• varje version pekar även på sig själv
• saknas en returlänk hoppar Google över hela uppsättningen

Fel i språk- och landskoder

Ett felstavat värde gör att Google tyst hoppar över raden, utan varning och utan att något syns i Search Console. Ett SEO-verktyg som crawlar sajten hittar den typen av fel betydligt snabbare än ögat. Vanliga misstag att undvika:

• en-UK i stället för korrekta en-GB
• gb utan språkkod före landet
• sv_SE med understreck i stället för bindestreck
• EN med versaler där gemener ska stå

Hreflang steg för steg i praktiken

Det finns tre sätt att lägga in koden, och vilket du väljer beror på din plattform och på hur stor sajten är. Oavsett metod blir arbetet enklare om det får en egen rad i din SEO-checklista.

Vilken metod passar din sajt?

För de flesta mindre sajter räcker den första metoden gott, medan stora kataloger med tusentals URL:er, där även crawl budget och crawl rate limit spelar in, i regel tjänar på sitemap-varianten.

Taggen i HTML-head på WordPress

Det vanligaste och enklaste alternativet är en <link>-rad per version i sidans <head>. Kör du en WordPress-sajt finns flera tillägg som hanterar detta automatiskt på en flerspråkig sajt, ofta samma tillägg som redan sköter din XML-sitemap:

• ett tillägg skriver taggarna åt dig
• returlänkar sätts automatiskt mellan versionerna
• du slipper redigera koden för hand

Sitemap-metoden för stora sajter

För stora sajter med många URL:er blir head-metoden tung att underhålla, och då samlar du i stället alla språkversioner i en XML-sitemap.

Så ser en sitemap-rad ut

Varje URL får ett eget element per version, med språk, land och adress i samma block. Det gör uppsättningen enklare att överblicka och uppdatera när nya sidor tillkommer - särskilt om du publicerar i takt med en innehållsstrategi - i stället för att du ska jaga rader i varje <head> på sajten.

HTTP-headers för PDF:er

För filer som saknar HTML-head, som PDF:er, anger du i stället informationen i HTTP-svaret tillsammans med rätt Content-Type:

• används för PDF:er och andra filer utan HTML
• kräver åtkomst till serverns HTTP-headers, eller till ditt CDN
• skickas med en korrekt OK Content-Type i svaret

Oavsett metod är ordningen densamma när du sätter upp det, och gör du det till en vana att lägga in taggarna direkt när en ny version skapas slipper du bygga upp en felskuld som blir svår att nysta i:

1. Kartlägg alla språk- och landsversioner du har av varje sida.
2. Bestäm rätt språk- och landskoder enligt ISO 639-1 och ISO 3166-1.
3. Lägg in taggarna med absoluta URL:er, en rad per version.
4. Se till att varje version refererar till sig själv och till alla andra.
5. Lägg till en x-default för besökare som inte matchar någon version.
6. Crawla sajten med ett SEO-verktyg och rätta saknade eller felaktiga returlänkar.

Rätt mot fel: två uppsättningar sida vid sida

Reglerna sätter sig oftast snabbare med ett exempel framför sig, så här är skillnaden mellan en uppsättning som fungerar och en som Google tyst ignorerar. Samma jämförelse är nyttig när du gör en konkurrentanalys och tittar på hur andra har löst sina språkversioner.

Fungerar hreflang mellan olika domäner?

Ja, och det spelar ingen roll hur dina versioner är uppdelade. Du kan koppla ihop en .se-domän med en .co.uk-domän så länge varje version pekar tillbaka på alla andra, och samma sak gäller de tre vanliga uppläggen:

• separata domäner, till exempel .se och .co.uk
• underdomäner, till exempel en.exempel.se
• undermappar, till exempel exempel.se/en/

När du jobbar över flera domäner blir det extra viktigt att kontrollera att samtliga versioner refererar till varandra korrekt, eftersom ett enda missat steg gör att Google ignorerar hela uppsättningen. Har du många marknader kan en guide om flerspråkig SEO hjälpa dig planera strukturen innan du börjar koda, och byter du domän på vägen bör du läsa på om SEO efter ett webbplatsbyte först.

Kom också ihåg att varje domän bygger sitt eget rykte. Länkar till din brittiska domän hjälper inte den svenska automatiskt, så både off-page SEO och länkbygge behöver planeras marknad för marknad. Redaktionella länkar och omnämnanden på det lokala språket väger i regel tyngre än köpta länkar, som är en risk oavsett land, och att leta upp omnämnanden utan länk är ofta den enklaste starten. Över tid är det så du bygger topical authority och den E-E-A-T Google letar efter på varje marknad.

Verktyg som kontrollerar dina hreflang-taggar

Du behöver inte göra allt för hand, och några SEO-verktyg fångar upp felen innan de hinner ställa till det. Notera att Google i dag inte har någon egen rapport för det här: den separata International Targeting-rapporten i Search Console togs bort i augusti 2022, så site-täckande kontroll gör du numera bäst i ett crawl-verktyg.

• Screaming Frog SEO Spider crawlar hela sajten och listar saknade eller felaktiga returlänkar åt dig.
• Plattformar som Ahrefs visar dessutom vilka av dina språkversioner som faktiskt har fått länkar.
• En validator online kontrollerar att koderna stämmer mot ISO 639-1 och ISO 3166-1.
• Webbläsarens källkodsvy låter dig granska en enskild sida och söka efter hreflang för hand.
• I Google Search Console följer du fortfarande indexering och hittar sidor som inte kommer med.

En enkel rutin räcker längre än de flesta tror, och tre snabba steg brukar vara nog innan du anser dig klar:

• crawla sajten och fånga saknade returlänkar
• kör koderna genom en validator
• öppna källkoden på en handfull sidor och ögna igenom

Hur ofta bör du kontrollera dina taggar?

Det här är inget du sätter upp en gång och sedan glömmer, för varje gång sajten ändras kan en returlänk falla bort utan att någon märker det. Gör en snabb kontroll vid de här tillfällena:

• när du lägger till ett nytt språk eller en ny marknad
• när du flyttar, slår ihop eller tar bort sidor och sätter upp redirects
• vid en större omläggning av URL-struktur eller domän, till exempel ett webbplatsbyte

Har du flera marknader är arbetet i regel värt besväret och hör hemma i din SEO-checklista, och har du bara en språkversion rör du inte taggen alls. Riktar du dig enbart mot en svensk ort - säg Sundsvall, Luleå, Norrköping, Södertälje, Sollentuna, Landskrona eller Vimmerby - lägger du hellre tiden på kartan och innehållet. Sätt annars returlänkarna ömsesidigt, håll dig till absoluta adresser och korrekta ISO-koder, och lägg till en x-default för dem som inte passar in någonstans. Då slutar fel sida dyka upp för fel besökare, och en kund i Storbritannien möts av engelska medan din kund i Sverige möts av svenska.