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:

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 uden JavaScript-eksekvering.

Hurtigere indeksering: Nyt og opdateret indhold indekseres ved Googlebots første crawl — ikke dage eller uger senere.

Bedre First Contentful Paint (FCP): Browseren modtager HTML med indhold og kan begynde at vise siden straks, uden at vente på JavaScript-bundle-download og -eksekvering.

Robusthed: Selv hvis JavaScript-eksekvering fejler hos Googlebot, er basisindholdet stadig indekseret.

Links crawlable straks: Interne links er synlige i kildekoden, hvilket giver Googlebot direkte 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 (React): getServerSideProps til SSR per request, getStaticProps til SSG. Industristandard for React SSR.

Nuxt (Vue): Universal rendering som standard — SSR og SSG. Nuxt 3 understøtter Edge-side rendering.

Astro: Primært SSG, men med SSR-adapter til server-deployments. Fremragende til indholdstunge sites.

SvelteKit: SSR og SSG built-in. Kompilerer til meget effektiv kode.

Remix: SSR-first framework med fokus på web standards og hurtig 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.

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.

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.

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