Open de devtools, ga naar "View Page Source" (niet de Elements-tab — de échte ruwe HTML), en kijk wat je ziet. Bij veel client-side gerenderde single-page apps is dat antwoord: een lege <div id="root"></div> en een stapel <script>-tags. Voor een browser is dat geen probleem — die voert het JavaScript uit en bouwt de pagina. Voor de meeste AI-crawlers is dat exact wat ze te zien krijgen: niets.
Het probleem in één zin
Als je content pas verschijnt nadat JavaScript is uitgevoerd (hydration), en de crawler die je pagina bezoekt voert geen JavaScript uit, dan bestaat je content voor die crawler niet — ongeacht hoe goed die content is. Dit is precies wat de tekst-in-ruwe-HTML-ratio-check in onze zichtbaarheidsscan meet: hoeveel leesbare tekst zit er in de HTML zoals die vóór JavaScript-uitvoering binnenkomt, ten opzichte van de totale HTML-grootte.
Waarom de meeste AI-crawlers geen JavaScript uitvoeren
JavaScript uitvoeren voor elke gecrawlde pagina is duur: het vereist een headless browser (Chromium of vergelijkbaar), kost aanzienlijk meer rekentijd en tijd per pagina, en schaalt slecht als je miljarden pagina's per dag verwerkt. Googlebot doet dit inmiddels wel voor reguliere indexering, met een render- wachtrij die (soms dagen) vertraging kan geven. Maar de realtime AI-antwoord-crawlers — ChatGPT-User, PerplexityBot — moeten binnen seconden een antwoord opbouwen als iemand een vraag stelt. Daar is geen tijd voor een volledige browser-rendering per bronpagina. Het pragmatische gevolg: reken erop dat AI-crawlers de ruwe HTML lezen en niets anders.
Zelf checken
Twee manieren, van snel naar grondig:
- View Page Source (Ctrl+U in de meeste browsers, niet de Elements-tab van devtools — die toont de gerenderde DOM, niet wat de server stuurde). Zie je je hoofdcontent — de tekst die een bezoeker leest — terug in platte HTML? Dan zit je goed. Zie je vooral lege containers en scripts, dan heb je een probleem.
- curl de pagina zonder JavaScript-engine erbij:
curl https://jouwsite.nlen lees de output. Dit is exact wat de meeste crawlers ontvangen.
Onze scan doet dit automatisch en berekent het percentage leesbare tekst ten opzichte van de totale HTML — onder de 10% wordt het als een risico gemarkeerd.
Fixen: SSR, SSG of pre-rendering
Drie routes, ruwweg van meest naar minst ingrijpend:
- Server-side rendering (SSR). Frameworks als Next.js, Nuxt of SvelteKit renderen de eerste pagina op de server en sturen kant-en-klare HTML. De crawler krijgt volledige content zonder JS nodig te hebben. Dit is de structureel juiste oplossing als je een nieuw project start of een grote herbouw overweegt.
- Static site generation (SSG). Voor content die niet per gebruiker verandert (blogs, marketingpagina's, documentatie) is dit vaak nog beter: de HTML wordt vooraf gebouwd, is razendsnel, en is per definitie volledig aanwezig zonder rendering.
- Pre-rendering / dynamic rendering als tussenstap. Kun je niet meteen naar SSR migreren? Diensten als Prerender.io renderen je pagina met een headless browser en serveren die versie specifiek aan bots (op basis van de
User-Agent-header), terwijl echte gebruikers de normale client-side app krijgen. Niet elegant, maar een werkende noodoplossing tot een structurele fix past in de planning.
Wat níet helpt
Een <noscript>-fallback met een korte samenvatting is beter dan niets, maar geen volwaardige oplossing — het dekt zelden de volledige content, en crawlers die wél renderen (of dienoscript-inhoud negeren) profiteren er niet van. Meer meta-tags toevoegen lost het probleem ook niet op: title en meta description worden apart uitgelezen en zijn meestal al wél aanwezig in de ruwe HTML, maar dat verandert niets aan het feit dat je hoofdcontent — de tekst die daadwerkelijk in een AI-antwoord geciteerd zou moeten worden — onzichtbaar blijft.