Så kører bussen!

Teknisk SEO er den del af søgemaskineoptimering, som sjældent føles “kreativ”, men som afgør, om dit indhold overhovedet får en fair chance. Du kan have stærke landingssider, gode produkttekster og flotte billeder, men hvis Google ikke kan finde, hente eller fortolke siderne stabilt, bliver synligheden ujævn.

Det gode ved teknisk SEO er, at mange forbedringer giver effekt på tværs af hele sitet. Én rettelse kan løfte hundrede sider, fordi den handler om struktur, performance og signaler til søgemaskinerne.

Hvad teknisk SEO egentlig dækker

Teknisk SEO handler om alt det, der gør et website crawlable (kan hentes), indexable (kan gemmes og vises) og forståeligt (kan tolkes korrekt). Det er en blanding af server, kode, informationsarkitektur og klare regler for, hvilke URL’er der er “de rigtige”.

Det overlapper tit med udvikling og UX. Det kan mærkes på bundlinjen, fordi en hurtigere, mere stabil og mere konsistent side typisk får bedre engagement, færre fejl og lettere ved at blive crawlet hyppigt.

Typiske områder, der ender i en teknisk SEO-audit, er:

• Crawling og crawl-fejl

• Indeksering, noindex og canonical

• Hastighed og Core Web Vitals

• Mobilvenlighed og rendering

• HTTPS, redirects og sikkerhed

• Intern linking, sitemaps og arkitektur

• Strukturerede data (schema)

Crawling: kan Google overhovedet hente dine sider?

Crawling er den fase, hvor Googlebot forsøger at hente dine URL’er. Hvis du har problemer her, er resten næsten ligegyldigt.

De mest almindelige stopklodser er overraskende banale: en forkert , interne links der peger på gamle URL’er, eller en server der giver 5xx-fejl under spidsbelastning. Selv en lang kæde af redirects kan gøre, at crawl bliver langsommere og mere upræcist.

Et praktisk tegn på crawl-problemer er, når nye sider tager længe om at dukke op i Google, eller når vigtige sider pludselig forsvinder fra indekset efter en release.

Indeksering: hvad bliver gemt og vist?

At en side kan crawles betyder ikke, at den bliver indekseret. Indeksering er Googles valg om at gemme siden og gøre den mulig at vise i søgeresultater.

Her spiller dine signaler en stor rolle: , canonical-tags, interne links og kvalitetssignaler. En side kan også blive “opdaget, men ikke indekseret” eller “crawlet, men ikke indekseret”, hvis Google vurderer, at den er tynd, duplikeret eller uden tydelig plads i sitets struktur.

Mange sites får et skjult indeksproblem, når URL’er formerer sig: filtre i e-handel, trackingparametre, printvisninger, paginering, tags og interne søgninger.

Arkitektur og intern linking: vejene på dit website

Intern linking er både navigation for brugere og en ruteplan for crawlers. Når arkitekturen er enkel, kan Google finde det vigtigste hurtigt, og dine stærke sider kan sende værdi videre til undersider.

En tommelfingerregel: vigtige sider skal kunne nås via almindelige links i HTML, uden at de kræver specifikke brugerhandlinger eller er gemt bag formularer. Sider uden interne links, såkaldte orphan pages, bliver ofte crawlet sjældent eller ikke stabilt.

En god struktur er sjældent kompliceret. Den er bare konsekvent: kategorier hænger sammen med underkategorier, og relateret indhold linker naturligt på tværs.

Hastighed og Core Web Vitals: performance som synlighedsfaktor

Hastighed er ikke kun et spørgsmål om “score”. Det er tid til første respons, tid til at indhold kan bruges, og hvor meget layoutet hopper rundt, mens siden loader.

Core Web Vitals gør performance konkret, og de samme forbedringer gavner både SEO og konvertering: mindre JavaScript, bedre caching, optimerede billeder og en server, der svarer hurtigt.

Når performance-problemer skal prioriteres, kan det hjælpe at tænke i to lag:

• Hvad rammer alle sider (tema, scripts, font-loading)?

• Hvad rammer enkelte sidetyper (produktsider med mange billeder, blogindlæg med tunge embeds)?

Mobil først, men ikke mobil kun

Google crawler typisk ud fra mobilversionen. Det betyder, at den mobile oplevelse ikke må være en “skåret ned” udgave, hvor vigtigt indhold, interne links eller strukturerede data mangler.

Fejl ses ofte i praksis, når mobil-menuen bygger links via scripts, eller når elementer flyttes i DOM’en på en måde, der gør det sværere for bots at forstå hierarkiet. Responsivt design er ofte det enkleste at holde konsistent, men det kræver stadig test på rigtige enheder.

En enkelt side kan se flot ud på en iPhone, men stadig have tekniske mobilproblemer: for små klikmål, sticky-elementer der dækker indhold, eller inputfelter der skubber layoutet.

Sikkerhed, HTTPS og redirects

HTTPS er blevet standard. Den tekniske del handler mest om at gøre skiftet helt rent: alle interne links på HTTPS, ingen mixed content, og én tydelig version af sitet.

Her dukker et klassisk problem op: både , , og non- kan være tilgængelige. Det kan splitte signaler og skabe dubletter.

Et simpelt redirect-setup med 301-redirects til én foretrukken version er ofte nok. Det skal bare være konsekvent i hele stakken: server, CMS, canonical-tags og sitemap.

