Techniek · Prerendering · Performance
Wat is prerendering voor SEO?
Prerendering voor SEO uitgelegd: hoe je JavaScript-heavy SPA's toch goed laat indexeren door Google. 4 prerendering-strategieën, tools (Prerender.io, Rendertron) en implementatie-stappen.
01 — strategieën4 prerendering-strategieën vergeleken
Prerendering is een verzamelterm voor technieken die JavaScript van tevoren uitvoeren om statische HTML te genereren — voor zowel zoekmachines als voor performance. Er zijn 4 hoofd-strategieën met elk verschillende trade-offs. Voor breder context op rendering zie CSR vs SSR voor SEO.
4 strategieën · vergelijkingtrade-offs
Server-Side Rendering (SSR)
runtime · per request
Pagina wordt gerenderd op de server bij elk request. Frameworks: Next.js (default), Nuxt.js, Remix, Astro (SSR-mode). Ideaal voor dynamische content (live data, user-specific). Server moet voor elke request renderen — kostbare CPU + geheugen.
SEO: uitstekend
Snelheid: medium
Cost: hoog
Static Site Generation (SSG)
build-time · vooraf gerenderd
Pagina's worden gebouwd tijdens deploy-build. Frameworks: Astro, Eleventy, Gatsby, Hugo, Next.js Static Export. Resultaat = pure HTML files op CDN. Razendsnel + ideale SEO. Beperking: bij content-updates moet je site rebuilden.
SEO: uitstekend
Snelheid: extreem
Cost: laag
Dynamic Rendering
runtime · alleen voor bots
Detect crawler-user-agent en serveer prerendered HTML alleen aan bots. Mensen krijgen normale CSR-app. Tools: Prerender.io, Rendertron. Google ondersteunt dit officieel als "tijdelijke oplossing", maar adviseert SSR/SSG voor lange termijn.
SEO: goed
Snelheid: medium
Cost: medium
Incremental Static Regeneration (ISR)
hybrid · build + on-demand
Hybride van SSG + dynamic regeneration. Next.js-specifiek (en vergelijkbaar in andere frameworks). Pagina's worden gebouwd, maar regenereren periodiek of bij specifieke triggers. Beste van SSG (snel + SEO) zonder full rebuild bij elke change.
SEO: uitstekend
Snelheid: hoog
Cost: laag-medium
In mijn praktijk gebruik ik bij 90%+ van moderne projecten SSG of ISR. Pure SSR alleen waar dynamische user-specific content vereist is. Dynamic rendering als snelle fix bij legacy SPA's zonder grote rewrite.
02 — stappenImplementatie-stappenplan voor dynamic rendering
Voor sites die voorlopig geen tijd hebben voor volledige migratie naar SSR/SSG, is dynamic rendering met Prerender.io of self-hosted Rendertron een pragmatische oplossing. Hieronder mijn 5-stappen-implementatie die in 1-2 dagen live kan zijn.
5 stappen · dynamic renderingimplementatie
01
Audit current state — wat ziet Googlebot nu?
URL Inspection in Search Console. Test top-10 belangrijke pagina's. "View crawled page" toont wat Googlebot daadwerkelijk ziet. Bij leeg/missende content = dynamic rendering nuttig. Bij volledige content zichtbaar = misschien geen actie nodig.
02
Kies tool: Prerender.io (managed) of Rendertron (self-hosted)
Prerender.io = makkelijker, betaalt per pagina (€50-200/maand voor MKB). Rendertron = open-source, self-hosted op Docker, gratis maar vereist devops. Voor sites onder 1000 pages: Prerender.io. Voor enterprise: Rendertron of in-house solution.
03
User-agent detection in server-config
Nginx of Apache rule: check User-Agent header. Bekende crawlers (Googlebot, Bingbot, Slurp, DuckDuckBot) → reverse proxy naar prerender-service. Normale users → naar app. Code-voorbeelden in Prerender.io docs. Test grondig — verkeerde detection = problemen.
04
Cache-strategie configureren
Prerendered HTML cachen voor 24h tot 7 dagen. Voorkomt overhead bij elke crawler-request. Cache invalideren bij content-updates via webhook. Te lange cache = stale content, te korte cache = hoge kosten/load.
05
Test + monitor via Search Console
Na deploy: maandelijks URL Inspection van top-pages. Coverage Report → "Crawled but not indexed" tracking. Bij dalende rendering-errors = werkt. Verwacht 4-8 weken voor Google's volledige re-crawl + re-evaluation van de site.
03 — faqVeelgestelde vragen
FAQ · 3 vragenklik om te openen
Is dynamic rendering hetzelfde als cloaking?›
Nee — Google heeft dynamic rendering expliciet toegestaan als techniek. Vijf belangrijke principes om het correct te doen. (1) Content moet identiek zijn. Wat de prerender-service genereert moet exact dezelfde content tonen als wat gebruikers uiteindelijk zien (na JS-uitvoering). Verschillende content = cloaking-risico. (2) Geen content-manipulatie voor SEO. Niet "extra" keywords in prerendered version stoppen die niet in de echte app zitten. Dat is cloaking. Google detecteert dit via vergelijking. (3) Officieel toegestaan sinds 2017. Google's documentation noemt dynamic rendering als acceptabele temporary workaround voor JavaScript-heavy sites. Niet permanent oplossing, maar geen risico bij correcte uitvoering. (4) IP-verificatie als extra safety. Naast user-agent: verifieer dat Googlebot IP echt van Google's crawl-infrastructure komt. Voorkomt dat scrapers misbruik maken. (5) Google adviseert echter SSR/SSG voor lange termijn. Dynamic rendering werkt, maar SSR/SSG zijn future-proof. Plan migratie naar SSR/SSG binnen 12-18 maanden bij belangrijke sites. Voor breder context zie CSR vs SSR voor SEO.
Wat kost Prerender.io vs self-hosted Rendertron?›
Cost-vergelijking hangt af van site-grootte. Vijf overwegingen voor de juiste keuze. (1) Prerender.io pricing 2026. Free-tier tot 250 pages. Paid tiers vanaf €40/maand voor 5.000 pages. Enterprise tot €500+/maand voor 100.000+ pages. Charged per unique cached URL. (2) Rendertron self-hosted. Open-source, gratis. Vereist server (€20-100/maand afhankelijk van load) + devops tijd voor setup/maintenance (1-2 dagen initial + maandelijks 2-4 uur). Voor enterprise vaak goedkoper netto. (3) Hidden costs Prerender.io. API-rate-limits, cache-storage limits, en upgrade-costs als je groeit. Lees fine-print voor large-scale gebruik. (4) Hidden costs Rendertron. DevOps-tijd, server-monitoring, security-updates, scaling-issues. Vooral pijnlijk bij teams zonder dedicated DevOps. (5) Mijn praktijk-advies: tot 5.000 pages = Prerender.io (makkelijker). Boven 50.000 pages = self-hosted Rendertron of custom. Tussenin: afhankelijk van team-capabilities. Voor breder context zie SEO tools voor agencies.
Hoe snel zie ik SEO-resultaten na implementatie?›
Resultaten komen geleidelijk over weken/maanden. Zes signalen om te tracken. (1) Week 1-2: Google moet eerst opnieuw crawlen. Maximaal 2 weken voor populaire pages, langer voor diepe legacy-pages. URL Inspection forceer-aanvragen voor top-pages versnelt. (2) Week 2-4: Search Console "Coverage" toont meer indexeerde pages. Dalende "Crawled but not indexed" = JS-content nu zichtbaar. Track als KPI. (3) Maand 1-2: Eerste ranking-veranderingen. Vooral voor pages die voorheen helemaal niet rankten (omdat content niet zichtbaar) — die kunnen plotseling top-20 verschijnen. (4) Maand 2-4: Volledige re-evaluation van site door Google. Sites met JS-issues die nu opgelost zijn zien typisch 20-40% traffic-stijging in deze periode. (5) Maand 4-6: Compound effect. Backlinks naar nu-indexeerbare content beginnen te tellen. Rankings stabiliseren op nieuw plateau. (6) Belangrijk: meet altijd vóór + na. Baseline metingen van impressions, clicks, rankings voor de implementatie. Anders weet je niet wat de daadwerkelijke impact was. Voor breder context zie hoelang duurt SEO.
Prerendering voor jouw site?
Audit van JS-rendering-issues, implementatie van Prerender.io of Rendertron + migratie-plan naar SSR/SSG. Voor SPA's en JavaScript-heavy sites die SEO-zichtbaarheid verloren door rendering-issues.
Plan een gesprek met Ralf →