Vanliga hreflang-fel skickar nordiska kunder till fel språkversion

En norsk kund som landar på den svenska sidan är inte bara ett språkproblem utan en förlorad affärsrisk. Artikeln visar hur ni granskar hreflang, kanoniska länkar och landsversioner innan internationell synlighet och konvertering påverkas.

En svensk besökare söker efter er produkt, men Google skickar henne till den engelska eller norska sidan trots att en svensk version är publicerad och indexerad. När hreflang, canonical och indexeringssignaler pekar åt olika håll riskerar ni att betala för innehåll som leder till fel marknad, fel formulär och i slutänden färre relevanta affärer. Felet syns sällan genom att bara titta i sidans källkod, eftersom en tekniskt korrekt tagg kan motverkas av andra signaler. Den här artikeln visar hur SME-ägare och marknadsansvariga kan upptäcka problemet, prioritera rätt URL:er och ge webbyrån ett konkret felsökningsuppdrag.

En förvirrad tecknad svensk resenär dras mot fel av två färgkodade dörrar medan den rätta dörren står öppenAI-genererad

Så upptäcker ni att Google visar fel språk- eller landsversion

Fel språk märks först i sökdatan, inte i en enstaka googling från kontoret. Det första vi tittar på är därför resultatrapporten i Google Search Console, filtrerad på ett specifikt land och därefter uppdelad efter sökfråga och landningssida. Om svenska sökningar leder till adresser under /en/, eller om en svensk URL får exponeringar för norska sökfrågor i Norge, finns ett tydligt URL-par att undersöka. Det är mer handlingsbart än den allmänna observationen att ”Google väljer fel ibland”.

Analysen behöver göras sida för sida. En startsida kan fungera korrekt samtidigt som produkt-, kategori- och tjänstesidor kopplas till fel alternativ. Hreflang beskriver relationen mellan motsvarande URL:er, inte mellan hela webbplatser i största allmänhet. Därför säger en fungerande språkväxling på startsidan nästan ingenting om en produktsida vars översättning har fått en ny adress eller aldrig lagts in i samma språkkluster.

Manuella sökningar är användbara som illustration, men de är svaga som bevis. Resultatet påverkas av geografisk plats, valt gränssnittsspråk, enhet och tidigare beteende, och ett privat webbläsarfönster tar inte bort alla dessa faktorer. Webbläsarspråk och plats ska därför behandlas som felsökningssignaler snarare än ett facit för vilken version Google borde visa. Kontrollera gärna resultatet manuellt med ett kontrollerat språk och en relevant plats, men låt Search Console visa om mönstret faktiskt återkommer för den berörda marknaden.

Nästa steg är URL Inspection för de adresser som verkar konkurrera med varandra. Där framgår både vilken canonical sidan själv deklarerar och vilken canonical Google har valt. En canonical är signalen om vilken URL som ska betraktas som huvudversion när flera adresser liknar varandra. Om den svenska sidan deklarerar sin egen adress men Google ändå väljer den engelska som canonical, ligger problemet sannolikt djupare än en ensam hreflang-tagg.

Så här hade vi angripit det: först avgränsa en affärskritisk sidgrupp, därefter jämföra den svenska och felaktigt visade versionen som ett sammanhängande kluster. Granskningen omfattar sökfrågornas språk och avsikt, landningsadressen, Googles valda canonical, indexeringsstatus och de länkar som binder ihop språkversionerna. Den ordningen minskar risken för att en utvecklare justerar taggar i sidmallen medan den verkliga orsaken, exempelvis en omdirigering eller en felaktig canonical, lämnas kvar.

Webbanalysen kompletterar bilden genom att visa besök från oväntade länder på lokala landningssidor. En brittisk produktsida som huvudsakligen tar emot svensk organisk trafik kan vara värd att kontrollera, särskilt om sidan visar annan valuta, andra leveransvillkor eller ett formulär som går till fel säljteam. Analysen bevisar inte ensam att Google har gjort ett felaktigt språkval, men den synliggör affärskonsekvensen. Då går det att prioritera URL:er där fel språk faktiskt skapar friktion, i stället för att behandla varje teknisk avvikelse som lika brådskande.

