Hurtigt overblik: Hvad er en teknisk SEO-analyse, og hvad skal du gøre først?

En teknisk SEO-analyse er en systematisk gennemgang af dit websites tekniske setup for at finde, prioritere og dokumentere de fejl og muligheder, som påvirker crawl, indeksering, hastighed, struktur og dermed synlighed. I praksis betyder det, at du gennemgår sitet område for område, bruger dedikerede værktøjer, sætter impact x effort på hvert fund og omsætter resultaterne til konkrete udvikleropgaver.

Typisk består en teknisk SEO-analyse af fem trin:

1. Afklar mål og omfang (hvilket site, hvilke sprog, hvilke forretningskritiske sider).
2. Kør teknisk crawl og performance-tests.
3. Gennemgå tjeklisten: crawl/indeksering, statuskoder, hastighed/Core Web Vitals, struktur, indekseringssignaler, strukturdata mv.
4. Prioritér alle fund efter impact x effort og risiko.
5. Omdan fund til udviklertickets, implementer og valider i data.

Nedenfor folder vi hvert skridt ud, så du kan bruge analysen som et reelt beslutningsværktøj – ikke bare en fejl-liste.

Hvad er teknisk SEO?

Teknisk SEO er den del af søgemaskineoptimering, som sikrer, at søgemaskiner kan crawle, forstå og indeksere dit website korrekt, så godt indhold faktisk kan rangere. Det handler ikke om selve teksten, men om det tekniske fundament under indholdet.

Kernen i teknisk SEO er tre ting:

• Crawlability – kan søgemaskinernes robotter overhovedet finde og hente dine sider?
• Indexability – må og bør de sider, du har, rent faktisk komme med i indekset?
• Forståelse og performance – kan Google forstå sidens struktur og indhold, og loader den hurtigt og stabilt?

Det dækker blandt andet:

• Site-struktur og interne links.
• Brug af robots.txt og XML-sitemaps.
• Statuskoder (200, 301, 404, 500 osv.).
• Canonical-tags, noindex og hreflang.
• Core Web Vitals (hastighed, stabilitet og interaktivitet).
• Mobilvenlighed og rendering, især på JavaScript-tunge sites.
• Struktureret data (schema.org) og klar HTML-struktur.

En teknisk SEO-analyse er så den praktiske gennemgang af alle disse områder med henblik på at finde og rette problemer – ikke bare at forstå teorien.

Hvad er en teknisk SEO-analyse?

En teknisk SEO-analyse er en systematisk gennemgang af dit websites tekniske tilstand for at finde, prioritere og dokumentere de forhold, som påvirker crawl, indeksering, hastighed og struktur. Hvor teknisk SEO er disciplinen, er analysen den konkrete audit, du udfører for at få overblikket.

I en solid teknisk SEO-analyse gør du typisk følgende:

• Definerer mål: Er målet at løse konkrete problemer (fx fald i trafik) eller at sikre et nyt site før lancering?
• Indsamler data: Adgang til Google Search Console, hosting/server, CMS, eventuelle logfiler og SEO-værktøjer.
• Gennemfører en teknisk crawl af sitet og performance-tests.
• Går tjeklisten igennem: crawl, indeksering, statuskoder, redirects, hastighed/Core Web Vitals, mobilvenlighed, strukturdata, sitemaps, robots.txt osv.
• Kortlægger og grupperer fejl og muligheder i et fælles dokument (typisk regneark eller projektværktøj).
• Prioriterer hvert fund efter forretnings-impact, SEO-impact, risiko og implementerings-indsats.
• Omsætter fund til konkrete opgaver for udvikling/IT og følger op gennem validering.

En brugbar teknisk SEO-analyse bør som minimum levere for hvert fund:

• Beskrivelse af problemet (hvad sker der, og hvor).
• Påvirkning (crawl, indeksering, performance, UX, konvertering).
• Anbefalet løsning på et niveau, en udvikler kan arbejde videre med.
• Anbefalet ejer (hvem skal reelt løse det: udvikler, content, drift?).
• Valideringsmetode (hvordan kan vi se i data, at det er løst?).

På den måde bliver analysen ikke bare en rapport, men et arbejdsdokument, der kan bruges direkte i jeres backlog.

Teknisk SEO-tjekliste: de vigtigste områder

En god teknisk SEO-tjekliste starter med crawl og indeksering, går videre til hastighed og struktur og slutter med finjustering som strukturdata og internationale signaler. Pointen er at sikre, at Google både kan finde, forstå og belønne dine vigtigste sider.

1. Crawl og indeksering

