De 9 største SEO-problemer, og hvordan du undgår eller retter dem

SEO er en kompleks disciplin, hvor mange faktorer og procedurer skal overvejes nøje for at blive sat rigtigt op. Der er forskellige måder, vi kan gøre det forkert på og skade et websites organiske potentiale.
I dette indlæg gennemgår vi de mest almindelige SEO-problemer, og hvordan du undgår at falde i dem. Og kæmper du allerede med den slags problemer, kan vi hjælpe dig med at rette dem.
Lad os starte med det basale.
Hvad er SEO-problemer?
Et muligt SEO-problem, der kan skade vores websites performance i søgemaskinerne, kan identificeres som et problem. For at sikre en fornuftig optimering af sites, der rangerer højt i Google (og andre søgemaskiner), bør vi kende et par almindelige fejl.
Døde interne og eksterne links
Jo flere sider et website har, jo større er risikoen for døde links. Når et site bliver ved med at vokse og producere mere indhold, opstår faren for 404-sider, ingen opdager. Selvom det er godt at udvikle og tilføje nye funktioner og landingssider, skal vi altid holde øje med problemer med interne og eksterne links.
Vi som brugere bryder os ikke om at lande på en side, der ikke virker, vel? Det afbryder vores flow og ender ofte med, at vi forlader websitet med det samme.

Besøgende kan opfatte websiden som ikke troværdig. Som vi ved, er Google rigtig god til at aflæse brugernes opfattelse af et website eller en side. Er brugerne altså utilfredse, bliver søgemaskinerne det også.
Dertil kommer, at døde sider spilder dyrebart crawlbudget, der kunne bruges fornuftigt. Vi vil ikke have, at botterne *bruger tid og ressourcer *på sider, brugerne ikke kan komme til.
Den gode nyhed er, at vi let kan finde døde interne og eksterne links takket være forskellige SEO-værktøjer. Har vi et mindre website med få sider, kender vi dem naturligvis nok udenad, og så er det ikke så svært at sikre sig, at alt fungerer.
Men i takt med at vi udvikler vores websites, bliver det umuligt og unødvendigt at gøre det manuelt.
Tip: kør planlagte scanninger en gang om ugen eller måneden, og finder du døde links, så grav dybere og ret dem.

Dubleret indhold
Dubleret indhold er et af de ældste og mest almindelige problemer blandt digitale marketingfolk. Hovedbekymringen er, at søgemaskinerne, Google inklusive, kan have svært ved at finde og rangere de rigtige URL'er, når vi giver dem sider, der ligner hinanden.
Resultatet er, at vi (som SEO-folk) kan miste trafik eller bare ikke få det fulde udbytte af vores websites.
Vi som søgemaskinefolk skal sikre, at vores indhold er unikt. For at gøre livet lettere for søgemaskinerne bør vi undgå et par almindelige faldgruber.
Dubleret indhold opstår ofte, fordi forskellige versioner af samme side er tilgængelige for brugere og botter. For eksempel er det et udbredt problem, at både http- og https-versionen af et website loader uden de rigtige viderestillinger.
For at undgå det problem skal vi have de korrekte viderestillinger fra http til https sat op. Vi kan let teste det ved at skrive http://oursitename.com i browseren. Er vores https-protokol slået til og sat rigtigt op, bør browseren viderestille os til https://oursitename.com.

På samme måde bør versionen uden www af et website viderestille til www-versionen, hvis det er hovedversionen af vores website, og omvendt.

Parametre i URL'er er en anden *almindelig fælde *, der giver dublerede URL'er. Content management-systemer tilføjer ofte sorteringsparametre (for størrelse, farve, model og så videre), der kan ende med at give talrige sider med samme indhold.

