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
- API — Hvad er API og hvad betyder det for SEO?
- Browser rendering pipeline — Fra HTML til pixels
- CSS containment — Isolér rendering og accelerér layout
- DOM — Document Object Model og JavaScript-rendering
- Google Tag Manager — Tag-håndtering og SEO-tracking
- Hydration — SSR og client-side JavaScript kombineret
- JavaScript — Hvad er JavaScript og hvad betyder det for SEO?
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- JavaScript og crawling — Hvad Googlebot ser og ikke ser
- JavaScript Rendering og SEO — Hvad Googlebot ser
- JavaScript SEO — Hvad Googlebot kan og ikke kan
- JavaScript-debugging til SEO — Find rendering-problemer
- JavaScript-rendering fejl — Når Googlebot ikke ser dit indhold
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Next.js og SEO — Server-side rendering og SEO
- Prerendering — Forhåndsrenderet HTML til crawlere
- React og SEO — JavaScript-rendering og søgesynlighed
- Rendering — Hvad Googlebot ser efter JavaScript-rendering
- Scripts og SEO — render-blocking, async og defer
- Server-side rendering — SSR og fordele for SEO
- Service Workers — Offline caching og PWA performance
- Static site generation — SSG og SEO-fordele ved statiske sider
- Web Components og SEO — Custom elements og søgesynlighed
- Web Workers — Parallel JavaScript uden main thread-blokning
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
- API — Hvad er API og hvad betyder det for SEO?
- Browser rendering pipeline — Fra HTML til pixels
- CSS containment — Isolér rendering og accelerér layout
- DOM — Document Object Model og JavaScript-rendering
- Google Tag Manager — Tag-håndtering og SEO-tracking
- Hydration — SSR og client-side JavaScript kombineret
- JavaScript — Hvad er JavaScript og hvad betyder det for SEO?
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- JavaScript og crawling — Hvad Googlebot ser og ikke ser
- JavaScript Rendering og SEO — Hvad Googlebot ser
- JavaScript SEO — Hvad Googlebot kan og ikke kan
- JavaScript-debugging til SEO — Find rendering-problemer
- JavaScript-rendering fejl — Når Googlebot ikke ser dit indhold
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Next.js og SEO — Server-side rendering og SEO
- Prerendering — Forhåndsrenderet HTML til crawlere
- React og SEO — JavaScript-rendering og søgesynlighed
- Rendering — Hvad Googlebot ser efter JavaScript-rendering
- Scripts og SEO — render-blocking, async og defer
- Server-side rendering — SSR og fordele for SEO
- Service Workers — Offline caching og PWA performance
- Static site generation — SSG og SEO-fordele ved statiske sider
- Web Components og SEO — Custom elements og søgesynlighed
- Web Workers — Parallel JavaScript uden main thread-blokning