Een webshop verloor 47% van zijn zichtbaarheid in AI-zoeken nadat een update veranderde hoe pagina's worden gerenderd. Dezelfde productpagina's scoorden nog steeds in Google. Maar ChatGPT, Claude en Perplexity gaven nul resultaten. Het verschil was JavaScript-rendering.
Dit gebeurt bij elke site die op client-side rendering leunt. Een SaaS-landingspagina gebouwd met Vue.js verschijnt nooit in antwoorden van ChatGPT. Een nieuwssite op een JavaScript-framework heeft geen enkele aanwezigheid in Perplexity. Een kennisbank die content met React rendert, blijft onzichtbaar voor AI-crawlers. Dit zijn geen uitzonderingen. Het is het standaardgedrag van de meeste moderne webframeworks.
Het verschil tussen een site op basis van JavaScript en een site die zichtbaar is voor AI gaat niet over complexiteit of budget. Het gaat erom dat je begrijpt wat er in die eerste milliseconden gebeurt als een crawler langskomt.
Wat AI-crawlers zien als ze je pagina ophalen
De crawler van Google voert JavaScript uit. Hij wacht tot de pagina is gerenderd, legt de uiteindelijke visuele staat vast en indexeert die. De meeste AI-crawlers doen dat niet.
Als de crawler van ChatGPT (GPTBot) op je site komt, gaat het zo: 1. Hij haalt het HTML-bestand op 2. Hij haalt de tekst eruit die in die ruwe HTML zichtbaar is 3. Hij gaat door naar de volgende pagina
De JavaScript die je kop, je productbeschrijving en je artikeltekst rendert, draait nooit. De crawler ziet de verwijzingen naar JavaScript-bestanden, maar negeert ze. Je pagina ziet eruit als een lege schil.
Dit komt doordat AI-crawlers zijn gebouwd op snelheid en efficiëntie. JavaScript uitvoeren is traag. Je moet een browser opstarten, wachten tot bestanden laden, fouten afhandelen en time-outs beheren. Als je dagelijks miljarden pagina's crawlt, wordt JavaScript uitvoeren veel te duur.
Google investeert in die infrastructuur omdat zoekresultaten afhangen van begrip van de visuele weergave. AI-zoekmachines geven voorrang aan het uitlezen van ruwe tekst. Ze zijn gebouwd om feiten en citaten rechtstreeks uit de HTML te halen, niet uit wat er verschijnt nadat JavaScript de pagina heeft omgebouwd.
Welke renderingmethoden problemen geven bij AI-crawlers
Niet elk JavaScript-framework veroorzaakt hetzelfde verlies aan zichtbaarheid. Het probleem zit specifiek bij client-side rendering (CSR), waarbij JavaScript *in de browser* draait en de pagina opbouwt nadat de HTML is geladen.
Client-side rendering (CSR): React, Vue, Angular, Svelte als ze op CSR staan. De HTML komt leeg binnen of met laadplaceholders. JavaScript vult de content in na het downloaden. AI-crawlers wachten niet.
Server-side rendering (SSR): Next.js, Nuxt, Remix, SvelteKit. De server bouwt de pagina met de content al in de HTML. De browser krijgt complete HTML. AI-crawlers zien alles meteen.
Statische generatie (SSG): generatoren voor statische sites. Pagina's worden vooraf gebouwd en als statische HTML-bestanden geplaatst. Er wordt niets gerenderd op het moment van de aanvraag. AI-crawlers krijgen direct alle content.
Single-page applications (SPA's): de categorie met het hoogste risico. Een SPA laadt één HTML-bestand en wisselt met JavaScript de content bij het navigeren. Voor een crawler ziet elke route er hetzelfde uit, tenzij de server elke route apart afhandelt.
Op het moment dat je voor CSR kiest, bouw je een onzichtbare barrière tussen je content en elke AI-crawler op internet.
Waarom dit belangrijker is dan je denkt
AI-zoeken staat nog in de beginfase, maar het gebruik versnelt. Onderzoeken laten zien dat AI-zoekopdrachten sneller groeien dan traditionele zoekopdrachten op het web. ChatGPT, Perplexity en Claude worden voor professionals, studenten en beslissers de belangrijkste hulpmiddelen om onderzoek te doen.
Als iemand in ChatGPT zoekt naar "beste websitebouwers voor kleine bedrijven", kiest de AI welke merken hij noemt. Die keuze hangt af van welke content hij kan lezen. Als jouw pagina op JavaScript draait, ben je onzichtbaar.
Dit is geen probleem van de toekomst. Een analyse uit 2025 van meer dan 500 miljoen GPTBot-verzoeken liet zien dat sites die van JavaScript afhankelijk zijn, aanzienlijk minder citaties kregen dan server-gerenderde concurrenten in dezelfde sector. Het verschil werd groter bij technische content, productpagina's en handleidingen, precies de soorten content waar AI-engines voorrang aan geven.
Voor B2B-bedrijven en webwinkels worden AI-citaties een manier om zich van de concurrentie te onderscheiden. Genoemd worden in een antwoord van ChatGPT of een fragment van Perplexity kan evenveel verkeer opleveren als een plek op de eerste pagina van Google. Maar je kunt niet worden geciteerd als de crawler je content niet kan lezen.
Hoe bepaal je wat je eraan doet
Niet elke site hoeft weg van client-side rendering. De beslissing hangt af van drie dingen: je soort content, je doelgroep en de zakelijke waarde van AI-zichtbaarheid in jouw situatie.
Stel jezelf eerst deze vragen:
Is je content waard om door AI te worden geciteerd? Nieuws, handleidingen, productvergelijkingen, onderzoeksartikelen, deskundig advies. Die worden door AI geciteerd. Technische documentatie, interactieve tools, dashboards die vooral voor ingelogde gebruikers bestaan: die niet. Als je site vooral uit dat laatste bestaat, doet JavaScript-rendering er minder toe.
Zoekt je doelgroep in AI-engines? B2B-professionals, productonderzoekers, studenten, ontwikkelaars. Zij gebruiken AI-zoeken veel. Als je doelgroep heel specifiek is en alleen in Google zoekt, levert AI-zichtbaarheid minder snel iets op.
Wat kost het om onzichtbaar te zijn? Voor een nieuwssite of kennisbank is nul AI-citaties een concurrentienadeel. Voor een bedrijfsintranet of een SaaS alleen voor leden is het niet relevant. Voor een webwinkel hangt het ervan af of je klanten producten ontdekken via aanbevelingen van AI-winkelhulpen.
Als je antwoordt met "content die het waard is om geciteerd te worden", "ja, mijn doelgroep gebruikt AI-zoeken" en "verlies van zichtbaarheid kost echt iets", ga dan door. Zijn de antwoorden gemengd, dan kun je andere prioriteiten stellen.
Server-side rendering: de meest complete oplossing
SSR lost het JavaScript-probleem helemaal op. De server bouwt de complete pagina met alle content voordat hij die naar de browser stuurt. Zodra een crawler langskomt, is de content er al.
Hoe het werkt: als iemand (of een bot) een pagina opvraagt, draait je server je code en maakt de uiteindelijke HTML. Die HTML bevat je kop, je artikeltekst en je productdetails. De browser krijgt een complete pagina en toont die meteen. JavaScript kan de interactiviteit nog steeds verbeteren, maar de content is al toegankelijk.
Platforms die SSR eenvoudig maken: Next.js (React), Nuxt (Vue), Remix, SvelteKit. Deze frameworks zijn speciaal gebouwd om SSR simpel te maken. Je schrijft je componenten één keer, het framework regelt het renderen op de server en de pagina komt kant-en-klaar aan.
De afweging: SSR vraagt serverkracht. Je server verwerkt elk verzoek, bouwt de HTML en stuurt die uit. Dat kost meer CPU en geheugen dan kant-en-klare statische bestanden serveren. Trage of complexe pagina's kunnen de reactietijd verlengen, en dat raakt prestatiemetingen als First Contentful Paint (FCP) en Core Web Vitals.
Voor de meeste sites is de impact op de prestaties klein. Bij drukbezochte sites met complexe pagina's wordt het merkbaar. Dat is op te lossen met caching, edge computing of code-optimalisatie, maar daar moet je architectuurkeuzes voor maken.
Pre-rendering: een lichtere aanpak voor statische content
Bij pre-rendering bouw je je pagina's vooraf en zet je ze online als statische HTML-bestanden. Als een crawler langskomt, krijgt hij direct een complete pagina. Als iemand je site bezoekt, krijgt die een statisch bestand dat razendsnel laadt.
Diensten voor pre-rendering automatiseren dit. Je wijst ze naar je site, ze bezoeken elke URL in je sitemap, renderen elke pagina (waarbij ze de JavaScript uitvoeren), leggen de uiteindelijke HTML vast en geven die statische versies aan crawlers, terwijl browsers de interactieve versie blijven krijgen.
Dit werkt als: je content weinig verandert. Blogberichten, productpagina's, documentatie. Content die hooguit één keer per dag wordt bijgewerkt.
Dit werkt niet als: je content dynamisch is. Voorraadaantallen, gebruikersspecifieke data, realtime informatie, gepersonaliseerde content. Als je pagina er voor elke bezoeker anders uitziet, legt pre-rendering niet alle versies vast.
Kosten en complexiteit: zulke diensten kosten $99 tot $499 per maand, afhankelijk van het aantal pagina's. Je onderhoudt twee versies van je content: één voor de browser (JavaScript) en één die vooraf is gerenderd voor crawlers. Dat verdubbelt het onderhoud. Als je een nieuw artikel plaatst, moet je de statische versie opnieuw bouwen en online zetten.
Voor sites met stabiele content is pre-rendering een praktische middenweg tussen niets doen en overstappen op SSR.
Dynamisch renderen: een tactische optie voor sommige sites
Bij dynamisch renderen detecteert de server welke user agent het verzoek doet. Is het een crawler, dan krijgt die server-gerenderde HTML. Is het een browser, dan krijgt die de JavaScript-versie. Zo behoud je je bestaande techstack en krijgen crawlers toch complete content.
In theorie is het idee elegant. In de praktijk is het kwetsbaar. Je moet:
Een lijst bijhouden van user agents van AI-crawlers en die voortdurend bijwerken zodra er nieuwe crawlers bijkomen. Mis je er één, dan ziet die crawler de lege pagina.
Server-side rendering speciaal voor crawlers bouwen, terwijl je client-side rendering voor browsers houdt. Je bouwt in feite twee versies van je site.
Testen of beide versies gelijk blijven. Een bug in de crawlerversie breekt ongemerkt je zichtbaarheid in AI-zoeken.
Dynamisch renderen werkt voor eenvoudige contentsites. Voor complexe applicaties is het meer gedoe dan het waard is. Als je toch op de server rendert voor crawlers, kun je het net zo goed voor iedereen doen (dat is SSR).
Zo zie je of je site dit probleem nu heeft
Je hoeft niet te gokken. Je kunt het direct controleren.
Bekijk de paginabron: klik met rechts op je pagina, kies "Paginabron weergeven" en zoek op je kop. Staat je kop niet in de ruwe HTML, dan wordt hij met JavaScript gerenderd. AI-crawlers zien hem dan niet.
Haal de pagina op met curl: voer in je terminal curl https://yoursite.com/your-page uit. Staat de content er niet in, dan heeft JavaScript haar gerenderd.
Controleer je robots.txt: als je crawlers blokkeert bij het uitvoeren van JavaScript, zien ze alleen de ruwe HTML. Check je robots.txt-bestand of de crawlinstellingen van je site.
Gebruik een crawltool: een SEO-crawler of vergelijkbare tools halen je pagina's op zoals een crawler dat doet. Verschijnt de content wel in de browser maar niet in de crawler, dan is JavaScript de oorzaak.
Zoek direct in AI-engines: zoek in ChatGPT, Perplexity of Claude naar specifieke zinnen van je pagina's. Als je content nooit verschijnt, heb je een zichtbaarheidsprobleem door JavaScript.
Optimalisatie per platform voor verschillende AI-crawlers
Niet alle AI-crawlers gedragen zich hetzelfde. Ze verschillen in renderingmogelijkheden, crawlfrequentie en voorkeuren voor content.
ChatGPT (GPTBot): voert geen JavaScript uit. Haalt ruwe HTML op. Gebruikt de index van Brave Search voor realtime content. Frequentie: ongeveer wekelijks voor gevestigde content.
Claude (Brave Search): voert geen JavaScript uit. Haalt ruwe HTML op. Geeft voorrang aan verse, gezaghebbende content. Frequentie: wisselt, afhankelijk van signalen voor versheid van content.
Perplexity: voert geen JavaScript uit. Haalt ruwe HTML op. Weegt versheid zwaar. Content die ouder is dan 48 uur kan lager worden gewaardeerd. Frequentie: hoog voor trending onderwerpen, laag voor statische content.
AI Overviews van Google: voert *wel* JavaScript uit, omdat het dezelfde renderinginfrastructuur gebruikt als Google Zoeken. Optimaliseer toch alsof dat niet zo is, dan ben je beter zichtbaar voor andere AI-zoekmachines.
De praktische conclusie: optimaliseer niet voor één crawler. _blocked_ je belangrijkste content op de server en je bent zichtbaar voor allemaal.
Waar WEMASY bij helpt
De websitebouwer van WEMASY maakt standaard server-gerenderde HTML. Elke pagina die je maakt, wordt gebouwd met de content in de HTML voordat die de browser bereikt. Geen JavaScript-rendering. Je pagina's zijn direct zichtbaar voor AI-crawlers.
Als je een websitebouwer kiest en AI-zichtbaarheid is belangrijk voor je bedrijf, moet server-side rendering een eis zijn, geen bijzaak. Bekijk wat er in elk WEMASY-abonnement zit.
Veelgestelde vragen
Kan ik JavaScript gebruiken voor interactieve functies zonder AI-crawlers te blokkeren?
Ja. _blocked_ de kerncontent (je kop, je artikeltekst, je productdetails) op de server en gebruik JavaScript voor extra's (animaties, formuliervalidatie, interactieve widgets). Dit heet "progressive enhancement". De content staat al in de HTML en JavaScript voegt er een laag afwerking aan toe. AI-crawlers zien de kerncontent. Browsers krijgen de volledige interactieve ervaring. Met de websitebouwer van WEMASY stel je dit direct op je eigen website in.
Wordt mijn site trager als ik overstap op server-side rendering?
Dat kan, als je server te zwak is of je pagina's complex zijn. Modern server-side rendering met cachinglagen (zoals edge caching bij een hostingplatform) kan zelfs sneller zijn dan client-side rendering. Voor de meeste sites is het verschil klein. Is prestatie een zorg, test dan eerst in een testomgeving voordat je je vastlegt.
Moet ik mijn hele techstack veranderen?
Als je React, Vue of een ander JavaScript-framework als CSR gebruikt, betekent overstappen op Next.js, Nuxt of een vergelijkbaar SSR-framework dat je je componenten moet herschrijven voor server-rendering. Het is geen snelle wissel. Is je site gloednieuw, kies dan meteen een framework dat SSR als uitgangspunt heeft. Heb je een gevestigde site, dan zijn pre-rendering of dynamisch renderen op korte termijn misschien praktischer.
Wat als AI-crawlers uiteindelijk wel JavaScript uitvoeren?
Mogelijk, maar niet snel. JavaScript uitvoeren kost op grote schaal veel rekenkracht. Zolang de zakelijke waarde van AI-citaties de kosten van de infrastructuur niet rechtvaardigt, blijven crawlers ruwe HTML ophalen. _blocked_ je content nu op de server en verklein je risico.
Schaadt het JavaScript-renderingprobleem van mijn site mijn posities in Google?
Nee. De crawler van Google voert JavaScript uit, dus je posities in Google worden niet geraakt. Het probleem zit bij AI-zoekmachines zoals ChatGPT, Claude en Perplexity. Die voeren geen JavaScript uit. _blocked_ je content op de server als je zichtbaar wilt zijn in AI-zoekresultaten, niet omdat Google het eist. Het is een los probleem van SEO.
Hebben nieuwssites hetzelfde JavaScript-probleem?
Ja, en het wordt vaak over het hoofd gezien. Een nieuwssite op een JavaScript-framework die content client-side rendert, krijgt nul AI-citaties, ook als de content is gepubliceerd en geïndexeerd. Uitgevers ontdekten dit per ongeluk, toen artikelen die scoorden in Google Nieuws nul vermeldingen kregen in ChatGPT of Perplexity. Check je paginabron. Staat je kop er niet in, los het dan op.