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.
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 parsetasync: 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.
CSR-tilgangen introducerer fire SEO-udfordringer: rendering forsinker indekseringen, så 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. Og indlæsningsperformance lider — et stort JavaScript-bundle skal downloades og udføres, før indhold vises, hvilket giver 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.
SSR har fire konkrete fordele for SEO: fuldt indhold er tilgængeligt for Googlebot direkte i HTML, indeksering sker hurtigere, TTFB og LCP er bedre end ved ren CSR, og der er 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.
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. Metoder som ?_escaped_fragment_ og Fetch as Google er afsluttede, men URL Inspection Tool dækker det samme behov.
Artikler i dette emne
- API og SEO
- Client-side rendering
- DOM
- Google Tag Manager
- Hydration
- JavaScript-debugging til SEO
- JavaScript grundlæggende
- JavaScript og crawling
- JavaScript SEO
- Next.js og SEO
- Prerendering
- React og SEO
- Rendering og SEO
- JavaScript Rendering
- Scripts og SEO
- Server-side rendering
- Static site generation
- Web Components og SEO
Relaterede artikler
- Kode og teknisk SEO — den komplette guide
- Crawling og indeksering
- Web Performance — Core Web Vitals
- Grundlæggende webkode — HTML, CSS og JavaScript
Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog.
Artikler i dette emne
- 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.
- Browser rendering pipeline — Fra HTML til pixels Browser rendering pipeline: HTML → DOM, CSS → CSSOM, DOM + CSSOM → Render tree → Layout → Paint → Composite. Hvert trin har performance-implikationer. At kende pipelinen er fundamentet for performance-optimering.
- 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.
- CSS containment — Isolér rendering og accelerér layout CSS containment via contain og content-visibility isolerer rendering-scope. content-visibility: auto er den nemmeste quick win — browseren skipper rendering af off-screen indhold til det er nødvendigt.
- 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.
- Google Tag Manager — Tag-håndtering og SEO-tracking Google Tag Manager er en container der samler alle tracking-scripts ét sted og lader marketing og analyse-teams installere og opdatere tags uden udviklerbehov — men kræver korrekt opsætning for ikke at skade performance.
- Hydration — SSR og client-side JavaScript kombineret Hydration er JSs overtagelse af en SSR-renderet side. Det giver interaktivitet uden at ofre SEO — men kan forårsage INP-problemer og TBT ved tung JavaScript-indlæsning.
- 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.
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse JavaScript er dyrt: download, parse, kompilering og eksekvering. Code splitting sender kun den nødvendige kode til brugeren. Tree shaking fjerner ubrugt kode. Bundle-analyse afslører hvad der fylder.
- JavaScript og crawling — Hvad Googlebot ser og ikke ser Googlebot renderer JavaScript, men rendering sker i en separat wave og med forsinkelse. Indhold der kun eksisterer i JavaScript kan indekseres — men er det garanteret.
- JavaScript Rendering og SEO — Hvad Googlebot ser JavaScript rendering afgør om Googlebot ser dit indhold. Client-side rendering kræver at Google eksekverer din JavaScript — det sker med forsinkelse. Server-side rendering og static generation løser problemet.
- JavaScript SEO — Hvad Googlebot kan og ikke kan JavaScript SEO handler om at sikre at Googlebot kan se og forstå dit JavaScript-genererede indhold. CSR-frameworks, SPA'er og JavaScript-tunge sites kræver særlig opmærksomhed.
- JavaScript-debugging til SEO — Find rendering-problemer JavaScript-SEO-debugging kræver specialiserede værktøjer: GSC's URL-inspektion, Screaming Frog med JavaScript-rendering og Googles Rich Results Test er udgangspunktet.
- JavaScript-rendering fejl — Når Googlebot ikke ser dit indhold JavaScript-rendering fejl er den hyppigste årsag til at Googlebot ikke ser sider korrekt — indhold der kun vises efter JS-execution, failed hydration eller timeout-problemer under rendering.
- Kritisk renderingsti — Hvad browseren gør før du ser noget Den kritiske renderingsti er trin-for-trin-processen browseren følger fra HTML-download til første synlige pixel. Render-blocking ressourcer forlænger stien og forsinker LCP.
- Next.js og SEO — Server-side rendering og SEO Next.js er den primære React-løsning for SEO-venlig rendering — med App Router, Metadata API og hybrid SSR/SSG i samme projekt. Det eliminerer de fleste JavaScript-SEO-problemer.
- Prerendering — Forhåndsrenderet HTML til crawlere Prerendering genererer HTML-snapshots af JavaScript-sider til crawlere. Det er en løsning til eksisterende SPA-sites der ikke kan migreres til SSR eller SSG.
- React og SEO — JavaScript-rendering og søgesynlighed Ren React (Create React App) er client-side rendered og problematisk for SEO. Løsningen er Next.js (SSR/SSG), Astro (static-first) eller prerendering for eksisterende React-sites.
- 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.
- Scripts og SEO — render-blocking, async og defer Render-blocking scripts forsinker sidens indlæsning og påvirker både Core Web Vitals og Googlebots evne til at crawle siden effektivt.
- 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.
- Service Workers — Offline caching og PWA performance Service Workers intercepter netværkskald og cacher ressourcer lokalt. Returnerende brugere oplever øjeblikkelig indlæsning — TTFB og LCP reduceres til nul for cachede sider.
- Static site generation — SSG og SEO-fordele ved statiske sider SSG genererer færdige HTML-filer ved build-time — der er ingen server-side rendering ved hvert request, hvilket giver lavest mulig TTFB og optimal crawlbarhed.
- Web Components og SEO — Custom elements og søgesynlighed Web Components er native browser-komponenter med Shadow DOM. Google renderer Web Components men med begrænsninger — primært fordi Shadow DOM-indhold kan være utilgængeligt for crawlere.
- Web Workers — Parallel JavaScript uden main thread-blokning Web Workers kører JavaScript i en baggrundstråd. Main thread forbliver fri til brugerinteraktion — INP forbedres. Workers kan ikke tilgå DOM men kommunikerer via postMessage.
Ofte stillede spørgsmål
- Hvad er forskellen på CSR og SSR?
- CSR (Client-Side Rendering) genererer HTML i browseren via JavaScript — serveren sender et tomt HTML-skelet, JavaScript bygger indholdet. SSR (Server-Side Rendering) genererer komplet HTML på serveren inden afsendelse. For SEO er SSR og statisk generering bedre: Googlebot modtager indholdet direkte uden at vente på JavaScript-rendering.
- Kan Googlebot indeksere JavaScript-indhold?
- Ja, Googlebot kan rendere JavaScript, men det er en totrins-process: crawling sker først, rendering sker i en separat kø der kan forsinke indeksering med dage til uger. Indhold der kun eksisterer i JavaScript-renderet form risikerer at blive indekseret langsommere eller inkonsistent. Server-side rendering eliminerer dette problem.
- Hvad er lazy loading og hvad betyder det for SEO?
- Lazy loading udsætter indlæsning af billeder og iframes til de faktisk er synlige i viewport. Google understøtter native lazy loading, men kritiske billeder — hero-billeder, primære illustrationer — bør ikke have lazy loading. JavaScript-baseret lazy loading af tekstindhold er problematisk for indeksering.
- Kan Googlebot eksekvere JavaScript?
- Ja — Googlebot kan eksekvere JavaScript, men med forsinkelse. Rendering af JavaScript-indhold sker i en second wave of indexing der kan tage dage til uger efter crawling. Kritisk indhold (tekst, links, structured data) bør ikke afhænge alene af JavaScript-rendering — brug SSR eller statisk generering for SEO-kritiske elementer.
- Hvad er lazy loading, og hvad er SEO-implikationen?
- Lazy loading er en teknik der udskyder indlæsning af billeder og indhold til det kommer i viewport — det forbedrer initial load-tid. For SEO er implikationen vigtig: billeder og indhold der lazy-loades skal stadig være tilgængeligt for Googlebot. Brug native lazy loading (loading='lazy') fremfor JavaScript-baserede løsninger, og undgå lazy loading af above-the-fold indhold.
Placering i ordbogen
- Crawling og indeksering — Sådan læser Google din kode
- HTML-struktur — Tags, elementer og semantik
- Indholdselementer i kode — Links, billeder og formularer
- Metadata og tekniske signaler — Meta tags, canonical og hreflang
- Server og HTTP-responser — Statuskoder, redirects og caching
- Structured data — Schema markup og JSON-LD
- Web Performance — Core Web Vitals og teknisk hastighed