12 typiske tekniske SEO-fejl – og sådan løser du dem

En hjemmeside kan have godt indhold, attraktive produkter og en flot visuel identitet, men stadig have svært ved at opnå gode placeringer i Google. Forklaringen findes ofte under overfladen.

Tekniske SEO-fejl kan forhindre Google i at finde, gennemgå, forstå eller indeksere hjemmesidens sider korrekt. I andre tilfælde kan fejlene skabe en langsom og frustrerende brugeroplevelse, som gør det sværere for hjemmesiden at konkurrere i søgeresultaterne.

Problemet er, at mange tekniske fejl ikke er synlige for en almindelig besøgende. En side kan se ud til at fungere normalt i browseren, samtidig med at den:

• Er markeret med noindex.
• Er blokeret i robots.txt.
• Har en forkert canonical-adresse.
• Returnerer en forkert HTTP-statuskode.
• Ikke kan findes gennem interne links.
• Indlæses for langsomt på mobil.
• Sender Google gennem lange kæder af redirects.

I denne guide gennemgår vi 12 af de mest almindelige tekniske SEO-fejl. Du får samtidig en praktisk forklaring på, hvordan fejlene opdages, hvorfor de kan påvirke hjemmesidens synlighed, og hvordan de kan løses.

Hvad er en teknisk SEO-fejl?

En teknisk SEO-fejl er et problem i hjemmesidens struktur, kode, serveropsætning eller indekseringssignaler, som gør det vanskeligere for søgemaskiner at behandle hjemmesiden korrekt.

Google skal grundlæggende kunne gennemføre fire trin:

1. Finde sidens URL.
2. Gennemgå siden.
3. Fortolke sidens indhold og relation til andre sider.
4. Indeksere den korrekte version af siden.

Hvis processen bliver afbrudt, kan en vigtig side ende med slet ikke at blive vist i Google. Den kan også blive indekseret under en forkert URL eller få mindre synlighed, fordi Google modtager modstridende signaler.

Teknisk SEO handler derfor ikke kun om hastighed. Det omfatter blandt andet crawling, indeksering, URL-struktur, redirects, canonical-tags, mobilvenlighed, strukturerede data og hjemmesidens interne arkitektur.

1. Vigtige sider kan ikke indekseres på grund af noindex

Et noindex-direktiv fortæller søgemaskiner, at en side ikke skal vises i søgeresultaterne. Det kan være nyttigt på sider som interne søgeresultater, kontosider og andre sider uden selvstændig værdi for brugere fra Google.

Problemet opstår, når noindex ved en fejl bliver tilføjet til sider, som faktisk skal findes i søgeresultaterne.

Det ses blandt andet efter:

• Lancering af en ny hjemmeside.
• Flytning fra et testmiljø til det rigtige domæne.
• Ændringer i Yoast SEO eller et andet SEO-plugin.
• Import af sider fra en anden hjemmeside.
• Installation af et plugin, der styrer indekseringen.
• Ændring af WordPress-indstillingen for søgemaskinesynlighed.

Sådan finder du fejlen

Kontrollér siden med URL-inspektion i Google Search Console. Her kan du se, om Google har fundet et noindex-direktiv.

Du kan også åbne sidens kildekode og søge efter:

<meta name="robots" content="noindex">

Vær opmærksom på, at noindex også kan blive sendt som en HTTP-header:

X-Robots-Tag: noindex

Derfor er det ikke altid tilstrækkeligt kun at kontrollere HTML-koden.

Sådan løser du problemet

Fjern noindex fra de sider, som skal være synlige i Google. Læs eventuelt mere om, hvordan indeksering og crawling fungerer, hvis du vil forstå hele processen fra Google finder siden, til den kan vises i søgeresultaterne. Kontrollér derefter, at siden:

• Returnerer statuskode 200.
• Ikke er blokeret i robots.txt.
• Har en korrekt canonical.
• Findes i XML-sitemappet.
• Modtager interne links.

Når fejlen er rettet, kan du anmode om en ny indeksering i Google Search Console.

Læs mere om det i googles dokumentation for crawling og indexering.

2. Robots.txt blokerer vigtige dele af hjemmesiden

