Flerspråkig SEO: hreflang, undermappar och inte skjuta dig själv i foten
Gjort rätt, flerspråkig multiplicerar din söktrafik. Görs fel, hreflang blir tyst ignorerad och ingen berättar. Här är reglerna och de fem sätten som människor bryter mot dem.
Ge varje språk sin egen sökbara webbadress – undermappar som t.ex /fr/ är säkrast och koppla versionerna med hreflang-anteckningar. hreflang måste vara ömsesidigt, måste innehålla en självreferens, måste använda giltiga språk- och regionkoder och måste peka på indexerbara kanoniska webbadresser. Bryt någon av dem och Google ignorerar anteckningen helt utan att rapportera ett fel.
Det som gör flerspråkig SEO frustrerande är att det misslyckas tyst. En trasig omdirigering ger ett felmeddelande. En bruten hreflang-anteckning gör ingenting alls - Google läser det, kan inte verifiera det, kastar det och dina språkversioner fortsätter att konkurrera med varandra medan varje tagg ser rätt ut i din källa.
Så det här är en referens för att få strukturen rätt, följt av de specifika sätten den bryts.
Strukturera först: ge varje språk en riktig webbadress
Sökmotorer rangordnar sidor som de kan nå och särskilja. Varje språk behöver därför en egen, krypbar adress, och du har tre realistiska alternativ.
| Struktur | Exempel | Myndighet | Bedömning |
|---|---|---|---|
| Undermappar | example.com/fr/ | Delat över språk | Rekommenderas |
| Underdomäner | från.example.com | Dela per underdomän | Användbar |
| Landdomäner | exempel.fr | Helt separat | Endast för målinriktning i äkta land |
| Parametrar | example.com?lang=fr | Indexerat inkonsekvent | Undvik |
Undermappar vinner för de flesta webbplatser eftersom varje språk bidrar till och drar nytta av en domäns auktoritet. Landskodsdomäner är ett verkligt alternativ, men bara när du verkligen riktar dig mot länder snarare än språk, och var och en är en separat webbplats för att bygga auktoritet från början - ett engagemang som människor underskattar.
Språk eller land?
En skillnad som är värd att göra rätt tidigt, eftersom den bestämmer din URL-struktur och du inte vill ändra den senare. Serverar du fFranska, eller serverar du Frankrike?
Om innehållet är identiskt för alla som talar franska, vill du ha en struktur som bara är på ett språk: /fr/, kommenterad hreflang="fr". Om priser, fraktkostnader, juridiska villkor eller produkttillgänglighet skiljer sig åt mellan Frankrike, Belgien och Kanada vill du ha språkområde: /fr-fr/, /fr-be/, /fr-ca/. Skapa inte regionala varianter som du egentligen inte behöver – var och en är en annan sida att underhålla och en annan uppsättning anteckningar att hålla ömsesidiga.
hreflang, och de regler som faktiskt tillämpas
hreflang berättar sökmotorer att flera webbadresser är samma innehåll på olika språk, så rätt version når rätt sökare och versionerna behandlas inte som dubbletter som konkurrerar med varandra.
En korrekt uppsättning på den engelska sidan ser ut så här, och samma block – identiskt, oförändrat – visas även på de franska och tyska sidorna:
<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 egenskaper hos det blocket är viktigare än något annat:
Det är ömsesidigt. Varje sida i uppsättningen listar alla andra sidor i uppsättningen. Google behandlar en enriktad anteckning som obekräftad och kasserar den.
Det inkluderar en självreferens. Den engelska sidan listar den engelska webbadressen. Detta krävs, är lätt att utelämna, och dess frånvaro ogiltigförklarar uppsättningen.
Den är identisk på varje sida. Vilket är den praktiska anledningen till att det fungerar: generera blocket en gång och mata ut samma överallt, snarare än att försöka beräkna "de andra" per sida.
Markeringen x-default Entry namnger versionen för sökare som inte matchar något i uppsättningen. Det är valfritt men värt att ställa in medvetet, eller så låter du det valet vara en gissning.
De fem sätten som detta bryter
1. Icke-ömsesidiga kommentarer
Det vanligaste misslyckandet med bred marginal. Den engelska sidan listar franska, den franska sidan listar ingenting, och hela uppsättningen kasseras. Oftast orsakad av att anteckningar genereras från en lista per sida som är ofullständig för översatta sidor.
2. Ogiltiga språk- eller regionkoder
Formatet är en språkkod enligt ISO 639-1, valfritt följt av ett bindestreck och en ISO 3166-1 alfa-2. land kod. en-GB är giltigt. en-UK Det är det inte, eftersom landskoden är GB. fr-FR är giltigt, fr-FRA är inte. Och det finns inget sådant som hreflang="eu" För Europa måste halva regionen vara ett land. Ogiltiga koder ignoreras tyst.
3. hreflang som pekar på icke-kanoniska webbadresser
hreflang och kanoniska taggar måste hålla med. Om din franska sidas kanoniska pekar på den engelska versionen - vilket händer när en mall hårdkodar det - har du sagt till Google att den franska sidan är en dubblett av den engelska, och hreflang-uppsättningen är meningslös. Varje språkversion måste vara kanonisk för sig själv.
4. Peka på webbadresser som omdirigerar eller blockeras
En anteckning som pekar på en webbadress som visar 301:or någon annanstans, returnerar en 404:a eller inte är tillåten i robots.txt kan inte verifieras. Använd den slutliga, absoluta, indexerbara webbadressen – inklusive protokollet och, om relevant, den efterföljande snedstreckningen som webbplatsen faktiskt tjänar.
5. Automatiska omdirigeringar baserade på webbläsarens språk
Den subtila och den mest skadliga. Detektering Accept-Language Kraftomläggning är en dålig idé av två olika skäl.
För människor: en fransk talare i London kan avsiktligt vill ha din engelska sida, en utvecklare kan behöva originalet, och en besökare skickas någonstans de inte väljer med någon uppenbar väg tillbaka är en besökare som lämnar. Språkpreferens är inte en språkförmåga.
För sökrobotar: Googlebot söks främst från amerikanska IP-adresser utan att språkinställningar anges. Om du omdirigerar det kan du bara upptäcka dina engelska sidor någonsin, och de översatta versionerna du betalade för indexeras aldrig alls.
Föreslå, inte tvinga. En avvisande banner som erbjuder den franska versionen är användbar; en automatisk 302 till den är det inte. Låt hreflang styra sökresultaten och låt besökaren styra sin egen surfning.
Kontrollera ditt arbete
- Visa källa på en översatt sida och bekräfta att hreflang-blocket är närvarande, innehåller en självreferens och är identisk med den på originalet.
- Följ varje URL i blocket. Var och en ska returnera 200, inte en omdirigering, och vara kanonisk för sig själv.
- Kontrollera den kanoniska taggen på varje versionspunkter i den versionen, inte på originalspråket.
- Använda Search Consoles internationella målinriktningsdata där det är tillgängligt och en dedikerad hreflang-validerare för att upptäcka ömsesidighetsfel på en hel webbplats samtidigt.
- Bekräfta att alla språk finns i din webbplatskarta med egna uppgifter, så att sökrobotar kan upptäcka översatta sidor utan att vara beroende av att länkerna upptäcks.
Vanliga frågor
Vad är hreflang och behöver jag det?
hreflang är en HTML-anteckning som berättar sökmotorer att flera webbadresser är samma innehåll på olika språk eller regionala varianter, så lämplig version visas för varje sökare och versionerna är inte Döms som dubbletter av varandra. Du behöver det så fort du publicerar samma innehåll på mer än ett språk på sökbara webbadresser.
Ska jag använda undermappar eller underdomäner för olika språk?
Undermappar, t.ex. example.com/fr/, för de flesta webbplatser. Alla språk delar sedan en domäns samlade behörighet, och konfigurationen på CDN eller servern är enklare. Underdomäner fungerar men delar upp behörigheten mellan värdnamn. Landskodsdomäner som example.fr är lämpliga endast när de verkligen riktar sig till länder snarare än språk, eftersom var och en i själva verket är en separat webbplats att bygga auktoritet för.
Varför fungerar inte min hreflang?
Oftast eftersom anteckningarna inte är ömsesidiga - varje sida i uppsättningen måste lista alla andra sidor, inklusive sig själv, och Google kasserar uppsättningar som den inte kan bekräfta från båda hållen. Andra vanliga orsaker är ogiltiga koder som en-UK istället för en-GB, hreflang-URL:er som omdirigerar eller blockeras i robots.txt, och kanoniska taggar på översatta sidor som pekar tillbaka på originalspråket.
Måste hreflang finnas på varje sida?
Jaha. Anteckningar är per webbadress, inte per webbplats, så varje sida behöver ett block som namnger sina egna motsvarigheter på de andra språken. Blocket ska vara identiskt för alla versioner av den sidan och måste innehålla en självreferens. hreflang kan alternativt tillhandahållas i HTTP-huvuden eller i en XML-sitemap, vilket ofta är lättare att underhålla i skala.
Ska jag omdirigera besökare baserat på deras webbläsarspråk?
Nej. Automatiska omdirigeringar åsidosätter avsiktliga val - en fransk talare kanske vill ha den engelska versionen - och de stör crawling, eftersom Googlebot kryper till stor del från amerikanska adresser utan språkinställning och kan Upptäck därför aldrig dina översatta sidor. Erbjud en förslagsbanner som kan avvisas och en synlig språkväxlare istället, och låt hreflang hantera sökresultaten.
Är översatt innehåll duplicerat innehåll?
Nej. Innehåll översatt till ett annat språk är inte duplicerat innehåll, och korrekt genomfört hreflang gör relationen explicit så att versioner inte konkurrerar med varandra. Problem uppstår från nästan identiska sidor inom samma språk - till exempel separata sidor för Storbritannien och Australien med identisk engelsk text - där hreflang med regionkoder och korrekt självreferens Det är kanonerna som skiljer dem åt.
Få strukturen beslutat innan du översätter något, generera en identisk hreflang block per sida uppsättning, aldrig tvinga en omdirigering, och flerspråkig SEO blir underhåll snarare än arkeologi. Alternativet är att på sex månader upptäcka att inget av det någonsin räknades.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
