Artikel

Server-side rendering — SSR og fordele for SEO

SSR leverer færdig HTML fra serveren — Googlebot ser straks indholdet uden rendering-kø, og FCP forbedres markant.

Sidst opdateret:

Server-side rendering (SSR) er en webarkitektur hvor serveren genererer komplet HTML og sender den til browseren ved hvert request — i modsætning til client-side rendering (CSR) der sender et tomt HTML-shell og overlader al gengivelse til JavaScript i browseren. For SEO er SSR afgørende fordi Googlebot ser fuldt indhold allerede i kildekoden uden at vente i rendering-køen: links, overskrifter, tekst og metadata er synlige ved første crawl, hvilket giver hurtigere indeksering og mere pålidelig rangering af sider med JavaScript-baserede frameworks.

Hvad er server-side rendering?

Server-side rendering (SSR) er den traditionelle og SEO-venligste arkitektur for webapplikationer: serveren genererer en komplet HTML-side og sender den til browseren som færdig markup. Brugere og søgemaskiner ser fuldt indhold allerede i den rå HTML-kildekode — ingen JavaScript-eksekvering kræves for at se indholdet.

Det er en kontrast til client-side rendering (CSR), hvor serveren sender en tom HTML-skabelon og overlader al rendering til browseren.

Hvad Googlebot ser ved SSR

Med SSR indeholder kildekoden alt indhold:

<!DOCTYPE html>
<html lang="da">
<head>
  <title>Produkt: Løbesko Model X</title>
  <meta name="description" content="Lette løbesko til...">
</head>
<body>
  <h1>Løbesko Model X</h1>
  <p>Disse lette løbesko er perfekte til...</p>
  <a href="/kategori/lobesko/">Se alle løbesko</a>
</body>
</html>

Googlebot crawler kildekoden og ser straks titlen, overskriften, brødteksten og links. Ingen rendering-kø. Ingen forsinkelse. Indholdet kan indekseres ved første crawl.

SEO-fordele ved SSR

Indhold synligt i kildekoden

Alt tekst, titler, beskrivelser og links er tilgængeligt i den rå HTML uden JavaScript-eksekvering. Googlebot behøver ikke vente på rendering-køen for at se sidens indhold.

Hurtigere indeksering

Nyt og opdateret indhold indekseres ved Googlebots første crawl — ikke dage eller uger senere, som det kan ske med client-side rendering.

Bedre First Contentful Paint

Browseren modtager HTML med indhold og kan begynde at vise siden straks, uden at vente på JavaScript-bundle-download og -eksekvering. Det giver en markant forbedring af FCP sammenlignet med CSR.

Selv hvis JavaScript-eksekvering fejler hos Googlebot, er basisindholdet stadig indekseret. Interne links er desuden synlige direkte i kildekoden, hvilket giver Googlebot umiddelbar adgang til at finde og crawle underliggende sider.

SSR vs Static Site Generation (SSG)

SSG er teknisk set endnu bedre end SSR for SEO:

SSRSSG
Hvornår genereres HTMLPer requestBuild-tid (forudberegnet)
TTFBLangsommere (serveren arbejder)Meget hurtig (statisk fil)
Dynamisk indholdJaBegrænset (kræver rebuild)
ServerbelastningHøj ved mange requestsMinimal
SEOFremragendeFremragende

For indhold der ikke ændres konstant — blogindlæg, produktbeskrivelser, landingssider — er SSG den optimale løsning. For ægte dynamisk indhold (brugerprofiler, realtidsdata) er SSR nødvendigt.

TTFB og SSR — afvejningen

SSR har én ulempe: Time to First Byte (TTFB) er typisk højere end ved SSG, fordi serveren skal generere HTML’en per request. Komplekse sider med mange database-forespørgsler kan have TTFB på 500-1000ms+.

Løsninger:

  • Caching af SSR-output (edge caching)
  • Database-optimering og forespørgsels-caching
  • CDN med SSR-support (Vercel, Cloudflare Workers, Netlify Edge)

Frameworks med SSR-support

Next.js og Nuxt

Next.js (React) er industristandarden for SSR: getServerSideProps håndterer SSR per request, mens getStaticProps bruges til SSG. Nuxt (Vue) har universal rendering som standard og understøtter både SSR og SSG — Nuxt 3 tilføjer Edge-side rendering.

Astro, SvelteKit og Remix

Astro er primært SSG, men understøtter SSR via adapters og er fremragende til indholdstunge sites. SvelteKit har SSR og SSG built-in og kompilerer til meget effektiv kode. Remix er et SSR-first framework med fokus på web standards og lav TTFB.

Hydration — koblingen mellem SSR og JavaScript

SSR løser indekserings-problemet, men JavaScript er stadig nødvendigt til interaktivitet. Processen der “vækker” et SSR-renderet dokument til live med JavaScript kallas hydration:

  1. Serveren sender færdig HTML (hurtig FCP)
  2. Browseren viser HTML straks
  3. JavaScript-bundle downloades og eksekveres
  4. Applikationen “hydrateres” — JavaScript overtager og aktiverer interaktivitet