Robots.txt fortæller søgemaskinernes crawlere, hvilke adresser de må eller ikke må anmode om. En forkert regel kan derfor gøre store dele af hjemmesiden utilgængelige for Googlebot.

En problematisk opsætning kan eksempelvis se sådan ud:

User-agent: *
Disallow: /

Skråstregen betyder i dette tilfælde, at hele hjemmesiden er blokeret.

Mindre åbenlyse fejl kan blokere bestemte mapper, produktsider, kategorier, CSS-filer eller JavaScript-filer.

Robots.txt og noindex er ikke det samme

Robots.txt styrer crawling, mens noindex styrer indeksering.

Hvis en URL er blokeret i robots.txt, kan Google ikke nødvendigvis gennemgå siden og se dens noindex-direktiv. En blokeret URL kan i visse tilfælde stadig blive vist i søgeresultaterne, hvis Google finder adressen gennem eksterne eller interne links.

Derfor bør robots.txt ikke bruges som den primære metode til at fjerne sider fra Google.

Sådan kontrollerer du robots.txt

Filen findes normalt på:

https://ditdomæne.dk/robots.txt

Undersøg især regler med Disallow, og kontrollér, om de påvirker vigtige mapper eller URL-mønstre.

På en WordPress-hjemmeside er det normalt fornuftigt at blokere selve administrationsområdet og samtidig tillade admin-ajax.php:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Den præcise opsætning afhænger dog af hjemmesidens funktioner og URL-struktur.

3. Forkerte canonical-tags

En canonical fortæller Google, hvilken URL der bør betragtes som den foretrukne version, når flere adresser viser det samme eller næsten det samme indhold.

Et korrekt selvrefererende canonical-tag kan se sådan ud:

<link rel="canonical" href="https://eksempel.dk/kategori/produkt/" />

Canonical-fejl opstår ofte, når:

• En vigtig side peger på en anden side.
• Alle undersider peger på forsiden.
• HTTP-versionen angives i stedet for HTTPS.
• Et testdomæne stadig står som canonical.
• Filtrerede URL’er peger forkert.
• Sider med sideinddeling peger uhensigtsmæssigt på første side.
• Canonical-adressen omdirigerer eller returnerer en fejl.

Konsekvensen kan være, at Google vælger en anden side end den, du ønsker placeret i søgeresultaterne.

Sådan arbejder du med canonical-fejl

Kontrollér både den canonical, hjemmesiden selv angiver, og den canonical Google har valgt. Begge oplysninger findes ofte i URL-inspektionen i Search Console.

Hvis de to adresser ikke er ens, skal du undersøge, om Google modtager modstridende signaler gennem:

• Interne links.
• XML-sitemap.
• Redirects.
• Canonical-tags.
• Hreflang-tags.
• HTTP- og HTTPS-versioner.
• Versioner med og uden www.

Alle signaler bør pege mod den samme foretrukne URL.

4. XML-sitemappet indeholder forkerte URL’er

Et XML-sitemap hjælper Google med at opdage hjemmesidens vigtige sider. Det er især værdifuldt på større hjemmesider, webshops og sider, hvor nyt indhold udgives ofte.

Et sitemap er dog ikke automatisk korrekt, bare fordi det kan åbnes.

Typiske fejl omfatter:

• URL’er med noindex.
• URL’er, der omdirigerer.
• Slettede sider med statuskode 404.
• Dubletter og parameterbaserede URL’er.
• Testdomæner eller gamle domæner.
• Sider med canonical til en anden URL.
• Manglende produktsider, kategorier eller artikler.
• Fejl i datoen for seneste ændring.

Hvilke sider skal med?

Som udgangspunkt bør sitemappet kun indeholde kanoniske URL’er, der:

• Returnerer statuskode 200.
• Må indekseres.
• Har selvstændig værdi.
• Skal kunne findes i Google.
• Har en korrekt canonical.

Et sitemap er ikke en garanti for indeksering. Det er et signal om, hvilke URL’er du betragter som vigtige.

Indsend sitemappet i Google Search Console, og sammenlign de indsendte adresser med de sider, Google faktisk har indekseret. Store afvigelser kan afsløre problemer med kvalitet, dubletter, crawling eller tekniske signaler.

5. Brudte links og 404-fejl

