Skip to content
Search

Technical SEO-audit: find problemer der hæmmer søgning

En praktisk, trin-for-trin technical SEO audit, der finder crawl-, render-, index- og performance-problemer og viser, hvordan du verificerer og prioriterer rettelser.

Technical SEO Audit: Find Issues Holding Back Search

Hvad en technical SEO audit tjekker

En technical SEO audit er en fokuseret, evidensbaseret gennemgang af de systemer, der gør det muligt for søgemaskiner at opdage, gengive, indeksere og forstå dine sider. Målet er at finde de tekniske forhindringer, der reducerer synlighed, spilder crawl budget, ødelægger brugeroplevelsen eller skaber tvetydighed i rangeringen.

Hovedområder at undersøge

• Opdagelse og crawlability — robots.txt, serverresponser, sitemap-dækning, interne links og redirects
• Indexing signals — meta robots, X-Robots-Tag headers, canonical tags og brug af noindex
• Rendering og JavaScript — server-side vs client-side rendering, blokering af ressourcer og hvordan sider ser ud, når de er gengivet
• Site performance og page experience — Core Web Vitals field data, server responstider og indlæsning af ressourcer
• Duplicate content og URL canonicalization — parameterhåndtering, varianter med/uden trailing slash og pagination
• Structured data og SERP features — markup-nøjagtighed og berettigelse til rich results
• Internationalization og hreflang-korrekthed
• Security og accessibility — HTTPS-dækning, mixed content og sikre headers

Sådan gennemfører du en technical SEO audit (trin for trin)

1. Definér scope og succeskriterier

Begynd med at beslutte, hvilke dele af sitet du vil auditere og hvorfor. Eksempler: et helt domæne, en undermappe, en stor produktkategori, eller et sæt af landing pages. Beslut målbare succeskriterier (indeksering af canonical-sider, færre serverfejl, forbedrede Core Web Vitals-percentiler, synlighed for specifikke URL-grupper).

2. Lav en inventarliste

Saml en repræsentativ URL-liste fra sitemaps, analytics, serverlogs, interne links og kendte landing pages. Denne oversigt er dit audit-område — gem den i et regneark eller et crawler projekt, så du kan tagge og filtrere URL'er mens du arbejder.

3. Crawl og sammenlign (ekstern crawl + serverlogs)

Kør en ekstern crawl for at efterligne en søgemaskines opdagelse af sider. Kombinér crawlresultater med serverlogs for at se, hvilke URLs søgemaskiner reelt anmoder om. Serverlogs viser, hvor ofte crawlere henter sider, og om redirects, soft-404s eller hyppige fejl optræder i produktion.

For kun at inspicere headers: brug curl -I https://example.com/page for at se status og headerfelter. For at hente den HTML, en bestemt user-agent ville modtage: brug curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page og gem outputtet til sammenligning.

4. Verificér indexerbarhed og canonical-intent

For sider du ejer, brug Google Search Console URL Inspection til at tjekke, hvordan Google indekserede en URL, og om der blev fundet indekseringsproblemer. For tredjepartssider (publishers, partner-sider) brug eksterne checks: view-source, curl, rendered DOM-tjek i Chrome DevTools og offentlige indeks-signaler som site: operatoren som en indikation (ikke bevis) på, at Google kender til en URL.

5. Test rendering og JavaScript-opførsel

Åbn sider i Chrome DevTools, brug Elements- og Network-panelerne til at bekræfte, at ressourcer loader og ikke er blokeret, og tjek den renderede DOM for indhold injiceret af JavaScript. Hvis kritisk indhold først vises efter brugerinteraktion eller sent i render-processen, noter risikoen for synlighed og testtrinene for at reproducere det.

Brug Rich Results Test og Schema Markup Validator (schema.org) til at validere structured data og opdage fejl, der ville forhindre berettigelse til rich results.

6. Mål page experience og performance

