Hreflang: Vis den rigtige sprogversion uden skjulte fejl

Hreflang hjælper Google med at forbinde sprog- og regionsversioner af den samme side. Værdien ligger ikke i selve tagget, men i en komplet relation mellem korrekte, tilgængelige URL'er. Begynd med sitemap som kontrolleret liste over ønskede URL'er, hvis varianterne håndteres centralt.

Hreflang forbinder varianter – det oversætter ikke siden

Hreflang er en annotation, der beskriver forholdet mellem lokaliserede URL'er. Google kan bruge relationen til at vise en mere passende sprog- eller regionsversion i søgeresultatet. Annotationen ændrer ikke indholdet, sender ikke automatisk brugeren videre og gør ikke en generisk side lokal på egen hånd.

Hold derfor fire forskellige opgaver adskilt fra begyndelsen:

• Oversættelse gør det synlige indhold forståeligt på et andet sprog
• Lokalisering tilpasser eksempelvis valuta, levering, vilkår og kontaktvej
• Hreflang forbinder de tilsvarende sprog- og regions-URL'er
• Synlige links lader brugeren vælge en anden version direkte

Google oplyser, at sproget på en side bestemmes ud fra det synlige indhold, ikke ud fra hreflang eller HTML-attributten lang. En dansk side bliver derfor ikke engelsk, fordi den får hreflang="en". Hvis hovedindholdet stadig er dansk, har annotationen beskrevet en version, som siden ikke leverer. Det skaber et teknisk korrekt udseende signal med en forkert betydning.

Hreflang og lang løser to forskellige opgaver

Attributten lang på HTML-elementet beskriver tekstens sprog for blandt andet browsere, hjælpemidler og tekstbehandling. Hreflang på et link beskriver derimod en alternativ destinations sprog eller region for Google Search. Brug begge korrekt: lang="da" på den danske sides HTML og hreflang-relationer mellem de separate URL'er. W3C anbefaler altid at deklarere sidens standardsprog med lang, mens Google fortsat bruger det synlige indhold til sin egen sprogvurdering.

Vælg sprog først og region kun når siden reelt er forskellig

Den første hreflang-værdi er en sprogkode. En valgfri anden værdi afgrænser regionen, eksempelvis en-GB eller en-US. Regionen giver kun mening, når siderne faktisk er lavet til forskellige markeder. Brug ikke et land som erstatning for sproget, og opret ikke regionale varianter uden et særskilt brugerbehov.

Kontrollér beslutningen i denne rækkefølge:

• Brug da til dansk indhold, der ikke kræver en særlig regional variant
• Brug sprog og region, når pris, levering eller tilbud er markedsspecifikt
• Brug ISO 639-1 til sprog og ISO 3166-1 Alpha 2 til region
• Brug bindestreg mellem værdierne og en fuldt kvalificeret destinations-URL
• Tilføj en generisk sprogversion, hvis flere regioner deler samme sprog

Google advarer om, at en landekode ikke kan stå alene, fordi den første værdi altid læses som sprog. be betyder derfor belarusisk, ikke Belgien. For Belgien kan relevante kombinationer eksempelvis være nl-BE, fr-BE eller de-BE. Koden bør følge sidens faktiske indhold og målgruppe – ikke organisationens interne navn for markedet.

x-default er et fallback – ikke en skjult hovedversion

Værdien x-default kan pege på den side, der passer, når ingen af de angivne sprog- eller regionsversioner matcher. Det kan være en sprog- og landevælger eller en bevidst standardversion. Google anbefaler værdien som fallback, men den løser ikke manglende lokalisering. Destinationen skal stadig give brugeren en forståelig vej videre og indgå i det samme vedligeholdte sæt som de øvrige annotationer.

Byg komplette URL-par før koden bliver genereret

Hreflang virker som en relation, ikke som en løs egenskab på én side. Hver sprogversion skal angive sig selv og de øvrige relevante versioner. Hvis dansk peger på tysk, men tysk ikke peger tilbage, kan Google ignorere forbindelsen. Begynd derfor med et URL-kort, før tags eller sitemaplinjer bliver produceret.

Et brugbart URL-kort bør mindst vise:

• Den kanoniske URL for hver sprog- og regionsversion
• Den præcise hreflang-værdi, som passer til sidens indhold
• Hvilke URL'er der er direkte varianter af samme sideformål
• Om en side mangler oversættelse og derfor bevidst står uden relation
• Hvilken fallback der eventuelt skal bruges som x-default

Kortet beskytter også mod en almindelig indholdsfejl: at forbinde sider, som kun deler et emne. En dansk produktside bør ikke pege på en engelsk kategoriside, blot fordi den korrekte produktside ikke er oversat. Brugeren forventer den samme opgave og et tilsvarende informationsniveau. Hvis den ærlige variant mangler, er løsningen at oversætte eller undlade relationen – ikke at skjule hullet i markup.

Guiden til tekniske SEO-problemer i den rigtige rækkefølge viser, hvorfor relationer, canonical og intern struktur skal vurderes som én mekanisme. En annotation kan være syntaktisk gyldig og stadig pege på en redirect, en ikke-kanonisk URL eller en side, der ikke må indekseres. URL-kortet gør de konflikter synlige før implementeringen.

Retur-linket er en kontrol af gensidig enighed