En 404-status betyder, at den ønskede ressource ikke blev fundet. Det er ikke i sig selv farligt at have enkelte 404-sider. Sider bliver slettet, produkter udgår, og URL’er ændres.

Problemet opstår, når hjemmesiden selv fortsat linker til de slettede adresser, eller når værdifulde eksterne links ender på en fejlside.

Mange interne 404-links kan:

• Skabe en dårlig brugeroplevelse.
• Spilde søgemaskinernes crawling.
• Svække hjemmesidens interne struktur.
• Betyde, at linkværdi ikke når frem til relevante sider.
• Gøre det sværere for Google at forstå relationen mellem siderne.

Skal alle 404-fejl omdirigeres?

Nej. En slettet side skal ikke automatisk omdirigeres til forsiden.

Hvis der findes en tydelig erstatning, bør den gamle URL omdirigeres med en permanent 301-redirect. Det kan eksempelvis være:

• Et udgået produkt til en direkte efterfølger.
• En gammel kategoriside til den nye kategori.
• En gammel artikel til en opdateret udgave af samme emne.

Hvis der ikke findes en relevant erstatning, er en korrekt 404- eller 410-status ofte mere præcis end en irrelevant redirect.

Sådan finder du brudte links

Crawl hjemmesiden med et SEO-værktøj, og filtrér efter interne links, der ender på statuskode 404. Kontrollér også rapporterne i Google Search Console og eventuelle serverlogs.

Ret helst det interne link direkte. En redirect kan være nyttig for gamle eksterne links, men interne links bør pege direkte på den endelige URL.

6. Redirect-kæder og redirect-loops

En redirect-kæde opstår, når en URL omdirigerer gennem flere trin:

URL A → URL B → URL C → URL D

En redirect-loop opstår, når omdirigeringerne sender brugeren rundt i en cirkel:

URL A → URL B → URL A

Redirect-kæder gør siden langsommere og skaber unødvendigt arbejde for både browsere og søgemaskiner. Redirect-loops betyder, at siden slet ikke kan åbnes.

Problemerne opstår ofte efter flere redesigns eller migreringer, hvor nye regler bliver lagt oven på gamle redirects.

Den korrekte løsning

Alle gamle URL’er bør som udgangspunkt omdirigere direkte til den endelige destination:

URL A → URL D
URL B → URL D
URL C → URL D

Opdatér samtidig interne links, menuer, canonicals og sitemap-adresser, så de peger direkte på URL D.

Undersøg også, om der opstår unødvendige omdirigeringer mellem:

• HTTP og HTTPS.
• www og versionen uden www.
• URL’er med og uden afsluttende skråstreg.
• Store og små bogstaver.
• Gamle og nye sprogversioner.

7. Forkerte HTTP-statuskoder og soft 404-sider

En hjemmeside kommunikerer med både browsere og søgemaskiner gennem HTTP-statuskoder.

De mest almindelige er:

• 200: Siden fungerer og kan leveres.
• 301: Permanent omdirigering.
• 302 eller 307: Midlertidig omdirigering.
• 404: Siden blev ikke fundet.
• 410: Siden er permanent fjernet.
• 500: Intern serverfejl.
• 503: Tjenesten er midlertidigt utilgængelig.

En typisk fejl er, at en fejlside visuelt fortæller, at produktet eller siden ikke findes, men stadig returnerer statuskode 200. Google kan opfatte dette som en såkaldt soft 404.

Det modsatte kan også ske: En side ser normal ud, men serveren returnerer en fejlstatus.

Sådan undersøger du statuskoder

Brug et crawl-værktøj eller kontrollér serverens headers. Det er vigtigt at undersøge den faktiske statuskode og ikke kun det, der vises i browseren.

Kontrollér især:

• Slettede produkter.
• Tomme kategorier.
• Interne søgeresultater.
• Filtrerede sider.
• Midlertidigt deaktiverede sider.
• Sider med meget lidt eller intet reelt indhold.
• Serverfejl, der kun opstår for Googlebot eller på mobil.

Hvis en side midlertidigt er utilgængelig under vedligeholdelse, er 503 normalt mere præcis end 404 eller 200.

8. Langsom indlæsning og dårlige Core Web Vitals