• Crawlability: Kan Googlebot nå alle vigtige URL’er via interne links og sitemaps? Er der dybe sider, der kun nås via søgning eller filtre?
• Robots.txt: Blokerer du ved en fejl vigtige områder, fx hele /blog/ eller /produkt/?
• XML-sitemap: Er sitemap opdateret, fri for 4xx/5xx, og peger den kun på kanoniske, indekserbare URL’er?
• Indexability: Er der sider, der fejlagtigt har noindex, eller modsat burde være noindex (fx duplikerede filtrerede lister)?

2. Statuskoder og redirects

• Statuskoder: Er alle vigtige sider 200 OK? Har du mange 404-fejl eller 5xx-fejl, især på sider der har links eller trafik?
• Redirects: Bruges 301 til permanente ændringer, og er kæder og loops fjernet? Er HTTP til HTTPS-redirect sat korrekt op?
• HTTPS: Er hele sitet konsekvent på HTTPS uden blandet indhold (mixed content)?

3. Hastighed og Core Web Vitals

• Largest Contentful Paint (LCP): Hvor hurtigt loader den største synlige komponent på siden?
• Cumulative Layout Shift (CLS): Hopper layoutet rundt, mens siden loader?
• Interaction to Next Paint (INP): Hvor responsivt føles siden, når brugeren interagerer?
• Assets: Er billeder komprimeret, og bruges moderne formater som WebP? Er CSS/JS minificeret og kun indlæst, hvor det er nødvendigt?
• Server og caching: Har du rimelige svartider (TTFB), og er caching-konfiguration på plads for statiske ressourcer?

4. Mobilvenlighed og rendering

• Responsivt design: Er sitet fuldt funktionelt på mobil, også for forms, filtre og checkout?
• Mobile-first: Indhold og struktur på mobil skal matche desktop, da Google primært bruger mobilversionen til indeksering.
• JavaScript rendering: Kræver kritisk indhold (fx produkttekster, H1, interne links) JavaScript for at blive vist, og kan Google rent faktisk rendere det?

5. Struktur, duplicate content og kanoniske signaler

• Site-struktur: Har du en logisk hierarkisk struktur (forside → kategorier → undersider/produkter), eller er der rodede URL-mønstre?
• Canonical-tags: Er kanoniske URL’er sat korrekt, især på lister med filtre, sortering og paginering?
• Duplicate content: Er der mange næsten-identiske sider (fx samme produkt i flere kategorier) uden klare kanoniske signaler?
• Pagination: Er side 2, 3, 4 osv. til at crawle og indekse for Google, uden at stjæle værdi fra side 1?

6. Indekseringssignaler: sitemap, noindex, robots, hreflang

• noindex: Bruges bevidst på sider, du ikke ønsker i Google, fx interne søgesider eller staging-områder.
• Robots meta og X-Robots-Tag: Er der tekniske blokeringer via HTTP-headers, som spænder ben for crawl eller indeks?
• Hreflang: På internationale sites: matcher hreflang-sprog og -region faktiske sider, og peger de korrekt indbyrdes?

7. Struktureret data (schema markup)

• Schema.org: Bruger du relevante typer som Organization, Article, Product, FAQPage eller BreadcrumbList?
• Konsistens: Matcher struktureret data det faktiske indhold, så du undgår spam- eller mismatch-signaler?
• Rich results: Har du fokus på de typer, der giver mest forretning hos dig (fx Product med pris og lagerstatus for webshops)?

8. Loganalyse og crawl budget (især større sites)

• Serverlogs: Hvilke URL’er bruger Googlebot mest tid på at crawle, og stemmer det med din prioritet?
• Crawl waste: Spilder du crawl budget på filtre, interne søgesider, gamle parametre og auto-genererede sider?
• Blokering/optimering: Hvor kan du med fordel reducere crawl (robots.txt, noindex, interne links) og hvor skal du øge synlighed (bedre intern linking, sitemap)?

På større sites kan loganalyse være en af de mest værdifulde dele af analysen, fordi du ser, hvad Google reelt bruger sine besøg på – ikke kun hvad du håber, den ser. Det kobler naturligt til virksomhedens generelle brug af data og BI, hvor du kan hente inspiration i fx dataanalyse og BI.

Værktøjer og workflow til teknisk SEO-analyse

Google Search Console og PageSpeed Insights giver hurtig indsigt i indeksering og hastighed, mens værktøjer som Screaming Frog, Ahrefs og Semrush giver det fulde audit-billede via crawl, statuskoder og fejloversigter. Den bedste tilgang er at se værktøjerne som et workflow, ikke en liste.

Typiske værktøjer og hvad de bruges til

