Techniek · JavaScript · Rendering
De invloed van JavaScript op SEO.
JavaScript en SEO: hoe Google JavaScript crawlt en rendert via two-wave indexing. Mijn 6 best-practices voor JS-heavy sites, common issues, en hoe je crawl-budget niet verspilt aan client-side rendering.
01 — two-waveHoe Google JavaScript verwerkt: het two-wave model
Google's relatie met JavaScript is in 2024-2026 veel beter geworden dan vijf jaar geleden — maar nog steeds complex. Het two-wave indexing model is de kern van begrijpen hoe JS-content uiteindelijk in de SERP belandt. Voor breder context op rendering-strategieën zie CSR vs SSR voor SEO.
2 waves · Googlebot procesindexing-pipeline
W1
Wave 1 — Initial HTML crawl
Direct na request crawlt Googlebot de raw HTML. Alleen wat in de initial server-response zit wordt direct geïndexeerd. Bij client-side rendered (CSR) apps is dit vaak slechts een lege div met "loading" tekst. Geen content = geen ranking. Tijdsbestek: seconden tot minuten.
W2
Wave 2 — Rendering via Web Rendering Service (WRS)
Apart proces, vaak dagen tot weken later. Googlebot stuurt de URL door naar Google's WRS (gebaseerd op recente Chromium-versie). WRS voert JavaScript uit en index de uiteindelijke gerenderde HTML. Resultaat: uiteindelijk word JS-content geïndexeerd, maar met vertraging.
De vertraging tussen wave 1 en wave 2 is kritiek bij tijds-gevoelige content (nieuws, prijzen, voorraad). Bij e-commerce en news-sites kan de vertraging betekenen dat content te laat verschijnt in de SERP en kansen mist.
02 — best-practices6 best-practices voor JavaScript-SEO
JavaScript-heavy sites kunnen succesvol SEO doen — mits correct geïmplementeerd. Hieronder 6 best-practices die in mijn audits het verschil maken tussen "werkt redelijk" en "domineert SERP". Praktisch toepasbaar op React, Vue, Angular en custom-frameworks.
6 best-practices · JS-SEOimplementatie-rules
Best 01
Server-side render kritieke content
Title, meta-description, H1, hoofdcontent moeten in de initial HTML staan. SSR via Next.js, Nuxt.js of Astro. Bij echte CSR-apps: pre-rendering voor de belangrijkste paden (homepage, top landing pages, productpagina's).
Best 02
Gebruik geen "loading" placeholders als content
"Loading...", spinners, of skeleton-screens in raw HTML = Google ziet leeg. Pre-render altijd echte content, niet placeholders. Klant denkt dat het "snel laadt", Google denkt dat de pagina leeg is. Beide moeten content zien.
Best 03
Links als <a href> — niet via onClick
Googlebot volgt <a href="...">-elementen. JavaScript-buttons met onClick die programmatisch naar nieuwe URL navigeren = Google ziet geen link. React Router: gebruik Link-component die echte <a>-elementen rendert.
Best 04
Lazy-load images correct met loading="lazy"
Native lazy-loading via loading="lazy" attribute werkt voor Googlebot. JavaScript-based lazy-loading via IntersectionObserver moet correct met fallback voor crawlers. Te aggressieve lazy-loading = images worden niet geïndexeerd.
Best 05
Vermijd timeout-based content rendering
setTimeout(() => loadContent(), 5000) = Google's WRS heeft beperkte rendering-tijd. Als jouw content pas na 5 seconden verschijnt, wordt het mogelijk gemist. Render content zo snel mogelijk na page-load.
Best 06
Test via URL Inspection in Search Console
"View crawled page" toont wat Googlebot daadwerkelijk zag — inclusief de rendered HTML na JS-uitvoering. Als je content niet ziet daar = Googlebot zag het ook niet. Maandelijks testen voor top-pages.
Voorbeeld — fout vs goed:
// FOUT: onClick-based navigation
<button onClick="navigate('/products')">Producten</button>
// Google ziet GEEN link naar /products
// GOED: anchor met href + JS-enhancement
<a href="/products" onClick="handleClick()">Producten</a>
// Google volgt de href + JS enhances UX
<button onClick="navigate('/products')">Producten</button>
// Google ziet GEEN link naar /products
// GOED: anchor met href + JS-enhancement
<a href="/products" onClick="handleClick()">Producten</a>
// Google volgt de href + JS enhances UX
03 — faqVeelgestelde vragen
FAQ · 3 vragenklik om te openen
Moet ik mijn SPA omzetten naar SSR voor goede SEO?›
Niet altijd — afhankelijk van wat je belangrijk vindt. Vijf nuanceringen uit mijn praktijk. (1) Pure SPA's werken in 2026 redelijk. Google's WRS is competent in JS-rendering. Voor low-priority content (footer, secondary CTAs) prima. Voor kritieke landing-pages echter te risicovol. (2) SSR/SSG voor publieke content. Marketing-pagina's, blogs, productpagina's, kennisbank — alles publiek toegankelijk moet SSR of static-generation hebben. Next.js, Nuxt.js, Astro, SvelteKit zijn de moderne keuzes. (3) SPA voor app-features. Login-beschermde dashboards, real-time apps, complex interactieve features = SPA acceptabel. Google indexeert deze toch niet (en hoeft ook niet). (4) Hybrid approach. Modern frameworks supporten hybrid (SSR voor sommige routes, CSR voor andere). Volledige SPA → hybrid is haalbare migratie zonder volledige rewrite. (5) Pre-rendering als budget-vriendelijk alternatief. Prerender.io, Rendertron, of self-hosted Puppeteer renderen pagina's en serveren statische HTML aan crawlers. Niet ideaal maar werkt. Voor breder context zie CSR vs SSR voor SEO.
Hoeveel vertraging zit er tussen Wave 1 en Wave 2?›
Vertraging varieert enorm — van uren tot weken. Zes factoren die snelheid bepalen. (1) Site-autoriteit. High-authority sites (BBC, Wikipedia, government) krijgen Wave 2 vaak binnen 24 uur. Onbekende sites kunnen weken wachten. (2) Crawl-budget allocatie. Google's WRS heeft beperkte capaciteit. Sites met groot crawl-budget krijgen prioriteit. Crawl-budget hangt af van autoriteit + technische gezondheid. (3) Page-importance signalen. Pages met veel interne links en updates worden vaker gerenderd. Diepe legacy-pages kunnen maanden wachten. (4) Server-snelheid en rendering-cost. Pages die snel laden en weinig JS-resources gebruiken worden vaker gerenderd. Heavy JS-pages krijgen lagere rendering-prioriteit. (5) Sitemap-prioriteit. URLs in sitemap met lastmod-update krijgen rendering-prioriteit. Sitemap update na content-changes versnelt re-rendering. (6) Praktisch: voor tijd-gevoelige content (nieuws, voorraad, prijzen) niet vertrouwen op JS-rendering. SSR met cache-headers is veel betrouwbaarder. Voor breder context zie indexering in Google Search Console.
Werkt JavaScript-SEO hetzelfde voor Bing en andere zoekmachines?›
Nee, en het verschil is significant. Vijf observaties over zoekmachine-rendering. (1) Bing kan JS, maar minder goed. Bing heeft sinds 2021 JS-rendering capabilities, maar minder geavanceerd dan Google. Sites die alleen via Bing geïndexeerd willen worden hebben SSR nodig — Bing's WRS slaat vaak content over. (2) DuckDuckGo gebruikt Bing-index. Dus hetzelfde verhaal — voor DuckDuckGo-zichtbaarheid moeten content SSR-gerenderd zijn. (3) AI-zoekmachines verschillen sterk. ChatGPT's web-search via Bing = beperkte JS-support. Perplexity heeft eigen crawler met betere JS-rendering. Claude heeft minder JS-support. (4) Vragen-engines (Google's AI Overviews, ChatGPT) bevoordelen SSR-content. Citation-likelihood is hoger voor pages die direct content tonen in raw HTML. (5) Praktisch: SSR is de safest bet voor multi-platform SEO. Het kost iets meer development-tijd, maar werkt overal goed. Pure CSR is een Google-only gok in 2026. Voor breder context zie SEO voor ChatGPT.
JavaScript-SEO audit voor jouw site?
Volledige audit van JavaScript-rendering, two-wave indexing patronen, en kritieke content-zichtbaarheid voor Googlebot. Met implementatie-advies voor SSR/SSG/pre-rendering passend bij jouw stack.
Plan een gesprek met Ralf →