Hreflang-klustret måste innehålla rätt URL:er och ömsesidiga referenser

Mer hreflang är inte automatiskt bättre hreflang. Den vanliga rekommendationen att koppla ihop alla språkversioner håller bara när sidorna verkligen motsvarar varandra. En svensk produktsida och en engelsk kategorisida blir inte relevanta alternativ bara för att de ligger på samma nivå i CMS:et. Den falska kopplingen kan tvärtom göra det svårare för Google att förstå vilken sida som passar sökaren.

Ett språkkluster består av en sida och dess faktiska språk- eller regionsalternativ. Varje publicerad version bör normalt referera till sig själv och till de övriga versionerna med samma uppsättning adresser. Om /sv/tjanster/ anger /en/services/ som engelskt alternativ ska den engelska sidan också peka tillbaka på den svenska. Saknas returreferensen kan Google bortse från just den relationen, eftersom kopplingen inte har bekräftats från båda håll.

En typisk HTML-referens kan återges som <link rel="alternate" hreflang="sv" href="https://example.com/sv/tjanster/">. Självreferensen på den svenska sidan använder samma svenska URL, medan övriga rader pekar på de slutliga adresserna för exempelvis norska och brittisk engelska. Enligt Google Search Central ska alternativa versioner referera ömsesidigt till varandra, och fullständiga URL:er bör användas i implementationen.

Språkdelen anges normalt med en språkkod enligt ISO 639-1. En frivillig regionsdel kan läggas till med en landskod enligt ISO 3166-1 alpha-2, vilket gör en-GB giltigt medan en-UK är fel. För norskt bokmål används vanligtvis nb. Regionskoden ska inte användas som en lös marknadsföringsetikett; den signalerar en konkret regional målgrupp, medan sv ofta räcker för innehåll som riktar sig till svenskspråkiga oavsett land.

Fallgropen vi ser oftast i upplägget är att sidmallen genererar tekniskt välformade länkar utan att förstå innehållet. En AI-översatt titel kan få CMS:et att anta att en motsvarande produktsida finns, trots att produkten inte säljs på den marknaden eller den lokala adressen leder till en generell kategori. Lämna hellre en irrelevant version utanför klustret än att skapa en påhittad motsvarighet. Hreflang är en relevanssignal, inte ett krav på att varje URL måste finnas på varje språk.

x-default fyller en annan funktion. Den kan peka på en neutral global version eller en språk- och marknadsväljare för besökare som inte matchar de angivna alternativen. Den ersätter däremot inte tydliga språkversioner som sv, nb eller en-GB. Om alla användare skickas till x-default och sedan automatiskt omdirigeras vidare skapas ett extra lager där både sökmotorer och människor kan hamna fel.

Vid felsökning av hreflang i WordPress räcker det därför inte att kontrollera att ett flerspråkstillägg är aktiverat. Webbyrån behöver granska hur tillägget mappar inlägg, produkter, taxonomier och specialbyggda innehållstyper. WooCommerce-produkter kan exempelvis ha andra översättningsrelationer än redaktionella sidor, och gamla sluggar kan ligga kvar i tilläggets data trots att den synliga språkväxlaren ser korrekt ut. Automatiken sparar arbete först när den underliggande mappningen är sann.

En sprucken kompass med färgade språkmarkörer som pekar åt motstridiga håll och uttrycker osäkerhetAI-genererad

Canonical, omdirigeringar och indexering kan upphäva korrekt hreflang

En perfekt formaterad hreflang-tagg kan vara verkningslös när destinationssidan inte är ett valbart sökresultat. Google använder hreflang för att välja mellan alternativa URL:er, men taggen kan inte göra en blockerad, omdirigerad eller bortkanoniserad sida indexerbar. Därför bör canonical och indexeringsstatus granskas före detaljjusteringar av språkkoder. Annars riskerar webbyrån att putsa den svagaste signalen medan den starkare konflikten består.

Canonical-konflikten är särskilt vanlig på flerspråkiga webbplatser som har byggts från en gemensam mall. Om /sv/produkt/ har canonical till /en/product/ säger sidan i praktiken att den engelska adressen är den föredragna huvudversionen. Samtidigt försöker hreflang beskriva adresserna som separata lokala alternativ. Varje unik, indexerbar språkversion bör därför normalt ha en canonical som pekar på den egna slutliga URL:en.

