SEO i praksis: teknik før indhold

Der bliver skrevet meget om indhold i SEO, og med god grund. Men indhold er det sidste trin, ikke det første. En fremragende artikel på en side, Google ikke kan finde, ikke kan hente ordentligt, eller vælger ikke at indeksere, rangerer på ingenting. Teknikken er ikke det sjove ved SEO, men det er det, der afgør, om resten af arbejdet overhovedet tæller.

Den gode nyhed er, at teknisk SEO er afgrænset. Der er ikke uendelig mange ting at tjekke, og de fleste af dem kan besvares med et ja eller nej. Den her guide går dem igennem i den rækkefølge, der giver mest effekt for mindst arbejde, og siger også tydeligt, hvad du roligt kan lade ligge.

1. Kan Google overhovedet finde og hente siderne?

Start med det mest grundlæggende spørgsmål, og vær konkret: tag fem vigtige sider fra dit site og slå dem op i Search Console under URL-inspektion. Ikke forsiden, den er næsten altid fin. Tag de sider, der skal sælge noget.

• Er siden indekseret? Hvis ikke, siger Search Console hvorfor, og det svar er guld værd.
• Er den opdagede version den samme som den, du ville have haft? Ellers har du et canonical-problem.
• Hvornår blev den sidst crawlet? Måneder siden på en vigtig side er et signal om, at Google ikke prioriterer den.
• Er der en forældet version i indekset, fordi siden har skiftet URL uden et redirect?

Gå derefter i rapporten over sideindeksering og læs kategorierne for udelukkede sider. Den rapport er den ærligste feedback, du kan få fra Google, og der ligger ofte mindst én overraskelse. Typiske fund er interne søgeresultater, filtersider og gamle kampagnesider, der æder crawl-kapacitet uden at have en chance for at rangere.

robots.txt og sitemap: de to filer, der oftest modsiger hinanden

Det klassiske rod er et sitemap, der lister sider, robots.txt blokerer, eller som er sat til noindex. Du sender altså Google et kort over steder, du samtidig siger, den ikke må gå hen. Resultatet er advarsler i Search Console og spildt crawl-kapacitet.

• Sitemappet skal kun indeholde sider, der returnerer 200, er canonical og må indekseres. Ikke redirects, ikke fejlsider, ikke noindex.
• Bloker lavværdimønstre i robots.txt: interne søgeresultater, uendelige filterkombinationer og sessions-parametre.
• Husk, at robots.txt forhindrer crawl, ikke indeksering. Skal en side helt ud af indekset, er noindex svaret, og så skal siden faktisk kunne crawles, for at Google kan se direktivet.
• Tjek, at sitemappet er angivet i robots.txt og indsendt i Search Console.

2. Hastighed: de tre tal, der faktisk måles

Core Web Vitals er Googles forsøg på at måle, hvordan en side opleves, i stedet for hvor hurtigt en server svarer. Der er tre af dem, og Google angiver en tærskel for hver, målt på 75. percentil af de faktiske besøgende. Det sidste er vigtigt: det er dine rigtige brugeres oplevelse, ikke en test på din egen maskine.

• LCP, Largest Contentful Paint: hvor længe der går, før det største element er tegnet. Tærsklen er 2,5 sekunder.
• INP, Interaction to Next Paint: hvor længe siden er om at reagere, når man klikker eller taster. Tærsklen er 200 millisekunder. INP afløste FID i 2024 og måler nu hele besøget, ikke kun det første klik.
• CLS, Cumulative Layout Shift: hvor meget indholdet hopper, mens siden indlæses. Tærsklen er 0,1.

Dertil kommer TTFB, tiden til første byte, som ikke er en Core Web Vital i sig selv, men som næsten altid er årsagen, når LCP er dårlig. Ligger den over 800 millisekunder, er det serveren eller hostingen, du skal se på, ikke billederne.

I praksis kommer de fleste gevinster fra ret få ting: billeder i moderne format og i den rigtige størrelse, skrifttyper der ikke blokerer visningen, færre tredjepartsscripts, og en cache der virker. Et cookiebanner, der indlæses via en ekstern tjeneste og lægger sig over hele skærmen, er en overraskende hyppig synder på alle tre tal på én gang.

3. JavaScript: ser Google det samme som dine besøgende?