Indsaml field-metrikker (Core Web Vitals) fra Search Console og lab-profiler fra Lighthouse eller lokal testning. Field data afspejler rigtige brugere; lab-data hjælper med at reproducere problemer lokalt. Prioritér rettelser, der påvirker real-user-metrikker for sider, der betyder noget for søgesynlighed.

Verifikation og fejlfinding

Fejlfinding er en detektivproces: reproducer symptomet, isolér variabler og test rettelser. Brug en kombination af offentligt tilgængelige og ejer‑begrænsede værktøjer.

Nyttige verifikationstrin

• Tjek serverresponser: curl -I viser HTTP-status, content-type og X-Robots-Tag headers.
• Inspicer den leverede HTML: curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page og sammenlign med et browser-hent for at opdage indholdsforskelle.
• Renderet DOM-tjek: åbn URL'en i Chrome, deaktiver cache, og brug Elements til at bekræfte, at vigtigt indhold er til stede i DOM'en uden krav om brugerinteraktion.
• Indekseringsbevis (ejede sider): Google Search Console URL Inspection viser indeksstatus og årsager til eksklusion.
• Structured data: kør Rich Results Test og Schema Markup Validator for at se parsing og fejl.
• Field performance: gennemgå Core Web Vitals i Search Console for real-user-metrikker; brug Lighthouse eller lab-kørsler for at reproducere de langsomme tilfælde.
• Crawl-aktivitet: sammenlign crawler-forespørgsler i serverlogs med dit sitemap og kendte sider for at identificere huller eller overdreven crawling på lavværdi-URLs.

Almindelige fejl og misforståelser

• At betragte værktøjsadvarsler som selve auditen: Crawlere fremhæver mange signaler; auditens opgave er at fortolke, hvilke advarsler der faktisk betyder noget for dine forretningsmål.
• At forveksle crawling med indeksering: at blive hentet af en crawler garanterer ikke, at en side bliver indekseret eller vil rangere.
• At stole på site: som endeligt bevis: site: er et nyttigt offentligt signal, men ikke autoritativt. For ejede sider, brug URL Inspection i Search Console.
• At blokere kritiske assets: robots.txt eller serverregler, der forhindrer CSS/JS, kan ændre hvordan Google gengiver sider og kan bryde Core Web Vitals eller structured data-detektering.
• Forkerte canonical- eller redirect-kæder: canonical-tags der peger på ikke-canonisk indhold eller lange redirect-kæder skaber tvetydighed og gør crawls langsommere.
• At antage at rel="nofollow" betyder nul værdi: Google behandler rel="nofollow" som et hint; håndteringen er ikke en simpel on/off-sag.
• At ignorere indexerbarheden af publisher- eller partner-sider: et backlink eller en omtale er mindre nyttig, hvis siden ikke er indexerbar eller er skjult bag autentificering.

Når betalte placeringer eller sponsoreret indhold er involveret, følg Googles retningslinjer: marker betalte/kompencerede links med rel="sponsored" eller rel="nofollow" og brug rel="ugc" for bruger-genererede links. Husk: der findes ikke et rel="dofollow"-attribut; et standardlink er blot et link uden rel=nofollow/sponsored/ugc. Googles linkspam-vejledning angiver, at links primært ment til at manipulere ranking kan behandles som linkspam, så sørg for redaktionel kontekst, indexerbarhed og gennemsigtighed ved eksterne placeringer.

Tjekliste: høj-impact punkter og hvordan du verificerer dem

Brug denne kompakte tjekliste til at verificere de mest almindelige tekniske issues med høj effekt. For hvert punkt er det rigtige verifikationsværktøj angivet.

1) Canonical-intent: Er canonical-tags konsistente og peger de på den ønskede URL? (Verificér: view-source, sammenlign med HTTP-headers og brug en ekstern crawler.)

2) HTTP-status og redirect-kæder: Returnerer vigtige sider 200 og ikke-redirect-fejl, og er redirects minimale? (Verificér: curl -I og serverlogs.)

3) Robots og meta robots: Er vigtige assets eller sider utilsigtet blokeret? (Verificér: hent robots.txt, X-Robots-Tag i headers via curl -I og meta robots i HTML.)

