Teknisk SEO forklaret for dig der ikke er udvikler

Hvad dækker teknisk SEO egentlig over?

Teknisk SEO er alt det der skal være på plads, før Google overhovedet kan vurdere dit indhold. Fire opgaver: at siderne kan findes, at de kan hentes, at de kan forstås, og at de må indekseres. Går en af dem i stykker, er resten ligegyldigt.

Grænsen til on-page SEO er ikke knivskarp, men den er nem nok at tegne op. Teknisk SEO handler om maskinen der leverer siden. On-page handler om hvad der står på den. Titler, overskrifter, tekst og billeder er on-page. Serveren, koden, omdirigeringerne og de indstillinger der fortæller Google hvad der må vises, er teknik.

Jeg bruger opdelingen i fire opgaver fordi den gør det nemt at placere et problem. Når en side ikke dukker op i Google, er det altid en af de fire der svigter. Enten kender Google ikke siden, eller også kan den ikke hente den, eller den kan ikke læse indholdet, eller den har fået besked på at lade være med at indeksere.

• Findes. Der går links til siden, den står i sitemappet, og den er ikke begravet syv klik nede i strukturen.
• Hentes. Serveren svarer, siden loader, og der er ingen fejlkode eller timeout i vejen.
• Forstås. Indholdet ligger i HTML og ikke kun i JavaScript der skal køres først, og strukturen er til at læse.
• Indekseres. Ingen noindex, ingen canonical der peger væk, ingen blokering i robots.txt.

De fleste hjemmesider jeg kigger på, klarer tre ud af fire uden problemer. Det er typisk den sidste der driller, og den er næsten altid resultatet af en indstilling nogen satte for længe siden og glemte at tage af igen.

Hvornår er teknikken flaskehalsen og hvornår er det indholdet?

Min vurdering efter femten år med den slags: teknikken er flaskehalsen i omkring hver femte sag. Resten af tiden fungerer teknikken fint nok, og problemet er at siden ikke siger noget nogen søger efter.

Der er et par tydelige tegn på at det er teknik. Dine sider står slet ikke i Google, heller ikke når du søger på dit eget firmanavn plus et par ord fra teksten. Search Console viser flere sider under "Ikke indekseret" end under "Indekseret". Siden tager over otte sekunder at loade på mobil. Du har lige flyttet til et nyt system, og trafikken faldt med det samme uden at noget andet ændrede sig.

Og der er et par lige så tydelige tegn på at det ikke er teknik. Dine sider er indekseret, de har visninger i Search Console, men ingen klik. Du ligger på side to og tre på de søgeord du gerne vil have. Du har trafik, men ingen henvendelser. I de tilfælde kan du bruge tyve timer på at optimere hastighed og flytte dig nøjagtig ingenting, fordi problemet ligger i teksten eller i hvad siden tilbyder.

Den dyreste fejl jeg ser, er virksomheder der kaster penge efter en teknisk gennemgang, fordi det føles håndgribeligt. Man får en rapport med 40 punkter og en fornemmelse af at være i gang. Så løser man 40 ting der ikke var problemet, og undrer sig over at der ikke sker noget tre måneder senere.

Hvor lang tid tager en teknisk gennemgang på en lille hjemmeside?

På en side med under 100 undersider bruger jeg typisk fire til seks timer på selve gennemgangen. Det overrasker nogle, fordi tekniske lister kan se uendelige ud. Men en lille side har simpelthen ikke ret mange steder at gemme fejl.

Regnestykket ser cirka sådan ud. En halv time i Search Console med indekseringsrapporten og sitemappet. Tre kvarter på at crawle siden med et værktøj og kigge statuskoder, omdirigeringer og titler igennem. En halv time på hastighed i PageSpeed Insights på de tre til fem vigtigste sidetyper, ikke alle sider. En time på manuel gennemgang i browseren på mobil, hvor jeg klikker rundt som en kunde ville. En halv time på robots.txt, canonical og eventuelle duplikater. Og så halvanden time på at skrive det ned i en rækkefølge nogen kan arbejde efter.

