Subdomæner eller landespecifikke (ccTLD) domæner?

Hvis et landespecifikt domæne er ledigt, så vil det klart kunne betale sig at arbejde videre med det, frem for at oprette subdomæner eller undermapper. Landespecifikke domæner som eksempelvis .dk får en lille boost i lokale søgeresultater. Dog ikke nok til at man skal basere sit valg ud fra det alene. Det generiske .com kan også sagtens opnå gode placeringer, og på længere sigt har det sandsynligvis ingen betydning, hvad man vælger.

Man burde dog alligevel overveje at opkøbe landespecifikke domæner, alene for at beskytte sit brand. Desuden giver det mening for lokale brugere, der søger lokalt indhold, at eksempelvis besøge et .dk domæne. Hvis de derimod ønsker internationalt indhold, så vil de måske besøge .com versionen i stedet.

I søgeresultaterne vil brugerne også nemt kunne genkende lokale domænenavne, som sider der har indhold på deres eget sprog, eller som normalt er målrettet deres eget land.

Subdomæner er billigere at opsætte, fordi man ikke skal betale registreringsafgift, og dermed er de også nemmere at vedligeholde. Det eneste der skal til for at lave et subdomæne, er en opdatering af DNS indstillingerne for et eksisterende domæne. Brugen af subdomæner kan dog give begrænsninger, hvis man eksempelvis også har valgt at have en blog eller et forum på et subdomæne. Derfor vil undermapper ofte være en bedre løsning. Der er som sådan ikke en grænse for, hvor mange subdomæner til subdomæner man kan have. Personligt vil jeg forsøge at undgå for mange, følgende eksempel er lige på grænsen: da.forum.example.com

Undermapper fungere næsten på samme måde, men kræver altså ikke ekstra DNS indstillinger, og de kan også være lettere at konfigurere i forhold til HTTPS. Den nemmeste løsning vil derfor være, at oprette en undermappe, eksempelvis: example.com/da/. Men det giver også mindre fleksibilitet når man skal vælge URL struktur. De ekstra sprog-specifikke dele af URLen, vil også gøre det mere kompliceret for en bruger at forstå strukturen.

Overvej din URL struktur nøje

Jeg har set mange dårlige eksempler på URL struktur, ofte vil en side inkludere filendelser som .php eller .asp i adresser. Men noget af det værste jeg har set, er hjemmesider der automatisk omdirigere en bruger til en lokaliseret version. Google.com er meget slemme hvad det angår, her er det nemlig ikke nok at indtaste google.com for at tilgå den internationalle version, man skal faktisk skifte sprog på siden før den forstår det.

URL strukturen på din side skal helst ikke ændre sig, uden du sikre dig at omdirigere (brug 301 redirect) ALLE gamle sider, som kunne have betydning for brugerne. Jeg oplever ofte at store virksomheder, herunder Google og Microsoft, har ændret deres URL struktur uden at omdirigere gamle sider. Nogle gange har de måske endda helt slettet indholdet – til stor frustation for brugerne!

Det bedste du kan gøre, er derfor nøje at overveje din URL struktur, så du aldrig behøver at ændre på den igen.

Skulle det alligevel blive nødvendigt, så bør du sikre dig at omdiregere, som minimum, de vigtigste af dine sider. Det er de sider som modtager indgående trafik. Hvis en side har mange indgående links, så kan man også overveje, om ikke man burde omdirigere den til den nye placering. Hvis indholdet derimod er slettet, så kan man godt vise en 404 fejl.

Den perfekte URL struktur

Man kan kan ofte helt undgå problemer med URLs længere nede af vejen, hvis man tænker nøje over sin struktur fra starten. Nogle CMS systemer gør det endda nemt at ændre URL struktur, eksempelvis kan man ændre struktur under "permalinks" i wordpress. I andre tilfælde må man ændre i opsætningen på sin web-server.

Forsøg at undgå filendelser som .php, .xhtml, .dhtml eller .html, fordi hvis du pludselig skifter teknologi, så skal alle dine sider også opdateres og omdirigeres.