Hastighed påvirker både brugeroplevelsen og hjemmesidens mulighed for at konkurrere organisk. En langsom side får ofte flere besøgende til at forlade hjemmesiden, før de når at læse indholdet eller gennemføre en handling.

Core Web Vitals fokuserer på tre centrale områder:

• Largest Contentful Paint (LCP): Hvor hurtigt sidens primære indhold bliver synligt.
• Interaction to Next Paint (INP): Hvor hurtigt siden reagerer på brugerens handlinger.
• Cumulative Layout Shift (CLS): Hvor stabilt layoutet er under indlæsningen.

En god oplevelse tilstræbes normalt ved en LCP på højst 2,5 sekunder, en INP på højst 200 millisekunder og en CLS-score på højst 0,1.

Typiske årsager til en langsom hjemmeside

Problemerne skyldes ofte en kombination af:

• For store billeder.
• Manglende moderne billedformater.
• For meget JavaScript.
• Tunge temaer og pagebuildere.
• For mange WordPress-plugins.
• Eksterne skrifttyper og scripts.
• Manglende caching.
• Langsom serverrespons.
• JavaScript, der blokerer sidens rendering.
• Elementer uden faste dimensioner.
• Dårlig indlæsning af billeder uden for skærmbilledet.

Sådan arbejder du systematisk med hastigheden

Start med PageSpeed Insights, men se ikke kun på den samlede score. Undersøg de konkrete målinger og forskellen mellem laboratoriedata og faktiske brugerdata.

Arbejd derefter med de største flaskehalse:

1. Reducér størrelsen på det største synlige element.
2. Optimér serverens svartid og caching.
3. Fjern eller udsæt unødvendigt JavaScript.
4. Angiv højde og bredde på billeder og indlejrede elementer.
5. Indlæs billeder uden for skærmen senere.
6. Begræns tredjepartsscripts.
7. Test ændringer på både mobil og computer.

Hastighedsoptimering bør altid testes grundigt. Aggressiv minificering eller forsinkelse af JavaScript kan ødelægge menuer, formularer, kurve og betalingsfunktioner.

9. Dårlig mobilvenlighed

Google behandler som udgangspunkt hjemmesidens mobilversion som den primære version. Derfor er det ikke tilstrækkeligt, at en side fungerer godt på en stor computerskærm.

Typiske mobilproblemer omfatter:

• Tekst, der er for lille.
• Knapper og links, der ligger for tæt.
• Indhold, der går ud over skærmens bredde.
• Popups, der dækker hovedindholdet.
• Menupunkter, der ikke kan åbnes.
• Tabeller, som ikke tilpasser sig skærmen.
• Billeder med forkerte dimensioner.
• Indhold, der kun findes på desktopversionen.
• Lang indlæsningstid på mobile forbindelser.

Sådan tester du mobilversionen

Test ikke kun hjemmesiden ved at gøre browservinduet smallere. Brug en rigtig telefon, og gennemfør de vigtigste handlinger:

• Åbn menuen.
• Navigér mellem kategorier.
• Udfyld kontaktformularen.
• Tilføj et produkt til kurven.
• Gennemfør starten af checkout.
• Åbn filtrering og søgning.
• Kontrollér cookie-banner og popups.

Sørg også for, at mobilversionen indeholder de samme vigtige tekster, links, billeder, metadata og strukturerede data som desktopversionen.

10. Manglende eller forkert intern linkstruktur

Interne links hjælper brugere med at finde relateret indhold og hjælper Google med at forstå hjemmesidens struktur.

En side uden interne links kaldes ofte en forældreløs side. Den kan godt stå i XML-sitemappet, men hvis ingen andre sider linker til den, fremstår den isoleret fra resten af hjemmesiden.

En svag intern struktur kan også opstå, når:

• Vigtige sider ligger mange klik fra forsiden.
• Menusystemet er den eneste kilde til interne links.
• Links bruger generiske tekster som “klik her”.
• Gamle URL’er stadig bruges internt.
• Der linkes til redirectede eller slettede sider.
• Mange irrelevante sider modtager flere links end vigtige landingssider.
• JavaScript-baseret navigation ikke skaber almindelige crawlbare links.

Sådan forbedrer du strukturen

