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.

Sidst opdateret:

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. Ser en tom <div id="root">. Registrerer ingen meningsfuldt indhold. 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.

Forsinkelsen 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.

Tom kildekode skader crawlbudget: Googlebot finder ingen links i kildekoden og kan ikke crawle sig videre til underliggende sider effektivt.

Lang TTFB gavner ikke: Selv med hurtig server er siden tom indtil JS-bundle er downloadet og kørt. LCP forsinkes.

JavaScript-fejl skjuler alt indhold: En enkelt JavaScript-fejl kan betyde at hele siden er blank for Googlebot.

Metadata håndteres af JavaScript: Title-tag og meta description genereres af JavaScript, hvilket øger risiko for fejl og forsinkelse.

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.

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 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. 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 DOM — Document Object Model og JavaScript-rendering DOM er browserens live-version af siden — JavaScript ændrer DOM dynamisk, og det er Googlebots endelige analyse-objekt efter rendering. Artikel JavaScript — Hvad er JavaScript og hvad betyder det for SEO? JavaScript tilføjer interaktivitet — men JS-tunge sider kræver rendering, og det er SEOs største tekniske udfordring. 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
Client-side rendering — CSR og SEO-udfordringer