Selve rettelserne er en anden sag og afhænger fuldstændig af hvad der dukker op. En forkert noindex er rettet på to minutter. En hjemmeside bygget i et system der leverer alt indhold via JavaScript er et projekt der løber over måneder.

Pointen med regnestykket er at du kan gøre det selv. Ikke hele vejen, men de første to tredjedele. Der er ingen hemmelig viden i de første fire timer, kun et par gratis værktøjer og en systematisk rækkefølge.

Hvordan finder og crawler Google dine sider?

Googlebot finder dine sider ved at følge links. Den henter en side, læser de links der står på den, og stiller dem i kø til næste besøg. Dertil kommer dit sitemap og links fra andre sites. Interne links er den kanal du selv styrer, og den vejer tungest på små sites.

Der findes ikke nogen hemmelig indmeldingsformular. Google opdager sider ved at kravle rundt på nettet og følge links, og dit XML-sitemap er et supplement, ikke en genvej. Et sitemap siger "her er en liste over mine sider". Det siger ikke noget om, hvorvidt siderne er værd at hente. Det afgør Google selv ud fra, hvor godt siderne hænger sammen med resten af nettet og med resten af dit site.

Derfor ser jeg jævnligt sider der har ligget i sitemappet i måneder uden at være hentet én gang. Den typiske forklaring er ikke et teknisk problem, men at ingen anden side på hjemmesiden linker til dem. En side uden indgående links er en side Google kun kender af navn. Det hører til i bunden af SEO-pyramiden, hvor teknik og crawling ligger som fundamentet, og det er også derfor det giver mening at ordne crawl-delen før man kaster sig over indhold og links.

Skal jeg bekymre mig om crawl budget?

Nej, ikke hvis du har under nogle tusinde sider. Crawl budget er Googles måde at rationere ressourcer på, så de ikke hamrer løs på en server der ikke kan følge med. Google har selv skrevet, at det først bliver relevant for sites med over en million unikke sider, eller sites med over 10.000 sider der ændrer sig dagligt. Det står i deres vejledning om crawl budget for store sites.

En almindelig dansk virksomhedsside med 40 undersider og en blog er altså langt fra grænsen. Når sådan en side alligevel ikke bliver crawlet ordentligt, handler det stort set aldrig om budget. Det handler om, at siderne er svære at nå frem til, eller at serveren svarer langsomt eller med fejl. Hvis Googlebot møder mange 5xx-fejl eller svartider i sekunder, skruer den ned af sig selv. Den opfører sig som en høflig gæst der kan mærke, at værten er presset.

Det ene sted hvor små sites alligevel spilder crawl, er webshops og filtersider. Hvis hver kombination af farve, størrelse og sortering giver sin egen URL, kan 300 produkter sagtens blive til 40.000 adresser. Så er det ikke budgettet der er for lille, det er antallet af adresser der er for stort. Her skal filtrene lukkes af, ikke serveren opgraderes.

Hvad betyder opdaget men ikke crawlet i Search Console?

Det betyder, at Google kender adressen, men endnu ikke har hentet indholdet. Statussen hedder "Opdaget, ikke indekseret i øjeblikket" og står i indekseringsrapporten i Google Search Console. Google har set linket et sted, lagt URL'en i kø og så ladet den ligge. Oftest fordi serveren virkede langsom, eller fordi siden ikke så ud til at være vigtig nok til at komme foran i køen.

Den forveksles tit med "Crawlet, ikke indekseret i øjeblikket", men de to ting kræver vidt forskellige handlinger. Den første er et crawl-problem og løses med bedre interne links og hurtigere svartider. Den anden er en vurdering af indholdet, og den tager jeg i næste afsnit.

Det bedste sted at se, hvordan Googlebot opfører sig hos dig, er crawl-statistikken i Search Console. Den ligger under Indstillinger og hedder Crawl-statistik. Tre tal er værd at se på. Antal crawl-anmodninger pr. dag fortæller, om Google overhovedet kommer forbi. Gennemsnitlig svartid fortæller, om serveren er kvik nok, og ligger den over et halvt sekund, er der noget at hente. Fordelingen af svarkoder fortæller, om Google bruger sine besøg på 200-svar eller spilder dem på omdirigeringer og fejl.