Et enkelt workflow, du kan følge

1. Start i Google Search Console
   Se efter store udsving i dækning, indekseringsfejl, manuelle handlinger, Core Web Vitals-rapporter og mobile usability-problemer.
2. Kør en fuld crawl med Screaming Frog eller et site audit-værktøj
   Identificer statuskoder, redirect-kæder, duplikerede titler/H1, manglende canonical, blokeringer, tynde sider osv.
3. Test nøglesider i PageSpeed Insights og Lighthouse
   Fokusér på de vigtigste landingssider, produktkategorier og skabeloner – ikke hver eneste underside.
4. Suppler med loganalyse på større sites
   Hvis I har adgang til serverlogs, brug dem til at se, hvor Googles crawl-ressourcer bliver brugt.
5. Samlefund i et struktureret dokument
   Brug et regneark eller jeres projektværktøj som fælles kilde, hvor hvert fund får ID, type, prioritet og ansvarlig.

På software-siden skal du regne med mindst ét betalt værktøj (typisk Screaming Frog-licens eller Ahrefs/Semrush) oven i de gratis Google-værktøjer. Niveauet starter realistisk omkring få hundrede kroner om måneden, afhængigt af licenstype og behov.

Sådan prioriterer du tekniske SEO-fejl (impact x effort)

Tekniske SEO-fejl bør prioriteres efter hvor meget de blokerer crawl, indeksering, performance og forretning – kombineret med hvor let de er at rette. En lille fejl med stor effekt bør komme før en stor opgave med marginal gevinst.

Impact x effort: simpel matrix til din backlog

Brug en enkel matrix, hvor du for hvert fund vurderer:

• Impact: Hvor stor er potentiel gevinst for trafik, synlighed eller konvertering?
• Effort: Hvor mange timer/ressourcer skal der til at løse det?
• Risiko: Hvor meget kan gå galt, hvis vi ændrer dette?

Praktiske prioriteringsregler

• Alt der stopper Google i at finde eller indeksere dine vigtigste sider, er altid kritisk – uanset om det er en linje i robots.txt eller en forkert noindex.
• Performance på skabelon-niveau slår detaljer på enkelt-sider. En optimeret produktskabelon vil ofte give mere end at optimere én landingsside perfekt.
• Fokuser først på issues med stor dækning – fejl, der rammer hundreder eller tusinder af URL’er, bør op før et par enkeltstående 404’ere.
• Tag hensyn til digital modenhed. Hvis I ikke har et modent udviklingsmiljø, kan det være fornuftigt at starte med de lavthængende frugter og arbejde jer op. Du kan hente inspiration til modenhedstænkning i artikler om digital modenhed.
• Hold forretningskritiske sider særskilt. Kategorisér fund efter om de rammer landingssider, kategori-/produktsider, checkout, login eller informationssider.

Brug gerne et simpelt score-system (fx impact 1-3, effort 1-3) og prioriter efter højest “impact / effort”-forhold. Det er bedre at være nogenlunde konsistent end at bruge tid på at opfinde en perfekt model.

Fra teknisk audit til handling: sådan skriver du gode udviklertickets

Selv den bedste tekniske SEO-analyse skaber kun værdi, hvis fundene bliver omsat til klare opgaver med ejer, deadline og acceptkriterier. Den praktiske forskel ligger i, hvordan du overleverer til udvikling og drift.

En enkel handover-skabelon (copy-paste klar)

For hvert teknisk fund bør du mindst udfylde følgende felter i jeres projektværktøj:

• Titel: Kort, præcis beskrivelse (fx “Fjern utilsigtet noindex på produktkategorier”).
• URL’er / scope: Eksempel-URL’er og gerne forklaring på, om det gælder én skabelon eller mange sider.
• Faktisk adfærd: Hvad sker der nu? (fx “Alle kategori-sider returnerer 200 med meta robots noindex,follow”).
• Forventet adfærd: Hvad bør der ske? (fx “Kategori-sider skal være index,follow og vises i sitemap”).
• Forslag til løsning: Teknisk anbefaling på højt niveau (fx “Ret template X, fjern noindex på Y-betingelse, opdater sitemap-generator”).
• Impact: Kort begrundelse for hvorfor dette er vigtigt (crawl, indeksering, omsætning).
• Prioritet: Kritisk nu / næste sprint / senere.
• Ansvarlig: Hvem skal gøre hvad (backend, frontend, SEO, drift, hosting)?
• Acceptkriterier: Konkrete tjek, som skal være opfyldt, før opgaven kan lukkes (fx “5 udvalgte kategori-URL’er viser nu index,follow og fremgår som ‘Valgt til indeksering’ i GSC efter re-crawl”).

