Server-side rendering: wat de crawler écht binnenkrijgt

Bij client-side rendering (CSR) stuurt de server een vrijwel lege HTML-pagina en bouwt JavaScript de inhoud pas in de browser op. Bij server-side rendering (SSR) genereert de server de volledige HTML per verzoek. Bij static site generation (SSG) wordt die HTML al bij het bouwen gemaakt en als bestand geserveerd. SSR en SSG leveren beide direct leesbare content; CSR niet.

Googlebot crawlt eerst de ruwe HTML en zet JavaScript-rendering in een aparte wachtrij. Die tweede ronde kan uren tot dagen later plaatsvinden en mislukt bij fouten, trage scripts of geblokkeerde bestanden. Content die alleen na JavaScript verschijnt, wordt dus later, gedeeltelijk of niet geïndexeerd. Titles, canonicals en structured data die pas client-side worden gezet, lopen hetzelfde risico.

GPTBot, ClaudeBot, PerplexityBot en soortgelijke crawlers halen in de regel alleen de HTML op zonder JavaScript uit te voeren. Een single-page app zonder SSR is voor hen een vrijwel lege pagina. Wil je geciteerd worden in ChatGPT of Perplexity, dan moet je kernboodschap — definitie, cijfers, FAQ — letterlijk in de geleverde HTML staan.

Bekijk de broncode met Ctrl+U (niet de inspector, die toont het gerenderde resultaat) en zoek naar je H1 en je belangrijkste alinea. Of schakel JavaScript uit in de browser en herlaad. Gebruik daarnaast de URL-inspectie in Search Console: 'Bekijk gecrawlde pagina' toont exact welke HTML Google binnenkreeg. Staat je content daar niet in, dan bestaat hij voor crawlers niet.

Opties, van sterk naar zwak: overstappen op een framework met SSR of statische generatie; prerendering inzetten voor crawlers; of minimaal de kritieke content en metadata server-side meesturen. Hydration-fouten en client-side ingespoten meta-tags zijn de twee valkuilen die daarna nog het vaakst voor verschillen tussen bezoeker en crawler zorgen.