Et link fra en side Google besøger ofte, typisk forsiden eller en populær blogartikel, er mere værd end ti links fra sider der selv ligger gemt. Det er samme logik der gælder hele vejen igennem min guide til SEO. Interne links er både en vej for besøgende og en vej for robotten, og de to ting trækker heldigvis samme vej.

Få SEO-viden du kan bruge med det samme

Du får det jeg lærer af arbejdet med kunders synlighed: hvad der flyttede placeringer, hvad der ikke gjorde, og hvad Google har ændret undervejs. Skrevet så du kan handle på det.

Hvorfor bliver nogle sider crawlet men aldrig indekseret?

Crawling og indeksering er to forskellige ting. Googlebot kan sagtens hente din side ned og læse den igennem uden at gemme den i indekset bagefter. Siden bliver crawlet, vurderet, og så valgt fra. Det sker typisk fordi indholdet ligner noget der allerede findes, eller fordi siden ikke virker vigtig nok.

Det ærgrer mig hver gang en kunde har brugt tre uger på at skrive tekster, og de så ligger i kategorien "Crawlet, ikke indekseret endnu". Det er ikke en fejl i teknisk forstand. Google har set siden og sagt nej tak. Det er et kvalitetssignal forklædt som en statuskode.

Rapporten du skal bruge hedder Sideindeksering og ligger i Google Search Console. Den viser hvor mange sider der er indekseret, og hvor mange der ikke er, fordelt på årsager. Start altid dér, før du begynder at rette i koden.

Hvad betyder de enkelte statuser i indekseringsrapporten?

De fire du møder oftest er værd at kunne i søvne, fordi de kræver vidt forskellige handlinger.

Crawlet, ikke indekseret endnu betyder at Google har læst siden og fravalgt den. Årsagen er næsten altid tynd eller gentaget tekst. En produktside med to linjer beskrivelse, eller femten undersider der kun adskiller sig ved et bynavn. Her hjælper det ikke at trykke på Anmod om indeksering ti gange. Siden skal have mere på, eller den skal lægges sammen med en anden side.

Fundet men ikke crawlet betyder at Google kender adressen, men ikke har hentet den endnu. Det kan skyldes kø, men oftere er det fordi der næsten ikke peger interne links på siden. Jeg ser det typisk på sider der kun står i sitemappet og ikke i nogen menu. Løsningen er et link fra en side der allerede er indekseret.

Alternativ side med korrekt canonical er i langt de fleste tilfælde helt i orden. Du har to adresser med samme indhold, og Google har forstået hvilken der er originalen. Den skal du kun kigge på, hvis den side du gerne vil have frem, er den der bliver kaldt alternativ. Så peger dit canonical tag den forkerte vej.

Udelukket af tagget noindex betyder at du selv har bedt Google om at lade være. Det er rigtigt på kurv, kasse, login og takkesider. Det er en katastrofe hvis det står på forsiden, og det sker oftere end man skulle tro, typisk når en ny hjemmeside flyttes fra test til drift og nogen glemmer at slå fluebenet fra.

Hvad gør du konkret ved hver status?

En ting jeg vil advare imod. Vær tålmodig med tallene. Rapporten opdaterer ikke live, og jeg regner normalt med to til fire uger fra en rettelse til statussen skifter. Jeg har set folk rive deres sitemap i stykker, fordi de forventede resultat dagen efter.

Og hvis du sidder med flere hundrede sider i kategorien "Crawlet, ikke indekseret endnu", er det sjældent et teknisk problem. Så er det sortiment eller struktur, og det er en større samtale. Skal nogen kigge med udefra, har jeg skrevet om hvad du skal spørge om, inden du vælger en SEO-leverandør, så du ved hvilke svar der holder.