Google kræver, at de forbundne sider peger tilbage på hinanden. Det forhindrer et fremmed website i ensidigt at erklære sig som alternativ til din side. I praksis betyder det, at hele sættet skal opdateres, når en variant tilføjes eller fjernes. Test derfor ikke kun den nye URL. Kontrollér alle berørte sider, deres selvreference og retur-links, så en lille redaktionel ændring ikke efterlader en halv relation.

Vælg én implementeringsmetode, som teamet kan vedligeholde

Google understøtter tre ligeværdige metoder: HTML i sidens <head>, HTTP-headers og XML-sitemap. Der er ingen gevinst i Google Search ved at bruge alle tre samtidig. Tværtimod øger flere kilder risikoen for, at URL'er, koder eller sæt bliver forskellige efter næste ændring.

Vælg metoden efter indholdstype og ejerskab:

• Brug HTML, når templates stabilt kan udskrive hele sættet på hver side
• Brug HTTP-header til ikke-HTML-filer som PDF'er eller ved central responsstyring
• Brug sitemap, når mange URL-par allerede vedligeholdes i én datakilde
• Undgå manuelle kopier, hvis nye sprog kræver rettelser på mange sider
• Dokumentér hvilken datakilde der er autoritativ for relationerne

HTML er let at se i den renderede kilde, men store sæt bliver hurtigt tunge at vedligeholde manuelt. HTTP-headeren er nyttig, hvor der ikke findes et HTML-head. Sitemap kan samle relationerne centralt, men filen skal fortsat genereres fra korrekte, aktuelle URL-par. Den bedste metode er den, der kan opdateres som en del af den normale publicering uden parallelle sandheder.

Canonical og hreflang skal pege i samme retning

Hver lokaliseret side bør normalt være kanonisk for sig selv, mens hreflang forbinder den med de øvrige kanoniske varianter. Hvis den danske side erklærer den engelske som canonical, beder systemet Google om både at samle siderne og vise dem som separate sprogversioner. Sørg også for, at interne links og sitemap bruger de samme destinations-URL'er. En 301 redirect hører kun hjemme, når en adresse reelt er flyttet – ikke som mellemled i hreflang-sættet.

Test hele relationen på den levende løsning

En validator kan kontrollere koder og retur-links, men den kan ikke alene afgøre, om siderne løser samme brugeropgave. Testen skal begynde i URL-kortet og slutte på den levende side. Kontrollér både syntaks, serverrespons, canonical, synligt sprog og den vej, brugeren får mellem versionerne.

Et praktisk acceptscript bør omfatte disse kontroller:

• Hver URL svarer stabilt 200 OK og er tilgængelig for Googlebot
• Hver version refererer til sig selv og alle aftalte varianter
• Alle retur-links, sprogkoder, regionskoder og fulde URL'er er korrekte
• Canonical peger på den samme lokale URL, som sættet bruger
• Sprogvalg og eventuel region er synlige og forståelige for brugeren

Test den renderede produktion, ikke kun CMS-feltet. JavaScript, caching, plugins og miljøregler kan ændre outputtet efter publicering. Tag stikprøver fra hvert URL-mønster og sammenlign med datakilden. Hvis en validator finder hundrede fejl, så find den fælles generatorregel først. Manuel rettelse på hver side skjuler mekanismen og gør næste sprogudgivelse lige så risikabel.

Automatisk omdirigering kan skjule de versioner, der skal testes. Google anbefaler separate URL'er og fraråder automatisk omdirigering alene ud fra antaget sprog eller IP. Googlebot crawler ofte fra USA og sender normalt ikke Accept-Language, så en adaptiv løsning kan gøre varianter svære at finde. Vis hellere et diskret forslag og tydelige sproglinks, mens den valgte URL fortsat kan åbnes direkte. Det giver både brugeren kontrol og testeren en stabil destination.

Prioritér hreflang efter forretningsrisiko – ikke antal tags

Hreflang er relevant, når forkert sprog eller marked skaber reel friktion: forkerte priser, leveringsvilkår, kontaktoplysninger eller tilbud. Et lille website med to oversatte informationssider har en anden risiko end en webshop med mange lande. Scope bør følge vigtige URL-par og fælles templates, ikke et mål om flest mulige annotationer.

Prioritér arbejdet ud fra disse forhold:

• Hvilke markeder og sider skaber kvalificeret efterspørgsel eller omsætning?
• Hvor viser Google i dag en forkert eller mindre relevant version?
• Hvilken fælles template eller datakilde styrer flest vigtige relationer?
• Kan rettelsen testes på et afgrænset sæt før bred udrulning?
• Hvem ejer nye oversættelser, URL-ændringer og løbende kontrol?

Undgå at behandle hreflang som en engangsopgave ved international lancering. Nye sider, nedlagte produkter, ændrede canonicals og migreringer kan bryde tidligere korrekte sæt. Læg derfor en relationskontrol ind i releaseprocessen, når routes eller sprogversioner ændres. Gem URL-kortet som driftsdokumentation og markér bevidste huller, så de ikke senere bliver “rettet” til forkerte destinationer.

Når fejlen ligger på tværs af templates, sitemap, redirects og mange sprogversioner, kan et afgrænset SEO- og websprint med implementering og test være relevant. Scope skal navngive de berørte URL-par, datakilden og acceptkriterierne. Hvis Google allerede viser de rigtige versioner, relationerne er komplette, og teamet kan vedligeholde dem, er det legitimt at stoppe frem for at bygge en mere avanceret opsætning.