hreflang i praksis: opsætning, der ikke saboterer din SEO

Kort svar: hreflang fortæller søgemaskinerne, hvilken sprogversion af en side der skal vises til hvem – så svenskeren får /sv/, og danskeren ikke får svensk. Fire regler afgør det meste: annoteringerne skal være gensidige og pege på alle versioner inklusive sig selv, sprogkoderne skal være gyldige (“da”, “sv”, “nb” – “dk” er ikke en sprogkode), x-default angiver fallback, og canonical skal pege på sidens egen sprogversion. Flersprogede plugins til WordPress genererer ofte hreflang selv, men kontrollér det – fejlene er stille og koster præcis den internationale trafik, du byggede sprogene for.

Fagligt gennemgået: 2. oktober 2026

hreflang er en af de mest misforståede teknikker i flersproget SEO. Den løfter ikke placeringer i sig selv. Den sørger for, at de placeringer, du har, viser den rigtige version til den rigtige bruger.

Teknikken er også kendt for at fejle i stilhed. Forkerte annoteringer giver ingen fejlmeddelelser – bare svenske besøgende på danske sider og en konverteringsrate, ingen kan forklare. Denne guide går hele vejen: reglerne, kodeeksempler, implementeringen i WordPress, de klassiske fejl og testen.

Hvad hreflang gør – og ikke gør

hreflang er små annoteringer – i sidens head, i en HTTP-header eller i XML-sitemappet – der fortæller søgemaskinen: “denne side findes også på svensk her og på engelsk der”.

Effekten er styring af visningen:

• brugeren får sin sprogversion i søgeresultaterne
• dine sprogversioner konkurrerer ikke mod hinanden
• næsten ens versioner – fx dansk og norsk eller samme sprog til to lande – behandles som alternativer frem for dubletter

Det, hreflang ikke gør, er at løfte placeringer. Det arbejde udfører indholdet og det flersprogede søgeordsarbejde. hreflang omdirigerer heller ikke brugere – det er emnet i guiden om geolokation og omdirigering og en helt anden og mere risikabel disciplin.

Bemærk også, at Google ifølge egen dokumentation ikke bruger hreflang eller HTML-attributten lang til at afgøre, hvilket sprog en side er skrevet på. Sproget aflæses af selve indholdet. En “svensk” side med dansk tekst bliver derfor ikke svensk af en annotering.

Tænk på hreflang som skiltningen i lufthavnen: den bygger ikke flyene, men sørger for, at folk går til den rigtige gate.

Grundreglerne

Fire regler bærer hele systemet:

1. Gensidighed: hvis den danske side peger på den svenske, skal den svenske pege tilbage. Ensidige annoteringer kan blive ignoreret, og klyngen mister sin virkning.
2. Selvreference: hver side peger også på sig selv. Det føles overflødigt, men er en del af reglerne.
3. Gyldige koder: sprog angives med ISO 639-1-koder (“da”, “sv”, “nb” for norsk bokmål, “en”), eventuelt efterfulgt af en region i ISO 3166-1-format (“da-DK”, “en-GB”). En region alene er ugyldig.
4. x-default: én version udpeges som fallback for alle andre sprog og lande – typisk den engelske version eller en side med sprogvælger.

Brug kun region, når du har versioner målrettet forskellige lande på samme sprog. Ellers er rent sprog (“sv”) både nemmere og bredere.

Alle fire regler gælder for hver enkelt side – forside, kategorier, produkter og artikler – ikke kun for domænets forside. Og alle URL’er skal være fuldt kvalificerede med protokol, altså https://example.com/sv/ og ikke /sv/ eller //example.com/sv/.

Kode	Gyldig?	Bemærkning
da	Ja	Dansk
da-DK	Ja	Dansk målrettet Danmark – kun nødvendig ved flere danske versioner
dk	Nej	Landekode, ikke en sprogkode
sv-SE og sv-FI	Ja	Svensk målrettet to forskellige lande
nb	Ja	Norsk bokmål
no	Ja	Norsk uden angivelse af skriftsprog
SE	Nej	Region alene er ikke tilladt
x-default	Ja	Reserveret værdi til fallback

Sådan ser annoteringerne ud

Et site med dansk, svensk og norsk version af samme side og en engelsk version som fallback har disse linjer i head på alle fire sider – præcis det samme sæt på hver side:

<link rel="alternate" hreflang="da" href="https://example.com/produkt/" />
<link rel="alternate" hreflang="sv" href="https://example.com/sv/produkt/" />
<link rel="alternate" hreflang="nb" href="https://example.com/no/produkt/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product/" />

Bruger du sitemap-metoden, angives de samme alternativer som xhtml:link-elementer under hver URL:

<url>
  <loc>https://example.com/produkt/</loc>
  <xhtml:link rel="alternate" hreflang="da" href="https://example.com/produkt/" />
  <xhtml:link rel="alternate" hreflang="sv" href="https://example.com/sv/produkt/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/product/" />
</url>