Robots.txt, sitemap og canonical tags uden teknisk fnidder

Robots.txt styrer hvad Googlebot må hente, sitemap.xml fortæller hvilke sider du gerne vil have fundet, og canonical tags peger på den rigtige version når samme indhold findes på flere adresser. Tre små filer og en linje kode. De tager fem minutter at tjekke og kan koste dig hele din synlighed hvis de står forkert.

De tre ting bliver tit blandet sammen, også af folk der bygger hjemmesider til daglig. Robots.txt handler om adgang. Noindex handler om visning. Canonical handler om hvilken adresse der er originalen. Når jeg gennemgår en side for en ny kunde, er det næsten altid her de billige point ligger, fordi ingen har kigget på filerne siden sitet blev sat op.

Hvad gør robots.txt, sitemap og canonical hver for sig?

Robots.txt bruges fornuftigt til at holde søgemaskiner væk fra søgeresultatsider, kurv, login og filtersider der kan generere uendeligt mange varianter. Den bruges forkert når nogen prøver at skjule en side med den. En side der er blokeret i robots.txt, men som der linkes til udefra, kan stadig dukke op i Google som en tom titel uden beskrivelse. Google har ikke lov til at hente den, så den kan ikke se at den burde holdes ude.

Sitemappet skal kun indeholde sider du vil have indekseret, i status 200, uden redirects og uden noindex. Et sitemap fyldt med gamle adresser er ikke farligt, men det er støj, og det gør det sværere for dig selv at se hvad der sker i Search Console. Efter sitemaps.org-standarden må en enkelt sitemap-fil højst indeholde 50.000 adresser og fylde 50 MB ukomprimeret. Har du flere, deler du dem op og samler dem i en sitemap-indeksfil. For en typisk virksomhedsside med 40 til 300 sider er det et problem du aldrig kommer i nærheden af, og det er værd at vide, så du ikke bruger tid på det.

Canonical er den af de tre der oftest står tomt eller forkert. Har du den samme produktside liggende både som /produkt/vare og /kategori/produkt/vare, vælger Google selv en vinder hvis du ikke peger. Og nogle gange vælger den den version du helst var fri for.

Hvorfor må noindex og disallow aldrig stå på samme side?

Fordi de to ting modarbejder hinanden. Noindex er en besked inde i sidens kode: du må gerne hente mig, men vis mig ikke i søgeresultaterne. Disallow i robots.txt siger: du må ikke hente mig. Når begge er sat, kan Googlebot ikke hente siden, og derfor læser den aldrig din noindex-besked. Resultatet er at siden bliver liggende i indekset, typisk med teksten om at der ikke findes nogen beskrivelse for siden.

Det er den klassiske fejl, og den opstår næsten altid med god vilje. Nogen vil have en tak-side eller et testmiljø væk fra Google, sætter noindex på, ser at den stadig ligger der, og blokerer den så også i robots.txt for en sikkerheds skyld. Det er sikkerhedsselen der forhindrer døren i at lukke.

Min vurdering efter at have ryddet op i mange af den slags er, at robots.txt bør være kort og kedelig. Jo flere linjer der står i den, jo større er chancen for at en af dem rammer noget, den ikke skulle. Jeg har set en enkelt disallow-linje tage en hel sprogversion ud af søgeresultaterne, uden at nogen opdagede det i måneder. Hvis du vil have hjælp til at læse din egen fil igennem, er det en af de ting jeg kigger på i en gennemgang af den tekniske del af dit SEO-arbejde.

Hvordan tjekker du de tre ting på fem minutter?

Falder tallene i punkt fem langt fra hinanden, fx 200 adresser i sitemappet mod 40 indekserede, er det ikke robots.txt der er problemet. Så er det kvaliteten af siderne, og det er en anden snak.

Vil du have mere SEO-viden i indbakken?

Du får det jeg lærer af arbejdet med kunders synlighed: hvad der flyttede placeringer, hvad der ikke gjorde, og hvad Google har ændret undervejs. Skrevet så du kan handle på det.