Alligevel er det ikke noget at være bekymret for, hvis vi implementerer rigtige canonicals og no-index-attributter, når det er nødvendigt.
Bemærk: canonical-tags er en udbredt måde at fortælle Google, hvilken af et sæt ens URL'er der skal indekseres og tælle som den primære. En anden måde er at bruge en no-index-attribut, når parametre giver forskellige URL'er med samme eller lignende indhold.
**Fejl i **title-tags
Title-tags er blandt de vigtigste SEO-elementer på siden. De fortæller søgemaskinerne, hvad der er sidens hovedemne. Title-tags vises også i søgeresultaterne øverst i hvert organisk resultat. Det gør dem til et af nøgleelementerne og ofte en afgørende faktor for, om brugerne klikker på et bestemt resultat.
At tage sig tid til at sætte dem rigtigt er en afgørende SEO-opgave. Men nogle gange bliver det forsømt, og det giver lave klikrater.
De største problemer med title-tags er:
- title-tagget mangler helt
Her sætter Google selv et title-tag ud fra sin forståelse af, hvad vores side handler om. Normalt klarer den opgaven fint, men det er stadig en forspildt SEO-mulighed.
Det er godt at sætte title-tags selv, især på vores vigtigste sider.
- for lange eller for korte title-tags
At bruge korte title-tags er en forspildt chance for at tiltrække brugere og få dem til at klikke på vores resultater. Praksis er som regel at have mellem 55-65 tegn vist i søgeresultaterne.
Omvendt kan title-tags, der er for lange (over 65 tegn), blive skåret af og ikke vist fuldt ud. Det giver endnu en forspildt chance for at vise hele vores budskab til omverdenen.

Som vi kan se her, er både titlen og meta description afkortet og giver derfor ikke den bedste brugeroplevelse.
- dublerede title-tags
Det er almindelig praksis på e-handelssites at have identiske tags. Det er desværre ofte tilfældet på andre typer sites også. Dublerede title-tags gør det sværere for websider at skille sig ud og adskille sig fra andre lignende sider.

Problemer med robots.txt
*Robots.txt *er et forholdsvis enkelt, men nyttigt værktøj, der giver vigtig information og instruktioner til søgemaskinernes crawlere. Den ligger i websitets rodmappe og bruger formatet ren tekst.
Den kan forhindre, at bestemte dele af vores website bliver crawlet, så botterne ikke spilder dyrebare ressourcer. Men der er nogle mulige fejl, vi bør kende.
Adgang til staging- og dev-sites eller adminpaneler
Der er flere måder at stoppe søgemaskinerne fra at nå test- og udviklingsversioner af dit domæne. En af dem er en kommando i din robots.txt-fil, men der findes mere effektive måder (f.eks. HTTP-autentificering).
En af de mest almindelige blokeringsinstruktioner på WP-sites er at udelukke mappen med wp-admin-panelet. Sådan ser det ud:
User-agent: * Disallow: /wp-admin/
User-agent: * betyder, at instruktionen gælder for alle botter (Google bot, Bing bot og så videre), og anden linje siger, at vi vil stoppe dem fra at crawle mappen /wp-admin/ og alt, hvad der ligger i den.
Blokering af vigtige URL'er fra crawl
Ligesom ved den forrige kommando vil vi ikke disallowe vigtige mapper på vores website, så botterne ikke kan komme til dem. En almindelig fejl kunne for eksempel være:
User-agent: * Disallow: /example-important-directory/
Eller nogle gange ser vi endda dette:
User-agent: * Disallow: /
hvilket i praksis betyder disallow på hele websitet for alle botter. Det bruges normalt, før websitet »åbnes« for omverdenen under de første tests. Men nogle gange bliver det forsømt, og udviklere eller SEO-folk glemmer at fjerne det, når websitet er tilgængeligt for offentligheden, søgemaskiner og brugere inklusive.
Manglende link til sitemap-filen
Robots.txt er en god måde at gøre det lettere for søgemaskinerne at finde et websites sitemap-fil. Selvom det ikke er en kæmpe fejl at springe det over (især på mindre websites), er det stadig hurtigt og nyttigt at gøre.

