Fejlene der spærrer,
før indholdet når frem.
Teknisk SEO handler ikke om at samle point i et værktøj. Det handler om at fjerne det der står mellem din side og Googles indeks — og de spærringer ser sjældent ud af noget udefra.
Ingen tilmelding · intet kreditkort · svar på 30 sek.
Hvad teknisk SEO dækker
Teknisk SEO er alt det der skal fungere, før indhold og links overhovedet kommer i spil: at Googlebot kan hente dine sider, at den kan forstå hvilken version der er den rigtige, at den kan se indholdet efter rendering, og at siden loader hurtigt nok til at brugeren bliver.
Disciplinen bliver ofte forvekslet med performance alene. Hastighed er en del af den, men kun en del. Et site kan score 100 i PageSpeed Insights og stadig have halvdelen af sine kategorisider ude af indekset, fordi et canonical tag peger forkert. Omvendt kan et langsomt site ligge nummer et i årevis, hvis det er det eneste sted svaret findes.
Den praktiske afgrænsning er nem: teknisk SEO er de problemer der gør, at godt indhold ikke bliver vist. Alt andet er indhold, autoritet eller intention.
De otte fejl der går igen
Listen herunder er ikke teoretisk. Det er de fund der dukker op igen og igen, når agenten crawler et dansk site for første gang — uanset om det kører WordPress, Shopify eller noget hjemmebygget.
- 01
Redirect-kæder på tre led eller mere
En gammel URL peger på en nyere, som peger på en tredje. Googlebot følger op til ti hop, så kæden knækker sjældent — men hvert led koster ventetid for brugeren, og linkværdien fra den oprindelige URL bliver behandlet gennem en kæde ingen har set efter i tre år. Ret dem ved at pege det første led direkte på slutmålet.
- 02
Canonical der peger et andet sted hen end du tror
Et canonical tag er et signal, ikke en ordre. Google kan vælge en anden URL som den kanoniske, hvis resten af sitet siger noget andet: interne links, sitemap og hreflang peger et sted hen, mens taget peger et andet. Modstriden er den hyppigste årsag til at den forkerte side står i indekset.
- 03
Noindex der overlevede en lancering
Staging-miljøet havde noindex på hver side. Så gik sitet live, og to skabeloner tog mærket med sig. Det er den dyreste fejl på listen, fordi den ikke ser ud af noget: siderne loader fint, de er bare væk fra indekset inden for et par uger.
- 04
Blokeret i robots.txt og forventet slettet
robots.txt styrer crawl, ikke indeksering. En URL der er blokeret der, kan stadig stå i resultaterne — uden beskrivelse, fordi Google ikke må hente indholdet. Skal siden ud af indekset, skal den kunne crawles og bære et noindex.
- 05
Filtre og parametre der crawles som selvstændige sider
Facetteret navigation i en webshop kan producere titusinder af URL-varianter af de samme tyve produkter. De fortynder indekset og æder crawl-kapacitet der skulle være brugt på kategorierne. Løsningen er sjældent robots.txt alene — den er en kombination af canonical, interne links der ikke peger ind i filtrene, og et sitemap der kun indeholder de URL'er du reelt vil have vist.
- 06
Interne links til sider der svarer 404
Døde interne links er både et brugerproblem og et signal om at sitet ikke bliver vedligeholdt. De opstår typisk efter en migrering, hvor redirects blev sat op for de gamle URL'er, men de interne links aldrig blev opdateret til de nye.
- 07
Indhold der kun findes efter JavaScript er kørt
Google renderer JavaScript, men rendering ligger i kø og sker ikke altid ved første crawl. Er dine produktbeskrivelser, brødtekster eller interne links først til stede efter et klientkald, risikerer du at blive vurderet på en tom skabelon. Test med den renderede HTML, ikke med kildekoden.
- 08
TTFB der stiger langsomt over måneder
Serverens svartid vokser sjældent på én dag. Den kravler opad, mens der bliver installeret endnu et plugin og endnu et script, indtil Largest Contentful Paint pludselig ligger over fire sekunder på mobil. Uden en måling hver uge opdager du det først, når trafikken er faldet.
Crawl-budget er sjældent dit problem
Crawl-budget er blevet et af de begreber der bliver brugt til at sælge arbejde, ingen har brug for. Google beskriver selv, at det først er relevant for store sites med over en million URL'er der ændrer sig ugentligt — eller mellemstore sites med over ti tusind URL'er der ændrer sig dagligt.
Har du 400 sider, bruger Google ikke sit budget op på dig. Så er spørgsmålet et andet: hvorfor bliver de sider du gerne vil have crawlet, ikke besøgt? Svaret ligger næsten altid i strukturen. De ligger seks klik nede, de linkes kun fra et paginerings-element, eller de er begravet under et filter der producerer tusind varianter af det samme.
Undtagelsen er webshops med facetteret navigation. Her kan et site på tres kategorier producere hundredtusindvis af crawlbare URL'er, og så er budgettet pludselig en reel begrænsning. Det er også dér, den forkerte løsning gør mest skade: blokerer du filtrene i robots.txt, kan Google ikke længere se de canonicals der skulle have samlet signalerne.
Sådan arbejder agenten
Agenten crawler sitet på et fast interval og gemmer resultatet. Værdien ligger ikke i det enkelte crawl, men i sammenligningen: hvad er ændret siden sidst? Et nyt noindex, en ny redirect-kæde, en statuskode der er skiftet fra 200 til 301, en titel der er forsvundet fra 340 produktsider på én nat.
Fundene bliver holdt op mod data fra Search Console, så et fund på en side med visninger vejer tungere end det samme fund på en side ingen finder. Rækkefølgen i rapporten er derfor ikke alfabetisk eller efter alvorlighed i abstrakt forstand — den er efter, hvad der koster dig mest lige nu.
På de moduler hvor det giver mening, kan agenten rette selv: manglende meta descriptions, tomme title tags og forkerte canonicals kan skrives direkte tilbage via CMS'ets API. Alt andet ender som en konkret instruks, ikke som en advarsel.
Hvad du retter først
Rækkefølgen betyder mere end antallet. Ret indekseringsspærringer før hastighed, og hastighed før kosmetik. En side der er sat til noindex ved en fejl, koster dig hundrede procent af sin trafik. En side med et LCP på 3,1 sekunder koster dig en andel af den.
- Alt der forhindrer indeksering: noindex, robots-blokeringer, forkerte canonicals, 5xx-fejl.
- Alt der spilder signaler: redirect-kæder, døde interne links, dubletsider uden kanonisering.
- Alt der bremser brugeren: serversvartid, ukomprimerede billeder, blokerende scripts.
- Alt der forbedrer forståelsen: schema, overskriftsstruktur, interne ankertekster.
- Resten — hvis der er tid.
Efter hver rettelse skal du måle igen. Ikke fordi rettelsen kan have fejlet, men fordi den kan have flyttet problemet et andet sted hen. En ny redirect løser sjældent noget uden at skabe et nyt led i en kæde et andet sted.
Det der løser opgaven
Guiden herover beskriver arbejdet. Modulerne herunder udfører det — hver for sig, så du kun betaler for det du mangler.
Teknisk Audit
Ugentligt crawl med statuskoder, døde links, redirect-kæder, canonicals og schema — prioriteret efter effekt.
Se moduletRedirect Chain Cleaner
Finder kæder og løkker og skriver den rettede redirect-tabel du kan lægge direkte ind.
Se moduletSitemap Hygiejne
Holder sitemappet fri for URL'er der er blokerede, viderestillede eller døde.
Se moduletCrawl Depth Optimizer
Kortlægger hvor dybt dine vigtige sider ligger, og hvilke interne links der trækker dem op.
Se moduletSe hele kataloget på moduler, eller læs videre om Core Web Vitals og AI SEO.
Det bliver spurgt om oftest
Hvor tit skal teknisk SEO tjekkes?
Et fuldt crawl om ugen er nok for de fleste sites. Ændrer du skabeloner, migrerer domæne eller udgiver mange sider dagligt, skal frekvensen op — det er ved udrulninger fejlene opstår, ikke i de stille uger.
Kan teknisk SEO alene få mig i top 3?
Nej. Teknisk SEO fjerner spærringer, så indholdet og linkene kan gøre arbejdet. Er der ingen spærringer, giver flere tekniske rettelser meget lidt. Det er derfor rapporten prioriterer efter effekt frem for efter antal fund.
Hvad er forskellen på et crawl og en indeksering?
Crawl er når Googlebot henter siden. Indeksering er når Google beslutter at gemme den og vise den i resultaterne. En side kan blive crawlet uden nogensinde at blive indekseret, typisk fordi den ligner en anden side for meget eller ikke tilfører noget.
Skal jeg rette alle fund i rapporten?
Nej. Rapporten er sorteret efter effekt, og halen består ofte af fund uden praktisk betydning. Tag de øverste fem, verificér effekten i næste crawl, og gå så videre.
Kilder
- Google Search Central — Managing crawl budget for large sites
Googles egen beskrivelse af hvornår crawl-budget er en reel problemstilling, og hvad der påvirker crawl-hastigheden.
developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget - Google Search Central — Block search indexing with noindex
Forklarer hvorfor en side skal kunne crawles for at et noindex kan virke.
developers.google.com/search/docs/crawling-indexing/block-indexing - Google Search Central — Consolidate duplicate URLs
Kanonisering forklaret af Google, inklusive hvorfor rel=canonical er et signal og ikke en instruks.
developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls - Google Search Central — Redirects and Google Search
Hvordan Googlebot håndterer viderestillinger, og hvor mange hop den følger.
developers.google.com/search/docs/crawling-indexing/301-redirects
Se hvilke af de otte fejl der ligger på dit site.
Agenten crawler og afleverer en rapport med fundene prioriteret efter effekt. Det tager 30 sekunder.