Denne type skabelon gør det nemmere for udviklere at estimere, planlægge og implementere. Samtidig har marketing/SEO noget konkret at teste op imod senere. For større organisationer kan det give mening at koble dette til jeres generelle digitale governance og processer, som beskrevet i fx digital strategi og organisation.

Hvem bør eje hvad?

• Marketing/SEO: Ejer analysen, prioritering, business-case og test af resultatet.
• Udviklere/IT: Ejer implementering i kode, deploy og teknisk kvalitetssikring.
• Drift/hosting: Ejer serverkonfiguration, HTTPS, HTTP/2/3, caching, logadgang.
• Ledelse/produkt: Godkender større arkitekturændringer og sikrer ressourcer.

Hvis du samarbejder med eksterne leverandører på udvikling eller drift, kan du med fordel bruge principperne fra guides til leverandørvalg og IT-outsourcing, så teknisk SEO også bliver en del af jeres kravspecifikation og kontrakter.

Teknisk SEO i CMS’er og moderne websites

Teknisk SEO i moderne CMS’er handler ofte om rendering, plugin- og tema-konflikter, template-struktur, canonical-signaler og indekserbarhed. Mange fejl opstår ikke i Googles ende, men i den måde temaer, apps og moduler er sat op på.

WordPress

• Typiske faldgruber: For mange plugins, duplikerede URL’er via kategorier/tags, auto-genererede arkiver uden noindex, tunge page builders.
• Hvad du bør tjekke: SEO-plugin-indstillinger (title, meta, sitemap, noindex), canonical-tags, pagination og om performance påvirkes kraftigt af temaet.
• Løsninger: Slank plugin-setup, sæt noindex på irrelevante arkiver, optimer billeder og caching, brug et teknisk sundt tema.

Shopify

• Typiske faldgruber: Dobbelt-URL’er for produkter (med/uden /collections/), auto-genererede tag-sider, app-lag som indlæser tung JS.
• Hvad du bør tjekke: Canonical-strategi for produkter, om filtrerede kategorier indekseres uhensigtsmæssigt, og om temaet overholder basale performance-principper.
• Løsninger: Ryd op i auto-genererede sider, brug konsistente canonicals, minimér tunge tredjeparts-apps. Se evt. den mere platform-specifikke guide om Shopify SEO og teknisk struktur.

Magento og TYPO3

• Typiske faldgruber: Komplekse URL-strukturer, mange parametre, tunge kataloger, custom-moduler uden SEO-hensyn.
• Hvad du bør tjekke: Generel URL-strategi, canonical-tags på produkt- og kategoriniveau, sitemap-opsætning og caching/indekseringsopsætning.
• Løsninger: Arbejd med arkitektur på modul-/template-niveau, ryd op i parametre, og sørg for at SEO-krav kommer med i backloggen for videreudvikling.

JavaScript-frameworks (React, Vue, Angular mv.)

• Udfordring: Meget indhold genereres client-side, hvilket kan gøre det sværere for Google at se fuldt indhold, interne links og struktur.
• Løsninger: Overvej server-side rendering (SSR), pre-rendering eller hybrid-løsninger (fx Next.js, Nuxt, Angular Universal). Sikr at kritiske elementer som H1, brødtekst og interne links er synlige også uden JS.

Valget af CMS og arkitektur har direkte tekniske SEO-konsekvenser. Det bør tænkes ind allerede ved valg af forretningssystemer, hvor du kan hente inspiration i indhold om forretningssystemer og softwarevalg samt e-commerce-strategi og platformvalg.

Teknisk SEO og AI-søgning i 2026

Teknisk SEO handler i 2026 også om at gøre dit indhold let at forstå for AI-svarmaskiner gennem klar struktur, semantiske signaler og korrekt rendering. Det øger chancen for at blive brugt og citeret i AI Overviews og andre generative søgeresultater.

Machine readability: hvad AI rent faktisk har brug for

• Klar HTML-struktur: Brug logiske overskrifter (H1-H3), bullets og afsnit, så både mennesker og maskiner kan aflæse hovedpointerne.
• Struktureret data: Schema.org-markup hjælper AI med at forstå, hvad siden handler om (produkt, artikel, FAQ, organisation osv.).
• Svarblokke: Korte, præcise afsnit, der direkte besvarer typiske spørgsmål, gør det lettere for AI at citere dig korrekt.
• Rendering: AI-modeller er afhængige af, at indholdet faktisk kan hentes. Hvis dit vigtigste indhold kun lever i komplekse JS-lag, bliver du sværere at læse.

