Der er en udbredt misforståelse i branchen: “Google kan godt læse JavaScript, så det er ikke et problem.”

Det er en halv sandhed. Og den halve sandhed koster organisk trafik for mange sites.

Google kan godt render JavaScript. Men det er langsomt, dyrt og sker med forsinkelse. I mellemtiden er dit indhold ikke i indekset. Og for JavaScript-tunge sites kan den forsinkelse strække sig fra timer til uger.

Her er, hvornår det er et reelt problem — og hvad du konkret gør ved det.

Googles Web Rendering Service: Sådan fungerer det

Googles crawler, Googlebot, fungerer ikke som en browser. Den henter din HTML, CSS og JavaScript — men rendering sker i et separat system kaldet Web Rendering Service (WRS).

Processen ser sådan ud:

1. Crawl: Googlebot henter din sides HTML og ressourcer og placerer dem i en crawl-kø. Dette sker relativt hurtigt.
2. Render queue: Den crawlede side lægges i en render-kø. Her venter den på, at WRS behandler den. Denne kø kan tage timer — eller dage — afhængigt af din sides prioritet og serverens kapacitet.
3. Rendering: WRS renderer siden i en headless Chrome-instans og genererer det endelige DOM. Først nu er dit JavaScript-indhold synligt for Google.
4. Indeksering: Det renderede indhold sendes til indeksering.

Det kritiske problem: Indhold, der kun eksisterer i det renderede DOM — dvs. indhold injiceret af JavaScript — er usynligt for Google, indtil rendering er afsluttet. Og du har ingen garanti for, hvornår det sker.

For sites, der opdaterer indhold hyppigt, eller for nye sider der skal indekseres hurtigt, er det en reel begrænsning.

Hvornår JS-rendering er et konkret SEO-problem

Ikke alle JavaScript-sider er et problem. Her er de situationer, der faktisk påvirker din synlighed:

Single Page Applications (SPAs). En klassisk React- eller Vue-SPA leverer typisk en næsten tom HTML-fil, og alt indhold injectes via JavaScript. Det er client-side rendering i sin reneste form. Googlebot ser den tomme HTML ved crawl — og render-køen afgør, hvornår (hvis nogensinde) det fulde indhold indekseres.

Lazy-loaded indhold. Indhold der loader ved scroll, ved klik, eller efter en bruger-interaktion er problematisk. WRS simulerer ikke brugeradfærd. Hvad Googlebot ikke kan “se” uden at scrolle eller klikke, indekseres typisk ikke.

Dynamiske interne links. Hvis din navigationsmenu eller dine interne links genereres af JavaScript, kan crawling af dit site stoppe her. Googlebot følger ikke links, der kun eksisterer i det renderede DOM, med samme pålidelighed som statiske HTML-links. Det skader din interne linkstruktur og fordeling af PageRank.

JavaScript-fejl. En enkelt JavaScript-fejl kan forhindre WRS i at render siden korrekt. Det sker stille og roligt — ingen 500-fejl, ingen åbenbar signal — men dit indhold forsvinder fra indekset.

Tunge third-party scripts. Tunge analytics-, chat- og annoncescripts øger render-tid. Jo længere tid rendering tager, jo højere er risikoen for timeout i WRS.

CSR, SSR og SSG: Hvad er bedst for SEO?

De tre tilgange har fundamentalt forskellige SEO-implikationer.

Client-Side Rendering (CSR)

Client-side rendering sender en tom eller minimal HTML til browseren og overlader al rendering til JavaScript i browseren. Det er den tilgang, der brugte Next.js Pages Router med getInitialProps på client-side, og den der stadig er standard i Create React App-projekter.

SEO-implikationen: Alt indhold afhænger af render-køen. Uacceptabelt for sider, der skal ranke.

Server-Side Rendering (SSR)

Server-side rendering genererer HTML på serveren ved hvert request. Browseren modtager fuldt renderet HTML — og det samme gør Googlebot.