4) Indekseringsanomali: Er sider udelukket af tekniske årsager (noindex, canonical peger andetsteds, soft-404)? (Verificér: Google Search Console URL Inspection for ejede sider; for eksterne sider, sammenlign HTML + offentlige indeks-signaler.)

5) Renderet indholdsparitet: Indeholder den HTML, som søgemaskiner ser, det samme kritiske indhold som brugerne ser? (Verificér: curl med passende UA, Chrome DevTools renderede DOM.)

6) Structured data-korrekthed: Er structured data validt og opdateret? (Verificér: Rich Results Test og Schema Markup Validator.)

7) Core Web Vitals og load-performance: Viser field-metrikker problemer for dine kernesider? (Verificér: Search Console Core Web Vitals-rapport og lab-tests med Lighthouse.)

Prioritering: vælg rettelser der gør en forskel

Prioritér arbejde ved at kombinere tre dimensioner: relevans for forretningsmål (hvilke sider betyder noget for search-trafik eller konverteringer), teknisk alvorlighed (blokerer indeksering, forårsager hyppige fejl) og indsats for at fixe. Hurtige gevinster inkluderer ofte at rette fejlkodede noindex-tags, fjerne redirect-kæder for højt-traffikerede sider og unblocke kritisk CSS/JS, der påvirker rendering.

Rapportering og overvågning

Lever en audit-rapport der grupperer issues efter prioritet, viser eksempler og reproduktionstrin, og inkluderer en anbefalet rollout-plan. Tilføj overvågning for regressioner: følg serverfejl, indeksændringer via Search Console og Core Web Vitals field-metrikker. Efter deployment af rettelser, kør de præcise verifikationstrin fra auditen igen for at bekræfte løsning.

FAQ

Hvordan adskiller crawling sig fra indeksering og rangering?

Crawling er processen med at opdage og hente URLs. Indeksering er beslutningen om at gemme noget eller alt indholdet fra en side i søgeindekset. Rangering er rækkefølgen af resultater, når en forespørgsel udføres. En side kan blive crawlet men ikke indekseret, og at være indekseret garanterer ikke en høj rangering; hver fase har separate signaler og checks.

Hvad hvis jeg ser forskellig HTML, når jeg henter en side som Googlebot?

Først, bekræft om forskellen er tilsigtet (device-optimeret indhold) eller utilsigtet (servermisconfiguration eller user-agent-sniffing). Brug curl med en Googlebot-lignende UA til at gemme HTML'en, sammenlign med en normal browser-hent, og tjek server-side logik der varierer output efter UA eller headers. Undgå at servere væsentligt forskelligt indhold til crawlere versus brugere.

Hvordan tjekker jeg, om en publisher-side med et backlink er indexerbar?

Udefra, tjek sidens HTML for meta robots, brug curl -I til at inspicere X-Robots-Tag headers, og bekræft at siden returnerer 200. Brug den renderede DOM i en browser for at sikre, at linket er til stede i den statiske eller renderede HTML. Site: operatoren kan indikere offentlige indeks-signal, men er ikke definitiv.

Sikrer det at rette tekniske issues forbedret rangering?

Ingen enkelt teknisk rettelse garanterer rangforbedringer. Teknisk arbejde fjerner forhindringer og øger sandsynligheden for, at stærkt, relevant indhold kan konkurrere. Efter rettelser, overvåg indeksering og performance-signaler og kombiner tekniske forbedringer med arbejde på indhold og relevans.

Da Google bruger mobile-first indexing, hvad bør jeg tjekke først?

Google bruger mobilversionen som sit primære grundlag for crawling og indeksering. Siden July 2024 crawler Google sites til Search med Googlebot Smartphone by default. Bekræft at mobil-HTML'en eksponerer det samme kritiske indhold, metadata og structured data som desktop-versionen, og sørg for at mobilperformance og responsiv adfærd er acceptabel.

Related articles