Kontrollen ska omfatta HTTP-status, robots-regler, meta robots, deklarerad canonical och den HTML som faktiskt renderas. En server kan leverera hreflang i den ursprungliga HTML-koden medan ett skript senare skriver över eller duplicerar taggarna. För företaget innebär detta att en sida kan se riktig ut i CMS:ets redigeringsvy men fortfarande skicka motstridiga signaler till Google. Det som räknas är den version sökmotorn kan hämta och tolka.

Hreflang-referenser bör gå direkt till den slutliga, indexerbara adressen. En länk till en gammal svensk slug som omdirigerar till en ny skapar onödig osäkerhet och gör klustret beroende av att omdirigeringskedjan fungerar. En referens till en URL som returnerar ett fel, är märkt noindex eller blockeras för sökmotorer är ännu svagare. Den lokala versionen finns då kanske för användaren, men är inte en stabil kandidat för sökresultatet.

Automatisk omdirigering efter IP-adress eller webbläsarspråk låter ofta som god service, men kan bli ett hinder. En svensk person som befinner sig i Norge kanske vill besöka den svenska sidan, medan en norsk inköpare på ett internationellt företagsnätverk kan få en plats som inte motsvarar verksamheten. Om samma omdirigering träffar sökmotorernas hämtning kan alternativen bli svårare att nå och utvärdera. En synlig språkväxlare med vanliga, crawlbara länkar ger både människor och sökmotorer en robust väg mellan versionerna.

Det går att implementera hreflang i HTML, i HTTP-headern eller i en XML-sitemap. Att använda alla metoder samtidigt gör inte signalen starkare; det ökar främst antalet platser där uppsättningarna kan börja skilja sig åt. Välj gärna en huvudsaklig implementation som webbyrån kan kvalitetssäkra och underhålla. Om parallella metoder behövs ska samma URL:er, språk- och regionskoder förekomma i samtliga.

Även sidans synliga innehåll behöver stödja den tekniska signalen. En svensk URL vars navigering, titel och merpart av produkttexten fortfarande är på engelska skickar ett blandat språkbudskap. Detsamma gäller internlänkar som konsekvent leder svenska användare till engelska sidor. Hreflang hjälper Google att välja mellan begripliga alternativ, men kompenserar inte för en språkversion som bara är lokaliserad till namnet.

Rätta, validera och följ upp på URL-nivå – inte bara i sidmallen

Rättningen är klar först när de verkliga URL:erna fungerar som ett sammanhängande system. Efter kodändringen bör webbplatsen crawlas och resultatet läggas i en matris där varje indexerbar lokal sida matchas mot sina faktiska motsvarigheter. Matrisen gör luckor synliga som annars försvinner i mallkod: saknade översättningar, gamla adresser, omdirigeringar och canonical-signaler till fel språk. Följande tabell är ett förenklat, hypotetiskt exempel på hur underlaget kan se ut.

Exempel på hreflang-matris för en flerspråkig webbplats
Innehållsgrupp sv nb en-GB x-default Självreferens Returlänkar Canonical Indexerbar
Cirkulationspump X200 /sv/produkter/cirkulationspump-x200/ /nb/produkter/sirkulasjonspumpe-x200/ /en-gb/products/circulation-pump-x200/ /products/circulation-pump-x200/ Ja Ja Egen slutlig URL Ja
Installationstjänst /sv/tjanster/installation/ /nb/tjenester/installasjon/ → omdirigerar /en-gb/services/installation/ /services/installation/ Ja Nej, norsk referens är gammal Egen URL på sv och en-GB Nej för angiven nb-URL
Guide om filterunderhåll /sv/guider/filterunderhall/ Saknas avsiktligt /en-gb/guides/filter-maintenance/ /guides/filter-maintenance/ Ja Ja mellan publicerade versioner Egen slutlig URL Ja
Kategori för reservdelar /sv/produkter/reservdelar/ /nb/produkter/reservedeler/ /en-gb/products/spare-parts/ /products/spare-parts/ Ja Ja Svensk URL pekar felaktigt på en-GB Tekniskt ja, men signalerna strider

Tabellen visar varför en enkel kontroll av om taggen ”finns” ger ett falskt lugn. Installationstjänstens norska referens behöver uppdateras till den slutliga adressen, medan guiden inte behöver någon norsk länk alls när en verklig norsk motsvarighet saknas. Kategorien för reservdelar har fullständiga returlänkar men en canonical-konflikt som kan få Google att välja den brittiska sidan. Problemen kräver alltså olika rättningar trots att alla berör samma teknik.

En crawler som Screaming Frog eller Sitebulb kan exportera hreflang-referenser, svarskoder och returlänkar över hela webbplatsen. Verktyget bör konfigureras för att följa slutliga URL:er och identifiera ogiltiga språk- eller landskoder, duplicerade taggar, saknade självreferenser och länkar till icke-indexerbara adresser. Exporten ersätter dock inte innehållsbedömningen. Ett verktyg kan se att två URL:er länkar till varandra, men inte alltid avgöra att den ena beskriver en produkt och den andra en bred kategori.

Den manuella granskningen bör omfatta flera sidtyper, exempelvis startsida, kategori, produkt, tjänst och redaktionellt innehåll. CMS bygger ofta metadata på olika sätt i olika mallar, särskilt när WordPress kombineras med e-handel, egna fält eller separata översättningsflöden. Ett representativt urval visar om felet är systematiskt eller begränsat till vissa innehållstyper. När mönstret är känt kan webbyrån rätta generatorn i stället för att lappa enskilda sidor.

Efter rättningen behöver Google genomsöka och omvärdera adresserna innan sökresultatet kan förändras. Följ samma landningssidor och sökfrågor i Search Console, och kontrollera de mest problematiska URL:erna med URL Inspection. Bevakningen ska handla om vart relevanta exponeringar och klick går, inte bara om taggarna nu kan hittas i källkoden. En tekniskt godkänd implementation har inget affärsvärde om svenska sökare fortfarande landar på en version som skapar tvekan eller leder till fel kontaktväg.

Webbanalysen bör därför kopplas till den tekniska uppföljningen. Relevant organisk trafik per lokal landningssida, engagemang med sidans centrala innehåll och slutförda kontakt- eller köpflöden säger mer än den totala trafikvolymen. Om rätt språkversion börjar få mer relevant trafik men konverteringen fortfarande är svag kan nästa problem ligga i lokaliseringen, erbjudandet eller formuläret. Hreflang återställer förutsättningarna för relevans; taggen löser inte automatiskt alla delar av kundresan.

Prioritera först sidor med tydlig kommersiell betydelse och dokumenterade tecken på fel marknad. Det kan vara produkter som driver offertförfrågningar, tjänstesidor för lokala säljteam eller guider som fungerar som ingång till ett köp. Därefter kan samma metod rullas ut över resten av sajten. På så sätt läggs utvecklingstid där fel språk riskerar verkliga intäkter, utan att mindre metadataavvikelser tillåts styra hela projektet.

Hreflang är slutligen en signal, inte en garanti. Google kan fortfarande välja en annan version utifrån innehållets språk, canonical-signaler, internlänkar och användarens plats eller språkinställning. Målet är därför inte att tvinga fram ett resultat med fler taggar, utan att göra alla relevanta signaler konsekventa. När de pekar åt samma håll blir det lättare för sökmotorn att välja den version som bäst motsvarar sökningen.

En beslutsam tecknad mekaniker som varsamt riktar in tre färgade kugghjul märkta språk, canonical och indexeringAI-genererad

När hreflang är korrekt i koden men fel version ändå visas

Fel språk upptäcks i sökdata – inte genom en enstaka manuell googling

En manuell sökning visar vad en viss person ser under vissa omständigheter, inte hur en hel marknad behandlas. Segmentera i stället Search Console efter sida, land och sökfråga och leta efter återkommande kombinationer där språk, marknad och landningsadress inte hänger ihop. Granska därefter berörda adresser med URL Inspection och jämför Googles valda canonical med sidans deklarerade canonical. Då blir det möjligt att skilja ett hreflang-fel från ett bredare indexerings- eller dupliceringsproblem.