SEO-implikationen: Indhold er synligt ved crawl. Ingen afhængighed af WRS. Det er den sikre løsning for dynamisk indhold (brugerspecifikke sider, søgeresultater, produktlister med lagerfiltrering).

Ulempen: Serveren er i den kritiske vej. En langsom server giver langsom TTFB (Time to First Byte), der påvirker Core Web Vitals.

Static Site Generation (SSG)

SSG genererer HTML på build-tidspunktet. Der er ingen server-rendering ved request — HTML’en er allerede klar.

SEO-implikationen: Optimal. Fuld HTML ved crawl, hurtig TTFB, ingen render-køafhængighed. Det er den bedste løsning for indhold, der ikke skifter per bruger.

Ulempen: Indhold der ændres hyppigt kræver rebuild for at afspejle ændringer. Det kan løses med Incremental Static Regeneration (ISR) i Next.js eller lignende mekanismer.

Den praktiske tommelfingerregel: Brug SSG til alt statisk indhold. Brug SSR til dynamisk indhold, der skal ranke. Brug CSR kun til indhold bag login eller indhold, der aldrig skal indekseres.

Sådan tester du, om Googlebot ser dit JS-indhold

Inden du omskriver din arkitektur, bør du verificere, om der faktisk er et problem.

URL Inspection Tool i Search Console. Det er det mest præcise værktøj. Brug “Test Live URL” og klik på “View Crawled Page” → “Screenshot”. Du ser præcist, hvad Googles renderer ser. Sammenlign med, hvad en bruger ser — mangler indhold, er det et problem.

Kildekode vs. renderet kilde. I Chrome: Ctrl+U viser den rå HTML (hvad crawleren ser ved crawl). Ctrl+Shift+I → Elements viser det renderede DOM (hvad WRS ser efter rendering). Sammenligningen er meget afslørende for JS-tunge sider.

Cache-test. Søg i Google efter cache:www.ditdomæne.dk/din-side/. Det viser den sidst cachede version. Er dit nøgleindhold til stede? Er dine JavaScript-grundlæggende byggede links synlige?

Rendering SEO-diagnose. Er dit indhold tilgængeligt i den rå HTML, eller kræver det rendering? Et hurtigt grep i kildekoden for dit primære nøgleord afslører det.

Den praktiske konsekvens for Next.js og React

Debatten om React Server Components og Next.js 15 er relevant her.

React Server Components (RSC) renderer på serveren og sender HTML (ikke JavaScript) til klienten. For SEO er det fremragende — det kombinerer SSR’s fordele med bedre performance. Men RSC er ikke en magisk løsning: client-only komponenter i dit RSC-træ kan stadig introducere de ovennævnte problemer.

Next.js App Router bruger som default Server Components — det er et skridt i den rigtige retning. Men mange codebasees har stadig store mængder client-side logik (use client-direktiver), der ruller til CSR.

Det konkrete råd: Audit din Next.js-applikation med URL Inspection Tool. Identificér sider med vigtige rankings og verificér, at deres indhold er til stede i den servergenererede HTML — ikke kun i det renderede DOM.

Brug SSR eller SSG til sider der skal ranke

JavaScript-rendering er ikke et teknisk kuriosum — det er en direkte faktor i, om dit indhold indekseres og ranker.

Alt indhold der skal ranke, skal være til stede i den HTML Googlebot modtager ved crawl — ikke kun i det JavaScript-renderede DOM. Det kræver enten SSR eller SSG.

CSR er velegnet til app-lignende interfaces, indhold bag login og interaktive widgets der aldrig skal indekseres. Men for landingpages, blogindlæg, produktsider og kategorisider er CSR et unødvendigt selvmål.

Brug URL Inspection Tool på dine vigtigste sider. Ser Google det samme som en bruger? Hvis ikke, er der et problem der kan løses.