Katastrofer med meta robots-tagget
Meta robots er et af de vigtigste tags og direktiver overhovedet, når det gælder SEO. Det er en effektiv måde for sitejere at fortælle søgemaskinerne, at en bestemt side ikke skal følges eller indekseres.
Der er forskellige brugsscenarier og opsætninger, men det mest udbredte (og ofte farlige) er noindex-tagget. Det »bor« i head-sektionen i HTML'en og ser sådan ud:
<meta name="robots" content="noindex,follow" />
Grundlæggende betyder det, at vi beder søgemaskinerne om ikke at indeksere vores indhold i søgeresultaterne, men gerne vil have dem til at følge linkene på siden. Vi kan løse forskellige mulige problemer ved at forhindre søgemaskinerne i at indeksere indhold. For eksempel:
- sider med tyndt indhold, der ikke giver brugerne reel værdi- checkout-sider på e-handelssites- URL'er med følsomme oplysninger- dev- og staging-sider, der ikke er klar til at blive lanceret til offentligheden
Det mest almindelige problem med* noindex*-kommandoen er at glemme at fjerne den på en vigtig side (eller hele websitet), når den er klar til at blive officielt lanceret til omverdenen. Lad os sige, at udviklerne har arbejdet på den længe og testet forskelligt, og så glemmer nogen bare at fjerne den, når den er lanceret.
Det er uden tvivl et af de første (og enkleste) tjek, du skal lave, hvis du undrer dig over, hvorfor et bestemt website eller en bestemt sektion ikke giver organisk trafik.
Du skal bare åbne kildekoden og søge (ctrl+f) efter kommandoen »robots«. Ser du direktivet »no index«, så er du i problemer! Den gode nyhed er dog, at du nu kender grunden og kan rette det let.

Når canonicals går galt
Canonical-tagget er et stærkt våben i SEO-folks arsenal. Det bruges ofte til at undgå mulige SEO-problemer med ens indhold på forskellige URL'er.
Det er for eksempel meget almindeligt i e-handelskataloger med forskellige parametre på siderne, som potentielt kan give problemer med dubleret indhold.
Med canonical fortæller vi simpelthen søgemaskinerne, hvilken side der er den »primære« / »oprindelige«, så alle de andre versioner ikke skaber problemer. Google ved desuden, hvilken side den skal prioritere og vise i søgeresultaterne.
Der er et par problemer, der kan opstå her. Et af dem er, som allerede nævnt, ikke at have sat en canonical, når du har forskellige URL'er med samme indhold.

Er canonical sat, er her de mest almindelige farer at kende:
- canonical-URL'en peger på en URL med noindex-tag- canonical-URL'en peger på en URL, der svarer med en 4xx- eller 5xx-statuskode- canonical-URL'en peger på den usikre http-version af en side (når vi også har den sikre version)- ikke selvrefererende canonical (den såkaldte canonicalized URL)
Bemærk: det kan være fint, hvis det er med vilje, men i de fleste tilfælde vil vi have selvrefererende canonicals
- canonical-tagget er tomt eller peger på en ugyldig side
Problemer med hreflang
Hreflangs er hyperlink-referencer i en sides HTML-kode, der lader os angive de alternative URL'er, der hører til et bestemt sprog eller område. De er særligt vigtige for websites, der opererer i flere lande og leverer indhold på flere sprog.

Hovedidéen bag hreflang-referencerne er at sikre, at vi viser den rigtige version af websitet efter brugerne og deres land eller sprog.
For eksempel vil vi vise /es-versionen af et website eller en side til spanske besøgende, og til tyske besøgende skal det være /de, og så videre.
Grundlæggende fortæller vi Google, hvilken side og på hvilket sprog den skal vises til brugerne, afhængigt af deres sprogindstillinger og placering.
Hreflang-annotationer ser sådan ud:
<link rel="alternate" href="https://www.example.com/es/" hreflang="es" />
De mest almindelige hreflang-problemer er:
- manglende returlink
Alternative URL'er skal have den samme kode som den side, der indeholder de alternative hreflang-URL'er. Bruger du et hreflang-tag, og side X linker til side Y, skal side Y linke tilbage til side X. Grundlæggende skal hver linje hreflang-kode, der refererer til en anden side, stå med samme kode på hver side, den tilføjes til.
- det registrerede sprog matcher ikke det angivne sprog
Nogle gange er sproget, der er angivet i hreflang-tagget, et andet end sproget i sidens faktiske indhold
- forkerte ISO-koder
En udbredt fejl er at bruge »en-UK« i stedet for »en-GB«, når man går efter engelsktalende besøgende i Storbritannien. Syntaksen er også meget vigtig. Selvom mange websites bruger underscores til at angive sprog i deres URL'er, virker kun bindestreger i hreflangs.
- manglende selvrefererende tag
At tilføje et selvrefererende hreflang-tag er et must for at sikre, at internationale sites er sat rigtigt op og er lette for søgemaskinerne at forstå.
- brug af relative URL'er i stedet for absolutte
Endnu en almindelig fejl med hreflangs. Vi bør undgå relative adresser, der kun angiver en sti, og altid gå efter den fulde sidesti.
Rigtigt:
<link rel="alternate" href="https://www.example.com/es/spanish-post" hreflang="es" />
Forkert:
<link rel="alternate" href="es/spanish-post" hreflang="es" />
Her er et nyttigt værktøj til at finde hreflang-problemer- https://technicalseo.com/tools/hreflang/
Farer ved JavaScript
Selvom Google bekræfter, at JavaScript kan bruges uden at give SEO-problemer, bør vi være forsigtige med det. Udviklere bruger ofte JS til at loade vigtigt indhold og vigtige links, og det kan sætte os i en situation, hvor søgemaskinerne ikke kan crawle og forstå indholdet rigtigt.
Derfor er det en god idé at bruge ekstra tid på at inspicere vores websites og se, om al den vigtige information vises korrekt.
For eksempel kan en dårlig JS-implementering betyde, at Google* ikke læser de meta-titler og -beskrivelser*, vi har sat op, og det giver problemer med vores CTR i søgeresultaterne.

