Teknisk SEO er en af de mest komplicerede og nogle gange omkostningstunge discipliner, men det kan mange gange være den afgørende faktor, da optimeringer af den tekniske platform gælder for hele hjemmesiden. Vi har lavet denne guide til dig, som ønsker at vide mere om teknisk optimering af dit website. Har du spørgsmål eller har brug for hjælp, er du altid velkommen til at kontakte os.
Teknisk SEO er ikke “bare lige”
Teknisk SEO ikke bare lige noget man laver. Det tager lang tid, men der er virkelig også mange point at hente på teknisk SEO. Når du retter dine tekniske SEO udfordringer, så retter du det på hele sitet. Hvis vi leger med tanken om at du har x-antal sprog på dit website, så kan du gange indholdet op med det antal lande du er i. Det gør en kæmpe forskel at få rettet teknikken.
Når man får lavet en teknisk SEO analyse, så gennemgår vi hele websitet, finder alle de tekniske udfordringer, og sender dem til dig i en prioriteret rækkefølge. Det vi ofte anbefaler, er at få din udvikler til at sætte priser på hver enkelt opgave. På den måde kan vi sammen beslutte hvor vi først skal sætte ind. For det kan godt være dyrt at få rettet alt. Men effekten er også stor og langvarig.
Lad os give dig et tilbud på en teknisk SEO analyse. Alt vores tekniske SEO bliver udført af folk som både har programmerings baggrund samt mange års erfaring med SEO.
Få et tilbud på en teknisk SEO-analyse
Udfyld formularen her, og vi kontakter dig hurtigst muligt.
Hvad dækker teknisk SEO over?
Kodeoptimering
Jo mere fejlfrit og effektivt koden der bygger en hjemmeside er, jo bedre brugeroplevelse giver hjemmesiden når man besøger den. Du har sikkert oplevet en hjemmeside, som tager lang tid at indlæse, eller hvor et link ender med at vise en fejlside. Du har sikkert også besøgt en hjemmeside, hvor nogle af elementerne der bygger hjemmesiden ikke bliver indlæst, og funktionaliteten derfor ikke virker efter hensigten. Alle disse uhensigtsmæssigheder giver den besøgende en ringe brugeroplevelse, og derfor har de moderne søgemaskiner, med Google helt i front, lagt stor vægt på at belønne de hjemmesider, som fungerer optimalt og indlæses hurtigt, hvilket indirekte straffer de sider der har udfordringer.
Efter Google skiftede over på at indeksere den mobile version af hjemmesiden før den desktop baserede version, er der kommet meget fokus på de mange tekniske aspekter bag opbygningen af hjemmesiden.
Gengivelsesblokkerende indhold
Et af de vigtigste elementer i en god brugeroplevelse, er den hastighed hvorved en hjemmeside indlæses, og i hvilken rækkefølge elementerne indlæses i. Hvis der skal bruges en masse JavaScript og CSS til at bygge hjemmesidens udseende og indhold, vil dette virke gengivelsesblokerende, og sinke sidens visuelle indhold, specielt hvis referencerne til koden indsættes i sidens <head>, men selv inline CSS og JavaScript vil virke gengivelsesblokkerende.
Det går du på at bruge så lidt JS og CSS som muligt i starten af hjemmesidens kode, og udskyde mindre vigtigt scripts til sidst i koden.
Fjernelse af gengivelsesblokkerende scripts er en udvikleropgave og kan være en omkostningstung opgave, men kan gøre en stor forskel, og skal kun udføres en gang, så virker det for hele hjemmesiden.
Her kan du læse Googles egne anbefalinger omkring emnet: https://developers.google.com/web/tools/lighthouse/audits/blocking-resources
Reducer antallet af requests
Jo flere ressourcer, også kaldet requests, der skal bruges til at bygge en hjemmeside, jo mere kompliceret og uoverskueligt bliver det at sikre at det hele spiller sammen. En anden gevinst ved at anvende færre ressourcer er at siden indlæses hurtigere. Det skyldes at der er et begrænset antal forbindelse en enkelt bruger/besøgende får stillet til rådighed på den server hvor siden ligger.
Hvis man eksempelvis får stillet 5 forbindelser til rådighed, får disse tilegnet de 5 første ressourcer, og først når alle 5 ressourcer er indlæst, bliver der tilegnet de næste 5 ressourcer. Hvis en af disse ressourcer er meget store, eller komplicerede at behandle, vil indlæsningen af den næste 5 ressourcer derfor afvente unaturligt lang tid.
Et andet element i udfordringen med antallet af ressourcer er at der kan opsættes regler for hvilke ressourcer der må indlæses og hvilke ressourcer der skal behandles inden de kan indlæses, og det skal gøres for hver enkelt fil. Det kan være at søgerobotterne ikke må indlæse en fil på grund af en regel i sidens robots.txt, eller en fil skal viderestilles på grund af en regel i serverens .htaccess eller web.config
Denne sikring af regler skal udføres for hver enkelt ressource, og vil naturligt forlænge sidens totale indlæsningstid eksponentielt i forhold til antallet af ressourcer der skal bruges på siden.
Døde eller viderestillede ressourcer
Hvis vi holder fast i tanken om de 5 forbindelser der er til ressourcer på serveren, så er en anden hindring for hurtig indlæsning, nemlig hvis en ressource er blevet flyttet, eller ikke eksisterer længere.
Hvis en ressource er blevet flyttet, og der eksistere en regel for et nyt sted at finde den, tabes den eksisterende forbindelse, og den nye ressource sættes i kø ved næste omgang.
Hvis en ressource er blevet slettet eller ikke kan indlæses, vil dette trække tiden unaturligt, da serveren, alt efter opsætning, vil forsøge et defineret antal gange, hvilket unødigt sløver indlæsningen.
Effektiv kodeafvikling
Der er regler for hvordan koden der bygger en hjemmeside skal sammensættes, og en rodet og ikke gennemtænkt kode, kan sætte en stopper for en hurtig afvikling af koden. De fleste browsere og søgerobotter kan godt gætte sig til hvordan koden skulle have set ud, og derved vise det rigtige resultat, men hver gang der skal tænkes kreativt, tager det tid.
Herunder er et eksempel på hvordan kode skal laves, og et eksempel på en forkert anvendelse.
<p class=”korrekt”>
<strong>Denne tekst er fed</strong> og <em>denne tekst er skråskrift</em><br />
Dette er et link til <a href=”https://www.riveronline.dk”>RiverOnline.dk</a><br />
<img src=”https://www.riveronline.dk/kodeafvikling.jpg” alt=”Kodeafvikling” />
</p>
<strong>Denne tekst er fed <em> og denne</strong> tekst er skråskrift<br>
Dette er et link til <a href=”https://www.riveronline.dk”>RiverOnline.dk<br>
<img src=”https://www.riveronline.dk/kodeafvikling.jpg”></em>
Det er tilladt at kombinere eksempelvis <strong> og <em>, men man skal huske at lukke elementerne i modsat rækkefølge, som de er åbnet, som det kan ses af koden herunder.
<p><strong>Dette er fed tekst, som også kan være <em>skråskrift</em></strong></p>
Serveren
Der er stor forskel på de webhoteller der kan købes, og som oftest hænger prisen sammen med kvaliteten.
Når vi kigger på hvordan serveren behandler de forespørgsler der sendes til serveren, så er en af de afgørende faktorer hvor lang tid det tager fra ressourcen efterspørges på serveren, til den første byte data modtages af browseren – dette kaldes Time to First Byte, og forkortes TtFB, og kaldes ofte sidens ”Wait”
Time to First Byte
Nogle af de begrænsninger, som kan sættes op på en server, er hvor meget processorkraft og hvor meget RAM der stilles til rådighed for den session der er i gang.
Et andet element der kan sinke serverens leveringshastighed, er hvor mange forbindelser og hvor mange opkald der skal foretages til databasen. Jo mere kompliceret og jo større mængde data der skal hentes fra datalageret, jo længere tid tager det at sammensætte den data der skal sendes tilbage til den besøgendes browser.
Vi har tidligere i artiklen nævnt reglerne som kan opsættes i .htaccess og robots.txt, og hvis der er for mange unødvendige regler, kan dette være med til at forsinke sidens første byte data.
Ud over at sikre sig at serveren har de nødvendige fysiske rammer for afviklingen af de komplicerede forespørgsler, som er en opgave der bør løses af hostingselskab, så kan man anvende cachelagring for at sætte hastigheden op på siderne.
Cachelagring
En korrekt opsætning af caching, vi kunne reducere indlæsningshastigheden og TtFB væsentligt. Dette skyldes at systemet allerede har afviklet en stor del af den kode der skal køres for at bygge sidens indhold.
De 2 mest anvendte muligheder for caching er browser caching og server caching.
Hvad er Server cache?
Serveren som er ansvarlig for at generere websiden (dvs. at sætte websiden sammen), har lavet en kopi af hvordan websiden sidst så ud, så den behøver ikke generere den igen. Dette sparer tid (men ikke båndbredde), fordi serveren ikke behøver at gå gennem besværet med at opbygge en hel side – det kan bare sende det, det sendte sidste gang, browseren bad om det. Men hvis nogen data på websiden skal ændres, er serveren tvunget til at smide sin “hukommelse” af, hvad siden ser ud, og den skal generere siden igen. Denne form for caching er nyttig, hvis siden er meget kompleks og tager meget tid til at generere.
Hvad er Browser Cache?
Din webbrowser (Chrome, Firefox, Safari, Edge eller hvad du bruger) beslutter at huske, hvordan en webside ser ud, så det ikke behøver at bede serveren om at sende websiden igen. Dette sparer tid (og båndbredde) ved at fjerne næsten hele netværkskommunikationen. Men hvis serveren beslutter at ændre den måde, websiden ser ud på, er du i problemer, fordi browserenes “hukommelse” af, hvordan den mener, at siden skal se ud, nu er forældet, og det giver dig en gammel version af siden i stedet for den nye. Derfor fortæller folk nogle gange dig om at “rydde din browserens cache” – det tvinger din browser til at “glemme”, hvordan siden ser ud. Dette tvinger det til at spørge serveren til den nye, opdaterede version af siden.
En måde at styre browserens cache på, er at sætte en udløbsdato, også kaldet TTL, på de ressourcer der hentes fra serveren. Det er også muligt at opsætte en udløbsdato på enkelte typer ressourcer, så man for eksempelvis har en lang levetid på billeder, mens for eksempelvis JavaScripts og CSS filer, bør have en kortere levetid. Dette gøres i sidens konfigurationsfiler og på en Apache server hedder filen .htaccess hvor den på en IIS-server hedder web.config.
SSL Certifikater
Alle hjemmesider bør have tilknyttet et SSL Certifikat, ikke bare for at få gevinsten fra søgemaskinerne, men også for at beskytte den data dine besøgende afgiver på din side.
Et SSL Certifikat beskytter data som personlige oplysninger i forbindelse med log ind, tilmeldinger til nyhedsbreve, køb på nettet og mange andre data som udveksles med serveren.
Hvad er et SSL Certifikat?
SSL står for Secure Socket Layer, og er en teknologi, som sikrer den kommunikation der udveksles mellem den besøgendes browser og den server hvorpå hjemmesiden bliver afviklet fra.
Der findes mange forskellige typer og varianter af SSL Certifikater, og det er vigtigt at man vælger det rigtige fra starten. Skal dit SSL Certifikat eksempelvis også dække subdomæner, skal det være et såkaldt ”Wildcard” og skal det dække over flere forskellige domæner, skal man vælge et ”Multi-domain” certifikat.
Inden for hver type certifikat, findes der ligeledes forskellige grader af beskyttelse, og grundreglen er; jo mere beskyttelse, jo højere er prisen, og der er ikke noget der tyder på at de forskellige niveauer har større eller mindre indflydelse på om, og hvor stor, gevinst siden får af søgerobotterne fremfor en side uden SSL Certifikat.
Hvad koster et SSL Certifikat?
Prisen på et SSL Certifikat kan koste alt fra et par dollars om året til flere tusinde kroner. Det afhænger som regel af det miljø det skal installeres på, hvilket sikkerhedsniveau og hvorvidt det skal dække subdomæner.
Nogle hostingselskaber tilbyder sågar deres kunder gratis SSL. Du kan som regel købe og få rådgivning omkring certifikater hos dit hostingselskab.
Redirects
Man bør i videst mulige omfang forsøge at undgå at skulle opsætte redirect, men der er situationer hvor det ikke kan undgås. Det kunne eksempelvis være at man ønsker at skifte fra et CMS til noget andet, hvilket i mange tilfælde resulterer i at strukturen og webadresserne på hjemmesiden ændres. Andre gange sker det at produkter, kategorier eller mærker udgår, og så er det nødvendigt at tage en beslutning om hvad der skal ske med det gamle indhold.
Der findes mange forskellige typer af redirects, men den mest anvendte er ”301 Moved Permanently”.
Men hvad sker der hvis du ikke opsætter en viderestilling fra indhold der nedlægges, og bare lader siden sove stille ind?
Grunden til at vi altid anbefaler at viderestille nedlagt indhold, har flere årsager. Det skaber en dårlig brugeroplevelse at komme fra en søgemaskine til en fejlside, men der er også et andet aspekt, som skal tages med i betragtningen. Hvis den side der nedlægges, har optjent værdi, vil denne værdi gå forsvinde, hvorimod hvis siden viderestilles, bliver en stor del af værdien overført til den nye destination.
Hvordan tester jeg redirects?
Har du lavet redirects, og gerne vil teste om det er lavet korrekt, kan du bruge vores værktøj her:
https://www.riveronline.dk/301-redirect-checker
Hvis det er lavet korrekt, vil du se en linje hvor der står ”301 redirect” efterfulgt af ”200 OK”
Selvom Google har oplyst at de følger helt op til 5 omstillinger, så gælder det om at bruge så få som overhovedet muligt. For hver viderestilling, mistes en lille del af værdien, men det går også ud over indlæsningshastigheden og sidens crawlbudget.
At have styr på sine links, og specielt til interne ressourcer, viser at din hjemmeside på den front er vedligeholdt.
Robots.txt, noindex og .htaccess/web.config
Der kan være mange grunde til at udelukke sider fra indeksering eller udelukke søgerobotterne fra at kigge i filerne, og der er flere forskellige måder at gøre det på, men det er vigtigt at du forstår forskellen, inden beslutningen omkring metoden tages.
Robots.txt
Hvis du har indhold på din hjemmeside, som du af en eller anden grund, ikke vil have søgerobotterne kigger i, så skal du udelukke indholdet i sidens robots.txt
Dette vil effektivt forhindre søgerobotterne at kigge i filen, eller mappen, men det er ikke ensbetydende med at indholdet ikke kan dukke op i søgeresultaterne.
→ Google guide til oprettelse af robots.txt
Noindex
For at hindre at bestemte ressourcer ikke dukker op i søgeresultaterne, anvendes meta koden ”noindex” og det skrives på følgende måde:
<meta name=”robots” content=”noindex”>
Hvis du ønsker at holde søgerobotterne ude, og samtidigt ikke ønsker at finde indholdet i søgeresultatet, så har vi en udfordring. Hvis vi udelukker søgerobotterne i robots.txt vil de ikke komme ind og læse koden hvor der står ”noindex”, og vil derfor stadig kunne vises i søgeresultaterne.
.htaccess og web.config
En fil som altid bliver læst, er Apache serverens .htaccess og IIS serverens web.config. Heri er det muligt at opsætte ”noindex” på enkelte ressourcer, hele mapper eller specifikke filtyper.
Eftersom noindex ikke er muligt at sætte i meta koden for eksempelvis billeder, PDF filer, Excel ark og andre ikke-HTML ressourcer, er det gjort muligt at hindre indeksering gennem serverens .htaccess eller web.config.
Herunder er koden der skal sættes i .htaccess på en Apache server, for at udelukke indekserceringen af ALLE pdf filer på domænet:
<FilesMatch “\.pdf$”>
header set x-robots-tag: noindex
</FilesMatch>
Her er koden for at udelukke en enkelt PDF fil:
<Files guide.pdf>
header set x-robots-tag: noindex
</Files>
Det er også muligt at opsætte disse regler på en IIS serverens web.config, men jeg vil ikke komme med anbefaling her, da det kræver stor indsigt i serverens øvrige opsætning, og hvilke andre hjemmesider der ligger på serveren.
Sitemaps
Der findes grundlæggende 2 typer af sitemaps, nemlig et i kodeformatet XML og et opbygget med HTML. Formålet med de to typer forklares herunder.
En sitemap bruges til at underbygge forståelsen af hjemmesidens opbygning og indhold, om det så er for at hjælpe den besøgende eller en søgerobot.
Oftest er det CMS systemet som bygger ens sitemap, da det aldrig er statisk. Så snart du opretter, omdøber eller nedlægger webadresser til indhold, så skal sidens sitemap afspejle ændringen.
XML Sitemap
Der findes også forskellige typer af sitemaps, hvor jeg kun vil dække det gængse, nemlig en oversigt over de almindelige indekserbare webadresser der skal findes på søgemaskinerne.
Man kan ydermere lave sitemaps over billeder, videoer og nyheder som muligvis vil blive dækket i et senere blogindlæg.
Der er ydermere to måder at opbygge en XML-sitemap, som vi også lige vil runde, men ikke forklare i dybden, da Google har lavet en rigtig god beskrivelse af processen – der kommer et link i hvert af de to typer
Sitemap.xml
Et overskueligt website med under 5.000 indekserbare webadresser, kan oftest ”nøjes” med at bygge en sitemap.xml fil med de sider der skal vises på søgemaskinernes resultatsider.
→ Google guide til oprettelse og indsendelse af en sitemap
Sitemap-index.xml
Et stort site har oftest behov for at opdele sin sitemap i flere filer, enten på grund af den begrænsning der er for størrelsen eller antallet af webadresser i en sitemap.
Det kan også være en fordel at opdele sine sider i kategorier for at afstemme områdernes indekseringsgrad.
Kort fortalt er en sitemap-index.xml en struktureret liste af sitemap.xml filer
→ Google guide til opbyggelse af sitemap
Hvis du vil grave mere ned i de muligheder der findes i sitemaps, og de regler der gælder for opbygningen, så kan du læse meget mere på sitemaps.org
HTML sitemap
Et HTML sitemap bruges oftest til at vise den besøgende en ordnet oversigt over de sider der kan findes på domænet.
Det kan være med til at gøre siden mere overskueligt, men min holdning er at din side bør kunne stå alene, og behovet for et HTML sitemap, er et tegn på et dårligt eller uoverskueligt design på siden.
Der er også en SEO-mæssig gevinst af at have et HTML sitemap, da det kan forkorte rejsen ind til de inderste sider på domænet. Det er dog ikke den anvendelse vi anbefaler, da det oftest skyldes en uoverskuelig eller alt for rodet struktur på hjemmesiden. Hvis dine sider kan nås indenfor 3 klik fra forsiden, har du ikke SEO-mæssig behov for en HTML sitemap.
Hvis du vælger at lave et HTML sitemap, er min anbefaling at sætte siden/siderne til noindex, så søgemaskinerne ikke tager dem med i deres indeks. Men hvorfor? Siden giver ingen værdi til søgemaskinen, og handler jo ikke om noget, så hvilket søgeord skal man bruge på søgemaskinen for at finde siden?
Sprogversionering og SEO
Hvis du har flere sprogvarianter af din hjemmeside, kommer du ikke uden om at kode siderne op, så de forskellige sprogversioner sammen, hvis du skal have den fulde værdi.
Har du eksempelvis en dansk, tysk, hollandsk, tysk og engelsk sprogvariant af din hjemmeside, vil jeg få et par ting på plads.
Norsk eller svensk sprogversion ikke hører hjemme på et .dk domæne.
Vores anbefaling er altid at bruge et generisk domæne, også kaldet gTLD, til forskellige sprogversioner på samme domæne.
Det mest anvendte gTLD er .com eller .net, men der findes et stort antal muligheder, som du kan finde ved at besøge linket herunder.
→ Liste med Generic Top Level Domains
Den bedste løsning, men også den mest tidskrævende, er selvfølgelig at have et unikt domæne til hvert land, f.eks. som vi har, RiverOnline.dk til Danmark, RiverOnline.de til Tyskland, RiverOnline.com til US. Dette kan dog være en dyr løsning, hvis alle dine domæner ikke er ledige. Tilmed er opsætningen også mere kompliceret for din udvikler. Dog understøtter de fleste CMS systemer i dag, at have flere domæner på samme CMS, hvilket gør arbejdet det samme, uanset om du kun bruger et domæne eller flere.
Anbefalingen for hvilken domænetype du skal bruge, kommer dog helt an på din situation. Vi anbefaler altid at lave en forundersøgelse, hvilken løsning er den bedste for dig.
Rel=alternate hreflang
For at få den maksimale krydshenvisningsværdi af alle sprogvariationerne af din hjemmeside, skal de kodes sammen, og det er ikke kun forsiden, det er alle sider, som har en anden sprogvariant.
Sprogversioneret indhold på forskellige domæner
Hvis du har en sprogvariant A som er på dansk som er oversat på sprogvariant B på tysk og sprogvariant C er på hollandsk samt sprogvariant D findes på engelsk, skal der være rel=alternate hreflang henvisninger mellem dem alle.
Der skal også være en henvisning til den sprogvariant koden skal indsætte på. Kort sagt skal alle sider pege på alle sider, inklusive siden selv.
Slutteligt skal man have defineret en sprogversion til alle dem der ikke vil se siden på dansk, tysk, hollandsk eller engelsk, kaldet ”x-default”, og det kan sagtens være en af de allerede definerede versioner, og som oftest er det den engelske sprogvariant.
Koden til henvisningerne skal indsættes på de fire sider i sidens sektion.
Det kunne se således ud, hvis vi tager udgangspunkt i RiverOnline.dk
Sprogversioneret indhold på samme domæne
Det er også muligt at have flere sprogversioner på det samme domæne, og i princippet følger det samme opskrift som hvis de forskellige sprogversioner findes på forskellige domæner.
Sprogversionerede sitemap
En anden mulighed for at koble sprogvarianterne sammen, er gennem en sprogversioneret sitemap.
Eneste forskel i forhold til den kode der indsættes på hjemmesiderne på de forskellige domæner, er at det ikke er muligt at definere en ”x-default” version til de besøgende der ikke falder ind under de definerede sprog.
Sprogvarianter og regioner
Når man skal sprogversionere sit indhold, er det vigtigt at man bruger de rigtige koder til at definere målgruppen. I eksemplet herover, vises det at sprogvariationerne kun målrettes den besøgendes sprog, men det er også muligt at definere geografien. Dette kan gøre sig gældende hvis man har to målgrupper, som taler samme sprog, det kunne være engelsktalende englænder og en engelsktalende amerikaner.
En rel=alternate hreflang målrettet disse to målgrupper, kunne se således ud:
URL-opbygning
Når man planlægger opbygningen af menu-strukturen, giver det mest mening min kringlede SEO-hjerne, at den også afspejles i URL strukturen. Det vil sige hvis du har et menupunkt, som hedder ”hjemmesko” så hedder din webadresse også www.domain.dk/hjemmesko, og ikke som vi til tider ser www.domain.dk/?item=1428. Jeg plejer at have en tommelfingerregel, som hedder; ”Hvis du kan ringe til din tante Oda, og læse webadressen op i telefonen, og hun kommer ind på den rigtige side første gang, så har du gjort det helt rigtige”.
Der er aldrig en regel uden undtagelser, men gør man det nemt for brugeren, så bliver det også nemt for den søgerobot, som skal kravle din hjemmeside.
Og når vi nu alligevel har fat i menu og forholdet til søgerobotterne, så bliver jeg nød til at nævne et emne, som ikke bliver nævnt så tit, men er en væsentlig faktor i forhold til hvordan søgerobotterne opfatter og vurderer din hjemmeside, nemlig ”Crawl Depth”.
Hvad er Crawl Depth?
Algoritme-parameteret Crawl Depth er en betegnelse for hvor mange interne links man skal følge for at nå frem til indholdet. Jo længere indholdet ligger fra din forside, jo mindre relevant vurderes det at være. Det har tidligere fået mange SEO-specialister til at anbefale at lave et HTML sitemap, men det er en lappeløsning på et problem som er bedre løst på andre måder.
HTML Sitemap
Vi har tidligere omtalt emnet, men der er udfordringer med et HTML sitemap, som, til trods for det i dette tilfælde løser problemet med den lange vej til indholdet, så er der også andre faktorer som spiller ind i forhold til at måle relevansen af indholdet. Det er ikke bare et spørgsmål om hvor få kliks der skal til for at nå indholdet, men også hvor mange interne sider der linker til indholdet. Derfor er en velfunderet menu-struktur nøglen til at skabe den bedste relevans til dit hjørnestensindhold. Det er ikke meningen at alle sider absolut SKAL linke til alle andre sider, men så mange sider som det er muligt, skal linke til dit vigtigste indhold.
Der er mange, mere eller mindre geniale løsninger på lige netop denne problematik. Vi skal ikke mange år tilbage, for at finde en venstremenu med 50-100 links til sidens indhold, men den mest populære løsning for nuværende, er Mega Menuen.
Tilladte karakterer i en webadresse
Hvis du vil gøre det nemt for søgerobotterne og de besøgende, så holder du dig til bogstaver, som kan findes i det engelske alfabet, numeriske værdier og bindestreger.
Følgende karakterer må ikke indgå i en statisk webadresse: ! * ‘ ( ) ; : @ & = + $ , / ? % # [ ] < >
Disse karakterer er reserveret til andre formål, eksempelvis bruges spørgsmålstegnet og ampersand til dynamiske webadresser hvor parametre er med til at definere sidens indhold. Plustegnet bruges til at definere et mellemrum og der er hvis ingen der er i tvivl om hvilke typer adresser der bruger et snabel-a, nemlig e-mailadresser. Således har de ovenstående alle en funktion, som kan skabe konflikter hvis de bruges i webadresser.
Et af de tegn, som ikke er ”reserveret til andre formål”, men som jeg fraråder at bruge, er underscore. Tegnet er den lille streg i bunden, som vi ofte ser brugt til at skille ord ad i en webadresse. Men udfordringen er at søgerobotterne bruger underscore til at samle tekst til færre ord. En webadresse som www.domain.dk/sorte_hjemmesko bliver opfattet som www.domain.dk/sortehjemmesko.
Hvis der indgår mere end det ene søgeord i webadressen, er anbefalingen at bruge bindestregen, så kommer webadressen til at se således ud: www.domain.dk/sorte-hjemmesko
Du kan læse mere om de regler der er sat op for en URL her: https://www.ietf.org/rfc/rfc1738.txt
”Jamen jeg sælger jo æbler og pærer”
Søgerobotterne er blevet meget bedre til at forstå hvad et æble er, og ved at det også kan staves aeble, og pølse kan staves poelse får ikke at skulle gemme østers som kan staves oesters.
Hvis man ikke selv oversætter vores danske bogstaver, så gør søgerobotterne det for dig, hvilket ikke kommer til at se læseligt ud. Æble bliver lavet om til %C3%86ble og pære bliver til p%C3%A6re.
Hvis du er i tvivl om hvorvidt søgemaskinerne kan forstå dit oversatte ord, kan du bare prøve at søge efter det på søgemaskinen, for eksempelvis https://www.google.com/search?q=paere og se hvad søgemaskinen viser som resultater.
INFO: URL står for Uniform Resource Locator, og er en adresse til en ressource.
Hvor lang må en webadresse være?
Anbefalingen er at holde din webadresse så kort og forståelig som muligt, og derfor giver det heller ikke mening at snakke om hvor lang en webadresse må være, men så alligevel. Når man arbejder med webshops, så finder vi ofte at det ikke er muligt at holde sig til kun at anvende et enkelt niveau. For slet ikke at snakke om de muligheder der oftest er for filtrering og sortering. Man kunne godt forestille sig at nedenstående webadresse er eneste mulighed for en unik webadresse på visse CMS.
http://www.domain.dk/herre/hjemmesko/sorte?size=44&orderby=price&dir=desc&view=list
Den webadresse fylder 83 tegn, og jeg har set webadresser med over 500 tegn. Der er en tommelfingerregel, som jeg ikke håber du kommer til at skulle forholde dig til, nemlig at man bør holde sig under 115 karakterer.
Brugen af parametre i webadresser
Selvom jeg tidligere har skrevet at du ikke må bruge ? og & i statiske webadresser, så gælder det ikke for dynamiske webadresser. Dynamiske webadresser bruges til at indskrænke, sortere eller definere indhold på siden. Et eksempel på en dynamisk webadresse, nævnte vi tidligere, og selvom jeg fraråder den, så er den fuldt ud gyldig, nemlig webadresser som www.domain.dk/?item=1428.
Et eksempel på en dynamisk webadresse, som vi som regel ikke kommer uden om, er eksempelvis www.domain.dk/hjemmesko?color=black som vil gå ind til en side med hjemmesko i farven, sort. Et andet eksempel kunne være www.domain.dk/hjemmesko?color=black&orderby=price som har to parametre, hvor ampersand kommer ind i billedet, som adskillelse af de to parametre color og orderby.
Der er visse forholdsregler man skal tage i betragtning, når man bruger parametre i sine webadresser, nemlig risikoen for dobbelt indhold, som kan være meget skadeligt for din hjemmesides chancer for en topplacering på søgeordet. Hvis parametrene udelukkende ændrer på produkterne på siden, og ikke ændrer i sidens øvrige indhold, såsom title, meta beskrivelse eller onpage tekst, vil den rigtige løsning være at samle indholdet på de mange kombinationsmuligheder til hovedsiden. Den teknologi der anvendes til at samle værdien fra de mange kombinationsmuligheder i forbindelse med anvendelse af parametre, kaldes rel=canonical, og vil blive forklaret i det følgende afsnit.
Men jeg vil gerne findes på ”Sorte hjemmesko”?
Hvis du gerne vil findes på en søgning, som indeholder en indsnævring af et emne, som eksempelvis ”hjemmesko”, skal der oprettes en dedikeret landingpage til produkterne, hvor det er muligt at definere en optimeret title, meta beskrivelse og onpage indhold. Det kunne være på webadressen www.domain.dk/sorte-hjemmesko
En anden løsning kunne være at optimere siden om hjemmesko, så den også kan fange ”sorte hjemmesko” men det er sjældent den optimale løsning, hvis der er mange farvevarianter. Det kan hurtigt blive meget omfattende, hvis du har 10 forskellige farver i 10 forskellige materialer med 20 forskellige størrelser.
Det giver 2.000 sider hvor til der skal laves en unik tekst og skrives en fangende title og meta beskrivelse.
En dybdegående søgeordsanalyse, kan være med til at afgøre hvilke områder det kan ”betale” sig at gå efter.
Hvad er rel=canonical?
Metoden, eller teknologien, blev opfundet tilbage i 2009 af søgegiganterne Google, Bing og Yahoo, for at afhjælpe et stigende problem med at identificere det unikke indhold og tage hånd om duplikeret indhold.
Det skal i denne forbindelse nævnes at rel=canonical ikke betragtes som en regel, det vil sige at søgerobotterne kan ”vælge” at se bort fra en defineret canonical, men det betragtes som et stærkt signal til søgemaskinerne. Anvendelsen bliver beskrevet som en metode til at konsolidere indhold, som ikke er unikt.
Vi har rundet en af anvendelsesmulighederne, nemlig til at samle indhold i forbindelse med anvendelsen af parametre i webadresser, hvor indholdet ikke ændres i nævneværdig grad, og det er også den mest anvendte mulighed. En anden mulighed, som gør sig gældende i visse CMS, også nogle af de store, som ellers ville forventes at have taget hånd om så alvorligt et emne, er indhold, som kan tilgås på mere end én webadresse.
Lad os fortsætte med de sorte hjemmesko, som nogle Content Management Systemer lader eksistere på flere webadresser, eksempelvis www.domain.dk/hjemmesko/sorte, og www.domain.dk/sorte/hjemmesko, alt efter den vej man har fundet ind til indholdet på. Det gøres med andre ord forskel på det samme indhold, skulle man først vælge farven før man vælger typen, altså hjemmesko.
I dette tilfælde bør man vælge en ”master variant” til indholdet, og definere dette som sidernes ”canonical”. Dette gøres ved at indsætte en kode i sidens kildekode. Koden skal indsættes i sidens head område, og struktureres således:
Jeg ville personligt have det vigtigste emne først i webadressen, i dette tilfælde ”hjemmesko” fremfor ”sorte”.
En anden måde at sikre sig mod dobbelt indhold, er at viderestille den ene webadresse til den ønskede version, men det er ikke altid muligt, som eksempelvis ved anvendelsen af parametre. Fordelen ved at bruge redirects fremfor canonical, er at viderestillinger betragtes som en regel, som søgemaskinerne skal følge, og det vi derfor effektivt udelukke dobbelt indhold.
Du kan læse mere om redirects, eller viderestillinger på dansk, længere oppe i denne artikel.
Læs mere om link elementet canonical her: https://en.wikipedia.org/wiki/Canonical_link_element
Få mere ud af din digitale marketing
Lad os kigge din online marketing igennem og danne et overblik over, hvor vi kan optimere bedst muligt.
Thomas Muus
Senior Strategic Advisor
