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.

Sidst opdateret:

JavaScript og rendering — Scripts, DOM og CSR vs SSR

JavaScript er det tredje og mest komplekse lag i webkode set fra et SEO-perspektiv. Mens HTML og CSS er relativt transparente for Googlebot, introducerer JavaScript et lag af uforudsigelighed: indhold eksisterer ikke nødvendigvis i den originale HTML-fil, men genereres dynamisk i brugerens browser. At forstå JavaScript og rendering er uundværligt for enhver, der arbejder med moderne webudvikling og SEO.

Hvad er JavaScript i web-sammenhæng?

JavaScript er et programmeringssprog, der kører i browseren (og på servere via Node.js). Det er det eneste programmeringssprog, alle browsere understøtter nativt.

På web-fronten bruges JavaScript til:

  • Dynamisk opdatering af indhold uden sideopdatering
  • Formularhåndtering og validering
  • Animationer og interaktive UI-elementer
  • Hentning af data fra API’er
  • Single Page Applications (SPAs) og komplekse webapps

JavaScript-filer indlæses via <script>-tags i HTML:

<script src="/js/app.js" defer></script>

Attributterne async og defer styrer, hvornår scriptet downloades og udføres i forhold til HTML-parsingen:

  • defer: Scriptet downloades parallelt men udføres, efter HTML er parset
  • async: Scriptet downloades parallelt og udføres så snart det er klar — HTML-parsing pauses
  • Ingen attribut: Scriptet blokkerer HTML-parsing — undgå dette for kritiske sider

DOM — Document Object Model

DOM (Document Object Model) er den træstruktur, browseren bygger ud fra HTML-koden og efterfølgende manipulerer via JavaScript. DOM er det “levende” dokument, browseren renderer — ikke den statiske HTML-fil på serveren.

Forskellen er afgørende for SEO: Googlebot ser både den originale HTML og (efter rendering) det JavaScript-genererede DOM. Men processen er ikke identisk med en brugers browseroplevelse, og der er forsinkelse i rendering-trinnet.

Hvis din sides primære indhold — tekst, links, overskrifter — kun eksisterer i DOM’en efter JavaScript-eksekvering, og ikke i den originale HTML, er det afhængigt af Googles rendering-kapacitet, om det indekseres korrekt.

Client-side rendering (CSR)

Client-side rendering er den tilgang, der bruges af JavaScript-frameworks som React, Vue og Angular i SPA-konfiguration. Her er den originale HTML-fil minimal:

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

Alt det faktiske indhold genereres af JavaScript i browseren. Googlebot modtager denne tomme HTML, og for at se indholdet skal den rendere JavaScript-bundlet.

SEO-udfordringer med CSR:

  • Rendering forsinker indekseringen — indhold ses muligvis ikke ved første crawl
  • Rendering-kapacitet kan begrænse, hvor mange sider der renderes hurtigt
  • Fejl i JavaScript kan betyde, at sider aldrig renderes korrekt
  • Indlæsningsperformance lider — stort JavaScript-bundle skal downloades og udføres før indhold vises (høj LCP)

CSR er ikke nødvendigvis SEO-dræbende, men kræver ekstra teknisk opmærksomhed og løbende verifikation i Google Search Console.

Server-side rendering (SSR)

Server-side rendering er den traditionelle tilgang, der også er den mest SEO-venlige. Serveren genererer den komplette HTML — inklusive alt indhold — og sender den til browseren.

Med SSR ser Googlebot den fulde side i første crawl-request, uden brug af rendering-kapacitet. Indeksering kan ske umiddelbart.

Moderne JavaScript-frameworks understøtter SSR: Next.js (React), Nuxt.js (Vue), SvelteKit og lignende. Disse frameworks genererer HTML på serveren ved første request og hydrerer derefter til en interaktiv SPA på klienten.

Fordele ved SSR for SEO:

  • Fuldt indhold tilgængeligt for Googlebot i HTML
  • Hurtigere indeksering
  • Bedre TTFB og LCP end ren CSR
  • Ingen afhængighed af Googles rendering-kapacitet

Static Site Generation (SSG) og pre-rendering

Static Site Generation (SSG) er en variant, hvor alle sider pre-renderes til statisk HTML på byggetidspunktet. Dette er den hurtigste og mest SEO-venlige tilgang for sider, hvis indhold ikke ændres ved hver request.

Eksempler på SSG-frameworks: Astro, Gatsby, Eleventy, Hugo. Stegger.dk selv er bygget med Astro og genererer statisk HTML.

Pre-rendering er en bredere term, der dækker alle tilgange, der genererer HTML på forhånd. Dynamic Rendering er en specifik teknik, hvor serveren leverer pre-renderet HTML til crawlere og normalt JavaScript til brugere.

Lazy loading

Lazy loading er en teknik, der udsætter indlæsning af ressourcer — primært billeder og iframes — til de faktisk er synlige i viewport (brugerens skærm). Det forbedrer den initiale indlæsningstid markant på sider med mange billeder.

HTML5 har native lazy loading:

<img src="billede.jpg" alt="Beskrivelse" loading="lazy">

For SEO er der en vigtig nuance: billeder med loading="lazy" kan ikke indekseres i Googlebots viewport, hvis Googlebot ikke scroller siden. Google understøtter lazy loading, men det er en god praksis at sikre, at kritiske billeder — hero-billeder, primære illustrationer — ikke har lazy loading.

JavaScript-baseret lazy loading af tekstindhold er derimod problematisk: indhold, der først vises efter brugerinteraktion eller scroll, kan have sværere ved at blive indekseret.

API-kald og dynamisk indhold

Mange moderne sider henter indhold fra API’er via JavaScript (typisk via fetch() eller XMLHttpRequest). Produktlister, prisinformation, brugeranmeldelser — alt dette hentes ofte dynamisk.

Googlebot kan i princippet udføre disse API-kald og indeksere det returnerede indhold — men det er afhængigt af:

  • Om API’et er tilgængeligt for Googlebot (ingen autentificering der blokerer)
  • Timing — API-data indlæses muligvis efter Googlebots rendering timeout
  • Indeksering af dynamisk prisinformation og lagerstatus er generelt upålideligt

Kritisk indhold — den primære tekst, titler, beskrivelser — bør aldrig udelukkende hentes via klient-side API-kald.

Verifikation af JavaScript-rendering

Det er ikke tilstrækkeligt at antage, at Googlebot ser din side korrekt. Aktive verifikationsmetoder:

Google Search Console URL Inspection Tool: Viser, hvad Googlebot faktisk ser og renderer — inklusiv et skærmskud af den renderede side. Afgørende ved fejlfinding af rendering-problemer.

Brug af ?_escaped_fragment_ eller Fetch as Google: Afsluttede metoder, men URL Inspection Tool dækker det samme behov.

Sammenligning af statisk HTML og renderet DOM: Åbn kildeteksten (Ctrl+U) og sammenlign med Inspect-panelet i browseren. Forskellen er det JavaScript-genererede indhold — det, Googlebot skal rendere.

Relaterede artikler

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog.

Del af: Kode — Webkode og teknisk SEO →

Artikler i dette emne

Relaterede begreber

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. Artikel Scripts og SEO — Render-blocking JavaScript og performance Scripts i HTML head blokerer rendering — async og defer attributes løser problemet og forbedrer Core Web Vitals. 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 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 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 API — Hvad er API og hvad betyder det for SEO? API er grænsefladen der lader software kommunikere — men indhold hentet via API i JavaScript kræver rendering for at Googlebot ser det. Emne Crawling og indeksering — Sådan læser Google din kode Crawling og indeksering er forudsætningen for at ranke — forstå Googlebot, robots.txt, sitemaps og rendering. 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. 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 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.

Placering i ordbogen

Kode — Webkode og teknisk SEO
JavaScript og rendering — Scripts, DOM og CSR vs SSR