Derfor er det helt afgørende at kende Googles fortolkning af vores JavaScript-indhold, og om den kan crawle og indeksere informationen ordentligt.
Problemer med mobilvenlighed
Det overrasker nok ingen, at et websites mobilvenlighed og performance er to af de vigtigste SEO-faktorer i dag.
Der er gået nogle år, siden Google skiftede til mobile-first-indeksering og begyndte at tage udgangspunkt i en websides mobilversion.
Et af de største problemer, man så oftere dengang, var at vise forskelligt indhold til desktop- og mobilbrugere. Det er en meget farlig praksis og kan give dårligere organiske resultater.
Nogle af de vigtigste faktorer, der kan påvirke websitets performance, er:
- et stort antal plugins
Prøv at holde dig fra at installere et stort antal plugins. Jo flere plugins du har, jo tungere og mere klodset bliver dit website.
Dertil kommer, at plugins er en mulig indgang for hackere (når de ikke bliver opdateret i tide), så de kan også udgøre en sikkerhedsrisiko.
- ikke-optimerede billeder
Billeder er en af de mest almindelige faktorer, der påvirker sidernes hastighed og et websites samlede performance. Ingen bryder sig om langsomme websites, så vi anbefaler altid at prøve at holde billederne* under 100 kb* i størrelse.

- hostingtjenester
Husk, at serveren, du hoster dit website på, er det fundament, alt bliver bygget på. Derfor er det bedre ikke at gå efter den billigste løsning og spare dig selv for besvær senere. Det er værd at investere lidt mere og til gengæld få et pålideligt, sikkert og hurtigt hosting.
Kort sagt
Som vi har set, er der talrige måder at gøre det forkert på, når det gælder SEO. Det er også værd at bemærke, at det bare er nogle få af de mest udbredte og almindelige tekniske SEO-problemer, vi kan støde på. Der findes mange flere SEO-mareridt, der kan ske.
Vi håber, vi indtil videre har hjulpet dig med at få et bedre billede og en bedre forståelse af de vigtigste SEO-problemer og, endnu vigtigere, hvordan du undgår eller retter dem.
Held og lykke!
Forfatter: Ognian Mikov

SEO kom ind i mit liv i 2012, og jeg har været forelsket i det lige siden. For mig er det mere end et job — det er både en passion og en hobby, der holder mig motiveret til at lære og blive bedre. Uanset om jeg undersøger nye emner, skriver indhold eller graver mig ned i tekniske problemer, fascineres jeg af den enorme verden inden for digital markedsføring og af alle de måder, man kan forbedre et website på.
I 2021 kom jeg til SEO Alive og SEOcrawl AI — min første virksomhed med fuldt fjernarbejde — hvor jeg har fået nye kompetencer og arbejdet på spændende projekter. Vigtigst af alt har jeg mødt og lært af fantastiske kolleger, som også er blevet venner.
Jeg har en bachelor i marketing og en kandidatgrad i PR og reklame. I min fritid er jeg sammen med min datter og spiller og ser skak, fodbold (Само Левски & Més que un club) og poker.
Find mere indhold fra denne forfatter

