Søgning · Sidens sundhed
En tjekliste til teknisk SEO-audit af små virksomheders hjemmesider
Crawl først, meninger bagefter
En teknisk SEO-audit af en lille virksomheds hjemmeside undersøger, om søgemaskiner kan crawle, rendere, indeksere og forstå alle de sider, der betyder noget. For en typisk dansk hjemmeside på 20 til 500 sider omfatter den statuskoder, robots.txt, sitemaps, canonicals, interne links, Core Web Vitals, mobilvisning, sprogtags og strukturerede data, og det meste kan tjekkes med gratis værktøjer.
Tjeklisten
Før du går i gang: værktøjer og et udgangspunkt
En lille virksomhed behøver ikke en dyr platform for at auditere sin egen hjemmeside. De fleste problemer på en side med et par hundrede undersider dukker op med en håndfuld værktøjer, brugt i en fornuftig rækkefølge.
- Google Search Console: det eneste førstehåndsindblik i, hvordan Google ser hjemmesiden. Verificér domæneejendommen, så den dækker alle subdomæner og både http og https.
- Bing Webmaster Tools: værd at tilføje, fordi Bings indeks også fodrer andre søge- og AI-produkter. Det kan importere din opsætning fra Search Console.
- En desktop-crawler: gratisversionen af Screaming Frog crawler op til 500 URL’er, hvilket dækker mange små virksomheders hjemmesider. Sitebulb er et betalt alternativ.
- PageSpeed Insights: viser både feltdata fra rigtige Chrome-brugere og en labtest af en enkelt side.
Før du ændrer noget, så eksportér performancedata fra Search Console for de seneste 16 måneder, og notér, hvor mange sider der er indekseret. Uden et udgangspunkt kan du ikke senere se, om en rettelse virkede, eller om et redesign ødelagde noget.
Kan søgemaskinerne nå alle sider?
Crawlbarhed er fundamentet for alt andet. Hvis en side ikke kan hentes, er dens indhold ligegyldigt.
- robots.txt: åbn ditdomæne.dk/robots.txt og læs den. Kig efter en overset
Disallow: /fra et testmiljø, en meget almindelig fejl efter en lancering. Sørg for, at den ikke blokerer CSS- eller JavaScript-filer, som er nødvendige for at vise siderne. - XML-sitemap: det bør kun indeholde canonical, indekserbare sider, der returnerer status 200, og det bør være indsendt i Search Console. Et sitemap fyldt med redirects og 404-fejl lærer crawlerne at stole mindre på det.
- Statuskoder: crawl hjemmesiden, og sortér efter status. Ret interne links, der peger på 404-sider, og erstat links til omdirigerede URL’er med den endelige adresse.
- Redirect-kæder: ét hop er fint, tre hop efter to redesigns er ikke. Send gamle URL’er direkte til den aktuelle side med en 301.
- Forældreløse sider: sammenlign sitemappet med crawlet. Sider, der findes i sitemappet, men ikke får nogen interne links, er svære at finde for både søgemaskiner og besøgende.
Danske bogstaver fortjener også et hurtigt tjek. URL’er med æ, ø og å virker, men de bliver ofte kodet forskelligt i CMS’et, sitemappet og gamle links. Mange hjemmesider skriver dem simpelthen om (ae, oe, aa) i URL-slugs for at undgå problemet.
Indeksering, dubletter og canonical-tags
At blive crawlet er ikke det samme som at blive indekseret. Rapporten Sideindeksering i Search Console viser hver eneste begrundelse, Google giver for at udelade en URL, og det er det mest nyttige skærmbillede i en teknisk audit.
- Udelukket af noindex: tjek, at alle de viste sider faktisk skal være skjult. Skabeloner og plugins sætter nogle gange noindex bredere end tiltænkt.
- Dublet uden brugervalgt canonical: skyldes typisk URL-parametre, filtersider i en webshop eller den samme side, der kan nås både med og uden skråstreg til sidst.
- Crawlet, men ikke indekseret i øjeblikket: ofte et tegn på, at Google anser siden for tynd eller for lig andre sider. Det er et indholdsproblem med et teknisk symptom.
- Canonical-tags: alle indekserbare sider bør have en canonical, der peger på sig selv, og ingen side bør have en canonical, der peger på en URL, som omdirigerer eller er blokeret.
Brug værktøjet URL-inspektion på de vigtigste sider, fx forsiden, de centrale servicesider og de bedst sælgende produkter, for at bekræfte, at Google har indekseret dem, og for at se den renderede HTML, Google arbejdede ud fra.
Hastighed, Core Web Vitals og mobilvisning
Google har i nogle år brugt mobile-first-indeksering for alle hjemmesider, så det er mobilversionen af hver side, der tæller. Åbn de vigtigste sider på en rigtig telefon og i en browseremulator, og tjek, at menuer, formularer og indhold i faneblade er til stede og kan bruges.
Core Web Vitals er Googles tre feltmålinger af sideoplevelsen. En side består, når mindst 75 procent af de rigtige besøg opfylder hver grænseværdi:
| Måling | Hvad den måler | God grænseværdi |
|---|---|---|
| LCP, Largest Contentful Paint | Hvor hurtigt hovedindholdet vises | 2,5 sekunder eller mindre |
| INP, Interaction to Next Paint | Hvor hurtigt siden reagerer på tryk og klik | 200 millisekunder eller mindre |
| CLS, Cumulative Layout Shift | Hvor meget layoutet hopper under indlæsning | 0,1 eller mindre |
INP afløste First Input Delay som Core Web Vital i marts 2024, så ældre audits kan rapportere den forkerte måling. Hjemmesider med lidt trafik har ofte slet ingen feltdata, og så kan du bruge labresultater som pejlemærke, men uden at behandle en enkelt score som en dom. De typiske syndere på små hjemmesider er for store hero-billeder, tunge page builders, for mange tredjepartsscripts og cookiebannere, der flytter layoutet. Vores arbejde med Core Web Vitals tager dem én ad gangen.
Interne links, sprog og strukturerede data
Når siderne kan findes og indekseres, går audit’en videre til, hvor godt hjemmesiden forklarer sig selv.
Interne links og dybde
Vigtige sider bør kunne nås inden for tre klik fra forsiden og have links fra relevant tekst, ikke kun fra menuen. Tjek, at linkteksten beskriver destinationen („pakker til bryllupsfotografering“, ikke „læs mere“).
Danske og engelske versioner
Hvis hjemmesiden findes på begge sprog, bør hver side angive sine alternativer med hreflang-tags, fx da-DK og en, plus en x-default. Tags skal være gensidige: hvis den danske side peger på den engelske, skal den engelske pege tilbage. Manglende eller ensidige tags er en almindelig årsag til, at en engelsk side ranker i danske resultater eller omvendt. Sæt også den korrekte lang-attribut på html-elementet.
HTTPS og de små ting, der går i stykker i stilhed
Alle sider bør indlæses over https, og http-versionen, www-versionen og det rene domæne bør alle omdirigere i ét trin til én foretrukken adresse. Tjek for advarsler om blandet indhold, hvor en https-side stadig henter et billede eller script over http, og for et certifikat, der er ved at udløbe på et subdomæne, fx til et booking- eller webshopsystem. Se også på den tilpassede 404-side: den bør returnere en rigtig 404-status i stedet for 200, og den bør hjælpe den besøgende tilbage med links til de vigtigste sektioner. Det er små ting, men det er dem, ingen bemærker, før placeringer eller tillid allerede er faldet.
Strukturerede data og titler
- Validér Organization- eller LocalBusiness-markup med Googles Rich Results Test, og sørg for, at den stemmer overens med den synlige side.
- Kig efter manglende, dublerede eller afkortede title-tags og metabeskrivelser i crawl-eksporten.
- Tjek, at hver side har én tydelig h1, og at billeder har meningsfuld alt-tekst.
Fra fund til en prioriteret liste over rettelser
Alle crawlere spytter en lang liste af advarsler ud, og mange af dem betyder ingenting. Kunsten i en audit er at rangordne fundene efter effekt og indsats og så først rette de få, der blokerer de sider, der skaber omsætning.
- Blokeringer: alt, der forhindrer vigtige sider i at blive crawlet eller indekseret. Ret med det samme.
- Lækager: døde interne links, redirect-kæder, dublerede sider, der konkurrerer med hinanden. Ret i næste sprint.
- Forbedringer: hastighed, strukturerede data, intern linkning. Planlæg dem ind.
- Kosmetiske advarsler: manglende alt-tekst på dekorative billeder, mindre problemer med titellængde. Saml dem i én omgang.
Skriv hvert punkt som en opgave, en udvikler kan gå i gang med, med URL’en, problemet, rettelsen og hvordan man tjekker, at den virkede. Crawl igen efter rettelserne, og sammenlign med udgangspunktet. Ved en fuld teknisk SEO-audit leverer vi listen præcis i den form, og en lille hjemmeside er som regel værd at tjekke igen efter hvert redesign, hver migrering eller hvert skift af CMS. Mange af lækagerne i den anden gruppe sniger sig tilbage, efterhånden som sider bliver tilføjet og fjernet, og derfor sparer løbende vedligeholdelse af hjemmesiden og et kort crawl med få måneders mellemrum en større oprydning senere.
Spørgsmål om audits
Det spørger ejere om
før et crawl
Et let tjek hvert kvartal og en fuld audit én gang om året er en fornuftig rytme for de fleste små hjemmesider, med en ekstra audit efter hvert redesign eller platformskift. Advarsler fra Search Console dækker nogle problemer ind imellem, fordi Google sender en e-mail til ejeren, når indekseringsfejl stiger brat, eller når der pålægges en manuel handling.
Kvartalstjekket kan klares på en time: gennemgå rapporten Sideindeksering, kør et crawl, se på Core Web Vitals, og test kontaktformularen. Den årlige audit går dybere ned i dubletter, intern linkning, strukturerede data og hastighed. Migreringer er det mest risikable tidspunkt, fordi ændrede URL’er, tabte redirects og et glemt noindex-tag kan fjerne en hjemmeside fra søgeresultaterne på få uger. Crawl den gamle hjemmeside før lanceringen, kortlæg hver URL, og crawl den nye på lanceringsdagen.
For mange små virksomheders hjemmesider, ja. Gratisversionen af Screaming Frog SEO Spider crawler op til 500 URL’er og rapporterer statuskoder, redirects, titler, metabeskrivelser, canonicals, overskrifter og direktiver, hvilket dækker det meste af, hvad en grundlæggende audit kræver.
Begrænsningerne viser sig på større hjemmesider og ved dybere tjek. Den betalte licens fjerner loftet over antal URL’er og tilføjer JavaScript-rendering, gemte crawls, planlægning og forbindelser til data fra Search Console og PageSpeed. Husk, at billeder, PDF’er og URL’er med parametre tæller med i de 500, så en hjemmeside med 150 sider kan nå grænsen. Uanset hvilken version du bruger, så kombinér crawlet med Search Console, for en crawler viser, hvad der ligger på hjemmesiden, mens Search Console viser, hvad Google besluttede at gøre med det.
De klarer en del af den, men ikke det hele, og de kan skabe deres egne problemer. Plugins som Yoast og Rank Math genererer sitemaps, canonical-tags, grundlæggende strukturerede data og titelskabeloner, hvilket sparer meget manuelt arbejde på en WordPress-side.
Hvad de ikke kan rette, er hjemmesiden omkring dem. Et plugin komprimerer ikke et hero-billede på fem megabyte, fjerner ikke en langsom page builder, retter ikke redirect-kæder fra en gammel migrering og skriver ikke indhold, der fortjener at blive indekseret. Indstillingerne betyder også noget: én forkert knap kan sætte noindex på alle kategorisider eller fjerne sitemappet. To SEO-plugins på én gang giver ofte dublerede tags. Se pluginnet som et værktøj, du konfigurerer og tjekker ved hver audit, ikke som et bevis på, at den tekniske del er på plads.
Som regel fordi siderne kan nås, og intet fortæller Google, at de skal udelades. Søgemaskiner indekserer det, de kan finde, så tag-arkiver, interne søgeresultater, kopier fra testmiljøer, takkesider, vedhæftningssider og filtrerede webshop-URL’er havner overraskende tit i resultaterne.
Start med at finde dem: søg i Google med site:ditdomæne.dk, og tjek listen over indekserede sider i Search Console. Beslut derefter side for side. Tynde systemsider bør have et noindex-tag. Dubletter bør have en canonical, der peger på hovedversionen. Testmiljøer bør ligge bag en adgangskode, hvilket er mere pålideligt end robots.txt, fordi en blokeret URL stadig kan blive indekseret, hvis andre hjemmesider linker til den. Fjern alt, der er reelt privat, fra serveren, og brug værktøjet Fjernelser i Search Console til en hurtig, midlertidig skjulning.