Exempel: Om den svenska URL:en får exponeringar för norska sökfrågor i Norge bör den svenska och norska adressen granskas som ett gemensamt kluster. Jämför inte bara trafiken; följ också varje hreflang-referens, canonical och omdirigering mellan de två sidorna.

En enda saknad returlänk kan göra klustret ofullständigt

Varje indexerbar språk- eller regionsversion bör normalt bekräfta relationen genom att referera till sig själv och de övriga publicerade versionerna. Ett asymmetriskt kluster uppstår när exempelvis den engelska sidan länkar till svenska och tyska, medan den tyska sidan saknar länken tillbaka eller använder en utfasad svensk adress. Då kan Google ignorera den obekräftade kopplingen även om de andra taggarna är korrekt skrivna. Returlänkar är alltså inte kosmetisk kodkvalitet, utan en del av hur relationen mellan adresserna verifieras.

Exempel: Screaming Frog eller Sitebulb kan exportera samtliga referenser och markera uteblivna returlänkar, ogiltiga språkkoder och URL:er utanför det förväntade klustret. Exporten bör sedan stämmas av mot sidornas verkliga innehåll, eftersom teknisk symmetri inte bevisar att sidorna är motsvarigheter.

Canonical, omdirigeringar och noindex kan väga tyngre än rätt hreflang

Hreflang hjälper Google att välja mellan lokala alternativ som faktiskt kan indexeras. Om den brittiska sidan har canonical till den amerikanska versionen, omdirigeras eller är märkt noindex är den inte längre en stabil brittisk kandidat. Taggen kan vara syntaktiskt felfri och ändå förlora mot signalen att en annan URL är huvudversion. Därför granskar ett erfaret team alltid sidans valbarhet innan språkreferenserna felsöks isolerat.

Exempel: För varje berörd URL kontrolleras HTTP-status, robots-direktiv, deklarerad canonical och Googles valda canonical. Först när sidan är direkt åtkomlig, indexerbar och självkanonisk går det att bedöma om hreflang-klustret fungerar på rimliga villkor.

Mallvalidering missar de fel som bara finns på vissa URL:er

En korrekt mall visar hur systemet är tänkt att fungera, inte hur alla publicerade sidor faktiskt fungerar. Produkter kan sakna översättningar, kategorisluggar kan ha ändrats och redaktionella sidor kan använda ett annat tillägg eller en annan datakälla. Valideringen behöver därför utgå från slutliga URL:er som hämtas ur renderad HTML, HTTP-header eller XML-sitemap. Det är först då gamla länkar, dubbla uppsättningar och omdirigerande alternativ blir synliga.

Exempel: Ta ut problematiska landningssidor från Search Console, crawla hela deras språkkluster och kontrollera därefter varje berörd version i URL Inspection. Att enbart testa startsidan kan annars dölja fel som finns i hundratals produktrelationer trots att den globala sidmallen ser korrekt ut.

Frågor som avslöjar varför Google visar fel språk

Pekar varje språkversion på sig själv och ömsesidigt på alla motsvarande versioner?

Varje sida bör normalt ha en självrefererande hreflang och länka till sina verkliga motsvarigheter på övriga språk. Om den svenska sidan pekar på den engelska men den engelska inte pekar tillbaka kan Google bortse från den obekräftade relationen. Kontrollera också att båda sidorna använder samma slutliga adresser; en returlänk till en gammal URL är inte likvärdig med en direkt länk till den indexerbara sidan. Uppgiften är att verifiera hela klustret, inte bara raden som syns på den svenska sidan.

Använder vi giltiga språk- och landskoder som motsvarar målgruppen?

Språket anges med en språkkod, medan region är ett valfritt tillägg, exempelvis sv-SE eller en-GB. Felvända eller påhittade koder kan göra att Google inte kan tolka målgruppen. Alltför snäva regionskoder kan också skapa onödig komplexitet om innehållet egentligen riktar sig till alla som läser språket. Börja med språkets faktiska publik och lägg bara till region när sidan verkligen är lokaliserad för en särskild marknad.

Är de alternativa språkversionerna indexerbara och konsekventa med sina canonical-taggar?

