Kort fortalt: Hvad er teknisk SEO?
Teknisk SEO er arbejdet med at gøre en hjemmeside tilgængelig, forståelig og stabil for søgemaskiner og brugere. Google skal kunne finde URL'en, hente den uden at blive blokeret, modtage en meningsfuld statuskode, se indeksérbart indhold og forstå, hvilken version af siden der er den vigtigste. Derefter kommer blandt andet performance, mobiloplevelse, strukturerede data og JavaScript-rendering.
Vil du lære det eller have det løst?
Denne side er en forklarende guide. Har du et konkret indeksproblem, en langsom side eller brug for en teknisk gennemgang, kan du se professionel hjælp til teknisk SEO.
Crawling, rendering og indeksering er tre forskellige trin
Mange tekniske problemer bliver lettere at forstå, når du først afgør, hvilket trin der fejler.
Crawling
Googlebot opdager en URL gennem links eller et sitemap og forsøger at hente den. Robots.txt, login, serverfejl eller manglende links kan stå i vejen.
Rendering
Google behandler HTML, CSS og JavaScript for at se sidens indhold og links. En JavaScript-side kan kræve ekstra rendering, før hele indholdet er synligt.
Indeksering
Google vurderer siden, dens indhold og dubletter og vælger, om URL'en skal gemmes i indekset. En crawlbar side er derfor ikke automatisk indekseret.
Googles tekniske minimum
For overhovedet at være egnet til indeksering skal Googlebot kunne få adgang, siden skal fungere med en succesfuld HTTP-status, og den skal have indeksérbart indhold. Det er minimumskrav – ikke en garanti for indeksering eller gode placeringer.
En teknisk fejl er kun vigtig i den sammenhæng, den rammer
Et værktøj kan vise 500 advarsler uden at fortælle, om de påvirker en vigtig salgsside eller et gammelt tagarkiv uden trafik. Begynd med konsekvensen.
| Niveau | Typiske eksempler | Spørgsmål | Handling |
|---|---|---|---|
| Kritisk | Vigtige sider er blokeret, noindex, returnerer fejl eller er blevet fjernet uden redirects. | Mister vi adgang, indeks eller eksisterende trafik? | Undersøg og begræns skaden først. |
| Betydelig | Canonical-konflikter, dybe sider, omfattende dubletter, rendering eller langsomme centrale sidetyper. | Hvor mange værdifulde URL'er og brugere rammes? | Planlæg løsning efter omfang og risiko. |
| Forbedring | Mindre sitemap-oprydning, schema-advarsler eller fejl på sider uden værdi. | Er gevinsten større end arbejdet? | Løs efter fundament og vigtige sider. |
Et bedre prioriteringsprincip
Alvor × antal berørte sider × forretningsværdi × sikkerhed i løsningen. En enkel fejl på en vigtig side kan være vigtigere end en omfattende, men ufarlig advarsel.
Undgå score-jagten
PageSpeed, crawl-værktøjer og SEO-plugins giver nyttige signaler, men en samlet score er ikke målet. Målet er, at vigtige sider fungerer, kan forstås og hjælper brugeren.
Sådan gennemfører du en teknisk SEO-audit
En crawl alene er ikke en audit. Du skal kombinere værktøjsdata med manuelle stikprøver, Search Console og kendskab til de vigtigste sidetyper.
Afgræns sitet
Notér platform, domænevarianter, sprog, subdomæner, miljøer og de sidetyper, der skaber værdi.
Indsaml data
Crawl websitet, kontrollér sitemap og robots.txt, og hent relevante rapporter fra Search Console.
Test stikprøver
Undersøg konkrete kategorier, artikler, produkter og fejl-URL'er i browser og URL-inspektion.
Prioritér og test
Lav en rækkefølge, implementér sikkert, og validér både den tekniske ændring og dens effekt bagefter.
Værktøjer, der supplerer hinanden
- Screaming Frog eller lignende crawler til URL-mønstre og tekniske signaler.
- Google Search Console til Googles egne indeks-, crawl- og performanceoplysninger.
- PageSpeed Insights og Chrome DevTools til performance og rendering.
- Rich Results Test til understøttet struktureret data.
- Browserens netværks- og kildekodevisning til status, HTML og ressourcer.
Data, du bør indhente før store ændringer
- Organiske landingssider med trafik og konverteringer.
- URL'er med eksterne links eller historisk synlighed.
- Aktuelle redirects, canonicals og indeksstatus.
- De vigtigste skabeloner og deres tekniske afhængigheder.
- Backup og mulighed for at rulle ændringer tilbage.
Crawling: Kan Google finde og hente de rigtige URL'er?
En side uden crawlbare interne links kan være svær at opdage, selv om den står i et sitemap. Omvendt kan filtre og parametre skabe et næsten uendeligt crawlområde.
Kontrollér først
- Vigtige links er almindelige HTML-links med en reel href.
- Robots.txt blokerer ikke sider eller ressourcer, Google skal bruge.
- Interne søgeresultater, sortering og sessions-URL'er skaber ikke crawl-fælder.
- Serveren svarer stabilt og uden lange serier af 5xx-fejl.
- Vigtige sider kan nås gennem navigation, brødkrummer eller kontekstuelle links.
User-agent: *
Disallow: /intern-soegning/<meta name="robots" content="noindex,follow">Vigtig forskel
En blokering i robots.txt er ikke det samme som noindex. Hvis Google ikke må crawle URL'en, kan søgemaskinen heller ikke nødvendigvis se et noindex-direktiv på siden.
Læs også: robots.txt, crawler og crawl budget.
Indeksering og canonical: Hvilken URL skal Google vælge?
Google kan crawle en side uden at indeksere den. Siden kan være en dublet, have svagt indhold, pege på en anden canonical eller mangle tilstrækkelige interne signaler.
Canonical
Angiver den foretrukne URL blandt ens eller meget lignende sider. Det er et stærkt signal, men ikke en ordre, og andre signaler bør pege samme vej.
Noindex
Fortæller søgemaskinen, at siden ikke skal være i søgeresultaterne. Siden skal kunne crawles, før direktivet kan behandles.
Sitemap
Hjælper med at opdage foretrukne URL'er. Medtag normalt kun kanoniske, indeksérbare URL'er, der returnerer 200.
Signaler, der bør være enige
- Canonical peger på den ønskede URL.
- Interne links bruger samme URL-version.
- Sitemappet indeholder den ønskede URL.
- Redirects samler gamle eller alternative versioner.
- Hreflang refererer til kanoniske sprogversioner.
Når Google vælger en anden canonical
Undersøg om indholdet reelt er for ens, om interne links peger på flere versioner, om URL'en findes i sitemappet, og om serveren returnerer det forventede svar. Ret årsagen frem for bare at gentage canonical-tagget.
Læs også: indeksering, canonical tag og XML-sitemap.
Statuskoder og redirects skal beskrive, hvad der faktisk skete
Statuskoden hjælper både browser og crawler med at forstå, om indholdet virker, er flyttet eller ikke findes.
| Kode | Betydning | Typisk brug | Faldgrube |
|---|---|---|---|
| 200 | Siden virker | Aktive sider med reelt indhold. | En fejlbesked med 200 kan blive en soft 404. |
| 301 | Permanent flyttet | Ny varig URL, domæne- eller strukturændring. | Redirect-kæder og redirects til irrelevante sider. |
| 302 | Midlertidigt flyttet | Kortvarig omdirigering, hvor original URL fortsat er den primære. | Bruges permanent uden en bevidst grund. |
| 404/410 | Findes ikke | Indhold er fjernet uden relevant erstatning. | Værdifulde URL'er fjernes uden at kontrollere trafik og links. |
| 5xx | Serverfejl | Midlertidig teknisk fejl. | Vedvarende fejl kan stoppe crawling og fjerne sider over tid. |
Læs også: redirect, 301 redirect og 302 redirect.
En god struktur gør de vigtigste sider tydelige
Google opdager og vurderer sider gennem links. Strukturen skal derfor afspejle forretningen og brugerens vej – ikke kun CMS-systemets standardmapper.
Interne links bør
- føre til kanoniske URL'er uden unødige redirects
- bruge forståelig ankertekst i stedet for gentagne “læs mere”
- forbinde guider med relevante ydelses-, kategori- eller produktsider
- gøre vigtige sider lette at nå gennem logiske klik
- forhindre værdifulde, forældreløse sider
XML-sitemap er støtte – ikke navigation
Et sitemap hjælper Google med at opdage URL'er, men erstatter ikke interne links. Hold sitemappet rent: indeksérbare 200-sider, korrekte canonicals og realistiske lastmod-datoer. Del store sitemaps efter sidetype, hvis det gør fejl lettere at overvåge.
Core Web Vitals måler virkelige oplevelser – ikke bare en score
Core Web Vitals består aktuelt af LCP, INP og CLS. De bedste vurderinger kommer fra feltdata på rigtige brugere. Laboratorietests er gode til fejlfinding, men kan ikke alene fortælle, hvordan alle besøgende oplever siden.
- Optimér det faktiske LCP-element frem for alle billeder ukritisk.
- Begræns lange JavaScript-opgaver og tunge tredjepartsscripts.
- Reservér plads til billeder, embeds, bannere og dynamiske elementer.
- Skeln mellem labdata og feltdata, og test de vigtigste skabeloner.
PageSpeed er ikke hele teknisk SEO
En score på 100 løser ikke noindex, dubletter eller døde links. En side med lavere laboratoriescore kan stadig rangere. Brug målingerne til at forbedre oplevelsen, ikke som eneste succesmål.
Strukturerede data skal beskrive det synlige indhold korrekt
Schema kan hjælpe søgemaskinen med at forstå oplysninger og gøre en side egnet til bestemte udvidede søgeresultater. Det skaber ikke automatisk en visning og erstatter ikke synligt indhold.
Organization og LocalBusiness
Virksomhedsoplysninger, identitet og lokale data, når typen og de krævede egenskaber passer til den synlige side.
Product og Offer
Produkt, pris, lager og varianter på sider, hvor oplysningerne er synlige og holdes opdaterede.
BreadcrumbList
Beskriver sidens placering i hierarkiet og bør stemme med den synlige brødkrummenavigation.
- Vælg schema efter sidetype og Googles aktuelle understøttelse.
- Markér ikke oplysninger, der er skjulte eller ikke findes på siden.
- Hold pris, lager, anmeldelser og virksomhedsdata synkroniseret.
- Valider syntaks og krav, men vurder også om indholdet er sandt og relevant.
Læs også: strukturerede data, schema markup og FAQ-schema.
JavaScript SEO: Kontrollér både den første HTML og det renderede resultat
Google kan køre JavaScript, men crawling, rendering og indeksering sker som separate processer. En løsning bliver mere robust, når vigtigt indhold, status og links ikke afhænger unødigt af klientkode.
Kontrollér
- Vigtigt indhold findes i den renderede HTML.
- Interne links er a-elementer med href.
- Unikke titles, beskrivelser og canonical er konsistente.
- Fejlsider returnerer meningsfulde statuskoder og bliver ikke soft 404.
- Blokerede JavaScript- eller CSS-filer forhindrer ikke rendering.
- Lazy-loaded indhold kan opdages uden en umulig brugerhandling.
SSR, statisk HTML og klientrendering
Server-side rendering eller statisk generering kan gøre indholdet tilgængeligt tidligere for både brugere og crawlers. Det betyder ikke, at alle JavaScript-sites skal bygges om, men det giver et stærkere udgangspunkt på sider, hvor organisk synlighed er vigtig.
Test den konkrete implementering med URL-inspektion, renderet HTML og browserens netværksværktøjer frem for at antage, at frameworkets navn afgør resultatet.
Særlige tekniske situationer kræver en særskilt plan
Nogle websites har risici, som ikke bør behandles som almindelig oprydning.
Migrering og redesign
Kortlæg gamle og nye URL'er, top-landingssider, redirects, interne links, canonicals, sitemaps og tracking før lancering. Crawl både før og efter, og overvåg Search Console tæt.
International SEO
Hreflang skal forbinde tilsvarende sprog- eller landeversioner gensidigt. Brug kanoniske URL'er, konsistente sprogkoder og en struktur, der kan vedligeholdes.
Webshops og facetter
Filtre, sortering, varianter, udsolgte produkter og pagination kan skabe store URL-mængder. Vælg bevidst, hvilke kombinationer der skal kunne crawles og indekseres. Se webshop SEO.
Store websites
Crawl budget og logfiler kan blive relevante på store eller hurtigt skiftende sites. På mindre sider er almindelig adgang, interne links og indeksérbart indhold normalt vigtigere.
Teknisk SEO-tjekliste i den rigtige rækkefølge
Brug tjeklisten som et beslutningsværktøj. Gå ikke videre til små forbedringer, hvis vigtige sider stadig er blokeret eller returnerer fejl.
Få de vigtigste tekniske problemer prioriteret
På den kommercielle side kan du se, hvad en teknisk gennemgang indeholder, hvad forskellige budgetter realistisk kan dække, og hvordan SmartClicks arbejder med analyse, implementering og din udvikler.
FAQ om teknisk SEO
Kan god teknisk SEO alene give en topplacering?
Nej. Teknikken kan fjerne barrierer og gøre siden lettere at crawle, indeksere og forstå, men placeringer afhænger også af relevans, indhold, konkurrence, links og brugerens søgning.
Hvorfor er min side crawlet, men ikke indekseret?
Mulige årsager er dubletter, svagt eller meget lignende indhold, canonical-signaler, lav intern prioritet eller at Google endnu ikke har valgt siden. Undersøg den konkrete URL i Search Console og sammenlign den med den canonical, Google har valgt.
Skal alle sider have en selvrefererende canonical?
Det er ofte en robust standard for kanoniske, indeksérbare sider, men canonical skal afspejle den reelle URL-strategi. På dubletter eller alternative versioner kan den rette destination være en anden URL.
Er robots.txt en sikker måde at fjerne sider fra Google?
Nej. Robots.txt styrer crawling og er ikke en sikker fjernelsesmetode. En blokeret URL kan i visse tilfælde stadig blive vist uden indhold. Brug noindex på crawlbare sider eller fjern siden med den korrekte status, afhængigt af målet.
Er sitemap nødvendigt på en lille hjemmeside?
Et sitemap er nyttigt, men ikke en erstatning for interne links. På et lille, godt forbundet website kan Google ofte finde siderne uden problemer. Sitemappet gør opdagelse og kontrol lettere og bør holdes rent.
Skal alle 404-fejl redirectes?
Nej. En 404 eller 410 er korrekt, når indholdet reelt er fjernet uden en relevant erstatning. Redirect kun til en side, der matcher brugerens oprindelige hensigt, og kontrollér trafik og links før værdifulde URL'er fjernes.
Er en PageSpeed-score på 100 nødvendig?
Nej. Fokusér på virkelige brugerdata, de konkrete Core Web Vitals og de elementer, der påvirker oplevelsen. En laboratoriescore er et diagnoseværktøj, ikke et selvstændigt forretningsmål.
Hvor ofte skal jeg lave en teknisk SEO-audit?
Efter risiko og ændringer, ikke efter en universel kalender. En audit er særlig relevant ved migrering, redesign, større platformændringer, trafikfald eller nye indeksproblemer. Et stabilt mindre site kan nøjes med målrettet kontrol.
Kan Google indeksere JavaScript-indhold?
Ja, Google kan rendere JavaScript, men processen har særlige begrænsninger. Vigtigt indhold, links, status og metadata bør testes i både den første HTML og den renderede version.
Hvornår bør jeg få professionel hjælp?
Når problemet rammer mange URL'er, opstod efter en migrering, kræver adgang til kode eller server, eller når flere tekniske signaler modsiger hinanden. Se hjælp til teknisk SEO for analyse, priser og implementering.
Begreber, der hænger sammen med teknisk SEO
Fagligt grundlag: Google Search technical requirements, Google crawling and indexing, Google JavaScript SEO og Web Vitals.