Hvor hurtig skal hjemmesiden være for at det tæller?

Google måler hastighed med Core Web Vitals, og grænserne er LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1 ifølge web.dev. Rammer du dem på mobil for de fleste af dine besøgende, er hastighed ikke dit problem. Så skal du bruge tiden på noget andet.

De tre tal lyder tekniske, men de måler noget ret hverdagsagtigt. LCP er hvor lang tid der går før det største element på skærmen er tegnet færdigt, typisk et billede eller en overskrift. INP er hvor længe siden er om at reagere når nogen trykker på noget. CLS er hvor meget indholdet hopper rundt mens siden loader, altså den klassiske hvor du rammer forkert knap fordi en reklame skubbede alting ned.

Det Google kigger på, er ikke dit testresultat i et værktøj. Det er data fra rigtige brugere i Chrome over de seneste 28 dage. Derfor kan du godt have 95 point i PageSpeed Insights og stadig fejle, hvis dine besøgende sidder på mobil med dårligt signal. Scroll ned til feltdata i stedet for at kigge på den store farvede cirkel i toppen.

Hvor meget betyder hastighed i forhold til alt det andet?

Mindre end de fleste tror. Hastighed er et svagt rangeringssignal, og det slår aldrig et bedre svar på søgningen. Min vurdering efter en del år med det her er, at hastighed sjældent er grunden til at en side ikke rangerer. Jeg har til gengæld set masser af sider der ikke rangerer fordi teksten er tynd, eller fordi siden slet ikke er indekseret.

Hastighed betyder til gengæld noget for det der sker efter klikket. Folk gider ikke vente, og på mobil med 4G er tålmodigheden kort. Så jeg behandler hastighed som en konverteringsopgave med en SEO-bonus, ikke omvendt. Det ændrer prioriteringen, for så er det forsiden og de sider der får trafik fra Google der skal måles, ikke hele sitet.

Hvis du driver en lokal virksomhed og konkurrerer med andre lokale på de samme søgninger, er forskellen mellem 2,4 og 2,6 sekunder ikke det der afgør noget. Der er som regel mere at hente i at få styr på indhold og lokale signaler, som jeg har skrevet om i guiden til SEO for virksomheder i Esbjerg.

Hvad er typisk skyld i dårlige tal på en dansk WordPress-side?

Billeder. Næsten altid billeder. En fotograf leverer filer på 4 til 6 MB, de bliver uploadet direkte i mediebiblioteket, og WordPress viser dem i fuld størrelse på forsiden. Et enkelt billede på 4 MB tager omkring 8 sekunder at hente på en almindelig mobilforbindelse. Samme billede komprimeret til WebP i 1600 px bredde fylder typisk 150 til 250 kB. Det er den største enkeltgevinst, og den kræver ingen udvikler.

Nummer to er plugins. Hvert plugin lægger sin egen CSS og JavaScript ind på alle sider, også dem hvor det ikke bruges. Et kontaktformular-plugin loader på produktsiderne, en slider loader på kontaktsiden. Jeg har set WordPress-installationer med over 40 aktive plugins hvor halvdelen var sat op af en tidligere leverandør og aldrig fjernet igen. Det er ikke farligt, det er bare langsomt og dyrt at vedligeholde.

Nummer tre er tredjepartsscripts. Cookiebanner, chatbot, Analytics, Meta-pixel, Hotjar, Trustpilot-widget og en bookingkalender. Hver af dem henter kode fra en anden server, og du har ingen kontrol over hvor hurtigt den server svarer. Scripts er også den hyppigste årsag til dårlig INP, fordi de blokerer browseren mens den burde reagere på et klik.

Hosting hører med i billedet, men længere nede end folk tror. Flytter du fra billig delt hosting til noget ordentligt, henter du måske et halvt sekund. Komprimerer du billederne, henter du tre. Hvis du er i gang med at vurdere hvad driften koster og hvad du får for pengene, har jeg samlet det i et overblik over hvad en hjemmeside koster at drive.

Sådan laver du et teknisk tjek på en time