Start med at identificere hjemmesidens vigtigste emner og landingssider. Byg derefter emneklynger med interne links, hvor en overordnet side linker til mere specialiserede undersider, og undersiderne linker tilbage til den overordnede side.

På SEO Succes kan en overordnet side om teknisk SEO eksempelvis linke til uddybende sider om:

• Indeksering og crawling.
• XML-sitemaps.
• Core Web Vitals.
• Hastighedsoptimering.
• Robots.txt.
• Canonical-tags.
• Redirects.

Ankerteksten bør beskrive den side, brugeren kommer til. Skriv eksempelvis “læs mere om teknisk SEO” i stedet for blot “læs mere”.

11. Dubletindhold og ukontrollerede URL-parametre

Dubletindhold opstår, når det samme eller næsten det samme indhold kan findes på flere URL’er.

Det er især almindeligt i forbindelse med SEO til webshops, hvor filtrering, sortering og sporingsparametre kan skabe mange URL-varianter:

/produkter/
/produkter/?orderby=price
/produkter/?farve=sort
/produkter/?utm_source=nyhedsbrev

Dubletter kan også opstå gennem:

• HTTP og HTTPS.
• www og versionen uden www.
• URL’er med og uden skråstreg.
• Printervenlige sider.
• Tag- og kategoriarkiver.
• Produktvarianter.
• Flere kategoristier til samme produkt.
• Gentaget indhold på forskellige lokationssider.

Google kan normalt genkende mange dubletter, men en ukontrolleret struktur kan sende uklare signaler og få Google til at bruge tid på mindre værdifulde URL’er.

Sådan løser du dubletproblemer

Løsningen afhænger af, hvorfor URL’erne eksisterer:

• Brug 301-redirect, hvis den alternative URL ikke længere skal bruges.
• Brug canonical, hvis URL’en skal eksistere, men en anden version skal prioriteres.
• Brug noindex, hvis siden må bruges af besøgende, men ikke skal vises i Google.
• Begræns unødvendige URL-kombinationer i filtreringssystemet.
• Link konsekvent til den kanoniske version.
• Medtag kun kanoniske URL’er i XML-sitemappet.

Undgå at bruge robots.txt som erstatning for canonical. Hvis Google ikke må gennemgå siden, kan søgemaskinen heller ikke læse dens canonical-tag.

12. Fejl i JavaScript og strukturerede data

Moderne hjemmesider bruger ofte JavaScript til at indlæse produkter, tekster, filtre, menuer og links. Google kan behandle JavaScript, men processen er mere kompleks end ved almindeligt HTML-indhold.

Der kan opstå problemer, hvis vigtigt indhold:

• Først vises efter en brugerhandling.
• Kræver login, cookies eller lokal lagring.
• Indlæses gennem en blokeret API.
• Forsvinder, når JavaScript fejler.
• Kun findes i browseren og ikke i den renderede version, Google ser.
• Er gemt bag knapper, som ikke opretter crawlbare links.

Sådan undersøger du JavaScript-indhold

Sammenlign:

1. Den oprindelige HTML-kilde.
2. Den renderede side i browserens udviklerværktøjer.
3. Den renderede version i Google Search Console.

Hvis vigtige tekster eller links mangler i Googles renderede version, bør indlæsningen ændres. Centrale SEO-elementer bør så vidt muligt være tilgængelige stabilt og uden at afhænge af en kompliceret brugerhandling.

Strukturerede data

Strukturerede data hjælper Google med at forstå bestemte typer indhold, eksempelvis produkter, virksomheder, brødkrummer og artikler.

Typiske fejl er:

• Manglende obligatoriske egenskaber.
• Pris eller lagerstatus, der ikke stemmer med siden.
• Markup for indhold, som brugeren ikke kan se.
• Flere plugins, der genererer modstridende schema-markup.
• Forkert virksomheds- eller produktinformation.
• Markup, der ikke passer til sidens faktiske indhold.

Test siderne med Googles Rich Results Test. Husk dog, at gyldige strukturerede data ikke garanterer et udvidet søgeresultat.

Sådan gennemfører du en teknisk SEO-analyse

En teknisk SEO-analyse bør udføres systematisk. Det er sjældent effektivt at rette enkelte fejl uden først at forstå deres omfang og årsag.

Trin 1: Crawl hele hjemmesiden

