Vad hreflang faktiskt gör – och inte gör
Hreflang är ett HTML-attribut som placeras i <head> på en sida och talar om för sökmotorer vilket naturligt språk och vilken geografisk marknad sidan riktar sig till. Attributet tar ett värde enligt BCP 47-standarden, exempelvis sv för svenska utan landsbegränsning, en-GB för brittisk engelska eller en-US för amerikansk engelska. Syftet är att hjälpa sökmotorn att välja rätt URL när en användare söker på ett visst språk eller från ett visst land.
Hreflang ger inte en garanti att en viss version visas. Undersök därför faktiska språkversioner, huvudtext, status, canonical och returhänvisningar. Ett fel kan vara en trasig URL, fel språk eller en saknad motsvarighet; logga vilket förhållande ni faktiskt har kontrollerat i stället för att förklara sökmotorns val med en obestyrkt faktorlista.
Hreflang löser inte heller frågor om valuta, lokal prisinformation, lokala kontaktuppgifter eller fysisk närvaro på en marknad. De frågorna måste hanteras i sidinnehållet. En brittisk användare som möts av en sida på korrekt engelska men med priser i SEK och ett svenskt telefonnummer har inte fått en lokaliserad upplevelse – bara en språkversion. Det är en vanlig missuppfattning att hreflang ensamt räcker för internationell SEO.
Skilj också hreflang tydligt från canonical-taggen. Canonical pekar på den föredragna URL:en inom en grupp av duplikat eller nära-duplikat på samma marknad och samma språk. Hreflang pekar på avsiktligt olika versioner för olika marknader. De kan och ska ofta samexistera på en sida, men de löser olika problem. Mer om hur canonical fungerar i kombination med indexeringsstyrning finns i guiden om canonical, robots och indexering.
Språk, land, valuta och plats – fyra separata dimensioner
En av de vanligaste konceptionella felen vid internationell SEO är att behandla dessa fyra dimensioner som en enda fråga. Hreflang hanterar språk och, om du anger ett landssuffix, den avsedda marknaden. Valuta och lokala priser hanteras av sidinnehållet. Fysisk närvaro och lokal kontaktinformation hanteras av innehåll, eventuellt strukturerad data och Google Business Profile om det är relevant.
För en typisk svensk B2B-sajt som vill nå den brittiska marknaden är beslutet om URL-struktur det första strategiska vägvalet. De vanligaste alternativen är undermappar (/en/ eller /en-gb/ under samma domän), subdomäner (en.example.com) eller separata domäner (example.co.uk). Undermappar är i de flesta fall enklast att förvalta och konsoliderar auktoritet under en domän. Separata domäner ger starkast geografisk signal men kräver att du bygger upp länkprofil och auktoritet separat för varje domän. Subdomäner behandlas av de flesta sökmotorer som delvis separata egenskaper.
Om du planerar en brittisk engelska-version men ännu inte har publicerat den: skapa inga platshållar-URLs. En URL som existerar men saknar riktigt innehåll skapar en tunnelsida och kan skada crawlbudgeten. Dokumentera istället den planerade versionen i din URL-karta som en skuld att adressera när innehållet faktiskt är klart. Frågor om hur du strukturerar en URL-karta inför lansering behandlas i guiden om SEO-migrering och säker lansering.
Valutafrågan är inte trivial. Om du visar priser i GBP men ditt betalningsflöde hanterar valutor inkonsekvent, eller om kontraktsvalutan skiljer sig från den visade valutan, skapar det förvirring för användaren och potentiellt juridiska problem. Hreflang löser ingenting av detta – det är ett innehålls- och systemfråga.
BCP 47-koder och vanliga misstag med språkkoder
BCP 47 är den standard som definierar godkända språk- och regionkoder för hreflang. Språkkoden är alltid en ISO 639-1-kod med två gemena bokstäver: sv för svenska, en för engelska, de för tyska. Regionkoden är en ISO 3166-1 alpha-2-kod med två versaler: GB för Storbritannien, SE för Sverige, US för USA. Kombinationen skrivs med bindestreck: en-GB, sv-SE.
Vanliga kodfel inkluderar att använda landets namn istället för koden (sweden istället för sv), att blanda versaler och gemener felaktigt (EN-gb), att använda ISO 3166-1 alpha-3-koder med tre bokstäver (GBR är fel, GB är rätt), eller att ange en regionkod utan en giltig språkkod. Felaktiga koder ignoreras stilla – du ser inget felmeddelande, men taggen har ingen effekt.
En subtil men viktig distinktion: en utan regionkod täcker alla engelsktalande marknader utan specifik geografisk begränsning. en-GB signalerar brittisk engelska specifikt. Om du har en enda engelskspråkig version och inte vill begränsa den till en specifik marknad kan en vara ett rimligare val. Om du däremot har separata versioner för UK och US – med olika priser, stavning och kontaktuppgifter – ska du använda en-GB och en-US respektive.
Parmatrisen: self-referens, returlänkar och x-default
Hreflang fungerar som ett nätverk av ömsesidiga deklarationer. Varje URL som ingår i en hreflang-grupp måste deklarera samtliga URL:er i gruppen – inklusive sig själv. Om du har tre versioner (svenska, brittisk engelska och en x-default) måste alla tre URL:er innehålla alla tre link rel="alternate"-taggar. En returlänk som saknas gör att sökmotorn kan välja att ignorera hela det paret.
Self-referensen – att en sida pekar på sig själv med rätt hreflang-värde – är obligatorisk och ofta bortglömd. Den signalerar att sidan är medveten om sin egen roll i gruppen. Utan self-referens är implementeringen tekniskt ofullständig.
Nedan visas ett fullständigt HTML-exempel för en startsida på svenska (/) med en planerad brittisk engelska-version (/en/) och x-default:
<!-- På / (svenska startsidan) -->
<link rel="alternate" hreflang="sv" href="https://www.example.se/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.se/en/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.se/" />
<!-- På /en/ (brittisk engelska-versionen) -->
<link rel="alternate" hreflang="sv" href="https://www.example.se/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.se/en/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.se/" />Observera att x-default på båda sidorna pekar på den svenska startsidan. Det är ett redaktionellt beslut: i det här exemplet är svenska den primära marknaden och den svenska versionen är den lämpligaste fallback-URL:en för en besökare utan matchande språkkontext. Om du hade en dedikerad språkväljarsida, exempelvis /choose-language/, vore den ett alternativt val för x-default.
En fullständig parmatris för en sajt med fem sidor per språk skulle se ut som en tabell där varje rad är en URL och varje kolumn är en hreflang-destination. Alla celler i matrisen måste vara ifyllda för att implementeringen ska vara symmetrisk. För större sajter är detta opraktiskt att hantera manuellt – CMS-stöd eller sitemap-metoden är då mer skalbar.
Hreflang i sitemap – när och hur
Sitemap-metoden för hreflang är ett alternativ till HTML-taggar i <head> och är särskilt användbar för sajter med många sidor där det är svårt att injicera taggar via CMS. Metoden innebär att du deklarerar hreflang-relationerna i XML-sitemapen istället för i varje enskild sidas HTML.
En sitemap-post för hreflang ser ut så här:
<url>
<loc>https://www.example.se/</loc>
<xhtml:link
rel="alternate"
hreflang="sv"
href="https://www.example.se/" />
<xhtml:link
rel="alternate"
hreflang="en-GB"
href="https://www.example.se/en/" />
<xhtml:link
rel="alternate"
hreflang="x-default"
href="https://www.example.se/" />
</url>
<url>
<loc>https://www.example.se/en/</loc>
<xhtml:link
rel="alternate"
hreflang="sv"
href="https://www.example.se/" />
<xhtml:link
rel="alternate"
hreflang="en-GB"
href="https://www.example.se/en/" />
<xhtml:link
rel="alternate"
hreflang="x-default"
href="https://www.example.se/" />
</url>Kräver namespace-deklarationen xmlns:xhtml="http://www.w3.org/1999/xhtml" i rot-elementet <urlset>. Sitemap-metoden kräver samma symmetri som HTML-metoden: varje URL som ingår i en grupp måste deklareras i sitemapen med fullständiga returlänkar.
En viktig nackdel med sitemap-metoden är att sitemapen måste hållas synkroniserad med faktiska publicerade sidor. Om en sida tas bort eller får en ny URL men sitemapen inte uppdateras skapas inkonsekvenser som försvårar crawling. Om din sajt använder JavaScript-rendering för att generera innehåll finns det ytterligare aspekter att beakta – mer om det i guiden om JavaScript SEO och läsbar HTML.
Faktisk innehållsöversättning och lokalisering av pris- och kontaktinfo
En tekniskt korrekt hreflang-implementation är meningslös om sidornas innehåll inte faktiskt är lokaliserat. Med lokalisering menas inte enbart maskinöversättning av brödtext, utan en genomtänkt anpassning av hela sidans kommunikation till målmarknaden. Det inkluderar prisinformation i lokal valuta, lokala kontaktuppgifter (telefonnummer med landskod, lokal e-postadress om relevant), lokala referensfall, och terminologi anpassad till den brittiska marknaden snarare än en direkt ordagrann översättning från svenska.
En brittisk besökare som möter termen "offert" direkt översatt till "quote" utan kontextuell anpassning av vad tjänsten kostar, hur betalning sker och vem man kontaktar, har inte fått en genuint lokaliserad upplevelse. Sökmotorn kan servera rätt URL, men konverteringen uteblir om innehållet inte håller.
För B2B-tjänster med komplexa produkter eller tjänster innebär lokalisering också att anpassa CTA:er och formulärtexter. "Begär offert" på svenska är inte identiskt med "Request a quote" eller "Get a proposal" på brittisk engelska i termer av semantisk konnotation och förväntad responstid. Dessa beslut påverkar konverteringsgraden men är innehållsfrågor, inte tekniska SEO-frågor.
En illustrativ men hypotetisk situation: ett svenskt mjukvarubolag (låt oss kalla det Exemplet AB, ett illustrativt bolag) lanserar /en/ med en maskinöversatt kopia av alla svenska sidor. Prisinformationen visar fortfarande SEK-priser. Kontaktsidan har ett svensk telefonnummer utan landskod. En brittisk besökare som hittar sidan via sökning lämnar snabbt. Hreflang-implementeringen var tekniskt korrekt, men den affärsmässiga frågan – är sidan faktiskt användbar för en brittisk köpare? – var obesvarad. Det är inte ett tekniskt SEO-problem, det är ett innehålls- och affärsproblem.
Beslutstabell: när hreflang-varianter behövs och när de inte behövs
| Situation | Hreflang behövs? | Rekommenderad åtgärd | Diagnostisk signal att bevaka |
|---|---|---|---|
| Sajt på enbart svenska, ingen internationell expansion planerad | Nej | Ingen hreflang. Fokusera på canonical och indexeringskontroll istället. | Kontrollera att inga sidor felaktigt rankar för engelska söktermer du inte vill äga. |
| Svenska + brittisk engelska, båda versionerna publicerade och fullständiga | Ja | Fullständig parmatris med sv och en-GB, samt ett avsiktligt valt x-default när det behövs. Self-referens och returlänkar på alla URL:er. | Saknade returlänkar identifierade via crawl. Verifiera att canonical och hreflang inte pekar i olika riktningar. |
| Svenska publicerad, engelska planerad men inte klar | Nej ännu | Dokumentera engelska URL:er som framtida skuld. Implementera hreflang när /en/-sidor är publicerade med faktiskt innehåll. | Inga platshållar-URLs. Ingen hreflang-tagg på svenska sidor som pekar på opublicerade engelska URLs. |
| Engelska version existerar men saknar returlänk till svenska | Delvis | Rätta returlänken på engelska sidan omedelbart. Asymmetrisk parmatris ger ingen tillförlitlig signal. | Crawl-verktyg som Screaming Frog markerar saknade returlänkar. Åtgärda innan vidare expansion. |
| Sajt med tre eller fler språk, varav ett saknar fullständiga översättningar av alla sidor | Ja för kompletta par, nej för saknade | Implementera hreflang enbart för de URL-par som har faktiska motsvarigheter. Dokumentera saknade versioner separat. | Säkerställ att hreflang-gruppers storlek är konsekvent. Sidor med olika antal taggar per grupp är ett diagnostiskt varningstecken. |
| Subdomän-baserad struktur (en.example.se) istället för undermapp | Ja | Hreflang fungerar tekniskt likadant. Säkerställ att crawlern har åtkomst till subdomänen och att Search Console är konfigurerat för båda egenskaperna. | Verifiera att subdomänen inte blockeras av robots.txt och att canonicals på subdomänen pekar på subdomänens egna URL:er, inte på rooten. |
Arbetsblad · Steg för steg
Validera verkliga språkversioner
Markera det du har dokumenterat. Använd kontrollfrågorna och ladda ned arbetsbladet för ert eget underlag.
Dina egna arbetsnoteringar, inget kvalitets- eller rankingbetyg. Markeringarna sparas inte och skickas inte till RANGEL.
Visa arbetsbladets fält
Hreflang och internationell SEO: bygg verkliga språkversioner https://rangel.se/guider/hreflang-och-internationell-seo/ LÄSARUPPGIFT Implementera och validera en fullständig hreflang-parmatris för en sajt med svenska och brittisk engelska, inklusive self-referens, x-default och en tydlig plan för versioner som ännu inte publicerats. Validera verkliga språkversioner [ ] Inventera publicerade motsvarigheter Underlag att dokumentera: Dokumentera fullständiga URL:er, faktisk språkversion, marknad och saknat innehåll. Mitt underlag: Ansvarig / nästa steg: [ ] Kontrollera par och returhänvisning Underlag att dokumentera: Spara status, canonical och språkgrupp; jämför HTML, header eller sitemap enligt vald metod. Mitt underlag: Ansvarig / nästa steg: [ ] Verifiera lokal kundväg Underlag att dokumentera: Testa språkval, aktuella erbjudanden och kontakt; inga opublicerade språk-URL:er får ingå. Mitt underlag: Ansvarig / nästa steg: Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.
RANGELs arbetsmetod och illustrativa typfall
Nedan beskrivs RANGELs arbetsmetod för hreflang-implementering som ett strukturerat ramverk, illustrerat med tre hypotetiska men materiellt olika typfall. Typfallen är konstruerade för att visa hur beslut ser olika ut beroende på sajtens situation – de är inte anonymiserade kundcase.
Typfall A: Ny /en/-sektion under befintlig svensk domän
En illustrativ svensk IT-konsultfirma, låt oss kalla den Nordkod AB (hypotetiskt bolag), har en etablerad sajt på nordkod.se med tjänstesidor, en blogg och en kontaktsida. Ledningen beslutar att expandera till den brittiska marknaden och vill bygga nordkod.se/en/. Vid tidpunkten för beslutet finns ingen publicerad engelsk text.
Rätt åtgärd i detta skede är att inte implementera hreflang. Istället skapas en URL-inventering som mappar varje svensk URL till en planerad engelsk motsvarighet. Dokumentet noterar vilka sidor som ska översättas i första fasen och vilka som lämnas utan engelsk version tillsvidare. När de engelska sidorna väl är publicerade med fullständigt lokaliserat innehåll – inklusive GBP-priser och brittisk kontaktinformation – implementeras hreflang-parmatrisen.
Antag att fas ett täcker fem sidor: startsida, om oss, tjänster, kontakt och en case-sida. Det ger tio URL:er totalt (fem svenska, fem engelska). Varje URL behöver tre link rel="alternate"-taggar: sv och en-GB, samt ett avsiktligt valt x-default när det behövs. Det är 30 taggar totalt. Om blogginlägg lämnas utan engelsk version ska de inte ha en hreflang-tagg som pekar på en obefintlig engelsk URL.
Typfall B: Befintlig engelska-sektion med asymmetrisk parmatris
En illustrativ SaaS-leverantör, låt oss kalla den Verktygslådan.se (hypotetiskt), har haft en /en/-sektion i tre år. Vid en teknisk genomgång identifieras att engelska produktsidor saknar returlänkar till sina svenska motsvarigheter. Svenska sidor pekar på engelska, men engelska sidor pekar inte tillbaka. Parmatrisen är asymmetrisk.
Konsekvensen är att sökmotorn behandlar en del av implementeringen som opålitlig. Åtgärden är att genomföra en fullständig crawl, exportera alla hreflang-taggar per URL, och jämföra src-URL och href-URL i varje tagg med en parmatris-kontroll. Varje rad i matrisen som saknar sin spegelpost markeras för rättning. En hreflang-granskning kan kontrollera språkversioner och deras returhänvisningar – Screaming Frogs audit-funktion är ett etablerat verktyg för detta ändamål. Se Screaming Frogs guide till hreflang-audit för teknisk genomgång av metoden.
Efter rättning av returlänkarna bör implementeringen valideras på nytt. Det är inte ovanligt att rättningen av returlänkar också avslöjar URL-inkonsekvenser: att svenska sidor pekar på en HTTP-version av den engelska URL:en medan den faktiska URL:en är HTTPS, eller att trailing slash hanteras inkonsekvent. Dessa inkonsekvenser måste normaliseras.
Typfall C: Stor sajt med partiell engelska-täckning
En illustrativ e-handelsplattform för B2B (hypotetiskt, kalla den Grossistdigital AB) har 800 svenska produktsidor och 200 engelska produktsidor. De 200 engelska sidorna är en delmängd av de svenska och det finns ingen plan att översätta resterande 600 sidor kortsiktigt.
Hreflang ska i detta fall enbart implementeras för de 200 par som faktiskt har motsvarigheter. De 600 svenska sidor som saknar engelsk motsvarighet ska inte ha en hreflang-tagg. Om CMS:et automatiskt genererar hreflang för alla sidor måste en explicit logik läggas till som kontrollerar om en engelsk motsvarighet faktiskt existerar och är publicerad innan taggen genereras. Detta är ett vanligt implementationsfel vid CMS-baserad automation.
För att hantera detta i stor skala rekommenderar vi att bygga en URL-matris i ett kalkylark eller databas där varje rad representerar en kanonisk URL och kolumnerna representerar tillgängliga språkversioner. Matrisen används sedan som indata till CMS:ets hreflang-generator. Frågor om hur strukturerad data och metadata hanteras i komplexa sajter behandlas i guiden om strukturerad data och faktabeskrivning. En fråga om hur du ska prioritera vilka sidor som översätts först kan du arbeta igenom med SEO-affärscaseverktyget, som beräknar ett illustrativt affärscase på dina egna antaganden och hjälper dig sätta resurser i relation till uppskattad affärsnytta.
Statuskontroll och feldiagnos: vad du faktiskt kontrollerar
En hreflang-implementation är inte ett engångsprojekt. Den behöver underhållas i takt med att sajten förändras: nya sidor tillkommer, gamla tas bort, URL:er byter struktur. Varje förändring i URL-strukturen kräver en uppdatering av parmatrisen.
De vanligaste felsignalerna att leta efter vid en teknisk genomgång:
- Saknad returlänk: URL A pekar på URL B, men URL B pekar inte tillbaka på URL A. Identifieras genom att exportera alla hreflang-relationer och kontrollera symmetrin.
- Felaktig språkkod: Typo i hreflang-värdet, exempelvis
en-gbmed gemen b ellersv-SWEmed tresiffrig landskod. Identifieras via regexp-sökning i crawl-exportdata. - Hreflang pekar på icke-indexerbar URL: Om en URL som är inkluderad i en hreflang-grupp är blockerad av robots.txt eller returnerar 404, bryts gruppen. Kontrollera statuskoder för alla URL:er i varje hreflang-grupp.
- Canonical och hreflang pekar i olika riktningar: Om en sida har en canonical som pekar på en annan URL, men hreflang pekar på ursprungs-URL:en, skapas en konflikt. Sökmotorn föredrar vanligen canonical-signalen, vilket kan innebära att hreflang-signalen ignoreras. Se guiden om duplicerat innehåll och korrekt URL-val för mer om hur canonical-konflikter diagnostiseras.
- Inkonsekvent trailing slash:
example.se/en/ochexample.se/enär tekniskt sett olika URL:er. Hreflang-taggar måste peka på exakt samma URL-format som den kanoniska versionen av sidan.
En hreflang-granskning kan kontrollera språkversioner och deras returhänvisningar. Screaming Frog är ett etablerat verktyg för detta ändamål och kan exportera hreflang-data i ett format som möjliggör parmatris-kontroll. Komplettera gärna med en manuell stickprovskontroll av de mest kritiska sidorna: startsida, tjänstesidor och kontaktsida.
Om din sajt har HTTP-redirects som påverkar hur crawler når URL:er bör du också granska hur redirectkedjor interagerar med hreflang. En 301-redirect som tas bort kan bryta en hreflang-referens om hreflang-taggen pekar på den gamla URL:en. Mer om redirect-mekanik och hur det påverkar crawling finns i MDN:s djupgående dokumentation om HTTP-omdirigeringar och deras semantik.
Konkret checklista: implementering och validering steg för steg
Följande checklista är avsedd som ett arbetsunderlag för en implementering eller granskning av hreflang på en sajt med svenska och brittisk engelska. Anpassa stegen efter din sajts faktiska situation.
- Inventera alla publicerade URL:er per språkversion. Skapa ett kalkylark med kolumnerna: kanonisk URL, språk, motsvarande URL på annat språk (om den finns).
- Identifiera URL:er utan publicerad motsvarighet. Markera dessa som "utan hreflang" och dokumentera dem som planerade versioner om de är relevanta för framtida expansion.
- Bestäm hreflang-värden för varje språkversion. Verifiera att BCP 47-koderna är korrekta: sv för svenska, en-GB för brittisk engelska. Bestäm vart x-default ska peka.
- Välj implementeringsmetod: HTML-taggar i <head> eller sitemap. Välj en metod och tillämpa den konsekvent.
- Generera hreflang-taggar för alla URL-par med publicerade motsvarigheter. Inkludera self-referens och returlänkar på varje URL.
- Verifiera att canonical-taggar och hreflang-taggar på samma sida pekar i konsistenta riktningar. Canonical ska peka på sidans egen kanoniska URL, inte på en alternativ språkversion.
- Publicera godkända ändringar och verifiera status, språkversioner och returhänvisningar igen i crawlunderlaget. Spara datum och resultat. Sökobservationer behöver följas separat; de validerar inte automatiskt hreflang-konfigurationen.
- Kör en fullständig crawl med Screaming Frog eller motsvarande. Exportera hreflang-data och kontrollera parmatrisens symmetri.
- Kontrollera statuskoder för alla URL:er som refereras i hreflang-taggar. Inga 404, 301-kedjor eller robots.txt-blockade URL:er ska förekomma.
- Dokumentera resultatet och sätt upp en underhållsrutin: hreflang-matrisen ska uppdateras varje gång en URL läggs till, tas bort eller byter adress.
Använd RANGELs lokala HTML-kontroll för vissa grundläggande fält i inklistrad sidkälla. Verktyget validerar inte hela sajten eller hreflang-par. Kontrollera språkversioner och returhänvisningar separat med en faktisk URL-matris och ett lämpligt crawlunderlag. SEO-checklistan ger en bredare arbetsordning.
Teknisk SEO-tjänst och när extern hjälp ger mest värde
Hreflang-implementering är tekniskt hanterbar för en sajt med ett fåtal sidor och ett välkonfigurerat CMS. Komplexiteten ökar snabbt när sajten har hundratals URL:er per språk, när CMS:et genererar taggar automatiskt utan fullständig kontroll, eller när URL-strukturen ändras i samband med en migrering.
En extern teknisk genomgång ger mest värde i tre specifika situationer: när du inför en ny språkversion och vill säkerställa att implementeringen är korrekt från dag ett, när du misstänker att en befintlig hreflang-implementation är inkorrekt men inte kan identifiera exakt var felet sitter, och när du genomför en URL-strukturförändring som påverkar hela sajten och vill säkerställa att hreflang-matrisen uppdateras korrekt i samband med migreringen.
RANGELs tekniska SEO-tjänst inkluderar genomgång av hreflang-implementering som en del av en bredare teknisk analys. Uppdraget börjar med en inventering av befintlig URL-struktur och befintliga taggar, följt av en systematisk parmatris-kontroll och en prioriterad åtgärdslista. Granskning, åtgärdsförslag och eventuell implementation avgränsas i offerten. CMS-integration, behörigheter och publiceringsansvar måste vara överenskomna innan ett automatiserat arbetsflöde aktiveras.
Om du befinner dig i planeringsstadiet för en internationell expansion är det värt att involvera teknisk SEO-kompetens redan i URL-strukturbeslutet, inte efter att strukturen är fastlagd. Valet av undermappar versus subdomäner versus separata domäner är ett beslut med långsiktiga konsekvenser som är svåra och kostsamma att ändra i efterhand. Schema.org erbjuder också relevanta vokabulärer för att beskriva språkversioner av dokument, något som är värt att undersöka i relation till strukturerad data – se Schema.org Article för den tekniska definitionen av hur språkattribut kan deklareras i strukturerad data.
Sammanfattningsvis: hreflang är ett precisionsinstrument som kräver noggrannhet i implementering och aktivt underhåll. Det är inte en en gång-lösning utan en del av den tekniska infrastruktur som måste hållas synkroniserad med sajtens faktiska innehållsstatus. En korrekt implementering ger sökmotorer bättre förutsättningar att servera rätt URL till rätt användare. En felaktig implementering ignoreras och lämnar sökmotorn att gissa.