TECHNISCHE SEO AI & AGENTS 04 feb. 2026 9 min leestijd

JavaScript rendering: kunnen AI-crawlers je SPA lezen?

Bas Vermeer
Bas Vermeer SEO/AEO Specialist

Het JavaScript-probleem voor AI-crawlers

Modern webdevelopment leunt zwaar op JavaScript-frameworks zoals React, Vue, Angular en Svelte. Single Page Applications (SPA's) laden een minimaal HTML-document en bouwen de volledige interface op via JavaScript. Voor menselijke bezoekers met een moderne browser is dit naadloos. Voor AI-crawlers die geen JavaScript uitvoeren, is je pagina echter effectief leeg.

Dit probleem raakt de kern van AI-zichtbaarheid. Zoals we bespreken in ons artikel over AEO en waarom het belangrijk is, is technische machine-leesbaarheid een van de drie fundamentele pijlers. Een website die onleesbaar is voor AI-crawlers, kan niet worden geciteerd, ongeacht hoe uitstekend de content is.

Het probleem is niet theoretisch. GPTBot (OpenAI), ClaudeBot (Anthropic) en PerplexityBot voeren standaard geen JavaScript uit. Ze verwerken de ruwe HTML-response die je server retourneert. Als die response slechts een leeg div-element en een bundel JavaScript-bestanden bevat, ontvangt de crawler geen bruikbare content.

<!-- Wat een AI-crawler ziet bij een typische SPA -->\n<!DOCTYPE html>\n<html lang="nl">\n<head>\n  <title>Mijn App</title>\n  <meta name="description" content="" />\n</head>\n<body>\n  <div id="app"></div>\n  <script src="/js/app.bundle.js"></script>\n</body>\n</html>\n\n<!-- Geen heading, geen tekst, geen structured data.\n     Voor een AI-crawler is deze pagina volledig leeg. -->
BELANGRIJK

GPTBot, ClaudeBot en PerplexityBot voeren geen JavaScript uit. Alleen Googlebot (die ook Gemini voedt) voert JavaScript uit, maar met een vertraging van seconden tot minuten. Server-side rendering is geen optie, het is een vereiste voor AI-zichtbaarheid.

De rendering-methoden vergeleken

Er zijn vier hoofdbenaderingen voor het renderen van webpagina's, elk met een ander effect op AI-zichtbaarheid.

Client-Side Rendering (CSR)

Bij CSR stuurt de server een minimaal HTML-document en wordt alle content via JavaScript in de browser opgebouwd. Dit is de standaardmodus van de meeste SPA-frameworks. Voor AI-crawlers is dit de slechtst mogelijke situatie: ze ontvangen geen content.

Server-Side Rendering (SSR)

Bij SSR genereert de server de volledige HTML voor elke request. De client ontvangt een compleet document met alle content, heading-structuur en structured data. Na het laden neemt JavaScript het over voor interactiviteit (hydration). Dit is de ideale aanpak voor AI-zichtbaarheid.

Static Site Generation (SSG)

Bij SSG worden pagina's vooraf gerenderd tijdens het build-proces en als statische HTML-bestanden geserveerd. Dit combineert de voordelen van SSR (volledige HTML) met extreem snelle laadtijden. Ideaal voor content die niet vaak wijzigt.

Incremental Static Regeneration (ISR)

ISR combineert SSG met on-demand regeneratie. Pagina's worden statisch geserveerd maar op de achtergrond bijgewerkt wanneer ze verlopen. Dit biedt de snelheid van SSG met de actualiteit van SSR.

// Vergelijking: wat elke rendering-methode oplevert voor crawlers

// CSR (slecht voor AI-crawlers)
// Server stuurt: 
// Crawler ziet: leeg document // SSR (goed voor AI-crawlers) // Server stuurt: volledig gerenderde HTML met content // Crawler ziet: alle tekst, headings, structured data // SSG (goed voor AI-crawlers) // Server stuurt: pre-built HTML bestand // Crawler ziet: alle tekst, headings, structured data // Bonus: extreem lage TTFB // ISR (goed voor AI-crawlers) // Server stuurt: cached HTML, ververst op achtergrond // Crawler ziet: alle tekst, headings, structured data // Bonus: combinatie van snelheid en actualiteit

Oplossingen voor bestaande SPA's

Niet elke organisatie kan haar frontend-architectuur van de ene op de andere dag herschrijven. Gelukkig zijn er tussenoplossingen die de AI-zichtbaarheid van bestaande SPA's verbeteren.

Dynamic rendering (pre-rendering voor bots)

Dynamic rendering detecteert of een request afkomstig is van een bot of een menselijke bezoeker en serveert een andere response. Bots ontvangen een volledig gerenderde HTML-versie, terwijl menselijke bezoekers de standaard SPA krijgen.

# Nginx configuratie voor dynamic rendering
# Detecteer bekende bot user-agents en stuur door naar de pre-renderer

map $http_user_agent $is_bot {
    default                 0;
    ~*GPTBot                1;
    ~*ClaudeBot             1;
    ~*PerplexityBot         1;
    ~*Googlebot             1;
    ~*anthropic-ai          1;
    ~*ChatGPT-User          1;
}

server {
    listen 443 ssl;
    server_name example.nl;

    location / {
        if ($is_bot = 1) {
            proxy_pass http://prerender-service:3000;
        }
        try_files $uri $uri/ /index.html;
    }
}
  • Voordeel: geen grote refactor nodig. Je bestaande SPA blijft ongewijzigd voor menselijke bezoekers.
  • Nadeel: je moet een aparte pre-render service draaien en onderhouden. Er is een risico op cloaking als de gerenderde versie significant afwijkt van de SPA-versie.
  • Services zoals Prerender.io, Rendertron (Google) en Puppeteer kunnen als pre-render engine dienen.

Hybride rendering met frameworks

Moderne frameworks bieden steeds betere ondersteuning voor hybride rendering, waarbij je per pagina kiest welke methode het meest geschikt is.

// Next.js: kies de rendering-methode per pagina

// Server-Side Rendering (voor dynamische content)
export async function getServerSideProps(context) {
    const article = await fetchArticle(context.params.slug);
    return { props: { article } };
}

// Static Site Generation (voor statische content)
export async function getStaticProps(context) {
    const article = await fetchArticle(context.params.slug);
    return {
        props: { article },
        revalidate: 3600, // ISR: hervalideer elk uur
    };
}

// Nuxt 3: hybride rendering configuratie
// nuxt.config.ts
export default defineNuxtConfig({
    routeRules: {
        '/blog/**': { swr: 3600 },  // ISR voor blogposts
        '/': { prerender: true },     // SSG voor homepage
        '/api/**': { cors: true },    // API routes
    },
});

Hoe test je wat AI-crawlers zien?

Voordat je optimalisaties doorvoert, is het essentieel om te begrijpen wat AI-crawlers daadwerkelijk zien wanneer ze je website bezoeken. Er zijn meerdere methoden om dit te testen.

  1. Curl met bot user-agent: curl -A "GPTBot" https://jouwsite.nl geeft je exact de HTML die GPTBot ontvangt. Als je hier geen content ziet, zien AI-crawlers het ook niet.
  2. Google Rich Results Test: hoewel ontworpen voor Google, toont deze tool de gerenderde HTML na JavaScript-uitvoering. Vergelijk dit met de ruwe HTML om het verschil te zien.
  3. View Source versus Inspect Element: in je browser toont "View Source" de ruwe HTML (wat crawlers zien), terwijl "Inspect Element" de gerenderde DOM toont (na JavaScript). Het verschil is veelzeggend.
  4. Lighthouse SEO-audit: Lighthouse controleert of cruciale elementen beschikbaar zijn in de initiele HTML, zonder JavaScript.
# Test wat AI-crawlers zien van je website

# Simuleer GPTBot
curl -s -A "GPTBot" https://jouwsite.nl | head -100

# Simuleer ClaudeBot
curl -s -A "ClaudeBot" https://jouwsite.nl | head -100

# Controleer of er content in de initiele HTML zit
curl -s https://jouwsite.nl | grep -c '<h1\|<h2\|<p'
# Als dit 0 retourneert, is je pagina leeg voor AI-crawlers

Structured data en JavaScript

Een veelgemaakte fout is het injecteren van Schema.org JSON-LD via JavaScript. Als je structured data pas beschikbaar is na JavaScript-uitvoering, missen AI-crawlers die geen JavaScript ondersteunen deze cruciale metadata volledig. Plaats JSON-LD altijd in de initiele server-response, in de HTML head, ongeacht je rendering-methode.

<!-- GOED: JSON-LD in de initiele HTML -->\n<head>\n  <script type="application/ld+json">\n  {\n    "@context": "https://schema.org",\n    "@type": "Article",\n    "headline": "JavaScript rendering en AI-crawlers",\n    "author": {"@type": "Organization", "name": "AEO Expert"}\n  }\n  </script>\n</head>\n\n<!-- FOUT: JSON-LD via JavaScript inject -->\n<script>\n  // Dit zien AI-crawlers NIET\n  const script = document.createElement('script');\n  script.type = 'application/ld+json';\n  script.text = JSON.stringify(schemaData);\n  document.head.appendChild(script);\n</script>
JavaScript is een krachtige tool voor gebruikerservaring, maar het is een muur voor AI-crawlers. Elke byte content die je uitsluitend via JavaScript levert, is onzichtbaar voor het merendeel van de AI-modellen.

Samenvatting: de belangrijkste punten

  • De meeste AI-crawlers (GPTBot, ClaudeBot, PerplexityBot) voeren geen JavaScript uit en zien alleen de ruwe HTML-response van je server.
  • Client-side rendered SPA's zijn effectief onzichtbaar voor AI-modellen. Server-side rendering is een vereiste voor AI-zichtbaarheid.
  • Dynamic rendering (pre-rendering voor bots) is een tussenoplossing voor bestaande SPA's die niet direct kunnen worden omgebouwd.
  • Plaats Schema.org JSON-LD altijd in de initiele HTML, nooit via JavaScript-injectie, om alle AI-crawlers te bereiken.
  • Test je website met curl en een bot user-agent om te verifieren wat AI-crawlers daadwerkelijk ontvangen.

Veelgestelde vragen

Voert Googlebot JavaScript uit?

Ja, Googlebot is een van de weinige crawlers die JavaScript uitvoert. Google gebruikt een headless Chrome-browser om pagina's te renderen. Er zit echter een vertraging tussen het eerste bezoek en het renderen, die kan oplopen van seconden tot dagen. Voor tijdkritische content is server-side rendering daarom ook voor Googlebot aan te raden. Andere AI-crawlers zoals GPTBot en ClaudeBot voeren geen JavaScript uit.

Is Next.js of Nuxt beter voor AI-zichtbaarheid?

Beide frameworks bieden uitstekende ondersteuning voor server-side rendering en static site generation. Next.js (React) en Nuxt (Vue) leveren standaard volledig gerenderde HTML die AI-crawlers probleemloos kunnen verwerken. De keuze tussen beiden hangt meer af van je teamervaring dan van AI-specifieke overwegingen. Het belangrijkste is dat je de SSR- of SSG-modus daadwerkelijk activeert en niet terugvalt op pure client-side rendering.

Kan ik cloaking-problemen krijgen met dynamic rendering?

Google beschouwt dynamic rendering niet als cloaking, mits de gerenderde content substantieel overeenkomt met wat menselijke bezoekers zien. Het verschil mag zitten in de weergave (CSS, interactieve elementen), maar niet in de inhoud. Als je bots fundamenteel andere content serveert dan bezoekers, riskeer je een cloaking-penalty. Zorg ervoor dat de pre-gerenderde versie dezelfde tekst, headings en structured data bevat als de client-side versie.

Hoe ga ik om met lazy-loaded content?

Content die pas bij scrollen wordt geladen (lazy loading) is problematisch voor AI-crawlers, omdat deze niet scrollen. Zorg dat alle primaire content (tekst, headings, structured data) in de initiele HTML-response zit. Lazy loading is acceptabel voor niet-essientiele elementen zoals afbeeldingen lager op de pagina of gerelateerde artikelen. Gebruik het loading="lazy" attribuut voor afbeeldingen, maar niet voor content.

Moet ik mijn React-app volledig herschrijven voor AI-zichtbaarheid?

Niet per se. Als je React gebruikt zonder server-side rendering, zijn er meerdere stappen voordat een volledige herschrijving nodig is. Begin met het toevoegen van pre-rendering voor bots via een service als Prerender.io. Overweeg vervolgens een migratie naar Next.js, dat server-side rendering als standaard biedt. Een volledig herschrijven naar een traditioneel server-gerenderd framework is pas nodig als de pre-rendering aanpak onvoldoende resultaat oplevert.

De beste JavaScript is het JavaScript dat de server al voor de crawler heeft uitgevoerd. AI-zichtbaarheid begint bij de HTML die je server retourneert, niet bij het JavaScript dat je client uitvoert.

Hoe scoort jouw website op AI-gereedheid?

Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.

Gratis scan

DEEL DIT ARTIKEL

LINKEDIN X

GERELATEERDE ARTIKELEN