Brug et crawl-værktøj til at kortlægge:

• Statuskoder.
• Titler og metabeskrivelser.
• Canonical-tags.
• Robots-direktiver.
• Overskrifter.
• Interne links.
• Klikdybde.
• Billedstørrelser.
• Dubletter.
• Sider uden interne links.

Et crawl viser hjemmesiden fra en søgemaskines perspektiv og giver et samlet overblik over strukturen.

Trin 2: Sammenlign crawl med XML-sitemappet

Find URL’er, som:

• Er i sitemappet, men ikke kan crawles.
• Kan crawles, men mangler i sitemappet.
• Omdirigerer.
• Er markeret med noindex.
• Har canonical til en anden adresse.
• Returnerer en fejlkode.

Sitemappet og hjemmesidens øvrige signaler bør fortælle den samme historie.

Trin 3: Gennemgå Google Search Console

Undersøg især:

• Sideindeksering.
• Sitemaps.
• Core Web Vitals.
• HTTPS.
• Manuel handling.
• Sikkerhedsproblemer.
• Forbedringer og strukturerede data.

Klik videre ind i de enkelte fejltyper, og kontrollér konkrete URL-eksempler. En generel status er sjældent nok til at identificere årsagen.

Trin 4: Kontrollér de vigtigste sider manuelt

Gennemgå forsiden, centrale kategorier, servicesider, populære produkter og vigtige artikler.

Kontrollér for hver side:

• Statuskode.
• Indeksering.
• Robots-direktiv.
• Canonical.
• Mobilvisning.
• Hastighed.
• Interne links.
• Indhold i Googles renderede version.
• Placering i XML-sitemappet.

Trin 5: Prioritér efter konsekvens

Alle tekniske fejl er ikke lige alvorlige.

En fornuftig prioritering kan være:

1. Fejl, der blokerer hele hjemmesiden.
2. Fejl, der forhindrer vigtige sider i at blive indekseret.
3. Forkerte canonicals og redirects.
4. Serverfejl og ustabil drift.
5. Interne links og hjemmesidestruktur.
6. Hastighed og mobiloplevelse.
7. Metadata og strukturerede data.
8. Mindre optimeringer uden direkte konsekvens for crawling.

En enkelt forkert noindex på en vigtig landingsside er vigtigere end 50 manglende metabeskrivelser på mindre arkivsider.

Tekniske SEO-fejl efter en lancering eller migrering

Risikoen for tekniske fejl er særlig høj, når en hjemmeside flyttes til et nyt domæne, får nyt design eller skifter CMS.

Efter en lancering bør du blandt andet kontrollere:

• At testmiljøets noindex er fjernet.
• At robots.txt ikke blokerer hjemmesiden.
• At gamle URL’er har relevante 301-redirects.
• At der ikke findes redirect-kæder.
• At canonical-tags bruger det rigtige domæne.
• At interne links er opdateret.
• At XML-sitemappet indeholder de nye URL’er.
• At HTTPS fungerer korrekt.
• At billeder, CSS og JavaScript kan indlæses.
• At analyseværktøjer og Search Console stadig måler.
• At strukturerede data fortsat er korrekte.
• At vigtige sider returnerer statuskode 200.

Gem gerne en komplet crawl af den gamle hjemmeside før flytningen. Den kan bruges som sammenligningsgrundlag og som kilde til redirect-planen.

Hvor ofte bør teknisk SEO kontrolleres?

Teknisk SEO er ikke en engangsopgave. En hjemmeside ændrer sig løbende, når der installeres plugins, udgives indhold, fjernes produkter eller ændres i designet.

En mindre hjemmeside bør som minimum gennemgås efter større ændringer og med faste mellemrum. En større webshop bør overvåges oftere, fordi nye fejl hurtigt kan opstå gennem produkter, filtre, integrationer og automatiske URL’er.

Det er især relevant at gennemføre en teknisk kontrol:

• Efter lancering eller redesign.
• Efter flytning til et nyt domæne.
• Efter ændring af URL-strukturen.
• Efter installation eller opdatering af centrale plugins.
• Efter et pludseligt fald i organisk trafik.
• Når mange sider forsvinder fra Googles indeks.
• Når serveren har været ustabil.
• Når Search Console viser nye fejl.