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.

Client-side rendering genererer al sideindhold i brugerens browser via JavaScript, i stedet for at levere færdig HTML fra serveren. Det er standardarkitekturen i React-, Vue- og Angular-baserede Single Page Applications. For SEO er CSR den mest problematiske rendering-strategi: kildekoden er næsten tom, alt indhold kræver Googlebots JavaScript-rendering i fase 2, og rendering kan forsinkes med dage. Forstår man præcis hvorfor CSR er problematisk, er løsningen åbenlys: flytte rendering til serveren.

Hvad er client-side rendering?

Client-side rendering (CSR) er en arkitektur hvor HTML ikke genereres på serveren — i stedet sender serveren et minimalt HTML-dokument med et JavaScript-bundle, og det er JavaScript’et der kører i browseren og genererer alt sidens indhold ved at manipulere DOM’en.

Det er den arkitektur React, Vue og Angular typisk bruges til i såkaldte Single Page Applications (SPA).

Hvad serveren sender ved CSR

Et klassisk CSR-svar ser sådan ud:

<!DOCTYPE html>
<html>
<head>
  <title>Min App</title>
</head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>

Kildekoden er tom. Alt indhold — produktbeskrivelser, overskrifter, links — genereres af bundle.js i brugerens browser. Før JavaScript er indlæst og kørt, er siden visuel tom.

SPA-arkitektur

En Single Page Application henter kun én HTML-side fra serveren. Efterfølgende navigation håndteres af JavaScript — komponenter erstattes i DOM’en uden at hente en ny HTML-side. URL’en opdateres via History API.

For brugere kan SPA-oplevelsen føles hurtig og app-lignende efter den initiale indlæsning. Men den initiale indlæsning kan være langsom, og det er hér SEO-udfordringerne opstår.

CSR og Googlebots to-fase crawl

Googlebots crawl af CSR-sider foregår i to trin:

Fase 1 — HTML-crawl

Googlebot henter kildekoden og ser en tom <div id="root">. Der er intet meningsfuldt indhold at registrere og ingen links at følge til andre sider.

Fase 2 — Rendering

Googlebot placerer siden i sin rendering-kø og kører JavaScript. Først nu ses det faktiske indhold og links. Denne rendering kan ske dage til uger efter det første crawl, hvilket betyder at nyt og opdateret indhold i CSR-applikationer kan tage lang tid at nå Googles indeks.

SEO-problemer ved CSR

Indhold ikke i kildekoden

Alle produkttitler, beskrivelser og brødtekst er usynlige for crawlere der ikke renderer JavaScript. Googlebots første crawl ser en tom side, og indhold når først indekset efter rendering-fasen.

Tom kildekode skader crawlbudget

Googlebot finder ingen links i kildekoden og kan ikke crawle sig videre til underliggende sider effektivt. En SPA med hundredvis af sider kan fremstå som én tom side ved det første crawl.

LCP forsinkes

Selv med hurtig serverrespons er siden tom indtil JS-bundle er downloadet, parset og kørt. Largest Contentful Paint forsinkes systematisk, og Core Web Vitals lider under det.

JavaScript-fejl skjuler alt indhold

En enkelt JavaScript-fejl kan betyde at hele siden er blank for Googlebot. I modsætning til SSR, hvor en fejl typisk blot viser delvist indhold, kan en CSR-fejl gøre en side fuldstændig indholdsløs.

Metadata håndteres af JavaScript

Title-tag og meta description genereres af JavaScript, hvilket øger risikoen for fejl og forsinkelse. Mangler JavaScript at køre korrekt, kan Google se sider med generisk eller tom titel.

Løsninger til CSR og SEO

Server-side rendering (SSR)

Serveren renderer HTML-siden fuldt ud og sender færdig HTML. Se server-side rendering.

Static Site Generation (SSG)

Sider præ-renders til statiske HTML-filer på build-tidspunktet. Hurtigste løsning for indhold der ikke ændres konstant.

Pre-rendering / Dynamic rendering

En headless browser renderer siden og gemmer resultatet som statisk HTML, der serveres til søgemaskiner. Teknisk kompleks og betragtes af Google som en workaround.