Moderne hjemmesider bygger ofte indholdet i browseren. Google kan godt køre JavaScript, men det sker i et ekstra trin efter den første hentning, og det trin er hverken gratis eller garanteret. Jo mere af dit indhold der kun findes efter JavaScript er kørt, jo større er risikoen for, at noget falder på gulvet.

Testen er enkel: brug URL-inspektion i Search Console og se på den hentede HTML. Er din brødtekst, dine overskrifter og dine interne links der? Eller er der kun en tom beholder og et script? Er det sidste tilfældet, er serverside-rendering eller statisk generering den rigtige vej, og det er en ændring i selve hjemmesidens opbygning, ikke noget du kan plastre over.

• Interne links skal være rigtige a-elementer med en href. Et klikbart div fungerer for brugeren, men er ikke et link for en crawler.
• Indhold bag Læs mere, faner eller uendelig scroll skal findes i HTML fra start, ikke først hentes ved et klik.
• Paginering skal have rigtige links til side 2, 3 og så videre.

4. Struktur: hvor mange klik er der til dine vigtigste sider?

Intern linkstruktur er det mest oversete tekniske håndtag, og et af de billigste. Google finder sider ved at følge links, og den bruger samtidig linkene som et signal om, hvad der er vigtigt. En side, der kun kan nås fra sitemappet, sender et tydeligt signal om, at du ikke selv synes, den er vigtig.

• Kan alle vigtige sider nås fra forsiden på højst tre klik?
• Har hver side mindst ét internt link fra en anden relevant side, med en ankertekst der beskriver, hvad man kommer til?
• Er der brødkrummer, så både brugere og crawlere kan se, hvor en side hører hjemme?
• Findes der forældreløse sider, som ingen linker til? En crawl af sitet afslører dem hurtigt.

Struktureret data hører også til her. Schema-markup får dig ikke til at rangere højere i sig selv, men det gør din side lettere at forstå maskinelt, og det er forudsætningen for de udvidede visninger i resultaterne. Hold dig til de typer, der faktisk passer til siden: Organization, LocalBusiness, Article, FAQPage, BreadcrumbList og Product. Opfind ikke markup for indhold, der ikke står på siden.

5. AI-crawlere: den nye del af teknisk SEO

Teknisk SEO handlede længe kun om Googlebot. I dag henter en række andre robotter også dine sider: GPTBot, PerplexityBot, ClaudeBot og Google-Extended er blandt de mest almindelige. De læser ikke dit design, de læser din struktur, og de er blevet en reel trafikkilde og en reel synlighedskanal.

Det giver to opgaver. Den ene er at beslutte, hvem der må hente hvad, og skrive det i robots.txt per user-agent i stedet for at have én regel for alle. Den anden er at gøre indholdet let at uddrage: tydelige overskrifter, faktiske svar i brødteksten frem for kun i billeder og PDF-filer, og struktureret data der matcher siden.

Nogle sites lægger desuden en llms.txt, en kort maskinlæsbar oversigt over sitets vigtigste indhold. Det er endnu ikke en standard, Google har forpligtet sig på, så behandl det som et billigt eksperiment frem for et must. Vil du gå videre med den del, har vi skrevet om det under GEO og synlighed i AI-svar.

6. Hvad du roligt kan lade ligge

En teknisk gennemgang producerer altid flere fund, end der er tid til. Lige så vigtigt som at vide, hvad der skal rettes, er at vide, hvad der ikke betaler sig. Det her er typisk støj:

• At jagte 100 point i PageSpeed Insights. Forskellen mellem 85 og 98 mærker ingen bruger, og tallet er ikke det, der måles på.
• Meta keywords. De har ikke været brugt af Google i mange år.
• Små justeringer af nøgletæthed i teksten. Skriv til mennesker.
• Rettelser på sider, der hverken har trafik, links eller en forretningsmæssig grund til at eksistere. Overvej i stedet at fjerne dem.
• Validerings-advarsler i HTML, der ikke påvirker, hvordan siden vises eller forstås.

Teknisk SEO gør dig ikke synlig. Det fjerner grundene til, at du ikke er det.

Når fundamentet er på plads, er det indholdet og linkene, der flytter placeringerne, og det tager tid. Hvor lang tid er et spørgsmål for sig, og vi har svaret så ærligt vi kan i guiden om hvor lang tid SEO tager. Skal en af de tekniske rettelser laves i selve hjemmesiden, hører det under webudvikling.