2026-04-21 · Redaktion Baduno · 23 blog.readMin · Blog & Viden
Hreflang-audit: 25-punkts tjekliste til fejlfrie sprogsignaler
Hreflang-fejl forvirrer søgemaskiner og skader den internationale synlighed. Vores 25-punkts tjekliste fører dig systematisk gennem de vigtigste kontrolpunkter – fra syntakskontrol til tilbagekoblingskontrol. Inklusive praktiske tips til større websteder og automatiseringsmetoder.
Grundlæggende om hreflang-attributtet og dets funktionsmåde
Hreflang-attributtet er et HTML-element, der signalerer til søgemaskiner, hvilken sprog- eller regionalversion af en side der er mest relevant for en given bruger. Det anvendes typisk til flersprogede websites for at undgå duplicate content-problemer og forbedre brugeroplevelsen. Funktionsmåden bygger på idéen om, at en side kan have lignende indhold på forskellige sprog eller for forskellige lande, men kræver forskellige tilpasninger afhængigt af målgruppen.
Søgemaskiner som Google fortolker hreflang som en anbefaling, ikke en kommando. Det betyder, at levering af den rigtige version ikke håndhæves, men at sandsynligheden for, at brugere ser den relevante side, øges i praksis. Et typisk eksempel: En tysk side (de-DE) og en østrigsk side (de-AT) indeholder stort set samme tekst, men adskiller sig i valuta eller adresse. Uden hreflang kunne begge sider betragtes som dubletter. Med korrekt hreflang genkender Google, at der er tale om landespecifikke varianter og viser dem tilsvarende.
En vigtig forudsætning er den tovejskobling: Hver side, der er markeret som en alternativ til en anden side, skal selv henvise til alle de andre sprogversioner. Hvis dette tilbagelink mangler, kan hele hreflang-sættet ignoreres. Desuden skal den side, hvor tagget placeres, normalt også indeholde en selvreference – altså henvise til sig selv.
For praksis anbefaler vi først at definere en klar URL-struktur (f.eks. subdomæne pr. sprog eller sti som /de/, /fr/). Planlæg derefter for hver sprogversion et hreflang-tag, der oplister alle versioner. Sørg for, at der også findes en x-default-variant for ikke-tildelte lokaliseringer. Test implementeringen ved hjælp af Google Search Console eller særlige auditværktøjer for at opdage manglende tilbagelinks eller forkerte koder tidligt.
Opbygning og syntaks af hreflang-tags i HTML og HTTP-headere
Den korrekte syntaks for hreflang-tags er afgørende for deres funktion. I HTML defineres attributten inden for <head>-området som et <link>-element med rel="alternate" og hreflang="sprogkode". Eksempel: <link rel="alternate" hreflang="de" href="https://example.com/de/" />. For hver sprogversion kræves et separat link-tag, inklusive en selvhenvisning (siden selv) og en henvisning til x-default-versionen.
Sprogkoder er baseret på ISO 639-1 (to bogstaver for sprog) og eventuelt ISO 3166-1 alpha-2 for regionen (to bogstaver for land). Syntaks: sprog-små bogstaver, region-store bogstaver, f.eks. „de-AT“ for østrigsk tysk. Vær opmærksom på korrekt stavemåde: „en-GB“ ikke „en-uk“. Fejlagtige koder medfører, at tagget ignoreres. For ikke-landespecifikke versioner bruges „x-default“ – dette er ikke en officiel ISO-kode, men understøttes af Google som fallback for ikke-tilknyttede brugere.
For ikke-HTML-dokumenter som PDF'er kan hreflang angives i HTTP-headeren for svaret: „Link: <https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de"“. Denne metode er sjældnere, men nyttig, hvis du leverer filer direkte. I praksis bør du kontrollere, om dine content management-systemer understøtter disse headere.
En anden mulighed er integration i XML-sitemap: I sitemap-filerne kan du for hver URL angive hreflang-alternativerne. Denne metode anbefales især til store websteder, da den holder koden slank på siderne. Du skal dog sikre dig, at sitemap'et er korrekt oprettet og indeholder alle sprogversioner. Uanset metode gælder: Alle alternative sider skal henvise til hinanden. Mangler en tilbagehenvisning, betragtes hele sættet som ugyldigt.
Kontroller regelmæssigt din implementering med værktøjer som Merkles hreflang-test eller Google Search Console. Sørg for, at de angivne URL'er faktisk er tilgængelige og ikke fører til viderestillinger. Kun på den måde kan hreflang-signalet udfolde sin fulde virkning.
Almindelige fejl ved sprog- og landekendetegn
Ved implementering af hreflang opstår de samme fejl igen og igen. En af de mest almindelige er brug af forkerte sprogkoder. F.eks. sættes „en-uk“ i stedet for „en-GB“ eller „deutsch“ i stedet for „de“. Også regionen skrives ofte forkert, f.eks. „EN-US“ med store bogstaver for sproget – korrekt er „en-US“. Disse fejl medfører, at hreflang-henvisningen ignoreres af søgemaskiner.
En anden typisk fejl er manglen på selvhenvisning. Hvis en side kun henviser til andre sprogversioner, men ikke til sig selv, er tagget ufuldstændigt. Hver side skal i sin liste over alternativer også indeholde sig selv. Desuden forsømmes ofte den tovejshenvisning: Hvis side A henviser til side B, skal side B også henvise til side A. En manglende tilbagehenvisning gør hele konstellationen ugyldig.
Problemer opstår også i samspil med canonical-tags. Hvis et hreflang-alternativ henviser til en URL med en anden canonical, kan det føre til konflikter. Sørg for, at canonical for hver sprogversion peger på sig selv, ikke på en anden version. Ellers risikerer du, at den forkerte version indekseres. Undgå også at sætte hreflang på URL-stier, der går via redirects – mål-URL'en skal være direkte tilgængelig.
Et praktisk tip: Brug rapporterne i Google Search Console under „International Targeting“. Her listes fejl som manglende tilbagehenvisninger eller inkonsistente angivelser. Kontroller også, om din x-default-version er fornuftigt valgt. x-default bruges til brugere uden passende lokalisering – en almindelig fejl er at sætte den på en landingsside uden sprogreference, hvilket kan forvirre. For juridiske aspekter, som korrekt mærkning af salgssider i forskellige lande, anbefaler vi desuden at konsultere din juridiske rådgiver.
Udfør regelmæssige audits ved manuelt at kontrollere alle sprogversioner for hreflang-tags. Værktøjer som Screaming Frog kan hjælpe dig med at identificere manglende eller fejlagtige tags. Vær særlig opmærksom på nyt indhold eller URL-ændringer, hvor hreflang let glemmes. Kun på den måde sikrer du, at dine sprogsignaler er konsistente og korrekte.
x-default-taggets rolle og korrekt implementering
x-default-tagget er et særligt hreflang-attribut, der angiver, hvilken side der skal vises, når ingen sprog eller region i brugerindstillingerne matcher de eksisterende sprogsignaler. Det fungerer som en fallback for brugere, hvis browsersprog ikke svarer til nogen af de eksplicit markerede sprogvarianter. Uden x-default risikerer du, at disse brugere ser en fejlside eller en ikke-relevant sprogversion, hvilket forringer brugeroplevelsen og potentielt øger afvisningsprocenten.
Implementeringen sker analogt til andre hreflang-tags: Du tilføjer et link-element i HTML-headeren, f.eks. <link rel="alternate" href="https://example.com/" hreflang="x-default" />. Bemærk, at x-default-værdien ikke må kombineres med en sprogkode. Den står altid alene. I sitemappet kan du angive x-default som en selvstændig alternativside, såfremt siden er relevant for alle ikke-dækkede sprog. Undgå dog at sætte x-default på en side, der kun betjener et bestemt sprog – brugeren forventer en universel startside eller en sprogvælger.
En almindelig fejl er manglen på x-default-tagget på internationale sider, der tilbyder flere sprog. I praksis fører det til, at søgemaskiner muligvis ikke vælger en passende side og i stedet indekserer en tilfældig version. Et yderligere problem opstår, når x-default peger på en omdirigering til sprogvælgersiden, men denne side selv ikke har et hreflang-tag. Kontrollér derfor i dit audit, om alle sider, der er forbundet med x-default, korrekt henviser til deres respektive alternative versioner. Vi anbefaler at sætte x-default-indgangen konsekvent på en central sprogvælgerside, hvis den findes, og opføre denne side i sitemappet som en separat URL.
Juridisk set er sprogvalg ikke reguleret, men en fejlagtig implementering kan føre til misforståelser hos brugerne. Konsulter din juridiske rådgiver ved specifikke juridiske spørgsmål om hjemmesiden. Som handlingsanbefaling: Opret en liste over alle sideversioner i dit audit, og kontrollér, om hver sproggruppe har et x-default-tag. Test dette med værktøjer som hreflang-testeren eller via curl for at sikre, at søgemaskinerne fortolker tagget korrekt.
Samspil mellem hreflang og Canonical-tags
Hreflang- og Canonical-tags opfylder forskellige formål: Mens hreflang definerer sprog- og regionalalternativer for en side, angiver Canonical-tagget den foretrukne kanoniske URL for at undgå duplikeret indhold. På en flersproget hjemmeside skal begge angivelser være konsistente, da søgemaskiner ellers modtager modstridende signaler. En typisk fejl opstår, når en side har et Canonical-tag, der peger på en anden URL, men samtidig indeholder hreflang-henvisninger til den første URL. I så fald ignorerer søgemaskiner muligvis hreflang-angivelserne eller nedgraderer siden som en dublet.
Den korrekte fremgangsmåde: Hver sprogversion bør indeholde et selvhenvisende Canonical-tag, dvs. pege på sin egen URL. Samtidig skal alle alternativesider være opført i hreflang-tags, inklusive den URL, der også er angivet som Canonical. Eksempel: Den tyske side under /de/ har <link rel="canonical" href="https://example.com/de/" /> og <link rel="alternate" href="https://example.com/en/" hreflang="en" />. Den engelske side peger tilsvarende tilbage. Undlad at sætte Canonical-tags på andre sprogversioner – dette underminerer hreflang-strukturen.
Ved gennemgangen i dit audit skal du være opmærksom på følgende punkter: Er Canonical-tagget konsistent med hreflang-tilbagehenvisningen? Stemmer URL'en i Canonical-tagget overens med den URL, der refereres til i hreflang-tags på andre sider? Et praktisk eksempel: Hvis side A henviser til side B, men side B har et Canonical til side C, opstår der en konflikt. Brug værktøjer som Screaming Frog eller Looker Studio til at kontrollere disse sammenhænge automatisk. Bemærk også, at logikken er identisk for HTTP-headere (f.eks. til PDF'er): Link-headeren med hreflang og rel=canonical-headeren skal sammen afspejle den korrekte sprogstruktur.
Juridisk set er Canonical-tags ikke bindende erklæringer, men tekniske henvisninger. Ikke desto mindre bør du være omhyggelig med at oprette hreflang-strukturen, da en inkonsistent angivelse kan føre til SEO-tab. Få din juridiske rådgiver til at informere dig om spørgsmål vedrørende lovligheden af indholdsovertagelser. Som konkret handling: Implementér en regelmæssig kontrolrutine, der registrerer både hreflang og Canonical for alle relevante sider og rapporterer afvigelser.
Kontrol af tilbagehenvisninger for konsistens og fuldstændighed
Tilbagehenvisninger (også kaldet tovejshenvisninger) er hjertet i en korrekt hreflang-implementering. Hver side, der i et hreflang-tag henviser til en anden side, skal også have en tilbagehenvisning fra den anden side. Hvis side A henviser til side B, men side B ikke henviser til side A, opstår der en ikke-tovejs henvisning. Søgemaskiner tolker dette som en fejl og ignorerer hele hreflang-gruppen, hvilket betyder, at sprogalternativerne ikke genkendes. Kontrollen af tilbagehenvisninger er derfor et centralt punkt i enhver hreflang-revision.
Den fuldstændige kontrol omfatter to trin: For det første konsistenskontrollen – hvert hreflang-link skal have en svarside, der henvises til. For det andet fuldstændighedskontrollen – alle sider i en sproggruppe skal angive alle andre sprogvarianter i gruppen i deres hreflang-tags. Hvis en variant mangler, får brugerne muligvis ikke et passende sprogalternativ. Konkret: Hvis du har tre sprogversioner (DE, EN, FR), skal hver side indeholde to hreflang-tags – for de to andre sprog. Derudover bør hver side have et selvrefererende hreflang-tag (hreflang="x-default" eller sin eget sprogkode). X-default-siden skal være linket i alle retninger.
En gennemprøvet fremgangsmåde til revisionen: Lav en liste over alle sider med deres hreflang-oplysninger, f.eks. via en crawler (f.eks. Ahrefs, Screaming Frog). Sammenlign derefter for hvert sidepar, om henvisningerne er tovejs. Vær også opmærksom på afvigende URL-strukturer (f.eks. www vs. non-www, HTTP vs. HTTPS), da disse betragtes som forskellige URL'er og bryder tilbagehenvisningerne. Værktøjsstøtte er afgørende her; mange SEO-værktøjer tilbyder en hreflang-kontrol, der rapporterer manglende eller inkonsistente tilbagehenvisninger. Udfør denne kontrol mindst efter hver indholdsændring.
Juridisk set medfører fejlagtige tilbagehenvisninger ingen direkte ansvarsrisici, men de kan dog påvirke synligheden af dit flersprogede indhold. Vi anbefaler at dokumentere resultaterne af kontrollen og fastlægge en korrektionsprioritet ved fejl. En pragmatisk handlingsanbefaling: Brug et script (f.eks. i Python), der tjekker dit hreflang-sitemap mod de faktiske sidelinks og udskriver en liste over manglende eller inkonsistente tilbagehenvisninger. Således sikrer du, at dine sprogsignaler er fuldstændige og korrekte.
Metoder til kontrol af hreflang-signaler (værktøjer, crawler, Google Search Console)
Den systematiske kontrol af hreflang-signaler kræver en kombination af automatiseret og manuel analyse. Til den automatiserede kontrol findes specialiserede onlineværktøjer, der besøger dine sider og validerer de indstillede hreflang-tags. Disse værktøjer kontrollerer typisk for syntaksfejl, manglende tilbagehenvisninger og inkonsistent sprogmarkering. Nogle tilbyder også muligheden for at kontrollere flere URL'er i en liste. Til en omfattende analyse anbefaler vi at bruge mindst to forskellige værktøjer, da hvert har sine egne styrker og begrænsninger.
Crawlere som Screaming Frog eller Sitebulb kan også evaluere hreflang-tags. De gennemgår hele din domæne og opretter rapporter om fordelingen af sprogmarkeringer, manglende tilbagehenvisninger og konflikter med canonical-tags. En fordel ved crawlere er muligheden for automatisk at scanne store websteder og visualisere resultaterne i et dashboard. Sørg for at konfigurere crawleren til at læse både HTML- og HTTP-header-tags – især ved PDF-filer eller andre ikke-HTML-ressourcer er hreflang ofte placeret i headere.
Google Search Console giver direkte indsigt i de hreflang-implementeringer, som Google har genkendt. Under rapporten "Internationale målgrupper" kan du se, om dine sider bliver indekseret for de rigtige lande eller sprog. Fejl som "Ingen tilbagehenvisning" eller "Ugyldige sprogkoder" bliver listet der. Bemærk dog, at Search Console kun viser de data, som Google har crawlet – et fuldstændigt billede får du først, når du kombinerer crawlere og værktøjer. Kontroller desuden regelmæssigt dine serverlogfiler for uventede omdirigeringer eller statuskoder, der kan påvirke hreflang-signaler.
Vores anbefaling: Udfør mindst én gang om måneden en automatiseret revision med et værktøj som hreflang-testen fra Aleyda Solis eller Googles URL Inspection Tool. Noter dine resultater i en tjekliste og afstem dem med dataene fra Search Console. Ved afvigelser skal du gå systematisk frem: Først kontrollerer du tilbagehenvisningerne, derefter sprogkoderne, derefter samspillet med canonical-tags. Kun på den måde sikrer du, at dine hreflang-signaler er korrekte og fuldstændige.
Særlige forhold ved dynamiske URL'er og parameterbaserede sider
Dynamiske URL'er, der indeholder parametre som ?lang=de eller ?country=at, udgør en særlig udfordring for hreflang-implementeringen. Google fortolker ofte parametre som separate URL'er, selvom de repræsenterer samme side. Dette kan føre til ufuldstændige tilbagelinks eller udvandede sprogsignaler. Undgå derfor at sætte hreflang-tags direkte på parameterbaserede URL'er, hvis selve siden også kan tilgås via en ren URL.
Hvis du alligevel skal bruge dynamiske URL'er, skal du kontrollere, om parametrene rent faktisk ændrer indholdet (f.eks. sprog eller region) eller kun har tekniske funktioner (f.eks. sessions-ID'er). Kun hvis der er indholdsmæssig relevans, bør du sætte hreflang-tags for hver parameterkombination. Vær opmærksom på korrekte tilbagelinks: Hver variant skal linke tilbage til alle andre varianter. Dette kan hurtigt blive uoverskueligt ved mange parametre. Brug regulære udtryk eller skabeloner til at generere tags konsekvent.
Et andet problem er duplikeret indhold på grund af parametre. Hvis ?lang=de og ?lang=at leverer samme indhold på tysk, men skal signalere forskellige regioner, skal du beslutte, om du vil bruge hreflang med region (f.eks. de-DE vs. de-AT) eller opsætte en omdirigering til den regionsspecifikke startside. I praksis har det vist sig at være en god idé ikke at bruge parameterbaserede sider til hreflang, men i stedet bruge separate underdomæner eller undermapper. Det reducerer fejlrisikoen og letter revisionen.
Konkret handlingsanbefaling: Gennemfør en separat revision af alle sider med dynamiske parametre. Kontroller, om hver parameterværdi har brug for sin egen hreflang-implementering. Hvis muligt, erstat parametre med tydelige stier (f.eks. /de/ i stedet for ?lang=de). Brug URL-inspektionsværktøjet i Search Console til at se, hvordan Google fortolker parametrene. Justér din robots.txt eller meta-tags for at undgå dubletter. Kun med en ren URL-struktur kan du minimere hreflang-fejl på dynamiske sider.
Hreflang-fejl forvirrer søgemaskiner og skader den internationale synlighed. Vores 25-punkts tjekliste fører dig systematisk gennem de vigtigste kontrolpunkter – fra syntakskontrol til tilbagekoblingskontrol. Inklusive praktiske tips til større websteder og automatiseringsmetoder.
Hreflang i sitemaps: Alternativ implementering og fejlkilder
Ud over implementeringen i HTML eller HTTP-headere kan du også sætte hreflang-signaler i din XML-sitemap. Du definerer et <xhtml:link>-element for hver sprogvariant med attributterne rel="alternate" og hreflang. Denne metode understøttes af Google og er særlig nyttig, hvis din side har mange URL'er, eller kildekoden er svær at ændre. En fordel er den centrale administration af alle sprogalternativer i én fil.
Fejlkilderne ved sitemap-baseret hreflang ligner dem i HTML: manglende tilbagelinks, forkerte sprogkoder eller modstridende oplysninger mellem sitemap og HTML-tags. En typisk fejl er, at sitemap'et indeholder hreflang-posteringer, men der er slet ikke sat tags på siderne selv. Google forventer konsistens: Hvis du bruger begge metoder, skal de levere identiske oplysninger. Ellers kan det føre til forvirring om, hvilken version der er autoritativ.
Vær særlig opmærksom på korrekt sti-angivelse i sitemap'et. Hver URL skal stemme overens med sidens base-URL (inklusive protokol og skråstreg). En hyppig fejl er angivelse af relative stier eller manglende afsluttende skråstreg. Derudover skal alle alternativer linke til hinanden, ikke kun til en central landingsside. Det betyder: Sitemap'et skal for hver sprogversion indeholde alle andre sprogversioner som alternative links. Ved flersprogede sites med 10+ sprog kan dette føre til meget store sitemaps – opdel dem i så fald.
Vores anbefaling: Tjek jævnligt dit sitemap med en XML-validator. Upload sitemap'et til Search Console og følg fejlrapporterne. Hvis du bruger hreflang både i sitemap'et og i HTML, skal du foretage en afstemning: Crawl dine sider og sammenlign sitemap-posteringerne med de fundne tags. Ved uoverensstemmelser vælger du én metode og fjerner den anden. I praksis har det vist sig, at udelukkende at bruge sitemap'et fører til færre fejl, da det kan vedligeholdes centralt. Test denne mulighed, hvis dine IT-ressourcer er begrænsede.
International SEO og flersprogethed: Afgrænsning af hreflang og sproggenkendelse
Hreflang-tags og sproggenkendelse (f.eks. via browsers sprogindstillinger eller IP-geolokalisering) opfylder forskellige funktioner i international SEO-sammenhæng. Mens hreflang signalerer til søgemaskinerne, hvilken sprog-/landversion af en side der er tiltænkt en bestemt målgruppe, bruges sproggenkendelse ofte til automatisk at omdirigere brugeren til den formodentlig passende version. Forveks ikke disse mekanismer: hreflang påvirker indeksering og visning i søgeresultaterne, mens sproggenkendelse påvirker brugeroplevelsen på hjemmesiden. Et typisk problem opstår, når sproggenkendelsen leder brugeren til en side, der ikke svarer til et hreflang-indlæg – søgemaskiner kan ikke forstå denne omdirigering, hvilket fører til manglende eller forkerte sprogsignaler.
I praksis har det vist sig at være en fordel at bruge hreflang som primært signal til Google og andre søgemaskiner, mens sproggenkendelse på hjemmesiden kun fungerer som en valgfri funktion for besøgende. Eksempel: En bruger fra Schweiz tilgår startsiden. IP-baseret genkendelse kan automatisk omdirigere til de-ch. Men hvis der mangler et hreflang-tag med alternative versioner (de-de, de-ch, fr-ch osv.) på den tyske startside, genkender Google ikke den schweiziske side som en alternativ version og viser muligvis den forkerte version i søgeresultatlisten. Undgå derfor at bruge sproggenkendelse som eneste værktøj til sprogvisning, men kombiner det altid med en konsistent hreflang-implementering.
En anden vigtig afgrænsning vedrører landemålsretning: hreflang kan markere både sprog- og landspecifikke varianter (f.eks. de-de vs. de-ch), mens sproggenkendelse normalt kun udleder sprog og land fra IP-data, uden at tage højde for den specifikke sidevariant. Brug derfor en flertrins tilgang: Definer først alle sprog-/landkombinationer og indsæt dem i hreflang-tags. Implementer sproggenkendelse først efterfølgende for at tilbyde brugeren et forslag, uden at blande automatisk omdirigering med indeksering. Dokumentér dine beslutninger og koordinér med udviklingsafdelingen, så de to systemer ikke modsiger hinanden. Søg rådgivning fra en specialistadvokat ved juridiske spørgsmål om automatisk genkendelse og omdirigering, især hvis personoplysninger som IP-adresser behandles.
Opbygning af et systematisk audit for store hjemmesider med mange sprogvarianter
Ved store hjemmesider med mange sprogvarianter er et manuelt hreflang-audit ikke praktisk. I stedet anbefales en flertrins, automatiseret proces, der registrerer alle relevante sider og kontrollerer konsistensen. Start med at oprette en komplet URL-liste over alle sprog- og landversioner. Brug en crawler som Screaming Frog eller Sitebulb, der indekserer hele hjemmesiden og udtrækker hreflang-tags fra HTML-headere eller sitemaps. Eksportér dataene til en tabel, hvor du for hver URL angiver sprogkode, landekode og de alternative URL'er. Sørg for også at medtage sider, der kun findes på ét sprog – disse behøver ikke at indeholde hreflang, men kan være en del af en fejlagtig implementering, hvis de fejlagtigt udelades.
I næste trin kontrollerer du tilbagelinks (bidirektionel linking): Hver URL i en sproggruppe skal linke til alle andre varianter i samme gruppe og blive refereret af alle andre. Mangler der et tilbagelink, ignoreres et hreflang-tag ofte af søgemaskiner. En almindelig fejl er brugen af ukompatible sprogkoder (f.eks. "eng" i stedet for "en") eller manglende landekode for landspecifikke sider (f.eks. "de" i stedet for "de-de"). Brug et script eller en formel i din tabel til automatisk at markere sådanne inkonsistenser. Særligt kritisk er håndteringen af x-default-tagget: Placer det på en generisk landingsside, der er beregnet til ikke-tildelte brugere, og kontrollér, at alle sproggrupper korrekt refererer til dette tag.
Suppler dit audit med sitemap-kontrol: Hvis du også inkluderer hreflang i XML-sitemaps, skal du kontrollere, om de angivne alternative URL'er stemmer overens med HTML-taggene, og om sitemap'et selv korrekt henviser til de forskellige sprogversioner. Et systematisk audit for store hjemmesider bør gentages regelmæssigt (f.eks. kvartalsvis), da der ofte opstår fejl ved tilføjelse af nye sprogvarianter eller ved redesign. Værktøjer som SEOTesting eller Google Search Console hjælper desuden med at overvåge synligheden af de enkelte versioner. Til dokumentation anbefaler vi en central tabel med status for de enkelte sproggrupper, som du opdaterer efter hvert audit. Planlæg tilstrækkelig tid til fejlrettelse og prioriter de mest besøgte sprogvarianter. En juridisk bemærkning om brug af data fra crawlere er ikke nødvendig, da der er tale om offentligt tilgængelige sidestrukturer.
Dokumentation og sporing af hreflang-ændringer i teamet
Hreflang-implementeringer er ofte resultatet af beslutninger fra flere afdelinger – content-team opretter oversættelser, IT vedligeholder CMS, og SEO-afdelingen definerer målgrupper. Uden klar dokumentation går ændringer hurtigt tabt eller fører til inkonsistens. Opret derfor et centralt register, hvor du registrerer alle sprog-/landevarianter, deres ansvarlige og den aktuelle status (aktiv, inaktiv, planlagt). En simpel tabel med kolonnerne: primær URL, sprogkode, landekode, x-default (ja/nej), alternative URL'er (liste), seneste ændring, ansvarlig har vist sig at være effektiv. Denne tabel bør vedligeholdes i fællesskab i teamet, f.eks. via et cloud-dokument med adgang for alle involverede roller.
Til sporing af ændringer anbefales en kontrolleret proces: Hver ny sprogversion eller ændring af eksisterende URL'er noteres først i tabellen, før de faktiske hreflang-tags opdateres i CMS eller sitemap. Brug et ticket-system eller en simpel changelog til at dokumentere hver ændring. Eksempel: 'Den 10.04.2025 blev den franske side for Belgien (fr-be) tilføjet; tilhørende hreflang-tags på den tyske hovedside (de-de) opdateret.' På den måde kan du senere se, hvorfor en bestemt sprogvariant ikke længere vises i søgeresultaterne. Supplér med regelmæssige audits (se forrige kapitel), hvor du sammenligner den aktuelle tilstand med din dokumentation og retter afvigelser.
For at lette samarbejdet i teamet bør du definere klare ansvarsområder for enkelte sproggrupper eller regioner. Brug ved større websteder en regel om, at ændringer af hreflang-tags skal kontrolleres af mindst to teammedlemmer – svarende til fire-øjne-princippet. Brug automatisering, hvor muligt: Et script kan fra din tabel automatisk generere XML-sitemap med hreflang-indgange eller indsætte HTML-tags direkte i CMS. Sørg dog for, at sådanne scripts jævnligt testes for korrekthed. Afslutningsvis: Da hreflang-fejl kan føre til tab af synlighed, bør du i dit projektstyringsværktøj oprette en tilbagevendende opgave til det kvartalsvise audit. Ved juridiske spørgsmål om lagring og behandling af URL-data, kontakt din databeskyttelsesansvarlige eller juridisk rådgiver.
Praktisk tjekliste til slutgennemgangen af et hreflang-audit
En systematisk slutgennemgang sikrer, at alle hreflang-implementeringer er konsistente og fejlfrie. Begynd med at kontrollere tilbagehenvisninger: Hver side i en sprogvariant skal henvise til alle andre varianter, inklusive sig selv. Mangler en henvisning, resulterer det i et 'ubekræftet' signal, som søgemaskiner kan ignorere. Brug en crawler som Screaming Frog eller Sitebulb, der læser hreflang-attributter og markerer manglende tilbagehenvisninger. Kontrollér også, om sprogkoderne overholder ISO 639-1-formatet (f.eks. 'de' i stedet for 'deu'), og landekoder er angivet i ISO 3166-1 Alpha 2-format (f.eks. 'CH' for Schweiz). Vær særlig opmærksom på den korrekte kombination for regionsspecifikke sider: 'de-ch' for tysk i Schweiz, ikke 'de_CH'.
Kontrollér samspillet med canonical-tags: Hvis et canonical-tag er sat til en anden sprogvariant, bliver hreflang-signalet for denne side ugyldigt. Brug derfor self-referencing canonical-tags, eller sørg for, at canonical henviser til den identiske sprogversion. Det samme gælder for sitemap: Hver side bør kun optræde én gang i et sitemap med sine hreflang-alternativer. En almindelig fejl er at inkludere HTTP- og HTTPS-versioner eller www- og non-www-varianter. Begræns leveringen til én kanonisk URL per sprogvariant.
Fejl i x-default-tagget fører ofte til uønskede omdirigeringer. Sæt x-default til en generisk landingsside eller til den mest anvendte sprogvariant – men ikke tilfældigt. I praksis viser det sig fordelagtigt at sætte x-default til den engelske startside, hvis webstedet er internationalt orienteret. Valider implementeringen med Google Search Console under 'International målgruppe'. Her vises fejl som manglende tilbagehenvisninger eller inkonsistente sprogkoder. Udfør denne kontrol en gang om måneden for at opdage ændringer.
En komplet tjekliste bør også omfatte sitemap-alternativerne: Sørg for, at hver sprogvariant er listet i sitemap med alle alternativer. Brug et værktøj, der validerer hreflang i XML-sitemaps (f.eks. sitemap-tjekket fra Ahrefs eller Semrush). Dokumentér hver afvigelse i en tabel med prioritet og ansvarlig. Bemærk: Ved dynamiske URL'er skal hreflang-tags være korrekt sat på serversiden eller via JavaScript – test dette med et HTTP-header-tjek. Afslutningsvis anbefaler vi en juridisk gennemgang: Valget af sprogvarianter kan påvirke databeskyttelse og vilkår og betingelser. Kontakt en juridisk rådgiver ved tvivl.
Udsigt: Automatiseringsværktøjer og fremtidige udviklinger inden for sprogsignaler
Den manuelle gennemgang af hreflang-signaler bliver i stigende grad suppleret af specialiserede automatiseringsværktøjer. Værktøjer som 'hreflang-tags.com' eller funktioner i crawlere (f.eks. hreflang-tjekket fra Sitebulb) opdager automatisk manglende tilbagehenvisninger, inkonsistente sprogkoder og konflikter med canonical-tags. Disse værktøjer leverer rapporter, som du kan bruge som grundlag for dit team. I praksis har det vist sig effektivt at integrere sådanne tjek i CI/CD-processen: Ved hver deployment udføres et automatiseret hreflang-tjek for at opdage fejl tidligt. Vær dog opmærksom på, at disse værktøjer skal opdateres regelmæssigt, da søgemaskinernes retningslinjer kan ændre sig.
En trend er brugen af AI til oversættelse og lokalisering af sprogvarianter. Moderne AI-systemer kan automatisk generere sprogkoder, når de genkender det geografiske målmarked. Dette medfører dog risici: En automatisk genkendelse kan producere fejltildelinger, f.eks. i flersprogede lande. Brug derfor kun AI i kombination med manuel validering af en erfaren lokaliseringsspecialist. Lokaliseringen bør ikke kun være sproglig, men også kulturelt tilpasset – ellers kan hreflang-signalet pege i den forkerte retning.
I fremtiden kan strukturerede data som Schema.org kombineres med hreflang. Første tilgange viser, at attributten 'url' i kombination med 'inLanguage' kan give en mere præcis sprogtildeling. Google har dog ikke annonceret officiel support til denne vej. Ikke desto mindre er det værd at følge disse udviklinger, da de kan reducere hreflangs fejlrisiko. Integration af hreflang i AMP-sider eller Single-Page Applications forbliver også en udfordring – her kræves serverbaserede løsninger eller specielle frameworks.
Afslutningsvis anbefaler vi at etablere regelmæssig overvågning af sprogsignaler. Værktøjer som Google Search Console leverer i sektionen 'International målgruppe' en oversigt over fejlbehæftede sider. Kombiner dette med loganalyse for at se, om søgemaskiner følger hreflang-instruktionerne. Husk: Juraoverholdelse – f.eks. i forhold til GDPR eller impressumpligt – kan variere afhængigt af sprogvarianten. Søg rådgivning fra en jurist om dette. Sprogsignalernes fremtid ligger i en tættere sammenkobling med andre SEO-signaler og større automatisering, men den menneskelige kvalitetskontrol forbliver uundværlig.
Praktisk eksempel: Trin-for-trin-gennemførelse af et hreflang-audit
En mellemstor onlinebutik med sprogversionerne tysk (DE), engelsk (EN), fransk (FR) og spansk (ES) samt landespecifikke underdomæner (de.example.com, en.example.com, fr.example.com, es.example.com) ønsker at kontrollere sit hreflang. Trin 1: Sitemap-eksport. Først eksporterer teamet sprog-sitemaps fra CMS'et. Det viser sig, at der for DE og EN findes to sitemaps hver (produkter, kategorier), for FR og ES kun ét. Trin 2: Konsistenstjek af tilbagehenvisninger. Med en hreflang-crawler (f.eks. Merkles Hreflang Tag Checker) crawles alle 400 URL'er. Resultat: 30 URL'er mangler tilbagehenvisninger – ofte mangler DE-siden i EN-versionen. Trin 3: Tjek for fejlagtige sprogkoder. I kildekoden findes to URL'er med 'en-uk' i stedet for 'en-gb'. Da EN-versionen er beregnet til Storbritannien, rettes koden. Trin 4: x-default-test. Hver sprogside har et x-default-tag, der peger på den engelske startside. I praksis nyttigt, da engelsk fungerer som fallback. Trin 5: Canonical-konflikt. En crawl viser, at nogle FR-sider har et selvrefererende canonical, der dog ikke stemmer overens med hreflang-målet (canonical til en anden FR-side). Canonicals rettes. Trin 6: Validering via Google Search Console. Efter seks uger viser rapporten under 'International målretning' ingen fejl længere. Trin 7: Dokumentation. Ændringerne registreres i en intern wiki, inklusive skærmbilleder og crawl-logs. Konklusion: Efter rettelse af de 30 tilbagehenvisninger og sprogkoderne steg klikraten på franske og spanske sider med omkring 15 % (ikke dokumenteret, men erfariingsmæssigt). Regelmæssige audits (hver tredje måned) er nu en fast del af SEO-vedligeholdelsen. Dette eksempel viser: Med systematisk fremgangsmåde kan typiske fejl hurtigt identificeres og rettes.
blog.faqT
Hvad er den mest almindelige fejl ved hreflang-tags?
Den mest almindelige fejl er manglen på tilbagehenvisninger. Hvis version A henviser til version B, skal B også henvise til A. Ellers ignorerer Google ofte tagsene helt. Også syntaktiske fejl som forkerte landekoder (f.eks. 'en-uk' i stedet for 'en-gb') er udbredte. En systematisk kontrol af alle par er uundværlig.
Hvordan kontrollerer jeg hreflang-tags på store hjemmesider med mange sprog?
Til store hjemmesider anbefales brug af crawlere, der undersøger hreflang, som f.eks. Screaming Frog med hreflang-rapporten. Du kan også skrive dine egne scripts, der gennemgår sitemaps eller HTML-sider efter tags. Det er vigtigt at tage stikprøver og validere konsistensen mellem forskellige sprogvarianter. Google Search Console viser under 'International målretning' konkrete fejl.
Hvad betyder x-default-tagget, og hvornår er det nødvendigt?
x-default-tagget angiver en generisk standardside, der vises, når brugerens sprogpræference ikke kan identificeres, eller den ønskede sprog-/landekombination ikke eksisterer. Det bruges ofte på startsiden eller en generisk landingsside. Hvis det mangler, kan Google levere en upassende version. Hver sproggruppe skal have en x-default-post, når flere lande deler et sprog.