En ren URL vil ikke have fil endelser eller unødvendige parametre – og hvis du er radikal, så undlader du også skråstregen til sidst. Flere CMS systemer vil automatisk inkludere en skråstreg til sidst i en URL. Men med mindre der er tale om en mappe eller et "indeks" af en slags, så er det ikke teoretisk/logisk korrekt med en skråstreg som endelse. Et par gode URL eksempler kan være: example.com/navn-paa-artikel eller example.com/da/navn-paa-artikel hvis din side har flere sprog.

Efter nøje overvejelse, og i jagten på en perfekt URL struktur, har jeg selv bestemt mig for følgende struktur:

Hvis du har indhold på flere sprog så undgå at bruge subdomæner og undermapper. Køb i stedet de landespecifikke domæner, og skab en adskilt side til formålet. Det giver større fleksibilitet med hensyn til udarbejdelse af en logisk, korrekt URL struktur. Selvom man måtte være ligeglad med URL strukturen, så vil landespecifikke domæner altså stadig give et lille boost i søgemaskinerne, ligesom brugervenligheden også generelt er højere.

Man skal dog ikke regne med at opkøbe alle landespecifikke (ccTLD) udgaver af sit navn, da der er virkeligt mange, og det hurtigt kan blive dyrt. Nedenfor er et lille udpluk:

Hvis man enten ikke kan købe landespecifikke domæner, eller hvis man vil spare penge, så kan man med fordel bruge subdomæner eller undermapper i stedet.

Enkelte sider på andre sprog

Hvis man kun har enkelte artikler som er på andre sprog, så behøver man nødvendigvis ikke udføre nogle større tekniske ændringer på hverken CMS systemet eller URL strukturen.

Det eneste problem der kan være, er med hensyn til kodningen af siden. Hvis CMS systemet ikke tillader at skifte sprog på artikel-niveau, men kun tillader at man skifter sprog på hele siden, så vil din kode vise et forkert sprog.

Søgemaskinerne bør stadig kunne opfatte, at siden er skrevet på et andet sprog. Men skærmoplæsere, og andre mindre applikationer, kan få problemer, når de prøver at forstå siden. Det er usandsynligt at en skærmoplæser vil foretage en analyse af indholdet, for at bestemme sproget på en side, og derfor er det altså vigtigt, at man koder siden rigtigt.

Hvis dit CMS system tillader at skifte sprog per-artikel, så burde lang attributten opdateres, sammen med eventuelle andre relevante sprog-relateret kode.

Duplicate Content

Normalt behøver man ikke, at frygte duplicate content ved flersproget sider, da der ikke er tale om reelt duplikeret indhold. Har man bare oversat indholdet ved hjælp af Google Translate, så er det måske en anden snak. Desuden er der i forvejen plugins til oversættelse af indhold, ligesom at visse browsere har indbygget funktionalitet til det.

For at sikre den bedst mulige brugeroplevelse, bør man genskrive artikler på et andet sprog. Man kan også oversætte artiklerne ord for ord, men det kan være en langsommelig proces. Det er dog nødvendigt, når forfatteren ikke selv kan skrive en version af artiklen på andre sprog.

Jeg skriver selv både på Dansk og Engelsk, og ofte synes jeg det er nemmere bare at skrive en helt ny artikel, frem for at oversætte en artikel ord for ord. Uanset hvordan man gør, så kan søgemaskinerne godt forstå, at der er tale om forskelligt indhold.

Alternate hreflang link tagget kan bruges til at målrette en side lokale søgeresultater, eksempelvis når man bruger subdomæner eller undermapper til forskellige sprog-versioner. Hreflang tilføjes enten til <head> delen på en side eller HTTP headerne, og det har intet at gøre med duplikeret indhold.

<link rel="alternate" hreflang="da" href="http://da.example.com/">

Links

1. Websites med flere regioner og sprog – support.google.com
2. Brug hreflang til sprog og områdespecifikke webadresser – support.google.com

Fortæl os hvad du tænker: