JavaScript SEO: rendering en indexering

technical-seo9 min leestijd

Google kan JavaScript renderen. Maar het kost extra resources, er zit vertraging op, en het gaat niet altijd goed. AI-crawlers (GPTBot, ClaudeBot, PerplexityBot) renderen JavaScript helemaal niet. Een analyse van Vercel (2025) over 569 miljoen GPTBot-requests vond nul bewijs van JavaScript-executie.

Dat maakt de keuze voor je rendering-strategie een van de belangrijkste technische SEO-beslissingen. In deze gids: hoe rendering werkt voor zoekmachines, welke strategie je moet kiezen, en wat er per framework misgaat.

Inhoudsopgave

Het probleem: wat crawlers zien vs wat gebruikers zien
Rendering-strategieën vergeleken
SSR: Server-Side Rendering
CSR: Client-Side Rendering
SSG: Static Site Generation
Hybrid: het beste van beide
Hydration en de SEO-risico's
AI-bots en JavaScript: het grote gat
Hoe je test of Google je content rendert
Veelgemaakte fouten per framework
Veelgestelde vragen

Het probleem: wat crawlers zien vs wat gebruikers zien {#het-probleem}

Open een moderne React-app en bekijk de broncode (Ctrl+U). In veel gevallen zie je:

<div id="root"></div>
<script src="/bundle.js"></script>

Dat is alles. Geen tekst, geen links, geen structured data. De volledige content wordt pas geladen nadat de browser het JavaScript-bestand downloadt, parst, en uitvoert. Gebruikers zien dit niet, want hun browser doet dat automatisch. Maar crawlers?

Googlebot rendert JavaScript via een headless Chrome-instantie. Het werkt, maar met beperkingen:

Er zit vertraging op (seconden tot dagen na de eerste crawl)
Het kost Google extra resources per pagina (beïnvloedt je crawlbudget)
Sommige JavaScript-features worden niet ondersteund (Web Components, bepaalde API's)
Lazy-loaded content buiten de viewport wordt mogelijk niet gezien

AI-crawlers (GPTBot, ClaudeBot, PerplexityBot) renderen JavaScript niet. Ze doen een HTTP-request, ontvangen de raw HTML, en dat is het. Staat je content in een JavaScript-bundle? Dan zien ze een lege pagina.

Rendering-strategieën vergeleken {#rendering-strategieen-vergeleken}

Strategie	Hoe het werkt	Google-indexering	AI-bots	Performance	Geschikt voor
SSR	Server rendert HTML per request	Direct	Volledig	Goed (TTFB hoger)	Dynamische content, e-commerce
CSR	Browser rendert alles	Vertraagd, risicovol	Niets	Slecht (lang wit scherm)	Interne apps, dashboards
SSG	HTML gegenereerd bij build	Direct	Volledig	Uitstekend	Blogs, docs, marketing sites
Hybrid	Mix van SSR en SSG per route	Direct	Volledig	Uitstekend	Complexe sites met mix van content

SSR: Server-Side Rendering

Bij SSR rendert de server het JavaScript en stuurt complete HTML naar de browser. De crawler ontvangt een volledig gerenderde pagina zonder zelf JavaScript te hoeven uitvoeren.

Voordelen:

Content direct zichtbaar voor alle crawlers (Google en AI)
Snellere First Contentful Paint (FCP) dan CSR
Dynamische content mogelijk (user-specifiek, real-time data)

Nadelen:

Hogere serverbelasting (elke request vereist rendering)
Hogere TTFB dan SSG (server moet renderen voor de response)
Complexity in caching-strategie

Wanneer kiezen: als je content vaak verandert, user-specifiek is, of afhankelijk is van real-time data. E-commerce productpagina's, zoekresultaten, dashboards.

CSR: Client-Side Rendering

Bij CSR stuurt de server een minimaal HTML-document en een JavaScript-bundle. De browser doet al het werk.

SEO-risicoprofiel: hoog. Google kan CSR-content renderen, maar met vertraging en onzekerheid. AI-bots zien niets. Client-side gerenderde sites krijgen merkbaar minder citaties in AI-zoekmachines dan SSR-varianten, omdat de meeste AI-bots geen JavaScript renderen. Dat is een directe technische limitatie, niet een ranking-keuze.

Wanneer acceptabel: interne applicaties (dashboards, admin-panels), SPA's achter login, tools die niet geïndexeerd hoeven te worden. Nooit voor publieke content die je wilt laten ranken.

Voor arcadiagames.io (gaming platform) is de core app bewust CSR. De lobby, leaderboards, en gameplay hoeven niet geïndexeerd te worden. Maar de marketing-pagina's en landingspagina's zijn SSG. Die scheiding is essentieel.

SSG: Static Site Generation

Bij SSG wordt elke pagina vooraf gerenderd tot statisch HTML tijdens de build. De server serveert alleen bestanden, geen rendering nodig.

Voordelen:

Beste performance (laagste TTFB, direct leverbaar via CDN)
Volledig leesbaar voor alle crawlers
Laagste serverbelasting
Goedkoopst om te hosten

Nadelen:

Content is "bevroren" tot de volgende build
Niet geschikt voor dynamische of user-specifieke content
Build-tijden groeien bij grote sites (10.000+ pagina's)

Wanneer kiezen: content die niet per request verandert. Blogs, documentatie, marketing-pagina's, kennisbanken. Hiveminds.nl zelf gebruikt Vite met statische builds.

Hybrid: het beste van beide

Moderne frameworks (Next.js, Astro, Remix, SvelteKit) bieden hybride rendering: per route kiezen welke strategie het beste past.

/                    → SSG (homepage, verandert zelden)
/blog/*              → SSG (artikelen, statisch)
/products/*          → SSR (dynamische prijzen, voorraad)
/dashboard/*         → CSR (achter login, niet indexeerbaar)
/search?q=*          → SSR (dynamische zoekresultaten)

Dit is de aanbevolen aanpak voor de meeste moderne sites. Je combineert de performance van SSG met de flexibiliteit van SSR, zonder de SEO-risico's van CSR.

Astro verdient speciale vermelding. Het "Islands Architecture" model rendert pagina's als statisch HTML met selectieve JavaScript "eilanden" voor interactieve componenten. Minimaal JavaScript, maximale crawlbaarheid.

Hydration en de SEO-risico's

Hydration is het proces waarbij de browser een server-gerenderde HTML-pagina "activeert" door JavaScript event handlers te koppelen. De pagina is al zichtbaar (vanuit SSR), maar pas na hydration interactief.

SEO-risico's van hydration:

Content mismatch. Als de client-side hydration andere content produceert dan de server-side render, ziet Google een discrepantie. React's useEffect hooks draaien alleen client-side. Content die in een useEffect wordt geladen, is onzichtbaar voor crawlers.
Layout shifts. Hydration kan CLS veroorzaken als client-side rendering de layout wijzigt ten opzichte van de server-render. Dat beïnvloedt je Core Web Vitals.
Partial hydration gotchas. Bij partial hydration (Astro Islands, React Server Components) moeten interactieve componenten correct gemarkeerd zijn. Content in een niet-gehydreerd component is statisch HTML en SEO-safe. Content in een lazy-gehydreerd component kan onzichtbaar zijn tot hydration voltooid is.

Meer over performance: Core Web Vitals: complete gids

AI-bots en JavaScript: het grote gat {#ai-bots-en-javascript}

Dit is het punt dat veel ontwikkelaars onderschatten. Google rendert JavaScript (met vertraging). AI-bots doen het niet.

Crawler	JavaScript rendering	Wat ze zien bij CSR
Googlebot	Ja (headless Chrome)	Volledige content (vertraagd)
GPTBot (OpenAI)	Nee	Lege `<div>`
ClaudeBot (Anthropic)	Nee	Lege `<div>`
PerplexityBot	Nee	Lege `<div>`
Bingbot	Ja (beperkt)	Meeste content
Google-Extended	Nee (training crawler)	Raw HTML alleen

De impact is direct: een React SPA zonder SSR is onzichtbaar voor ChatGPT, Claude, en Perplexity. Dat zijn honderden miljoenen queries per maand waar je content niet kan verschijnen.

Hiveminds Lens meet specifiek of AI-crawlers je content correct kunnen lezen. Dat is de overlap tussen JavaScript rendering en AI Search Visibility.

Test het zelf:

# Simuleer wat een AI-crawler ziet
curl -s -A "GPTBot" https://jouwsite.nl/ | head -100

# Als je alleen <div id="root"></div> ziet: probleem.
# Als je volledige HTML-content ziet: goed.

Hoe je test of Google je content rendert

1. URL Inspection Tool (Search Console)

Ga naar Search Console, voer een URL in, en bekijk het tabblad "Live Test". Hier zie je:

HTML: de raw HTML die Google ontvangt
Rendered: hoe Google de pagina ziet na JavaScript-rendering
Screenshot: visuele weergave

Vergelijk HTML en Rendered. Is de content alleen in Rendered zichtbaar? Dan is je site afhankelijk van JavaScript-rendering door Google.

2. site:jouwsite.nl in Google

Zoek op site:jouwsite.nl "specifieke tekst". Als Google je content correct indexeert, verschijnt de pagina met de gezochte tekst in het snippet. Verschijnt de pagina zonder snippet of met minimale tekst? Dan rendert Google je content niet volledig.

3. curl test

# Bekijk raw HTML (wat crawlers zonder JS-rendering zien)
curl -s https://jouwsite.nl/pagina | grep "belangrijke tekst"

# Geen resultaat? Dan staat de tekst in JavaScript.

Veelgemaakte fouten per framework

React (Create React App)

Fout: CRA is standaard CSR. Geen SSR, geen SSG.
Impact: Google rendert vertraagd, AI-bots zien niets.
Fix: migreer naar Next.js of Remix. Of gebruik react-snap voor pre-rendering.

Next.js

Fout: useEffect gebruiken voor content die geïndexeerd moet worden.
Impact: useEffect draait alleen client-side. Die content is onzichtbaar voor crawlers.
Fix: gebruik getServerSideProps (SSR) of getStaticProps (SSG) voor SEO-kritieke content.

Vue / Nuxt

Fout: asyncData of fetch niet correct gebruiken in Nuxt.
Impact: content wordt client-side geladen in plaats van server-side.
Fix: gebruik Nuxt's useAsyncData of useFetch composables in <script setup>.

Astro

Fout: client-directives (client:load, client:visible) op content-componenten.
Impact: content in client-only componenten is niet in de statische HTML.
Fix: gebruik client-directives alleen voor interactiviteit, niet voor content.

Angular

Fout: Angular Universal niet configureren.
Impact: standaard Angular is volledig CSR.
Fix: configureer Angular Universal voor SSR of gebruik Angular's SSG-modus.

Veelgestelde vragen

Moet ik SSR gebruiken als ik al goede Google-rankings heb? Als je Google-rankings goed zijn, rendert Google je JavaScript blijkbaar correct. Maar voor AI-zichtbaarheid is SSR of SSG alsnog essentieel. AI-bots renderen geen JavaScript. Als dat kanaal voor je relevant is, is een rendering-upgrade noodzakelijk.

Is dynamic rendering nog een optie? Google heeft dynamic rendering in 2024-2025 officieel afgeraden (deprecated). Het was altijd een workaround, niet een oplossing. Investeer in SSR of SSG.

Hoe beïnvloedt JavaScript mijn crawlbudget? JavaScript-rendering kost Google meer resources per pagina. Bij grote sites (10.000+ pagina's) kan dat je effectieve crawlbudget verlagen. SSR en SSG elimineren die extra kosten volledig.

Kan ik pre-rendering gebruiken als tussenoplossing? Ja. Services als Prerender.io genereren statische HTML-snapshots voor bots. Het is een pragmatische tussenoplossing als je niet kunt migreren naar SSR/SSG. Maar het voegt complexiteit en kosten toe.

Welk framework is het beste voor SEO? Next.js (React), Nuxt (Vue), SvelteKit, en Astro zijn alle vier uitstekende keuzes. Ze bieden native SSR/SSG met minimale configuratie. De keuze hangt af van je team's expertise en je tech stack.

Volgende stap

JavaScript-rendering is de technische basis. Maar zelfs met perfecte SSR heb je nog goede performance (Core Web Vitals), correcte crawler-toegang (robots.txt), en structured data nodig.

→ Bekijk Hiveminds Lens