Hybrid rendering

Frameworks som Next.js (React), Nuxt (Vue) og Astro tilbyder per-side valg af rendering-strategi: SSR, SSG eller CSR. Kritiske sider kan SSR/SSG, mens applikationsdele kan forblive CSR.

Googles holdning til CSR

Google kan indexere JavaScript-renderet indhold, men erkender selv forsinkelsen. For SEO-kritiske sider — forsider, produktsider, kategorisider — anbefales SSR eller SSG konsekvent frem for CSR. Google har aldrig officielt anbefalet CSR som SEO-strategi.


Kan Google indexere React og Vue-sider? Ja, men med forsinkelse og risiko for fejl. Google renderer JavaScript, men det er langsommere og mere upålideligt end statisk HTML. SSR eller SSG er stærkere løsninger til SEO-kritiske sider.

Hvad er en SPA? SPA (Single Page Application) er en applikation der indlæser én HTML-side og navigerer dynamisk via JavaScript uden at hente nye HTML-sider fra serveren.

Er CSR altid dårligt for SEO? CSR er problematisk for SEO-kritiske sider. For indhold bag login eller i applikationsflader der ikke skal ranke, er CSR fuldt acceptabelt.

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.

Andre artikler i samme emne

Ofte stillede spørgsmål

Hvad er client-side rendering?
Client-side rendering (CSR) er en rendering-strategi hvor serveren leverer et næsten tomt HTML-shell — typisk blot <div id=root></div> — og alt sideindhold genereres af JavaScript der kører i brugerens browser. Frameworks som React, Vue og Angular bruger CSR som standard. Brugeren ser en blank side mens JavaScript downloader og eksekverer, derefter bygges al indhold i browser-DOM'en. Det giver hurtig interaktivitet efter første load, men kræver at Googlebot renderer JavaScript for at se indholdet.
Hvad er SEO-problemerne med client-side rendering?
CSR er den mest udfordrende rendering-strategi for SEO. Kildekoden er næsten tom ved fase 1 af Googlebots crawl — al indhold kræver rendering i fase 2, der typisk sker dage til uger senere. Metadata som title-tag og canonical kan mangle helt ved det initiale crawl. Interne links genereret af JavaScript opdages ikke straks af crawleren. Indhold der er afhængigt af rendering kan forblive unindekseret i lang tid. Jo mere kritisk et stykke indhold er for SEO, jo mere problematisk er det at have det i CSR.
Hvad er løsningerne på SEO-problemer med CSR?
Den primære løsning er at migrere til server-side rendering (SSR) eller statisk site generation (SSG) via frameworks som Next.js, Nuxt eller Astro. For eksisterende CSR-sites kan dynamic rendering være en midlertidig løsning: servering af server-renderet HTML specifikt til crawlere via reverse proxy. Kritisk indhold — title-tag, H1, canonical og interne links — bør altid inkluderes i server-leveret HTML. Brug Google Search Console's URL Inspection Tool til at verificere hvad Google faktisk ser efter rendering.
Hvad er en SPA og er SPA altid dårligt for SEO?
SPA — Single Page Application — er en applikation der indlæser én HTML-side og navigerer dynamisk via JavaScript uden at hente nye HTML-sider fra serveren. SPA er ikke automatisk dårligt for SEO, men CSR-SPA'er er det. Løsningen er hybrid rendering: frameworks som Next.js og Nuxt lader dig vælge rendering-strategi per side, så offentlige sider kan SSR/SSG, mens applikationsdele bag login kan forblive CSR.
Hvad er dynamic rendering og anbefaler Google det?
Dynamic rendering er en teknik hvor serveren detekterer om en forespørgsel kommer fra en bot eller en rigtig bruger, og serverer pre-renderet HTML til bots men client-side JavaScript til rigtige brugere. Google har officielt anerkendt dynamic rendering som en workaround men anbefaler det ikke som en langsigtet løsning — de betragter det som en midlertidig afhjælpning og foretrækker SSR eller SSG som permanent arkitektur.

Placering i ordbogen