JS SEO & Rendering

Moderne websites bygges i vid udstrækning med JavaScript, og det er der gode grunde til: hurtigere udvikling, rigere brugeroplevelser, fleksible arkitekturer. Men JavaScript rejser også et spørgsmål, som klassisk HTML aldrig stillede: ser maskinerne det samme som brugerne? Svaret afgør, om jeres indhold overhovedet kan findes – i Google såvel som i AI-søgemaskinerne.

Hvorfor rendering afgør jeres synlighed

Rendering er processen, hvor browserens JavaScript bygger den færdige side. På et serverrenderet site ligger indholdet klar i den HTML, serveren sender. På et client-side renderet site sender serveren i stedet en næsten tom skal, og indholdet opstår først, når JavaScript har kørt i browseren.

For brugeren er slutresultatet ofte det samme. For maskinerne er forskellen fundamental: en crawler, der ikke kører JavaScript, ser den tomme skal – ingen tekst, ingen links, ingen produkter.

Sådan behandler Google JavaScript

Google kan rendere JavaScript og gør det med en opdateret Chromium-browser. Men renderingen sker i to trin: Googlebot henter først sidens rå HTML, og selve JavaScript-renderingen lander i en kø, der afvikles, når der er ressourcer til det. Det giver tre konsekvenser:

• Forsinkelse. Indhold, der kun findes efter rendering, kan blive opdaget og opdateret langsommere end indhold i den rå HTML.
• Ressourcer. Rendering er dyrt, og store sites kan opleve, at kun en del af siderne bliver renderet så ofte, som indholdet ændrer sig.
• Fejl. Blokerede JavaScript-filer, timeouts eller scripts, der fejler i Googles miljø, efterlader siden halvtom i indekset, uden at nogen opdager det i browseren.

Links fortjener et særskilt punkt: Googlebot følger a-tags med href-attributter. Navigation, der kun virker via JavaScript-events, kan efterlade hele sektioner af sitet uden interne stier, som crawleren kan følge. Det underminerer både crawling og indeksering og jeres interne linkstruktur.

AI-crawlere renderer som hovedregel ikke JavaScript

Her adskiller AI-fladerne sig fra den klassiske diskussion om JavaScript SEO. Crawlerne bag ChatGPT, Claude, Perplexity og de øvrige AI-søgemaskiner henter i altovervejende grad kun den rå HTML – de kører ikke jeres JavaScript. Indhold, der kun eksisterer efter client-side rendering, er derfor usynligt for de fleste AI-flader, uanset hvor godt det står i Google.

Det gør serverrenderet indhold til det sikre valg på begge flader: den HTML, serveren sender som svar på første forespørgsel, skal indeholde jeres reelle indhold. Klassisk search og AI-search stiller her præcis samme krav, og arbejdet med AI search-optimering starter derfor ofte netop her.

Renderingstrategier: CSR, SSR og SSG

• Client-side rendering (CSR). Alt bygges i browseren. Hurtigt at udvikle, men den svageste løsning for synlighed: Google skal vente på renderingskøen, og AI-crawlere ser en tom skal.
• Server-side rendering (SSR). Serveren bygger den færdige HTML ved hver forespørgsel. Indholdet er komplet fra første byte, og JavaScript overtager derefter interaktiviteten i browseren.
• Static site generation (SSG). Siderne bygges som færdig HTML på forhånd og serveres lynhurtigt fra et CDN. Ideelt til indhold, der ikke ændrer sig fra minut til minut; moderne frameworks kan genopbygge enkeltsider løbende, når indholdet opdateres.

I praksis vælger de fleste moderne frameworks – Next.js, Nuxt, SvelteKit, Astro og lignende – en hybrid: statisk eller serverrenderet HTML som fundament, JavaScript ovenpå til interaktivitet. Det giver samtidig et godt udgangspunkt for Core Web Vitals, fordi brugeren ser indhold, før al JavaScript er hentet og kørt.

Headless CMS: frontenden afgør, ikke CMS'et

Mange JavaScript-diskussioner starter i virkeligheden med et CMS-valg. Headless-arkitekturer, hvor indholdet ligger i systemer som Storyblok, Sanity, Contentful, Strapi eller Prismic og serveres via API til en selvstændig frontend, er blevet helt almindelige – og fra et SEO-perspektiv er selve CMS-valget mindre vigtigt, end det ofte gøres til.

Maskinerne kan ikke se, hvilket CMS der ligger bag. De ser udelukkende den HTML, frontenden leverer. Groft sagt varetager CMS'et jeres indhold, mens frontend-frameworket varetager jeres tekniske SEO. Et velvalgt headless-setup med serverrendering kan derfor være et stærkt fundament, mens præcis samme CMS bag en ren client-side app kan gemme alt indholdet væk. Læg derfor opmærksomheden der, hvor beslutningen hører hjemme: i frontend-arkitekturen. Det er også her, vi oftest arbejder sammen med kundernes udviklere eller vores eget hold i webudvikling.

Sådan tester I, hvad maskinerne ser

1. Vis kilden. Åbn sidens kildekode (ikke inspektøren) og søg efter en sætning fra brødteksten. Står den der, er indholdet serverrenderet. Inspektøren viser derimod den færdigrenderede DOM – forskellen mellem de to er præcis det, JavaScript bygger.
2. Slå JavaScript fra. Deaktivér JavaScript i browseren og genindlæs siden. Det, I ser nu, er nogenlunde det, en AI-crawler ser.
3. Brug URL-inspektion i Search Console. Værktøjet viser den renderede HTML, som Google faktisk indekserer, og afslører blokerede ressourcer og renderingsfejl.
4. Hent siden som en bot. Et curl-kald mod URL'en viser præcis den rå HTML, serveren leverer til crawlere uden rendering.

Typiske faldgruber

• Metadata sat i browseren. Sidetitler, meta descriptions og canonical-tags, der først indsættes af JavaScript, læses upålideligt. De hører hjemme i den rå HTML.
• Indhold bag interaktion. Tekst, der først hentes ved klik, scroll eller faneskift, bliver som regel ikke indekseret.
• Blokeret JavaScript. Ligger jeres scripts bag robots.txt-blokeringer, kan Google ikke rendere siden korrekt.
• Soft 404-sider. Client-side apps svarer ofte 200 OK på sider, der ikke findes. Sørg for rigtige statuskoder, så fejl kan opdages og håndteres – det hænger tæt sammen med jeres site health og redirects.

JavaScript og SEO kan sagtens leve sammen, hvis rendering bliver behandlet som en arkitekturbeslutning frem for noget, man ordner til sidst. Er I i tvivl om, hvad maskinerne faktisk ser på jeres site, afdækker en gratis SEO-analyse det sammen med resten af jeres tekniske fundament.