Artikel

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.

Rendering er processen hvor HTML, CSS og JavaScript kombineres til en færdig webside. For SEO er rendering afgørende fordi den bestemmer hvad Googlebot faktisk ser — og dermed hvad der kan indekseres. Valget mellem client-side rendering (CSR), server-side rendering (SSR) og static site generation (SSG) har direkte konsekvenser for indekseringshastighed, crawl budget og synlighed i søgeresultater.

To rendering-modeller

Moderne websites følger enten client-side eller server-side rendering. Valget har direkte konsekvenser for indeksering.

Client-side rendering (CSR) er standardtilgangen i JavaScript-frameworks som React, Vue og Angular i SPA-konfiguration. Serveren sender et minimalt HTML-skelet — typisk kun en tom <div id="app"> — og JavaScript bygger siden i brugerens browser.

Googlebot modtager dette tomme skelet. For at se indholdet skal det rendere JavaScript-bundlet i et separat trin. Det sker i en render-kø der kan tage dage til uger. I perioden imellem kan siden fremstå som tom for Google.

Server-side rendering (SSR) genererer den komplette HTML på serveren inden den sendes til browseren. Googlebot modtager fuldt indhold ved første crawl og behøver ikke bruge rendering-kapacitet.

Moderne frameworks understøtter SSR: Next.js (React), Nuxt.js (Vue), SvelteKit. Astro — som stegger.dk er bygget med — genererer statisk HTML på byggetidspunktet, hvilket er den hurtigste og mest SEO-venlige tilgang.

Googlebots rendering-process

Googlebot er baseret på Chromium og kan i princippet rendere moderne JavaScript. Processen foregår i to faser:

Fase 1 — Crawl: Googlebot henter siden og parser den rå HTML. Links og metadata er tilgængelige her.

Fase 2 — Rendering: Siden placeres i en render-kø og behandles af Googles Web Rendering Service (WRS). JavaScript eksekveres, DOM bygges, og det endelige indhold indekseres.

Forsinkelsen mellem fase 1 og fase 2 er det primære problem. Kritisk indhold — titler, brødtekst, interne links — bør ikke udelukkende eksistere i JavaScript-renderet form.

Hvad der går galt med CSR

JavaScript-rendering fejler ikke kun ved tomme sider. Typiske problemer:

JavaScript-fejl: En enkelt runtime-fejl kan forhindre siden i at rendere. Googlebot stopper ved fejl og indekserer det ufuldstændige indhold.

Timeout: Googles rendering har en tidsbegrænsning. Sider der er for tunge eller bruger API-kald med lang responstid kan timeout inden indholdet er klar.

API-afhængigheder: Indhold der hentes fra eksternt API via fetch() kan mangle ved rendering, hvis API-kaldet ikke gennemføres inden timeout.

Hydration-mismatch: Frameworks der bruger SSR med hydration kan producere mismatch mellem server-genereret HTML og client-genereret DOM — Google kan se et andet indhold end brugeren.

Dynamic rendering

Dynamic rendering er en workaround der leverer pre-renderet HTML til crawlere og normal JavaScript til brugere — baseret på User-Agent-detektion.

Implementering kræver typisk en proxy (Rendertron, Prerender.io) der detekterer Googlebot og serverer en statisk kopi. Google betragter dynamic rendering som en acceptabel men midlertidig løsning.

Advarslen: dynamic rendering kan udgøre cloaking hvis den leverede HTML afviger meningsfuldt fra det brugere ser.

Verifikation

Brug Google Search Consoles URL Inspection Tool til at se hvad Googlebot faktisk renderer. Sammenlign skærmbilledet med den faktiske side. Tjek om kritisk indhold — primær tekst, H1, interne links — er synligt i inspektionens renderede HTML.

Sammenlign også den rå kildetekst (Ctrl+U) med browser-DOM i Inspector-panelet. Forskellen er det JavaScript-genererede indhold der kræver rendering.

Relaterede artikler


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

Andre artikler i samme emne

Ofte stillede spørgsmål

Hvad er forskellen på client-side og server-side rendering?
Client-side rendering (CSR) sender et tomt HTML-skelet til browseren og bygger indholdet via JavaScript i browseren. Server-side rendering (SSR) genererer den komplette HTML på serveren inden afsendelse. For SEO er SSR og statisk generering bedre: Googlebot modtager fuldt indhold i første crawl uden at vente på JavaScript-eksekvering.
Kan Googlebot køre JavaScript?
Ja — Googlebot bruger et Chromium-baseret headless browser til at rendere JavaScript. Men det er en totrins-process: crawling sker i et første pass, rendering sker i en separat kø der kan forsinke indeksering med dage til uger. Indhold der kun eksisterer efter JavaScript-rendering kan indekseres langsommere eller inkonsistent.
Hvad er dynamic rendering, og hvornår giver det mening?
Dynamic rendering er en server-side teknik der leverer pre-renderet HTML til crawlere (Googlebot) og normal JavaScript til brugere. Det er en midlertidig løsning til sites der ikke kan skifte til SSR. Google betragter det som en acceptabel workaround men ikke en langsigtet løsning. SSR eller statisk generering er foretrukket.
Hvad er totrins-crawling og hvad er konsekvensen for indeksering?
Googles crawler processerer JavaScript-sider i to faser: fase 1 er HTML-download (hurtig), fase 2 er JavaScript-rendering i en separat kø (kan tage dage til uger). Indhold der udelukkende eksisterer i JavaScript — tekst, links, structured data — indekseres først i fase 2. Det betyder at nyt og opdateret JavaScript-genereret indhold kan ranke langsommere end HTML-baseret indhold.
Hvad er forskellen på SSG og SSR set fra Googlebots perspektiv?
Fra Googlebots crawling-perspektiv er SSG og SSR i praksis identiske: begge leverer fuldt HTML ved første crawl og kræver ingen rendering-kø. TTFB er typisk lavere for SSG (statisk fil fra CDN) end SSR (server genererer HTML per request). Begge er langt bedre end CSR for indeksering.

Placering i ordbogen