Artikel

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.

Sidst opdateret:

Prerendering er processen med at generere statisk HTML fra JavaScript-sider til brug for søgemaskinecrawlere. Det er en pragmatisk mellemvej for eksisterende Single Page Applications der ikke kan migreres til server-side rendering — et SEO-fix der eliminerer render-kø-forsinkelse for Googlebot uden at kræve arkitekturel ombygning af det eksisterende JavaScript-site.

Problemet prerendering løser

Single Page Applications (SPAs) bygget med React, Vue eller Angular genererer HTML via JavaScript i browseren. Googlebots kan render JavaScript, men med forsinkelse og ressourcebegrænsning. For sites der er gebygget som SPA er prerendering en løsning der ikke kræver arkitekturel ombygning.

Sådan fungerer prerendering

En prerendering-service (Prerender.io, Rendertron, eller custom Puppeteer-setup) kører en headless browser, renderer JavaScript-siden og gemmer HTML-snapshots. En server- eller CDN-regel sender disse snapshots til crawlere (baseret på User-Agent-detektion) og det normale JavaScript-site til brugere.

Nginx-eksempel:

if ($http_user_agent ~* "googlebot|bingbot|...") {
  proxy_pass http://prerender-service;
}

Prerender.io og lignende services

Prerender.io er den mest udbredte managed prerendering-service. Den fungerer som middleware: crawlere omdirigeres til Prerenders cached HTML-snapshots. Prismodellen er baseret på antal renders og cache-størrelse.

Alternativt kan man sætte sin egen prerendering op med Puppeteer (Node.js headless Chrome) og cache HTML i Redis eller filsystem.

Begrænsninger

Prerendering-snapshots er statiske — de afspejler indholdet på det tidspunkt de blev genereret. Hyppigt opdateret indhold kræver aggressiv cache-invalidation. For dynamisk indhold der ændres per bruger er prerendering ikke velegnet — brug SSR i stedet. → Denne artikel er en del af JavaScript og rendering — Scripts, DOM og CSR vs SSR.

Del af: JavaScript og rendering — Scripts, DOM og CSR vs SSR →

Andre artikler i samme emne

Relaterede begreber

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. 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 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. Artikel 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. Artikel 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.

Ofte stillede spørgsmål

Hvad er forskellen på prerendering og cloaking?
Cloaking er forbudt: at vise forskelligt indhold til crawlere og brugere med det formål at manipulere ranking. Prerendering viser det samme indhold — men i et optimeret format (forhåndsrenderet HTML) til crawlere. Google accepterer prerendering eksplicit som en legitim teknik. Betingelsen er at det renderede HTML-indhold er ækvivalent med brugeroplevelsen.
Hvornår er prerendering den rigtige løsning vs. SSR?
SSR (server-side rendering) er den foretrukne langsigtede løsning — rendering sker på serveren, brugere og crawlere modtager begge HTML. Prerendering er en pragmatisk løsning når: eksisterende SPA ikke kan/vil migreres til SSR, tredjepartssites skal integreres, eller hurtig SEO-fix er nødvendig uden arkitekturel ændring. For nye projekter: byg med SSR/SSG fra start.
Accepterer Google prerendering uden at betragte det som cloaking?
Ja — under betingelse af at det renderede HTML-indhold er ækvivalent med brugeroplevelsen. Google betragter dynamic rendering (serving pre-rendered HTML til crawlere og JavaScript til brugere) som en acceptabel løsning. Det er cloaking hvis det renderede indhold afviger meningsfuldt fra det brugeren ser — fx ved at vise andet indhold specifikt til Googlebot for at manipulere ranking.
Hvad er Prerender.io og hvad koster det typisk?
Prerender.io er den mest udbredte managed prerendering-service. Den kører headless Chromium, cacher HTML-snapshots og serverer dem til crawlere via User-Agent-detektion. Prismodellen er baseret på antal renders og cachestørrelse. Alternativet er en self-hosted Puppeteer-løsning der er gratis men kræver serverressourcer og vedligeholdelse.
Hvilke User-Agent-strenge bruges til at identificere crawlere i en prerendering-opsætning?
De primære User-Agents der skal rutes til prerendering er Googlebot, Bingbot, DuckDuckBot, Slurp (Yahoo), Baiduspider og sociale medie-crawlere som facebookexternalhit og Twitterbot. Prerender.io og lignende services vedligeholder egne lister over kendte crawler-User-Agents. Det er vigtigt at listen holdes opdateret og at regulære brugere under ingen omstændigheder rutes til prerenderet indhold — det ville udgøre cloaking og er i strid med Googles retningslinjer.

Placering i ordbogen

Kode — Webkode og teknisk SEO
JavaScript og rendering — Scripts, DOM og CSR vs SSR
Prerendering — Forhåndsrenderet HTML til crawlere