En hreflang-URL som omdirigerar, blockeras, har noindex eller canonical till ett annat språk skickar en svag eller motstridig signal. Varje unik lokal version bör normalt vara direkt åtkomlig, indexerbar och ha canonical till sin egen slutliga adress. Kontrollera både vad sidan deklarerar och vad Google faktiskt har valt. Skillnaden mellan dessa två uppgifter kan förklara varför en till synes korrekt svensk sida ändå ersätts av en engelsk i sökresultatet.

Kopplar vi ihop verkliga motsvarigheter, eller bara sidor som råkar ligga på samma URL-nivå?

Hreflang ska länka mellan sidor med samma huvudsakliga innehåll och syfte, exempelvis svenska och engelska versioner av samma produktsida. En produktsida bör inte kopplas till en startsida, kategorisida eller innehållsmässigt avvikande sida bara för att en direkt översättning saknas. Den kontrarianska men säkrare lösningen är ofta att utelämna den referensen. Ett mindre men sanningsenligt kluster ger Google tydligare information än en komplett tabell fylld med falska motsvarigheter.

Skickar sidans innehåll och övriga signaler samma språkbudskap som hreflang?

Google tolkar hreflang tillsammans med synlig text, sidtitlar, navigering, internlänkar och URL-struktur. En svensk sida som till stor del innehåller engelska produktbeskrivningar kan därför uppfattas som mindre tydligt svensk, även när taggarna är korrekta. Språkväxlaren bör leda direkt till motsvarande sida med vanliga länkar, och internlänkningen bör hålla användaren inom den valda versionen när det är relevant. Teknisk internationell SEO fungerar bäst när kod och innehåll beskriver samma verklighet.

Börja med ett begränsat antal viktiga sidgrupper och följ varje hreflang-länk hela vägen till den slutliga, indexerbara URL:en. När språk, canonical, internlänkning och sidinnehåll säger samma sak får Google bättre förutsättningar att visa rätt version för rätt sökare. Ett erfaret team eller en teknisk partner prioriterar först de landningssidor där fel språk påverkar leads och försäljning, rättar grundorsaken och följer sedan upp samma URL-par i sökdatan. Det gör hreflang till en kontrollerbar del av webbplatsens marknadsarbete i stället för ännu en tagg som antas fungera bara för att den finns i koden.

Ämnen
Dela

FAQ

Vanliga frågor

01

Hur ser jag om Google visar fel språkversion av min webbplats?

Sök efter viktiga sidtyper och varumärkestermer från respektive målmarknad och kontrollera vilken URL Google visar. Jämför sedan exponering och klick per sida och land i Google Search Console samt granska sidans hreflang, canonical, indexerbarhet och omdirigeringar.

02

Vad är skillnaden mellan hreflang och lang-attributet?

Hreflang hjälper sökmotorer att välja rätt språk- eller landsversion av en URL, medan HTML-attributet lang beskriver sidans språk för bland annat webbläsare och hjälpmedel. En flerspråkig webbplats behöver normalt båda, eftersom de fyller olika funktioner.

03

Hur fungerar hreflang tillsammans med canonical?

Canonical anger vilken URL som är huvudversion för indexering, medan hreflang kopplar samman alternativa språk- och landsversioner. Varje indexerbar språkversion bör normalt ha en canonical till sig själv; om alla versioner pekar canonical till samma URL kan Google bortse från hreflang-klustret.

04

Hur lägger man in hreflang i WordPress utan att skapa fel?

Använd en flerspråkslösning som genererar hreflang mellan motsvarande, publicerade sidor och kontrollera att kopplingarna är ömsesidiga. Granska dessutom den renderade HTML-koden och varje faktisk URL, eftersom plugininställningar inte skyddar mot felaktiga canonical-taggar, omdirigeringar eller saknade översättningar.

05

Räcker en hreflang checker eller Chrome extension för att validera taggarna?

Nej, ett hreflang-verktyg kan hitta saknade eller felaktiga taggar men visar inte alltid hela indexeringsproblemet. Kontrollera även att mål-URL:erna svarar korrekt, är indexerbara, har rätt canonical och refererar tillbaka till den granskade sidan.

Fler artiklar