Hydration har sin egen performance-udfordring: siden ser færdig ud, men interaktion er ikke mulig til hydration er komplet. Partial hydration og Islands-arkitektur (brugt af Astro) reducerer dette problem.

Ofte stillede spørgsmål

Er SSR altid bedre end CSR for SEO?

Ja for SEO-kritiske sider der skal ranke i Google. For applikationsdele bag login eller interaktioner der ikke indekseres, er CSR fuldt acceptabelt.

Hvad er forskellen på SSR og SSG?

SSR genererer HTML per request på serveren. SSG forudgenererer HTML ved build-tidspunktet og serverer statiske filer. SSG har lavere TTFB og er mere skalerbar, men kræver rebuild ved indholdsændringer.

Hvad er hydration?

Hydration er processen der tilføjer JavaScript-interaktivitet til en SSR-renderet HTML-side. Siden er synlig straks, men fuldt interaktiv først efter hydration.

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog. → Denne artikel er en del af JavaScript og rendering — Scripts, DOM og CSR vs SSR.

Del af: JavaScript og rendering — Scripts, DOM og CSR vs SSR →

Andre artikler i samme emne

Relaterede begreber

Emne JavaScript og rendering — Scripts, DOM og CSR vs SSR JavaScript er SEOs største rendering-udfordring — forstå CSR vs SSR, DOM, lazy loading og hvad Googlebot faktisk ser. Artikel Client-side rendering — CSR og SEO-udfordringer CSR genererer sidernes HTML i browseren — det er SEOs sværeste rendering-udfordring, da Googlebot skal vente på rendering. Artikel Rendering — Hvad Googlebot ser efter JavaScript-rendering Rendering er Googles oversættelse af kode til indhold — JavaScript-rendering sker i en separat kø og kan forsinke indeksering med dage. Artikel Backend — Server-side kode og SEO Backend er kode der kører på serveren — og server-hastighed, statuskoder og rendering-strategi påvirker SEO direkte. Emne Web Performance — Core Web Vitals og teknisk hastighed Web performance er en direkte SEO-rankingfaktor — Core Web Vitals, hastighed og responsivt design påvirker din placering. Hovedguide Kode — Webkode og teknisk SEO Komplet guide til webkode og teknisk SEO — fra HTML-struktur og metadata til crawling, structured data og Core Web Vitals.

Ofte stillede spørgsmål

Hvad er server-side rendering?
Server-side rendering (SSR) er en teknik hvor serveren eksekverer JavaScript-kode og genererer fuldt HTML-output der leveres direkte til browseren ved hvert request. Frem for at sende et næsten tomt HTML-shell (som ved client-side rendering) og lade browseren bygge siden via JavaScript, modtager browseren og Googlebot færdigt HTML med alt indhold synligt i kildekoden. Googlebots fordel er at indholdet er tilgængeligt allerede ved fase 1 af crawling — ingen afhængighed af rendering-kø.
Hvad er SEO-fordelen ved SSR frem for CSR?
Med SSR indekserer Google alt indhold øjeblikkeligt ved det initiale crawl — title-tag, H1, brødtekst og interne links er alle til stede i kildekoden. Ved client-side rendering (CSR) er kildekoden næsten tom og alt indhold kræver Googles rendering-pipeline med dages forsinkelse. SSR giver hurtigere indeksering af nyt og opdateret indhold, bedre First Contentful Paint og sikrer at metadata som canonical og hreflang er til stede ved crawl-tidspunktet.
Hvad er forskellen på SSR og statisk site generation?
SSR genererer HTML dynamisk på serveren ved hvert request — nyttigt til personaliseret eller hyppigt skiftende indhold. Statisk site generation (SSG) genererer HTML én gang på build-tidspunktet og serverer det som statiske filer. SSG er den hurtigste løsning for SEO og performance fordi der er ingen server-beregning per request — bare statiske filer der serveres direkte. Astro, Next.js og Gatsby understøtter begge strategier. For indhold der ikke ændrer sig hyppigt er SSG den anbefalede tilgang.
Hvad er hydration og har det SEO-konsekvenser?
Hydration er processen der tilføjer JavaScript-interaktivitet til en SSR-renderet HTML-side. Serveren sender færdig HTML — browseren viser indholdet straks (god FCP) — derefter downloades og eksekveres JavaScript-bundlen der 'vækker' applikationen. For SEO har hydration minimal konsekvens: Googlebot ser den færdige HTML fra serveren og indekserer straks. Problemet er Time to Interactive (TTI) for rigtige brugere: siden ser færdig ud men er ikke klikbar til hydration er komplet.
Hvornår er SSR det forkerte valg?
SSR er suboptimalt til statisk indhold der sjældent ændrer sig — blogindlæg, landingssider, ordbøger. Her er SSG bedre fordi det eliminerer server-beregning per request og giver lavere TTFB. SSR er overflødigt for applikationsdele bag login der ikke indekseres af Google. SSR er det rigtige valg til ægte dynamisk indhold: personaliserede sider, realtidsdata, brugergenereret indhold der ændrer sig konstant.

Placering i ordbogen

Kode — Webkode og teknisk SEO
JavaScript og rendering — Scripts, DOM og CSR vs SSR
Server-side rendering — SSR og fordele for SEO