Det ændrer ikke grundprincipperne i teknisk SEO, men skærper kravene til struktur, stabil performance og ren markup. Overvej at koble teknisk SEO-arbejdet med virksomhedens bredere AI-strategi, som beskrevet i fx automatisering og AI i praksis og AI-transformation i virksomheder.

Hvordan validerer du, at rettelserne virker?

En teknisk rettelse er først reelt løst, når den kan ses i data – ikke kun i koden eller i et screenshot. Validering bør derfor være en fast del af dit workflow efter hver større ændring.

Konkrete målepunkter før og efter

• Google Search Console:
  • Dækning og indekseringsstatus for de berørte URL’er (fra fejl/udeladt til “Valgt til indeksering”).
  • Core Web Vitals-rapporter: bevægelse fra “Dårlig”/“Behov for forbedring” til “God” på de relevante URL-grupper.
  • Manuelle handlinger og sikkerhedsproblemer: bør være tomme.
• PageSpeed Insights/Lighthouse:
  • Forbedrede scores på LCP, CLS og INP for de optimerede skabeloner.
  • Løste konkrete anbefalinger (fx reduceret JS load, optimerede billeder).
• Crawl-værktøj (Screaming Frog/Ahrefs/Semrush):
  • Færre 4xx/5xx-fejl, færre redirect-kæder, korrekte canonical-tags og noindex-brug.
  • Konsistens i statuskoder og struktur efter redirect- eller URL-ændringer.
• Serverlogs (større sites):
  • Skift i, hvilke områder Googlebot crawle oftest, efter ændringer i robots.txt, sitemap eller interne links.
• Forretningsdata:
  • Udvikling i organisk trafik, synlighed på nøglesider og konverteringer efter tekniske rettelser (typisk med en forsinkelse på nogle uger).

Lav gerne en kort “før/efter”-sektion i dit audit-dokument for de vigtigste ændringer. Det gør det lettere at kommunikere effekt til ledelse og interessenter og at argumentere for fremtidige tekniske investeringer.

Når teknisk SEO bliver løbende drift – og ikke kun et projekt

For de fleste virksomheder bør en teknisk SEO-analyse ikke være en éngangsøvelse, men en tilbagevendende del af den digitale drift. Frekvensen afhænger af sitets størrelse og hvor ofte, I laver større ændringer.

• Mindre sites (lokale B2B, simple informationssites):
  • Fuld teknisk gennemgang ved større redesigns og derefter et tjek 1-2 gange om året.
• Mellemstore sites/webshops:
  • Kvartalsvis mini-audit (GSC, performance, statuskoder) og fuld gennemgang ved store releases.
• Store, dynamiske sites (e-commerce, SaaS, mediesites):
  • Løbende overvågning via automatiske site audits, faste tekniske SEO-punkter i release-processen og jævnlig loganalyse.

Prisniveauet for en teknisk SEO-analyse varierer væsentligt med domænestørrelse, kompleksitet og om der følger implementeringshjælp med. I praksis ser man alt fra simple gennemgange i den lave ende til løbende tekniske audits på månedligt retainer-niveau. Det vigtigste er, at du ser analysen som et investeringsspørgsmål: hvor meget organisk trafik og forretning er i spil, hvis fundamentet ikke er i orden?

Hvis du vil gøre teknisk SEO til en mere fast del af jeres digitale governance, kan du med fordel koble det til øvrige processer omkring IT-ledelse og drift samt generelle beslutningsguides og trin-for-trin implementering.

Konkrete næste skridt for din virksomhed

Hvis du vil i gang nu, kan du bruge denne kortliste som første iteration:

1. Log ind i Google Search Console og identificer de største dækning- og CWV-problemer.
2. Kør en basis-crawl af dit site (fx med Screaming Frog) og noter de vigtigste statuskode- og indekseringsfejl.
3. Udvælg 3-5 forretningskritiske skabeloner (forside, vigtig kategori, produkt, nøglelandingsside) og test dem i PageSpeed Insights.
4. Samlefund i et enkelt regneark med kolonner for problem, URL, impact, effort og forslag til løsning.
5. Prioritér efter impact x effort og opret rigtige tickets til udvikling ud fra handover-skabelonen ovenfor.
6. Aftal en fast rytme for opfølgning og validering af rettelser.

Når først processen er sat i system, bliver teknisk SEO mindre et “mystisk teknisk projekt” og mere en løbende disciplin på linje med andre tekniske driftsopgaver. Har du brug for mere inspiration til tjeklister og beslutningsværktøjer, kan du finde det i samlingen af værktøjer og guides til beslutningsstøtte.