Server og HTTP-responser — Statuskoder, redirects og caching

Når Googlebot eller en bruger besøger en side, sender serveren et svar — en HTTP-response. Dette svar indeholder selve siden, men også en statuskode og response headers, der kommunikerer afgørende information til browseren og søgemaskinerne. At forstå HTTP er ikke blot backend-viden; det er grundlæggende teknisk SEO.

HTTP — protokollen bag webbet

HTTP (HyperText Transfer Protocol) er den kommunikationsprotokol, browsere og servere bruger til at udveksle data. HTTPS er den krypterede version og er i dag standarden — alle sider uden HTTPS markeres som “ikke sikre” i Chrome og nedvægtes af Google.

Hvert HTTP-request og response følger en fast struktur:

• Request: Browser/Googlebot anmoder om en URL
• Response headers: Serveren sender metadata om svaret
• Response body: Selve HTML-koden (eller hvad der nu hentes)

Response headers indeholder information som content-type, cache-direktiver, redirect-destinationer og sikkerhedsindstillinger. Disse headers er usynlige for brugeren men læses aktivt af Googlebot.

HTTP-statuskoder

Statuskoder er tre-cifrede tal, der fortæller, hvad der skete med en request. De er opdelt i klasser:

2xx — Succes

200 OK er den normale, succesfulde response. Siden findes og leveres korrekt. Dette er den statuskode, dine vigtige sider altid bør returnere til Googlebot.

204 No Content returneres, når der ikke er indhold at sende. Sjælden i normal sidevisning.

3xx — Redirects

301 Moved Permanently er den permanente redirect. Bruges ved:

• Domæneskift
• URL-ændringer (fra /old-url/ til /new-url/)
• HTTP til HTTPS-redirect
• www til ikke-www (eller omvendt)

En 301-redirect signalerer til Google, at den originale URL er permanent erstattet. Link equity (linkstyrke) overføres i høj grad — men ikke 100% — til den nye URL.

302 Found (midlertidig redirect) brug er mere begrænset. En 302 fortæller Google, at den originale URL stadig er aktiv og blot midlertidigt sendes videre. Google overfører ikke link equity på samme måde, og den originale URL forbliver i indekset.

En hyppig fejl er at bruge 302 frem for 301 ved permanente ændringer — for eksempel at opsætte HTTPS-redirects som 302. Dette er teknisk SEO-fejl med potentielt Link equity-tab.

307 Temporary Redirect og 308 Permanent Redirect er de HTTP/1.1-kompatible versioner af 302 og 301. Brug 301 for permanente redirects i langt de fleste tilfælde.

4xx — Klientfejl

404 Not Found returneres, når den anmodede side ikke eksisterer. En håndfuld 404-fejl er normalt og uundgåeligt på et aktivt site. Et stort antal 404-fejl — specielt på sider med interne links — er et signal om tekniske problemer.

Bløde 404-fejl er sider der returnerer 200 OK, men viser “siden blev ikke fundet”-indhold. Google opdager dette og behandler dem som rigtige 404-fejl, men det kræver mere ressourcer for Googlebot at identificere dem.

410 Gone er den korrekte statuskode for sider, der er permanent slettet. Den fortæller Google, at siden er bevidst fjernet og ikke blot midlertidigt utilgængelig. Google fjerner 410-sider fra indekset hurtigere end 404-sider.

403 Forbidden returneres, når serveren nægter adgang. Sider med 403 for Googlebot indekseres ikke.

429 Too Many Requests kan returneres, hvis Googlebot crawlspeeden overstiger serverens kapacitet. Google tager hensyn til dette og reducerer crawlraten.

5xx — Serverfejl

500 Internal Server Error er en generel serverfejl. Er fejlen midlertidig, vil Googlebot prøve igen. Er den vedvarende, risikerer sider at miste indekseringen.

503 Service Unavailable bruges ved planlagt vedligeholdelse. Serveret korrekt med en Retry-After-header signalerer det til Googlebot, at nedetiden er midlertidig.

Redirects og SEO

Redirects er nødvendige ved URL-ændringer, men de koster. Hvert redirect-hop tilføjer latency og kræver, at Googlebot bruger crawl budget på at følge kæden.

Redirect-kæder — tre eller flere redirects i rækkefølge — bør undgås. De øger indlæsningstid for brugere, kan stoppe link equity-overførslen og forvirrer Googlebot. Hold redirects til ét hop: fra gammel URL direkte til endelig destination.

Redirect-loops — A redirecter til B, B redirecter til A — er fejl der skal rettes omgående. Browsere og Googlebot afbryder efter et antal hop.

Caching

HTTP-caching styrer, hvornår browsere og CDN’er (Content Delivery Networks) gemmer og genbruger ressourcer frem for at hente dem fra serveren igen.

Cache-Control headeren specificerer caching-adfærd:

Cache-Control: max-age=31536000, immutable

Dette fortæller browseren, at ressourcen kan caches i ét år og er uforanderlig. Bruges typisk til CSS- og JavaScript-filer med versionnummer i filnavnet.

Cache-Control: no-cache

Kræver at browseren validerer med serveren, om den cachede version stadig er gyldig, før den bruges.

God caching-strategi forbedrer performance markant: returnerende brugere og Googlebot kan hente statiske ressourcer fra lokal cache frem for at downloade dem igen. Det reducerer serverbelastning og forbedrer Core Web Vitals.

Komprimering

Komprimering reducerer filstørrelsen på HTML, CSS og JavaScript, der sendes over nettet. Gzip og Brotli er de to primære komprimeringsformater.

En komprimeret HTML-fil er typisk 60-80% mindre end den ukomprimerede version. Dette reducerer Time to First Byte (TTFB) og forbedrer LCP markant.

Komprimering aktiveres på serveren og er transparant for brugeren og Googlebot. Response headeren Content-Encoding: gzip (eller br for Brotli) indikerer, at indholdet er komprimeret.

Minificering

Minificering er fjernelse af unødvendige tegn fra kode — mellemrum, linjeskift, kommentarer — uden at ændre funktionaliteten. En minificeret JavaScript-fil kan være 30-50% mindre.

Minificering er ikke det samme som komprimering — de er komplementære. Komprimering sker på transport-laget; minificering reducerer den faktiske filstørrelse.

CSS og JavaScript bør altid minificeres i produktion. HTML minificeres i mange tilfælde også, men gevinsten er typisk lille sammenlignet med CSS og JavaScript.

Server response time (TTFB)

Time to First Byte (TTFB) er den tid, der går fra browseren sender en request, til den modtager den første byte af svaret. TTFB er en indikator for serverydelse og er relateret til LCP-metrikken.

Google anbefaler under 800ms TTFB. En høj TTFB kan skyldes:

• Langsom databaseforespørgsel
• Manglende server-side caching
• Langsom hosting
• Geografisk afstand til serveren (løses med CDN)

Relaterede artikler

• Kode og teknisk SEO — den komplette guide
• Crawling og indeksering
• Web Performance — Core Web Vitals
• JavaScript og rendering

---

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog.