Flersproget SEO: hreflang, undermapper og ikke skyde dig selv i foden
Gjort rigtigt, går flersproget ganger din søgetrafik. Hvis du gør det forkert, bliver hreflang ignoreret, og ingen fortæller dig det. Her er reglerne og de fem måder, folk bryder dem på.
Giv hvert sprog sin egen webadresse, der kan gennemgås – undermapper som f.eks /fr/ hreflang skal være gensidig, skal indeholde en selvreference, skal bruge gyldige sprog- og regionskoder og skal pege på indekserbare kanoniske webadresser. Bryd enhver af dem, og Google ignorerer annotationen helt uden at rapportere en fejl.
Det, der gør flersproget SEO frustrerende, er, at det fejler stille og roligt. En ødelagt omdirigering giver en fejl. En brudt hreflang-annotation gør slet ikke noget - Google læser det, kan ikke bekræfte det, kasserer det, og dine sprogversioner fortsætter med at konkurrere med hinanden, mens hvert tag ser korrekt ud i din kilde.
Det her er en reference for at få strukturen til at være rigtig efterfulgt af de specifikke måder, den bliver brudt på.
Struktur først: Giv hvert sprog en rigtig URL
Søgemaskiner rangerer sider, de kan nå og skelne mellem. Hvert sprog har derfor brug for sin egen unikke adresse, som kan gennemgås, og du har tre realistiske muligheder.
| Struktur | Eksempel | Myndighed | Dommen |
|---|---|---|---|
| Undermapper | example.com/dk/ | Delt på tværs af sprog | Anbefalet |
| Underdomæner | fra.example.com | Opdel pr. underdomæne | Virksom |
| Landedomæner | example.fr | Helt adskilt | Kun for ægte landemålretning |
| Parametre | example.com?lang=fr | Indekseret inkonsekvent | Undgå |
Undermapper vinder for de fleste websteder, fordi hvert sprog bidrager til og drager fordel af ét domænes autoritet. Landekodedomæner er en reel mulighed, men kun når du virkelig målretter mod lande i stedet for sprog, og hver enkelt er et separat websted for at opbygge autoritet fra bunden - en forpligtelse folk undervurderer.
Sprog eller land?
En forskel, der er værd at få ret tidligt, fordi det bestemmer din URL-struktur, og du vil ikke ønske at ændre det senere. Serverer du FranskEller er det dig, der tjener Frankrig?
Hvis indholdet er identisk for hver fransktalende person, skal du have en struktur, der kun omfatter sproget: /fr/, kommenteret hreflang="fr". Hvis priser, forsendelse, juridiske vilkår eller produkttilgængelighed varierer mellem Frankrig, Belgien og Canada, ønsker du sprogområde: /fr-fr/, /fr-be/, /fr-ca/. Opret ikke regionale varianter, du ikke har brug for – hver enkelt side er en anden side, der skal vedligeholdes, og et andet sæt anmærkninger, der skal bevares gensidigt.
hreflang, og de regler, der faktisk håndhæves
Hreflang fortæller søgemaskiner, at flere webadresser er det samme indhold på forskellige sprog, så den rigtige version når den rigtige søger, og versionerne behandles ikke som dubletter, der konkurrerer med hinanden.
Et korrekt sæt på den engelske side ser sådan ud, og den samme blok identisk, uændret vises også på de franske og tyske sider:
<link rel="alternate" hreflang="en" href="https://example.com/en/page" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page" />Tre egenskaber af denne blok betyder mere end noget andet:
Det er gensidigt. Hver side i sættet viser alle andre sider i sættet. Google behandler en notation i én retning som ubekræftet og kasserer den.
Det inkluderer en selvreference. Den engelske side viser den engelske URL-adresse. Dette er påkrævet, er let at udelade, og dets fravær ugyldiggør sættet.
Den er identisk på alle sider. Hvilket er den praktiske grund til, at det virker: Generer blokken en gang og output det samme overalt, i stedet for at forsøge at beregne "de andre" per side.
Den x-default indgangen navngiver versionen for søgeresultater, der ikke matcher noget i sættet. Det er valgfrit, men det er værd at indstille bevidst, eller du lader det valg være op til et gæt.
De fem måder, hvorpå det bryder sammen
1. Ikke-gensidige anmærkninger
Den mest almindelige fejl med stor margin. Den engelske side viser fransk, den franske side viser intet, og hele sættet kasseres. Normalt forårsaget af at generere anmærkninger fra en liste pr. side, der er ufuldstændig for oversatte sider.
2. Ugyldige sprog- eller områdekoder
Formatet er en ISO 639-1 sprogkode, eventuelt efterfulgt af en bindestreg og en ISO 3166-1 alfa-2. land kode. en-GB er gyldig. en-UK Det er det ikke, fordi landekoden er GB. fr-FR er gyldig; fr-FRA Det er det ikke. Og der findes ikke noget sådant som hreflang="eu" Europa: Halvdelen af regionen skal være et land. Ugyldige koder ignoreres lydløst.
3. hreflang peger på ikke-kanoniske webadresser
Hreflang og kanoniske tags skal være enige. Hvis din franske sides kanoniske peger på den engelske version - hvilket sker, når en skabelon hardcodes det - har du fortalt Google den franske side er en kopi af den engelske, og hreflang-sættet er meningsløst. Hver sprogversion skal være kanonisk for sig selv.
4. Peger på webadresser, der omdirigerer eller blokeres
En anmærkning, der peger på en webadresse, der indeholder 301'ere et andet sted, returnerer en 404'er eller ikke er tilladt i robots.txt, kan ikke bekræftes. Brug den endelige, absolutte, indekserbare webadresse – herunder protokollen og, hvis det er relevant, den efterfølgende skråstreg, som dit websted rent faktisk tjener.
5. Automatiske omdirigeringer baseret på browsersprog
Den subtile, og den mest skadelige. Opdagelse Accept-Language Det er en dårlig idé af to forskellige grunde.
For mennesker: en fransktalende i London kan bevidst ønsker din engelske side, en udvikler kan have brug for originalen, og en besøgende sendt et sted, de ikke vælge med nogen indlysende vej tilbage er en besøgende, der forlader. Sprogpræference er ikke en sproglig evne.
For crawlere: Googlebot crawler hovedsageligt fra amerikanske IP-adresser, hvor der ikke er angivet nogen sprogpræference. Hvis du omdirigerer det, kan du kun finde dine engelske sider nogensinde blive opdaget, og de oversatte versioner, du har betalt for, indekseres aldrig overhovedet.
Foreslå, ikke tvinge. Et afvisbart banner, der tilbyder den franske version, er nyttigt; en automatisk 302 er det ikke. Lad hreflang styre søgeresultaterne, og lad den besøgende styre sin egen browsing.
Tjek dit arbejde
- Vis kilde på en oversat side og bekræft, at hreflang-blokken er til stede, indeholder en selvreference og er identisk med den på originalen.
- Følg alle URL'er i blokken. Hver skal returnere 200, ikke en omdirigering, og være kanonisk for sig selv.
- KontrollTjek det kanoniske tag på hver version, der peger på den pågældende version, ikke på originalsproget.
- Brug Search Consoles internationale målretningsdata, hvor de er tilgængelige, og en dedikeret hreflang-validator til at fange gensidighedsfejl på tværs af et helt websted på én gang.
- Bekræft, at alle sprog er angivet i dit sitemap med deres egen indgang, så webcrawlere kan finde oversatte sider uden at være afhængige af linkopdagelse.
Ofte stillede spørgsmål
Hvad er hreflang, og har jeg brug for det?
hreflang er en HTML-anmærkning, der fortæller søgemaskiner, at flere webadresser er det samme indhold på forskellige sprog eller regionale varianter, så den relevante version vises til hver søger, og versionerne er ikke Bedømt som dubletter af hinanden. Du har brug for det, så snart du udgiver det samme indhold på mere end ét sprog på webadresser, der kan crawles.
Skal jeg bruge undermapper eller underdomæner til forskellige sprog?
Undermapper, f.eks. example.com/fr/, for de fleste websteder. Alle sprog deler derefter ét domænes akkumulerede autoritet, og konfigurationen på CDN eller serveren er enklere. Underdomæner virker, men deler autoritet på tværs af værtsnavne. Landekodedomæner som example.fr er kun hensigtsmæssige, når de virkelig er rettet mod lande i stedet for sprog, da hver enkelt er et separat websted til at opbygge autoritet til.
Hvorfor virker mit hreflang ikke?
Oftest fordi anmærkningerne ikke er gensidige - hver side i sættet skal liste alle andre sider, herunder sig selv, og Google kasserer sæt, det ikke kan bekræfte fra begge retninger. Andre almindelige årsager er ugyldige koder såsom da-UK i stedet for da-GB, hreflang URL'er, der omdirigerer eller er blokeret i robots.txt, og kanoniske tags på oversatte sider, der peger tilbage på det oprindelige sprog.
Skal hreflang være på hver side?
Ja, ja. Anmærkninger er pr. URL, ikke pr. websted, så hver side skal have en blok, der navngiver sine egne ækvivalenter på de andre sprog. Blokken skal være identisk på tværs af alle versioner af den side og skal indeholde en selvreference. hreflang kan alternativt leveres i HTTP-overskrifter eller i et XML-sitemap, hvilket ofte er lettere at vedligeholde i skala.
Skal jeg omdirigere besøgende baseret på deres browsersprog?
Nej. Automatiske omdirigeringer tilsidesætter bevidste valg - en fransktalende vil måske have den engelske version - og de forstyrrer crawling, da Googlebot crawler stort set fra amerikanske adresser uden en sprogpræference og kan derfor aldrig opdage dine oversatte sider. Tilbyd i stedet et forslagsbanner, der kan afvises, og en synlig sprogskifter, og lad hreflang håndtere søgeresultaterne.
Er oversat indhold at betragte som duplikeret indhold?
Nej. Indhold oversat til et andet sprog er ikke duplikeret indhold, og korrekt implementeret hreflang gør forholdet eksplicit, så versioner ikke konkurrerer med hinanden. Problemer opstår fra næsten identiske sider inden for samme sprog - for eksempel separate sider for Storbritannien og Australien med identisk engelsk tekst - hvor hreflang med regionskoder og korrekt selvhenvisning Det er kanonerne, der adskiller dem.
Få strukturen besluttet, før du oversætter noget, generere en identisk hreflang blok per side sæt, aldrig tvinge en omdirigering, og flersproget SEO bliver vedligeholdelse snarere end arkæologi. Alternativet er at opdage om seks måneder, at intet af det nogensinde blev talt.
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