Duplikatindhold, canonical og URL-parametre

Duplikatindhold handler sjældent om snyd. Det handler om, at dit CMS kan producere flere URL’er med samme indhold: sortering, filtre, paginering, kampagneparametre, eller en produktside der findes i flere kategorier.

Når Google møder mange næsten ens URL’er, bliver crawl-budget og indeksering spildt. Det kan også føre til, at “den forkerte” URL ranker, eller at signaler spredes ud.

Her er de vigtigste greb:

• Canonical-tag: peger på den version, du vil have som primær

• Noindex: holder lavværdi-sider ude af indekset

• Redirects: samler varianter, der ikke bør eksistere

• Parameterstyring: begrænser URL-eksplosion fra filtre og tracking

Strukturerede data: gør indholdet lettere at tolke

Strukturerede data er ikke en genvej til topplaceringer, men det hjælper søgemaskiner med at forstå, hvad en side repræsenterer. På e-handel kan Product markup støtte visning af pris og lagerstatus, og på artikler kan Article markup give klare signaler om forfatter, dato og type.

Det kræver, at markup matcher det synlige indhold. Hvis du markerer noget, som ikke findes på siden, eller hvis felter er forkerte, kan rich results udeblive.

Validering er en fast del af arbejdet. Det er bedre med korrekt, enkelt schema end med en stor opsætning, der halvt virker.

En hurtig oversigt: hvad du bør tjekke, og hvordan

Nedenfor er en praktisk tabel, der kan bruges som startpunkt til en teknisk gennemgang. Den er ikke komplet, men den rammer de ting, der oftest stopper vækst i organisk trafik.

Område	Typisk problem	Hvad det betyder	Sådan tjekker du
Crawlability	Blokeret af	Vigtige sider kan ikke hentes	Google Search Console, robots-test, crawlværktøj
Server og fejl	5xx, timeouts, ustabil drift	Crawl falder, sider droppes	Server logs, GSC Crawl stats, uptime-monitor
Indeksering	“Crawlet men ikke indekseret”	Google fravælger sider	GSC Indeksering, intern linking review
Duplikater	Manglende canonical, mange parametre	Signaler splittes	Crawlværktøj, URL-inspektion, logik for parametre
Hastighed	Tunge billeder, meget JS	Dårlig UX, langsom crawling	Lighthouse, PageSpeed Insights, RUM-data hvis muligt
Mobil	Manglende indhold/links på mobil	Mobilcrawl ser “mindre” site	Mobiltest, device checks, GSC mobilbrugervenlighed
Sitemap	Forældede URL’er	Google får forkert kort	Sitemap-validering, statuskoder, coverage i GSC
Strukturerede data	Ugyldige felter	Ingen rich results	Rich Results Test, schema-validering

E-handel og facetter: når URL’er formerer sig

E-handelssites har en særlig teknisk SEO-udfordring: facetteret navigation. Hver kombination af filter, sortering og kategori kan skabe en ny URL. Det giver brugeren værdi, men det kan give søgemaskinen et bjerg af sider, der ligner hinanden.

En sund model er at beslutte, hvad der skal ranke, og hvad der kun er til brug. Nogle filterkombinationer kan være gode landingssider, hvis de har efterspørgsel og stabilt sortiment. Resten bør styres med canonical/noindex, eller ved at begrænse, hvilke parametre der skaber crawlbare links.

Her er en kort prioritering, der ofte virker i praksis:

• Stabile kategorier: indekseres og optimeres

• Filtre med søgevolumen: kan gøres til SEO-landingpages

• Sortering og “midlertidige” visninger: holdes ude af indekset

• Interne søgninger: næsten altid noindex

En arbejdsgang der gør teknisk SEO til drift, ikke et projekt

Teknisk SEO falder ofte mellem to stole: marketing ser et SEO-problem, udvikling ser et backlog-problem. Det hjælper at gøre arbejdet mindre dramatisk og mere rutinepræget.

En simpel tilgang er at køre faste checks, koblet til releases: efter større ændringer tjekker man redirects, indexering, sitemap og performance. Efter mindre ændringer holder man øje med fejl og hastighed.

Hvis du vil gøre det operationelt, kan du arbejde efter denne rækkefølge:

1. Find crawl- og serverfejl, der stopper adgang

2. Ryd op i indekset (noindex, canonical, dubletter)

3. Få styr på arkitektur og intern linking

4. Optimer performance på skabelon-niveau

5. Læg strukturerede data på de vigtigste sidetyper

Hvor AI og automation passer ind

Teknisk SEO kan sagtens kræve udviklingstid, men meget af arbejdet handler om at opdage problemer tidligt, holde overblik og få prioriteret rigtigt. Her kan AI-baserede SEO-platforme være nyttige til at samle signaler fra audits, content-planer og interne links, så tekniske fund ikke lever i et regneark, der bliver glemt.

En platform som SEO.AI bliver typisk brugt til at binde workflowet sammen: fra research og indholdsproduktion til on-page optimering og intern linking, med løbende opdatering. Det løser ikke serverfejl i sig selv, men det kan gøre det lettere at se, hvilke sider der mangler interne links, hvilke emner der kræver bedre struktur, og hvilke ændringer der bør følges tæt i Search Console og rank tracking.

Teknisk SEO er sjældent én stor fix. Det er en række små beslutninger, der gør dit site let at læse for både mennesker og maskiner, hver uge, hele året.