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. Reglerne, der afgør alt: annoteringerne skal være GENSIDIGE (hver version peger på alle andre – og på sig selv), sprogkoderne skal være rigtige („da“, „sv“, „nb“ – og husk: dk er IKKE en sprogkode), x-default dækker resten af verden, og canonical skal pege på sidens EGEN sprogversion. I WordPress genererer flersprogede plugins ofte hreflang selv – men VERIFICÉR det: de klassiske fejl er stille og koster præcis den internationale trafik, du byggede sprogene for.
hreflang er flersprogs-SEO’ens mest misforståede teknik: 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. Og den er berømt for at fejle i stilhed: forkerte annoteringer giver ingen fejlmeddelelser, bare svenske besøgende på danske sider og undren over konverteringen. Denne guide bygger på førstehåndserfaring – vi har selv udviklet et hreflang-plugin og set kanterne indefra – og går hele vejen: regler, WordPress-implementering, selvmålene og testen.
hreflang er små annoteringer (i sidens head eller sitemap), der fortæller søgemaskinen: „denne side findes også på svensk HÉR og på engelsk DÉR“. Effekten er VISNINGS-styring: brugeren får sin sprogversion i resultaterne, dine sprogversioner konkurrerer ikke mod hinanden, og næsten-ens versioner (dansk og norsk, eller samme sprog til to lande) behandles som det, de er – alternativer, ikke duplikater. Det, hreflang IKKE gør: løfte placeringer (indholdet og det flersprogede søgeordsarbejde gør det arbejde) eller omdirigere brugere (det er geolokations-guidens emne – og en helt anden, farligere sport). Tænk på hreflang som skiltningen i lufthavnen: den bygger ikke flyene – den sørger for, at folk går til den rigtige gate.
Fire regler bærer hele systemet: 1) Gensidighed – hvis den danske side peger på den svenske, SKAL den svenske pege tilbage; ensidige annoteringer ignoreres, og hele klyngen mister virkning. 2) Selvreference – hver side peger også på sig selv; det føles redundant og er obligatorisk. 3) Korrekte koder – sprog i ISO 639-1 („da“, „sv“, „nb“ for norsk bokmål, „en“), eventuelt med region („da-DK“, „en-GB“) – og de berømte fælder: „dk“ er en landekode, ikke et sprog, og region alene („SE“) er ugyldig. 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. 4) x-default – én version udpeges som fallback for alle andre sprog/lande (typisk din engelske eller din forside/sprogvælger). Alle fire gælder for HVER side – forsiden, kategorier, produkter, artikler – ikke kun domænets rod.
Tre veje: Sprogpluginet – Polylang og WPML genererer hreflang automatisk for koblede sprogversioner (jf. plugin-valget); det dækker standardtilfældene, MEN verificér kanterne: sider uden kobling, søge-/arkivsider, pagination og x-default-håndteringen er de steder, automatikken oftest glipper. Dedikeret hreflang-plugin – relevant, når sprogløsningen ikke leverer (multisite på tværs af installs, særlige strukturer) eller når du vil have præcis kontrol; det er netop de scenarier, der fik os til at bygge Hostious’ eget hreflang-plugin, og erfaringen derfra er entydig: kanterne (varianter, blandede indholdstyper, delvist oversatte sites) er 80 % af arbejdet. Sitemap-vejen – annoteringerne kan alternativt bo i XML-sitemappet; teknisk ligeværdigt, men sværere at fejlsøge med det blotte øje. Uanset vej: ÉN kilde til annoteringerne – dobbelt-hreflang fra to plugins giver konflikter, ingen af dem melder om.
1) Den manglende returpil – nye sider får hreflang, gamle bliver ikke opdateret: klyngen brydes. 2) „dk“-fejlen – ugyldige koder ignoreres stille; „da“ er sproget. 3) hreflang til døde mål – annoteringer mod sider, der redirecter, er noindex eller 404: hele signalet devalueres; 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 „svensk 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 maskine; annotér kun versioner, der ER versioner, og lad resten være, til de er oversat (jf. synkroniserings-guiden).
Test ved lancering OG efter hver større ændring (nyt sprog, nyt tema, plugin-opdateringer): 1) SE annoteringerne med kildevisning på en håndfuld sidetyper – forside, kategori, produkt, artikel – på ALLE sprog; tjek gensidighed, selvreference og koder i hånden. 2) Kør et hreflang-valideringsværktøj på tværs af sitet – de fanger brudte par og døde mål i skala. 3) Hold øje med SYMPTOMERNE i analytics og Search Console: svensk trafik, der lander på danske URL’er (eller omvendt), og „forkert sprog“-mønstre i landerapporterne er hreflang-lugt, længe før nogen finder den tekniske årsag. Og skriv opsætningen ind i site-dokumentationen – hvilken kilde genererer annoteringerne, og hvad er x-default – så næste udvikler ikke tilføjer kilde nummer to. hreflang belønner præcis én ting: omhu – og den betaler tilbage i den mest målbare valuta, der findes: rigtige besøgende på rigtige sider.
Ikke direkte – den 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 høstes rigtigt.
Rent sprog („sv“), medmindre du har flere versioner af samme sprog til forskellige lande – så skiller regionen dem („sv-SE“, „sv-FI“). Og husk: „dk“ er aldrig gyldigt som sprog – dansk er „da“.
Teknisk ligeværdige – vælg ÉN af dem. Head-tags er nemmest at fejlsøge med kildevisning; sitemap skalerer pænt på meget store sites. Aldrig begge fra hver sin kilde.
