Sådan hænger crawling, rendering og indeksering faktisk sammen
De fleste taler om "at blive indekseret" som ét samlet trin. I virkeligheden er det mindst fire adskilte processer, der sker efter hinanden, og en side kan gå i stå på hvert eneste af dem uden at give nogen fejlmelding, du kan se med det blotte øje.
Først skal URL'en opdages — via et link, et sitemap eller en tidligere crawl. Dernæst crawler Googlebot selve HTML-svaret fra serveren, forudsat at robots.txt tillader stien og serveren svarer med en 200-status. Herefter lægges siden i en renderingskø, hvor Google kører JavaScript for at se det færdige DOM, ligesom en browser ville — dette trin kan være forsinket flere dage på store eller langsomme sites, og det er præcis her, mange JavaScript-tunge sites taber indhold, fordi renderingen aldrig når det centrale indhold. Først derefter vurderes siden til indeksering, og til sidst afgøres det, om den rent faktisk vises for en given søgning.
Rendering er den del, flest overser. Hvis dit indhold indsættes af klient-side JavaScript uden serverside-rendering eller prerendering, ser Googlebot i første omgang kun det tomme skelet — det fulde indhold kommer først med i vurderingen, når renderingskøen har kørt scriptet. På sites med hyppige opdateringer (nyheder, tilbud, lagerstatus) kan den forsinkelse betyde, at indholdet er forældet, når det endelig bliver renderet.
Konsekvensen er, at du skal diagnosticere trin for trin i stedet for at antage, at "siden er her jo, men rangerer ikke" er ét problem. En side, der ikke vises i søgeresultaterne, kan fejle ved opdagelse, crawling, rendering, indeksering eller ren relevans — og løsningen er vidt forskellig alt efter hvilket trin, det er.
Google har fundet URL'en — via et link, et sitemap eller en tidligere crawl. Det er ikke det samme som at have besøgt den.
Typisk stopper siden her fordi
- Siden er forældreløs: ingen interne links peger på den, og den mangler i sitemap.
- URL'en ligger for dybt i sitestrukturen til at blive opdaget hurtigt.
Sådan diagnosticerer du det
- Search Console → Sideindeksering → "Opdaget – ikke indekseret pt."
- Tjek at URL'en findes i sitemap.xml og har mindst ét internt link.
Robots.txt vs. noindex vs. canonical: tre forskellige værktøjer
Det er den hyppigste forvekslingsfejl i teknisk SEO, og den koster ofte måneders arbejde, når den går galt. De tre mekanismer løser hvert sit problem, og de kan ikke erstatte hinanden.
Robots.txt forhindrer crawling. Den fortæller søgemaskinen, at den slet ikke må hente en given sti. Det er nyttigt til at spare crawl-budget på f.eks. interne søgeresultater eller admin-stier, men det forhindrer ikke indeksering i sig selv — en URL, der er disallowed i robots.txt, kan stadig dukke op i søgeresultaterne uden beskrivelse, hvis andre sider linker til den, fordi Google aldrig fik lov at læse et noindex-tag på siden.
Noindex forhindrer indeksering. Det er et meta-tag eller en HTTP-header, som Google skal kunne crawle siden for at se — hvis du både disallow'er en sti i robots.txt og sætter noindex på samme side, ser Google aldrig noindex-tagget, og resultatet er ofte det modsatte af det tilsigtede.
Canonical konsoliderer dubletter. Den fortæller, hvilken URL der er den foretrukne, når flere URL'er viser identisk eller næsten identisk indhold — typisk på grund af parametre, filtrering eller sortering. Canonical er et hint, ikke en kommando: Google kan vælge en anden canonical, hvis den finder beviser for, at en anden URL er den rigtige, og det er præcis det, du skal holde øje med i Search Console.
| Situation | Rigtigt værktøj | Hvorfor |
|---|---|---|
| Interne søgeresultatsider skal ikke bruge crawl-budget | robots.txt disallow | De skal slet ikke hentes |
| En testside eller takkeside skal ikke i indekset | noindex | Siden må gerne crawles, bare ikke vises |
| Samme produkt tilgås via ?farve=blå og ?farve=roed | canonical til hovedversionen | Konsoliderer signaler til én URL |
| Samme indhold findes på flere sprog/regioner | hreflang (ikke canonical) | De er ikke dubletter, men lokale varianter |
| En side er flyttet permanent | 301-redirect | Overfører signaler og undgår dubletindhold |
# robots.txt — bloker crawling af interne søgeresultater og filterparametre
User-agent: *
Disallow: /soeg
Disallow: /*?sort=
Disallow: /*?farve=
Allow: /
Sitemap: https://www.eksempel.dk/sitemap.xml
<!-- Canonical i <head> på en filtreret variant -->
<link rel="canonical" href="https://www.eksempel.dk/produkt/vinterjakke" />
<!-- Hreflang-blok for samme side på tre sprog/markeder -->
<link rel="alternate" hreflang="da-dk" href="https://www.eksempel.dk/produkt/vinterjakke" />
<link rel="alternate" hreflang="sv-se" href="https://www.eksempel.se/produkt/vinterjacka" />
<link rel="alternate" hreflang="en" href="https://www.eksempel.com/product/winter-jacket" />
<link rel="alternate" hreflang="x-default" href="https://www.eksempel.com/product/winter-jacket" />Den klassiske faldgrube
Bloker aldrig en URL i robots.txt, hvis du samtidig har sat noindex på den. Google skal kunne crawle siden for overhovedet at se og adlyde noindex-tagget.
Sådan læser du Search Console-rapporten Sideindeksering
Rapporten Sideindeksering i Search Console er det første sted, du bør kigge, når trafikken falder, eller når du vil verificere, at et relanceret site er sundt. Den viser antal indekserede sider over tid og grupperer alle ikke-indekserede URL'er efter årsag.
De statuskoder, der oftest kræver handling, er: "Crawlet – i øjeblikket ikke indekseret" (Google har set siden, men vurderet den ikke værd at indeksere, typisk pga. tyndt eller duplikeret indhold), "Opdaget – i øjeblikket ikke crawlet" (Google kender URL'en, men har ikke prioriteret at hente den endnu, ofte et crawl-budget- eller lavprioritetssignal), "Side med omdirigering" (URL'en videresender og indekseres derfor ikke selv, hvilket er forventet adfærd), "Duplikat, Google har valgt en anden canonical end brugeren" (dit canonical-signal er blevet overtrumfet af andre signaler), og "Blokeret af robots.txt" (bevidst eller ved en fejl).
Den vigtigste vane er at sammenligne antallet af sider i din sitemap med antallet af "Indekserede sider" i rapporten. Er forskellen stor og voksende, er det næsten altid enten et indeksforstyrrende teknisk problem eller en større mængde tyndt indhold, der bør konsolideres eller fjernes fra sitemappet.
Brug URL-inspektionsværktøjet til enkeltsider: det viser Googles "valgte canonical", sidste crawl-dato, om siden er indekseret, og en "Se testet side"-funktion, der viser det renderede HTML. Det er det hurtigste værktøj til at bekræfte, om en specifik side fejler i crawling, rendering eller indeksering.
- Crawlet – i øjeblikket ikke indekseret: typisk tyndt eller duplikeret indhold — forbedr eller konsolider siden.
- Opdaget – i øjeblikket ikke crawlet: ofte et prioriteringssignal — styrk interne links til siden.
- Duplikat, Google har valgt en anden canonical: dine egne signaler (interne links, sitemap) modsiger dit canonical-tag.
- Blokeret af robots.txt: tjek om det er bevidst — mange relanceringer arver en for bred disallow-regel fra staging.
- Soft 404: siden svarer 200, men indholdet ligner en fejlside — ret enten indholdet eller statuskoden.
Sitemaps der reelt hjælper
Et XML-sitemap er en liste over de URL'er, du gerne vil have crawlet og indekseret — det er en anbefaling, ikke en garanti. Værdien af et sitemap falder markant, hvis det er fyldt med støj: URL'er der omdirigerer, giver 404, er sat til noindex, eller er blokeret i robots.txt.
Et sundt sitemap indeholder kun kanoniske, indekserbare 200-URL'er, opdateres automatisk når indhold tilføjes eller fjernes, og er opdelt i mindre filer via et sitemap-indeks, hvis sitet har mere end nogle tusinde URL'er. Inkludér lastmod-datoen korrekt — sæt den kun, når indholdet reelt er ændret, ellers mister signalet sin værdi over tid.
På store sites er det værd at opdele sitemaps efter sidetype (produkter, kategorier, blog) og indsende hver type separat i Search Console. Det gør det muligt at se indekseringsraten pr. sidetype i stedet for ét samlet tal, hvilket ofte afslører at ét bestemt segment (f.eks. udsolgte produkter) trækker gennemsnittet ned.
URL-struktur, parametre, facetterede filtre og crawl-budget
Crawl-budget — hvor meget Googlebot vælger at crawle på dit site inden for en given periode — er reelt kun en bekymring for store sites med hundredtusindvis af URL'er. Men facetteret navigation kan skabe et crawl-budget-problem på selv mellemstore sites, fordi kombinationer af filtre (farve, størrelse, pris, sortering) kan generere tusindvis af URL-varianter af de samme få hundrede produkter.
Hver facetteret kombination, Googlebot crawler, er en crawl-anmodning, der ikke går til en side, du faktisk vil have indekseret. Løsningen er en kombination: brug canonical fra filtrerede varianter til hovedkategorisiden, bloker de mest støjende parameterkombinationer i robots.txt, og undgå at linke internt til facetterede URL'er, medmindre kombinationen har selvstændig søgeværdi (f.eks. en populær "løbesko herre str. 43"-kombination kan fortjene sin egen indekserbare side, mens en tilfældig sortering ikke gør).
URL-strukturen selv bør være læsbar, konsistent og kort: brug bindestreger mellem ord, undgå sessions-ID'er og unødvendige parametre i indekserbare URL'er, og hold hierarkiet forudsigeligt (/kategori/underkategori/produkt) så både brugere og søgemaskiner kan gætte sig til strukturen. En URL-ændring uden ordentlig 301-redirect er en af de dyreste tekniske SEO-fejl, der findes, fordi den nulstiller alle akkumulerede signaler på den gamle URL.
Tommelfingerregel for facetter
Spørg for hver filterkombination: "Ville nogen reelt søge efter præcis dette?" Hvis ja, gør den indekserbar med eget canonical og relevant metadata. Hvis nej, canonical til kategorisiden og undlad at linke til den internt.
Dubletindhold og de mest almindelige canonical-fejl
Dubletindhold er sjældent et "straf"-problem — det er et konsolideringsproblem. Når flere URL'er viser samme eller næsten samme indhold, splitter det rangeringssignaler (links, klik, relevans) mellem URL'erne i stedet for at samle dem på én, hvilket typisk resulterer i, at ingen af URL'erne rangerer så godt som én samlet version ville.
De hyppigste kilder til utilsigtet dubletindhold er: www vs. ikke-www eller http vs. https uden korrekt redirect, samme indhold tilgængeligt med og uden trailing slash, produktvarianter (farve/størrelse) på separate URL'er uden canonical mellem dem, og udskriftsvenlige eller AMP-versioner uden korrekt kobling til hovedversionen.
De hyppigste canonical-fejl er: en canonical, der peger på en URL, som selv omdirigerer videre (canonical-kæder), en canonical der peger på en 404-side, canonical på tværs af sider med reelt forskelligt indhold (f.eks. hele kategorisider canonical til forsiden), og manglende selv-referentiel canonical på sider, der ikke har nogen dubletproblematik — hver side bør som udgangspunkt pege på sig selv.
Statuskoder og redirect-kæder
Statuskoder er det sprog, servere og søgemaskiner taler sammen på, og fejl her skaber usikkerhed om, hvilken URL der reelt skal indekseres. En 200 betyder "her er indholdet", en 301 betyder "flyttet permanent, brug den nye URL fremover", en 302 betyder "flyttet midlertidigt, bliv ved den gamle URL", en 404 betyder "findes ikke", og en 410 betyder "fjernet med vilje" — hvilket signalerer tydeligere end en 404, at indholdet ikke kommer tilbage.
Redirect-kæder (URL A → URL B → URL C) opstår typisk efter flere års omstruktureringer, hvor ingen har ryddet op i de mellemliggende led. Hver ekstra hop i kæden koster crawl-effektivitet og kan i værste fald få Google til at give op undervejs. Ret altid en kæde til ét direkte hop fra den oprindelige URL til den endelige destination.
302 bruges alt for ofte, hvor 301 er den rigtige kode — typisk fordi det er standardindstillingen i mange CMS'er. Konsekvensen er, at rangeringssignaler ikke overføres helt til den nye URL, fordi 302 signalerer, at den gamle URL stadig er den "rigtige" på sigt.
| Kode | Betydning | Brug når |
|---|---|---|
| 200 | OK | Siden findes og skal vises/indekseres |
| 301 | Flyttet permanent | URL'en er ændret for altid — overfør signaler hertil |
| 302 | Flyttet midlertidigt | Kortvarig omdirigering, f.eks. under en kampagne |
| 404 | Ikke fundet | Siden findes ikke og forventes ikke at komme tilbage snart |
| 410 | Fjernet | Indholdet er bevidst og permanent fjernet |
| 5xx | Serverfejl | Bør aldrig ses af Googlebot i normal drift — undersøg straks |
Hypertekst-hygiejne: interne links, forældreløse sider og sidedybde
Intern linkbuilding er stadig den mest oversete gevinst i teknisk SEO. Den koster ingenting, kræver ingen ekstern godkendelse og kan udføres på en eftermiddag på de fleste sites — alligevel er det ofte det sidste, der bliver prioriteret.
En forældreløs side er en side uden interne links fra resten af sitet — den kan kun findes via sitemap eller direkte URL. Sådanne sider crawles sjældnere, opdages senere efter ændringer, og signalerer lav vigtighed til søgemaskinen, fordi intern linkstruktur er et af de klareste signaler om, hvilke sider der betyder mest på et site.
Sidedybde — hvor mange klik der skal til fra forsiden for at nå en given side — bør holdes lav for alt vigtigt indhold, typisk maksimalt tre til fire klik. Dybtliggende sider crawles sjældnere og modtager mindre linkværdi gennem sitet, uanset hvor godt indholdet på dem er.
En praktisk øvelse er at eksportere alle indekserbare URL'er og krydstjekke, hvor mange interne links hver enkelt har — værktøjer som Search Console (Links-rapporten) eller en almindelig crawler kan levere dette. Sider med nul eller ét internt link bør enten kobles ind i relevant navigation og relaterede artikler, eller vurderes om de overhovedet skal bestå.
- Hver vigtig side skal kunne nås fra relevante sider med beskrivende ankertekst — undgå "klik her".
- Ét overskriftshierarki pr. side: én H1, derefter H2/H3 der faktisk beskriver indholdet.
- Naviger nye artikler/produkter ind i eksisterende relaterede sider med det samme, ikke som en efterfølgende oprydningsopgave.
- Brødkrummer (breadcrumbs) styrker både brugerorientering og det interne linksignal på dybtliggende sider.
Core Web Vitals i 2026: LCP, INP og CLS med de faktiske tærskler
Core Web Vitals måles på feltdata — reelle brugeres oplevelse via Chrome User Experience Report — og vurderes på den 75. percentil, hvilket betyder at mindst tre ud af fire besøg skal ligge inden for "god"-tærsklen, før hele siden vurderes god. Et enkelt pænt testresultat i et labværktøj beviser derfor intet om den reelle brugeroplevelse på 4G-mobil.
Largest Contentful Paint (LCP) måler, hvor lang tid der går, før det største synlige element er renderet. Tærsklen for "god" er 2,5 sekunder eller derunder; op til 4 sekunder er "skal forbedres"; derover er "dårlig". De mest effektive tiltag er at prioritere det største element (typisk et hero-billede eller en stor overskrift) med fetchpriority="high", undgå lazy loading netop på det element, servere billeder i korrekt størrelse og moderne format, og reducere serverresponstid.
Interaction to Next Paint (INP) afløste First Input Delay som den officielle responsivitetsmetrik og måler forsinkelsen fra en brugerinteraktion til den næste visuelle opdatering, hele siden igennem — ikke kun ved første klik. Tærsklen for "god" er 200 millisekunder eller derunder; op til 500 ms er "skal forbedres"; derover er "dårlig". Løsningen er typisk at dele lange JavaScript-opgaver op, udskyde tredjepartsscripts til efter første interaktion, og undgå tunge synkrone DOM-opdateringer ved klik.
Cumulative Layout Shift (CLS) måler uventede layoutforskydninger under sidens levetid. Tærsklen for "god" er 0,1 eller derunder; op til 0,25 er "skal forbedres"; derover er "dårlig". Løsningen er at reservere plads til billeder, videoer, annoncer og embeds med width/height eller aspect-ratio, og undgå at indsætte indhold over eksisterende indhold uden brugerinteraktion.
LCP — Largest Contentful Paint
Tærskler (75. percentil af rigtige brugere): god ≤ 2.5 s, skal forbedres op til 4.0 s, derover dårlig.
Mest effektive tiltag for LCP
- Prioritér det største element i viewport med fetchpriority="high" og undgå lazy loading på det.
- Server billeder i moderne formater (AVIF/WebP) i korrekt størrelse via srcset.
- Reducér serverresponstid og brug en CDN foran statiske aktiver.
- Fjern render-blokerende CSS/JS over folden og inlinér kun det kritiske.
Lab vs. felt
Lighthouse og PageSpeed Insights' lab-score er nyttige til fejlfinding, men den officielle vurdering — og det, der optræder i Search Console — er feltdata fra rigtige brugere over 28 dage.
Billed- og fontoptimering
Billeder er ofte den enkeltstørste faktor i LCP og samlet sidevægt. Server billeder i moderne formater (AVIF eller WebP) med en srcset, der giver browseren mulighed for at vælge den mindste tilstrækkelige størrelse til den aktuelle skærm, og undgå at skalere et stort originalbillede ned med CSS alene.
Lazy loading bør bruges på alt indhold under folden, men aldrig på det element, der udgør LCP — at lazy loade det vigtigste billede forsinker netop den metrik, det skal måles på. Sæt altid width og height (eller aspect-ratio) på billed-tags for at undgå layoutforskydning, mens billedet indlæses.
Fonte kan forårsage både forsinket tekst-visning og layoutforskydning. Brug font-display: swap eller optional, preload de kritiske web-fonte i <head>, og vælg en fallback-systemfont med lignende bredde og højde for at minimere det synlige hop, når web-fonten er klar.
Mobil, responsivitet og hreflang ved flere sprog
Google indekserer med mobile-first indexing, hvilket betyder, at det er mobilversionen af siden, der lægges til grund for crawling og rangering — ikke desktopversionen. Sørg for, at alt indhold, alle strukturerede data og alle interne links, der findes på desktop, også findes på mobilversionen; en ofte overset fejl er at skjule sekundært indhold helt på mobil af pladshensyn, hvilket reelt fjerner det fra grundlaget for rangering.
På mobil bør klikbare elementer have tilstrækkelig størrelse og luft omkring sig til at undgå fejlklik, tekst skal være læsbar uden at zoome, og viewport-metataggen skal være korrekt sat, så siden ikke renderes i en fast desktopbredde.
Har sitet flere sprog eller regionale varianter, bruges hreflang til at fortælle søgemaskinen, hvilken version der passer til hvilket sprog/marked — det er ikke et duplikat-problem, og canonical må ikke bruges til at pege alle sprogversioner mod én. Hreflang-relationer skal være gensidige: peger den danske side på den svenske, skal den svenske også pege tilbage på den danske, ellers ignoreres signalet. Inkludér altid en x-default for besøgende, der ikke matcher nogen af de definerede sprog/regioner.
Strukturerede data: hvilke typer der giver værdi, og hvordan man validerer
Strukturerede data (Schema.org-markup, typisk i JSON-LD) hjælper søgemaskinen med at forstå indholdet med sikkerhed i stedet for at gætte ud fra teksten alene, og kan udløse rige resultater i søgeresultaterne. De typer, der oftest giver reel værdi, er Product (pris, lagerstatus, anmeldelser) på webshops, Article eller BlogPosting på indholdssider, LocalBusiness på lokationssider, BreadcrumbList på alle sider med hierarki, FAQPage hvor indholdet reelt er spørgsmål/svar, og Organization på forsiden.
Den vigtigste regel er, at markeringen skal afspejle indhold, der reelt er synligt på siden — at markere priser, anmeldelser eller lagerstatus, der ikke fremgår af selve siden, er et brud på retningslinjerne og kan koste retten til rige resultater for hele domænet.
Validér altid strukturerede data efter implementering med Googles Rich Results Test og Schema Markup Validator, og hold øje med Search Console-rapporten for det pågældende markup-type (f.eks. "Produkter" eller "FAQ") for løbende fejl og advarsler efter lancering af nye sidetyper.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Teknisk SEO-checkliste 2026",
"datePublished": "2026-07-30",
"author": { "@type": "Person", "name": "Loui Wagner Gellin" }
}Sikkerhed, HTTPS og HSTS
HTTPS er en forudsætning, ikke en fordel — ren HTTP behandles som usikkert af moderne browsere, og et website uden gyldigt certifikat mister brugertillid før det overhovedet mister rangering. Tjek at alle interne links, billeder og scripts loades over HTTPS; blandet indhold (HTTP-ressourcer på en HTTPS-side) udløser advarsler i browseren og kan blokere dele af siden fra at loade.
HTTP Strict Transport Security (HSTS) er en HTTP-header, der fortæller browseren, at den altid skal bruge HTTPS til domænet fremover, selv hvis en bruger manuelt skriver http:// — det fjerner et helt angrebsvindue og bør slås til på ethvert site, der udelukkende kører på HTTPS.
Sørg desuden for, at http-versionen af sitet 301-omdirigerer permanent til https-versionen, at certifikatet fornys automatisk, og at der ikke findes gamle, forældede TLS-versioner tilbage på serveren, som kan give advarsler i sikkerhedsscannere og enkelte browsere.
Log-analyse på et grundniveau
Serverlogs viser, hvad Googlebot rent faktisk gjorde — i modsætning til Search Console, der viser et forsinket og delvist aggregeret billede. En grundlæggende log-analyse filtrerer webserverens adgangslog til kun Googlebot-besøg (identificeret ved user-agent og verificeret ved omvendt DNS-opslag) og ser på tre ting: hvilke URL'er crawles oftest, hvilke statuskoder Googlebot rent faktisk møder, og hvor meget af crawl-aktiviteten der går til sider, der aldrig burde crawles i første omgang.
Et typisk fund er, at en stor andel af crawl-aktiviteten går til facetterede filter-URL'er, gamle kampagnesider eller interne søgeresultater, mens de vigtigste kategori- og produktsider crawles sjældnere end ønsket. Det er direkte handlingsbart: bloker eller canonical de støjende stier, og styrk interne links til de vigtige sider for at skifte prioriteringen.
Log-analyse behøver ikke avanceret værktøj for at give værdi — selv en enkel filtrering i regneark eller et gratis kommandolinjeværktøj på et par ugers logdata afslører som regel de største crawl-spild med det samme.
Sådan prioriterer du fund efter effekt vs. indsats
Et teknisk SEO-tjek genererer typisk mellem tyve og hundrede fund på et site af almindelig størrelse, og det er fristende at gå i gang med det, der er nemmest at forklare. Den rigtige tilgang er at vurdere hvert fund på to akser: forventet effekt (hvor mange sider/hvor meget trafik/hvor centralt er problemet) og indsats (udviklertimer, afhængigheder, risiko).
Fund med høj effekt og lav indsats — som en fejlagtig noindex på en central side eller en canonical-fejl på produktsider — skal altid løses først, ofte samme dag som de opdages. Fund med høj effekt men høj indsats, som en fuld migrering til server-side rendering, bør planlægges som et projekt med tydelig business case. Fund med lav effekt og lav indsats (quick wins som manglende alt-tekster eller doble H1'er) samles og udføres i bundter, mens fund med lav effekt og høj indsats som udgangspunkt nedprioriteres, medmindre de er forudsætning for noget andet.
Undgå at lade organisatorisk lethed (hvad er nemmest at få godkendt) erstatte den faktiske prioritering. Et interaktivt board, hvor fund grupperes efter kvadrant og kan markeres som håndteret, gør det lettere at holde overblikket, når listen vokser efter et par kvartaler.
0 af 15 fund markeret som håndteret i denne visning.
Gør først
Quick wins
Overvej senere
Den fulde tekniske SEO-tjekliste
Brug listen herunder som et fast punkt ved relanceringer, kvartalsvise gennemgange og når trafikken uventet ændrer sig. Den er sorteret efter samme rækkefølge som artiklen: se, om Google overhovedet kan finde og forstå siden, før du bruger tid på finpudsning.
- 1Robots.txt og noindexBekræft at ingen vigtige sider er utilsigtet disallowed eller sat til noindex, og at ingen side har begge dele samtidig.
- 2SitemapKun kanoniske 200-URL'er, opdelt efter sidetype hvis sitet er stort, og indsendt i Search Console.
- 3CanonicalsSelv-referentiel som udgangspunkt, korrekt sat på filtrerede/parametriserede varianter, ingen canonical-kæder.
- 4Search Console – SideindekseringGennemgå hver statuskode, og sammenlign antal indekserede sider med antal sider i sitemap.
- 5Statuskoder og redirectsIngen redirect-kæder, korrekt brug af 301 vs. 302, ingen 5xx set af Googlebot i logs.
- 6Interne linksIngen forældreløse sider, maksimalt 3-4 klik til vigtigt indhold, beskrivende ankertekst.
- 7Core Web VitalsLCP, INP og CLS inden for 'god' på feltdata for de vigtigste sidetyper, ikke kun forsiden.
- 8Billeder og fonteModerne formater, srcset, ingen lazy loading på LCP-elementet, reserveret plads til alt indhold.
- 9MobilSamme indhold og strukturerede data som desktop, korrekt viewport, tilstrækkelig klikstørrelse.
- 10HreflangGensidige relationer mellem alle sprogvarianter, korrekt x-default, ingen konflikt med canonical.
- 11Strukturerede dataKun markup der afspejler synligt indhold, valideret med Rich Results Test.
- 12HTTPS og HSTSIngen blandet indhold, http omdirigerer permanent til https, HSTS aktiveret.
- 13Log-analyseStikprøve af Googlebot-aktivitet for at se crawl-spild og statuskodefordeling.
Prioriteret 30-dages plan
Planen herunder forudsætter adgang til Search Console, analytics og udviklerressourcer i mindre bidder gennem hele perioden. Rækkefølgen følger effekt-vs-indsats-princippet: det, der kan koste dig mest, hvis det er galt, kommer først.
| Uge | Fokus | Konkrete opgaver |
|---|---|---|
| Uge 1 | Indeksering og sikkerhed | Gennemgå robots.txt, noindex-tags, canonicals og HTTPS/HSTS. Ret alt med høj effekt og lav indsats med det samme. |
| Uge 1-2 | Search Console-oprydning | Gennemgå Sideindeksering-rapporten statuskode for statuskode, ryd sitemap for støj. |
| Uge 2 | Struktur og interne links | Find forældreløse sider og dybtliggende vigtige sider, tilføj interne links og brødkrummer. |
| Uge 2-3 | Redirects | Find og fjern redirect-kæder, ret forkert brug af 302 hvor 301 burde bruges. |
| Uge 3 | Core Web Vitals | Mål LCP/INP/CLS på de vigtigste sidetyper, implementér de tiltag der matcher den svageste metrik. |
| Uge 3-4 | Billeder, fonte og mobil | Konvertér til moderne billedformater, tjek font-loading, verificér mobilparitet med desktop. |
| Uge 4 | Strukturerede data og log-analyse | Valider/udbyg strukturerede data, kør en stikprøve af serverlogs for crawl-spild. |
Rækkefølgen betyder noget
Ret indeksering og sikkerhed, før du bruger tid på strukturerede data. Det første afgør, om du overhovedet er med i løbet; det sidste er finpudsning oven på et fundament, der virker.
Hvordan du holder det ved lige
Teknisk SEO er ikke et projekt, men en driftsopgave. Nye sider, nye plugins, nye kampagnesider og nye udviklere skaber løbende afvigelser, og de opdages sjældent, før trafikken falder — fordi ingen af de nævnte fejltyper giver en synlig fejlmelding for en almindelig besøgende.
Sæt en fast månedlig kontrol: indekseringsstatus i Search Console, nye fejl i Sideindeksering-rapporten, Core Web Vitals på de vigtigste sidetyper, og en gennemgang af interne links til nyt indhold. En halv time om måneden er ofte nok til at holde et normalt site sundt, hvis den halve time bruges konsekvent hver måned frem for som en stor oprydning en gang om året.
Ved større ændringer — relansering, ny platform, ny URL-struktur — kør hele tjeklisten igen før lancering, ikke bare efter. De fleste alvorlige indekseringsfejl kan fanges med en times manuel gennemgang af staging-miljøet, hvis nogen husker at fjerne det, der forhindrede søgemaskiner i at se udviklingsversionen.