Sitemappet skal da også erklære navnerummet xmlns:xhtml=”http://www.w3.org/1999/xhtml” i urlset-elementet. Den tredje metode – en Link-header i HTTP-svaret – bruges især til filer uden head, fx PDF’er.

Implementeringen i WordPress

Der er tre veje:

Sprogpluginet: Polylang og WPML genererer hreflang automatisk for sprogversioner, der er koblet sammen – se guiden om Polylang, WPML eller multisite. Det dækker standardtilfældene, men kontrollér kanterne: sider uden kobling, søge- og arkivsider, paginering og håndteringen af x-default er de steder, hvor automatikken oftest glipper.

Dedikeret hreflang-plugin: relevant, når sprogløsningen ikke leverer, fx ved multisite på tværs af installationer eller særlige URL-strukturer, eller når du vil have præcis kontrol. Erfaringen er, at kanterne – varianter, blandede indholdstyper og delvist oversatte sites – udgør en stor del af arbejdet.

Sitemap-vejen: annoteringerne kan i stedet ligge i XML-sitemappet. Det er teknisk ligeværdigt, men sværere at fejlsøge med det blotte øje.

Uanset vej gælder én regel: hav én kilde til annoteringerne. Dobbelt hreflang fra to plugins giver konflikter, som ingen af dem melder om. Tjek især efter, om dit SEO-plugin og dit sprogplugin begge skriver hreflang.

De seks klassiske fejl

1. Den manglende returpil: nye sider får hreflang, men gamle bliver ikke opdateret, og klyngen brydes.
2. “dk”-fejlen: ugyldige koder ignoreres i stilhed. Sproget hedder “da”.
3. hreflang til døde mål: annoteringer, der peger på sider med redirect, noindex eller 404, svækker hele signalet. Peg altid på den endelige, indekserbare URL.
4. Canonical-konflikten: hvis den svenske sides canonical peger på den danske, siger du samtidig “vis svensk” og “den svenske side findes ikke”. Canonical skal pege på sidens egen sprogversion.
5. Blandede URL-varianter: http/https eller med/uden www i annoteringerne matcher ikke de kanoniske URL’er.
6. Delvis oversættelse uden plan: hreflang til en “svensk” side, der reelt er halvt dansk, skuffer både bruger og søgemaskine. Annotér kun versioner, der er færdige, og lad resten vente – se guiden om at holde flere sprog synkrone.

Test og vedligehold

Test ved lancering og efter hver større ændring som et nyt sprog, et nyt tema eller opdateringer af sprog- og SEO-plugins:

1. Se annoteringerne i kildekoden på en håndfuld sidetyper – forside, kategori, produkt og artikel – på alle sprog. Tjek gensidighed, selvreference og koder i hånden.
2. Kør et valideringsværktøj til hreflang på tværs af sitet. Sådanne crawlere finder brudte par og døde mål i stor skala.
3. Hold øje med symptomerne i analyseværktøjet og Search Console: svensk trafik, der lander på danske URL’er (eller omvendt), og mønstre med “forkert sprog” i landerapporterne er tegn på hreflang-problemer, længe før nogen finder den tekniske årsag.

Skriv også opsætningen ind i sitets dokumentation: hvilken kilde genererer annoteringerne, og hvilken version er x-default? Så tilføjer næste udvikler ikke kilde nummer to.

hreflang belønner omhu, og gevinsten kan måles direkte: de rigtige besøgende på de rigtige sider.

Læs også

• Hub: Salg over grænser
• Flersproget WordPress: Polylang, WPML eller multisite?
• Flersproget SEO: søgeord, der ikke kan oversættes direkte
• Geolokation og omdirigering: gør det uden at ødelægge SEO
• Domænestrategi: .dk, .se, .com eller undermapper?
• WordPress hosting hos Hostious – LiteSpeed, NVMe, daglig backup og dansk support

Ofte stillede spørgsmål om hreflang

Giver hreflang bedre placeringer?

Ikke direkte. hreflang styrer, hvilken sprogversion der vises til hvem, og forhindrer versionerne i at konkurrere internt. Placeringerne bygges af indhold og links; hreflang sørger for, at de udnyttes rigtigt.

Skal jeg bruge “sv” eller “sv-SE”?

Rent sprog (“sv”), medmindre du har flere versioner på samme sprog til forskellige lande – så skiller regionen dem (“sv-SE”, “sv-FI”). “dk” er aldrig gyldigt som sprog; dansk er “da”.

Head-tags eller sitemap?

Teknisk ligeværdige – vælg én af dem. Head-tags er nemmest at fejlsøge i kildekoden; sitemap skalerer pænt på meget store sites. Brug aldrig begge fra hver sin kilde.

Hvad skal x-default pege på?

På den version, der passer bedst til besøgende, hvis sprog eller land du ikke har en version til. Typisk er det den engelske version eller en side med sprogvælger.

Skal hreflang-URL’erne være de samme som canonical?

Ja. Hver URL i annoteringerne bør være den kanoniske, indekserbare version af siden med samme protokol og samme www-variant. Ellers matcher signalerne ikke hinanden.