Et teknisk tjek på en time består af fem trin i fast rækkefølge. Du starter i Search Console med indekseringsrapporten, kører tre sider gennem PageSpeed Insights, åbner robots.txt og sitemap manuelt i browseren, tester forsiden på din egen telefon og tjekker til sidst at www og uden www lander samme sted.

Hvad kigger du efter i Search Console på tyve minutter?

Gå ind i Google Search Console og åbn indekseringsrapporten. Den deler dine sider i indekserede og ikke-indekserede. Tallet for indekserede sider er det vigtigste tal på hele sitet, for det er loftet over hvor meget trafik du kan få. Har du 40 sider og 12 indekserede, er der 28 sider der ikke arbejder for dig.

Klik dig derefter ned i listen over årsager til at sider ikke er indekseret. Du leder efter to ting. Den første er sider der burde være med, men ikke er det. Den anden er sider der er med, men ikke burde være der, typisk gamle kampagnesider, testsider eller søgeresultater fra sitets egen søgefunktion.

Brug de sidste minutter på URL-inspektionen. Indsæt adressen på din tre vigtigste sider en ad gangen. Står der at siden er på Google, er den i hus. Står der noget andet, giver Search Console dig grunden i klartekst, og så ved du hvad der skal rettes.

Hvordan tester du hastighed, robots.txt og mobilvisning uden værktøjer?

Hastighed klarer du i PageSpeed Insights. Indsæt adressen, vælg mobilfanen og se på feltdataene øverst, altså målingerne fra rigtige besøgende. Scoren nedenunder er en laboratoriemåling og svinger fra gang til gang. Tre sider er nok, for problemerne går som regel igen på tværs af hele sitet.

Robots.txt og sitemap kræver ingen værktøjer overhovedet. Skriv adressen i browseren og læs. I robots.txt leder du efter linjen Disallow. Står der en skråstreg alene efter den, beder du Google om at holde sig væk fra hele sitet. I sitemap.xml tæller du antallet af adresser og sammenligner med antallet af indekserede sider fra trin et.

Mobiltesten laver du med din egen telefon. Slå wifi fra og åbn forsiden. Tæl sekunder til du kan læse noget. Prøv at trykke på menuen, udfyld første felt i kontaktformularen og se om tastaturet dækker knappen. De fejl finder du ikke i et værktøj, kun med en tommelfinger.

Til sidst domænetesten. Prøv både med og uden www og både http og https. Alle fire varianter skal ende på den samme adresse. Gør de ikke det, har Google fundet to udgaver af dit site og skal selv gætte hvilken der tæller.

Hvad kan et site nå når teknikken er på plads fra dag et?

Ventipartner er mit bedste eksempel. Fra december til april lå siden fladt på under 100 visninger om dagen i Google, og de fleste dage kom der næsten ingen klik. Virksomheden var ny på markedet og havde ingen historik. I maj 2026 lancerede jeg en ny hjemmeside bygget på programmatisk SEO med landingssiderne samlet i klynger omkring de forskellige former for ventilationsrens.

Kurven begyndte at stige kort efter lanceringen. I juni lå siden på 700 til 800 visninger om dagen, og i september er tallet over 1.000 med toppe omkring 1.300. Fire måneder fra lancering til tidoblet synlighed, og væksten er ikke flad endnu. Du kan se kurven og hele opsætningen i min case om Ventipartner.

Pointen er ikke at alle kan ramme den kurve. Pointen er at teknikken var på plads inden den første tekst blev skrevet, så alt indhold talte med fra dag et. Når du har kørt timens tjek igennem og rettet det der er galt, handler næste skridt om indhold og struktur, og det gennemgår jeg i min guide til SEO-optimering af hjemmesiden.

Skal vi kigge på din SEO sammen?

Med 15 års erfaring i søgemaskineoptimering hjælper jeg små og mellemstore virksomheder med at blive fundet. Du går fra samtalen med mindst tre konkrete ting du kan gøre selv.

Ofte stillede spørgsmål

Relaterede artikler