Techniek · Rendering · JavaScript
Client-side vs server-side rendering.
CSR vs SSR voor SEO: hoe Googlebot omgaat met JavaScript-rendering, wanneer welke aanpak werkt, en de 4 hybride strategieën vergeleken op crawlbaarheid, snelheid en complexiteit.
01 — renderingDe 4 rendering-strategieën vergeleken
De keuze tussen client-side en server-side rendering is niet meer binair. Moderne frameworks (Next.js, Nuxt, Astro) bieden hybride-strategieën die de voordelen combineren. Hieronder de 4 hoofdvarianten met SEO-impact, snelheid en implementatie-complexiteit. Voor breder context op site-snelheid zie on-page SEO checklist.
4 strategieën · vergelijkingcrawlbaarheid + snelheid
SSR
Server-Side Rendering
Server genereert volledige HTML per request. Browser ontvangt complete pagina, Googlebot ziet alles direct in de eerste response.
SEO-impact
Snelheid
Complexiteit
SSG
Static Site Generation
Pagina's pre-rendered op build-time. Serveert statische HTML vanaf CDN — supersnel en optimaal voor crawling.
SEO-impact
Snelheid
Complexiteit
ISR
Incremental Static Regeneration
Hybride: statische HTML met periodieke regeneratie. Snelheid van SSG + dynamiek van SSR. Beste van beide werelden voor SEO.
SEO-impact
Snelheid
Complexiteit
CSR
Client-Side Rendering
Browser rendert content via JavaScript na laden. Googlebot moet apart een rendering-pass doen. Risicovol voor SEO als niet juist geïmplementeerd.
SEO-impact
Snelheid
Complexiteit
02 — beslismodelWelk type rendering past bij jouw site?
Geen one-size-fits-all. De juiste keuze hangt af van content-type, update-frequentie en team-capaciteit. Hieronder 4 scenarios om jouw site te plaatsen in de juiste strategie.
4 scenarios · beslismodelwelke past bij jouw site?
Blog / kennisbank / content-site → SSG of ISR
Waarom: Content verandert relatief weinig, pages worden duizenden keren per maand opgevraagd. Pre-rendering levert bliksemsnel CDN-served HTML. Tools: Astro, Hugo, Next.js (met getStaticProps). Build-tijd is acceptabel voor sites tot ~50.000 pagina's.
E-commerce / catalogus → ISR of SSR
Waarom: Voorraad, prijzen en beschikbaarheid veranderen. Pure SSG werkt niet (verouderde data). ISR met 60-300s revalidate is meestal optimaal. SSR voor pagina's met sterk wisselende content (cart, checkout). Tools: Next.js + ISR, Nuxt + hybrid mode, Shopify Hydrogen.
SaaS-applicatie / dashboards → CSR (achter login)
Waarom: Content achter login hoeft niet vindbaar te zijn. Sterke UI-interactie heeft baat bij CSR. Belangrijk: marketing-site (landingspagina's, pricing, blog) moet WEL SSG/SSR zijn. Tools: React, Vue voor app. Astro of Next.js voor marketing-site. Twee-app-architectuur is normaal.
Nieuws / real-time content → SSR
Waarom: Content wordt continu bijgewerkt, breaking news moet direct beschikbaar. Geen tijd voor build-step. SSR met aggressive caching (5-60s TTL) levert beste balans. Tools: Next.js SSR mode, Nuxt 3, Remix. Voor allergrootste nieuwssites: edge-rendering via Cloudflare Workers of Vercel Edge.
03 — faqVeelgestelde vragen
FAQ · 3 vragenklik om te openen
Hoe weet ik of mijn JavaScript-content geïndexeerd wordt door Google?›
JavaScript-indexering is het #1 issue voor CSR-sites. Vijf checks om te verifiëren of content correct geïndexeerd wordt. (1) URL Inspection Tool in Google Search Console. Plak een pagina-URL en klik 'View tested page' > 'Screenshot' + 'HTML'. Zie je de content die je verwacht? Vergelijk gerenderde HTML met source-HTML. Als content alleen in gerenderde versie zichtbaar is, ben je afhankelijk van rendering door Googlebot. (2) "site:" search met inhouds-snippet. Zoek site:jouwsite.nl "specifieke zin uit pagina". Als pagina verschijnt = content is geïndexeerd. Als niet = JavaScript wordt niet juist verwerkt. (3) Search Console > Coverage report. Filter op "Crawled - currently not indexed" of "Discovered - currently not indexed". JavaScript-heavy sites zien hier vaak veel pagina's. Dit zijn waarschuwingssignalen. (4) Test via Mobile-Friendly Test. Toont ook gerenderde HTML. Vergelijk met source. Verschillen = JS-rendering issues. (5) Lighthouse PWA-audit. SEO-section identificeert renderer-issues. Voor breder context op crawlability zie Screaming Frog inzetten voor SEO.
Wat is het verschil tussen SSR en pre-rendering services zoals Prerender.io?›
Beide leveren server-rendered HTML aan crawlers, maar de mechanismes verschillen significant. Vijf principes. (1) SSR = server rendert voor elke request. Pre-rendering = aparte service detecteert crawler-user-agent en serveert pre-rendered HTML alleen aan bots. Mensen krijgen nog steeds CSR-versie. (2) SSR is universal voor mensen + bots. Iedereen krijgt server-rendered HTML. Beste UX (sneller eerste-paint) + beste SEO. (3) Pre-rendering is "patch op CSR". Pre-rendering services zoals Prerender.io, Rendertron, Puppeteer Cluster crawlen jouw site en cachen rendered HTML. Bij bot-bezoek serveren ze die HTML. Werkt, maar er is delay tussen update en bot-zichtbaarheid (vaak 24h-7d). (4) Google waarschuwt voor cloaking-risico. Pre-rendering kan grenzen aan cloaking als HTML voor bots significant anders is dan voor mensen. Houd content identical om risico te vermijden. (5) Wanneer welk? Pure CSR-site die niet SSR kan zonder rewrite > pre-rendering als interim-oplossing. Nieuwe build > kies SSR/ISR vanaf start, geen pre-rendering nodig. Migratie naar SSR is moeilijk maar levert beter UX EN SEO. Voor breder context zie is dynamisch renderen nog de moeite waard.
Heeft Core Web Vitals impact op alle 4 de rendering-strategieën?›
Ja, maar de optimalisaties verschillen per strategie. Zes principes voor CWV-optimalisatie per rendering-mode. (1) LCP (Largest Contentful Paint). SSG: makkelijkst, statische HTML laadt instant. Optimaliseer hero-images. SSR: focus op server-response-time + caching. ISR: zoals SSG plus revalidate-budget. CSR: kritiek issue — LCP-element komt na JS-execution. Solution: pre-render initial content, lazy-load secondary. (2) FID/INP (Interactivity). CSR: heeft de zwaarste JS, vaak slechtste INP. Solution: code-splitting, hydration-strategie. SSR/ISR/SSG: minder JS = beter INP, maar hydration kan nog steeds blokkeren. (3) CLS (Layout Shift). Geen verschil per strategie. Reserve dimensions voor images, vermijd post-load content-injection. (4) TTFB (Time to First Byte). SSG > ISR > SSR > CSR (vanuit gebruiker-perspectief). SSG vanaf CDN onverslagen. (5) Edge-rendering verbeteren alle modes. Cloudflare Workers, Vercel Edge en Netlify Edge brengen rendering dichter bij gebruiker — significante TTFB-verbetering. (6) Monitor in production. CrUX-data (real user monitoring) vs synthetic Lighthouse. Beide nodig. Voor breder context zie duurzame SEO + site-snelheid.
Rendering-strategie reviewen?
Volledige rendering-audit voor jouw site: CSR vs SSR vs ISR vs SSG. Met concrete migratie-roadmap als huidige aanpak niet optimaal blijkt. Inclusief JavaScript-indexering check en Core Web Vitals plan.
Plan een gesprek met Ralf →