Het is een vraag die steeds vaker opkomt in GEO-discussies: beïnvloedt de snelheid van je website hoe vaak AI-systemen je als bron citeren? Het korte antwoord is ja, maar niet op de manier die je misschien verwacht.

Er is geen directe ranking-factor waarbij een AI-model denkt: "Deze site laadt snel, dus ik citeer hem vaker." Het verband is subtieler en werkt via meerdere indirecte routes. In dit artikel ontleden we die routes, bekijken we benchmarks en geven we praktische optimalisatietips die specifiek gericht zijn op AI-zichtbaarheid.

De vraag: beïnvloedt sitesnelheid AI-citaties?

Laten we eerst het directe en indirecte verband onderscheiden.

Direct effect: crawler timeouts

AI-crawlers — GPTBot, PerplexityBot, ClaudeBot en andere — werken met timeoutlimieten. Ze wachten niet oneindig op een response van je server. Uit analyse van crawlergedrag in serverlogboeken blijkt dat de meeste AI-bots een request afbreken na 5 tot 10 seconden.

Wat betekent dit in de praktijk?

• Trage serverresponse (hoge TTFB): Als je server er 4 seconden over doet om de eerste byte te verzenden, heeft de crawler nog maar 1-6 seconden voor de rest. Bij complexe pagina's is dat onvoldoende.
• Grote pagina's: Als je HTML-document 2 MB is door inline-CSS, ongecomprimeerde afbeeldingsdata of excessieve JavaScript, kan de download-tijd de timeout overschrijden.
• Onbeschikbaarheid: Servers die onder piekbelasting traag worden, missen crawlerbezoeken. AI-bots komen niet op een voorspelbaar tijdstip terug.

Het directe effect is binair: als de crawler je content kan ophalen, heb je een kans op citatie. Als de crawler een timeout krijgt, is die kans nul.

Indirect effect via Google Rankings

Google AI Overviews — de AI-gegenereerde samenvattingen bovenaan zoekresultaten — selecteren bronnen primair uit de reguliere zoekindex. Google gebruikt Core Web Vitals als ranking-signaal sinds 2021. Dat betekent:

1. Betere Core Web Vitals dragen bij aan hogere Google-rankings
2. Hogere Google-rankings vergroten de kans dat je als bron verschijnt in AI Overviews
3. Verschijnen in AI Overviews betekent directe citatie door Google's AI

Dit is een indirect maar significant verband. Sites die consistent goede Web Vitals scoren, hebben een structureel voordeel in de AI Overviews-bronselectie.

Indirect effect via Bing

Bing levert de zoekindex voor Microsoft Copilot en fungeert als een van de bronnen voor ChatGPT Search. Net als Google weegt Bing paginasnelheid mee als rankingfactor. Betere performance in Bing vertaalt zich naar meer zichtbaarheid in Copilot en ChatGPT.

Dit maakt Core Web Vitals een factor die op drie fronten tegelijk werkt: direct via crawler-bereikbaarheid, indirect via Google en indirect via Bing.

De drie Core Web Vitals

Even een korte opfrisser van de drie metrics die Google als Core Web Vitals hanteert.

LCP (Largest Contentful Paint)

LCP meet hoe lang het duurt voordat het grootste zichtbare element op de pagina is gerenderd. Dit kan een afbeelding, video of groot tekstblok zijn.

• Goed: onder 2,5 seconden
• Matig: 2,5 tot 4 seconden
• Slecht: meer dan 4 seconden

Relevantie voor AI: LCP correleert met de totale laadtijd van je pagina. Een hoge LCP wijst vaak op trage serverrespons of blokkerende resources — factoren die ook AI-crawlers raken.

INP (Interaction to Next Paint)

INP meet de responsiviteit van je pagina bij gebruikersinteracties. Het vervangt sinds maart 2024 de oude FID-metric.

• Goed: onder 200 milliseconden
• Matig: 200 tot 500 milliseconden
• Slecht: meer dan 500 milliseconden

Relevantie voor AI: INP is primair een gebruikerservaring-metric. AI-crawlers interacteren niet met je pagina, dus het directe effect is nihil. Maar INP beïnvloedt je Google-ranking, wat indirect je AI Overviews-zichtbaarheid beïnvloedt.

CLS (Cumulative Layout Shift)

CLS meet visuele stabiliteit — hoeveel elementen op je pagina onverwacht verschuiven tijdens het laden.

• Goed: onder 0,1
• Matig: 0,1 tot 0,25
• Slecht: meer dan 0,25

Relevantie voor AI: Net als INP is CLS vooral relevant als Google-rankingfactor. Er is geen direct effect op AI-crawling.

Benchmarks: wat is snel genoeg voor AI-crawlers?

Op basis van crawlergedrag en serverlog-analyses hanteren we de volgende benchmarks specifiek voor AI-zichtbaarheid:

De kritische grens ligt bij de totale HTML-response tijd. AI-crawlers lezen de HTML — niet de gerenderde pagina. Een TTFB van 200 ms met een HTML-document van 50 KB is ideaal. Een TTFB van 3 seconden met een document van 5 MB is een recept voor gemiste crawls.

Belangrijk: deze benchmarks gaan over de server-response, niet de volledig gerenderde pagina. AI-crawlers laden geen afbeeldingen, CSS of JavaScript. De metrics die ertoe doen zijn TTFB en de grootte en levertijd van het HTML-document.

Praktische optimalisatietips voor AI-crawling

1. Optimaliseer serverresponstijd (TTFB)

TTFB is de belangrijkste metric voor AI-crawlers. Elke milliseconde telt.

# Nginx: schakel gzip-compressie in voor HTML
gzip on;
gzip_types text/html text/plain application/json application/ld+json;
gzip_min_length 256;

# Stel cache headers in voor statische pagina's
location /blog/ {
    add_header Cache-Control "public, max-age=3600, stale-while-revalidate=86400";
}

Acties:

• Gebruik server-side caching (Redis, Varnish, of CDN edge caching)
• Optimaliseer database-queries die bij elke pageload worden uitgevoerd
• Overweeg SSG of ISR in plaats van SSR voor content die niet real-time hoeft te zijn

Meer over rendering-strategieën lees je in SSR en AI-zichtbaarheid.

2. Gebruik een CDN

Een Content Delivery Network serveert je content vanuit servers dicht bij de crawler. De meeste AI-crawlers opereren vanuit datacenters in de VS. Een CDN met nodes in Noord-Amerika zorgt voor snellere responses naar deze bots.

Populaire opties:

• Cloudflare (gratis tier al effectief)
• Vercel Edge Network (geïntegreerd met Next.js)
• AWS CloudFront

3. Minimaliseer render-blokkerende resources

Hoewel AI-crawlers geen CSS of JavaScript laden, beïnvloeden render-blokkerende resources je Core Web Vitals en daarmee je Google-ranking.

<!-- Vermijd: render-blokkerend CSS -->
<link rel="stylesheet" href="/styles.css">

<!-- Beter: critical CSS inline, rest asynchroon -->
<style>
  /* Critical CSS hier */
  body { font-family: system-ui; margin: 0; }
  h1 { font-size: 2rem; }
</style>
<link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">

4. Optimaliseer afbeeldingen

Afbeeldingen zijn vaak de grootste boosdoener bij trage pagina's. Ze beïnvloeden je LCP direct.

<!-- Gebruik moderne formaten -->
<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="Beschrijving" width="1200" height="630" loading="lazy">
</picture>

Checklist:

• Gebruik WebP of AVIF-formaten
• Stel expliciete width en height in (voorkomt CLS)
• Gebruik loading="lazy" voor afbeeldingen onder de fold
• Comprimeer afbeeldingen tot maximaal 200 KB per stuk

5. Beperk JavaScript-payload

Excessieve JavaScript raakt je INP en LCP. Elke kilobyte JavaScript die de browser moet parsen en uitvoeren, vertraagt de interactiviteit.

# Analyseer je JavaScript-bundle
npx webpack-bundle-analyzer stats.json

# Of met Next.js
ANALYZE=true npm run build

Richtlijn: Houd je totale JavaScript-payload onder 300 KB (gecomprimeerd). Verwijder ongebruikte dependencies, splits je code in chunks en laad niet-kritieke scripts asynchroon.

Hoe meet je het?

PageSpeed Insights

PageSpeed Insights geeft je zowel lab-data (gesimuleerd) als field data (echte gebruikersgegevens via CrUX). Check je belangrijkste pagina's maandelijks.

Google Lighthouse

Lighthouse biedt gedetailleerdere diagnostiek dan PageSpeed Insights. Draai het lokaal voor consistentere resultaten:

npx lighthouse https://jouwsite.nl --output=html --output-path=./rapport.html

Serverlogboeken

De meest directe manier om te meten of AI-crawlers problemen ervaren is door je serverlogboeken te analyseren:

# Zoek naar AI-crawler requests en hun responstijd
grep -E "GPTBot|PerplexityBot|ClaudeBot|ChatGPT-User" access.log | \\
  awk '{print $1, $7, $NF}' | head -20

Let op HTTP 408 (timeout) of 503 (service unavailable) responses naar AI-bots. Elke mislukte request is een gemiste kans op citatie.

De samenhang met rendering-strategie

Core Web Vitals en rendering-strategie zijn nauw verbonden. SSG en ISR scoren inherent beter op TTFB en LCP dan SSR, omdat er geen server-side processing plaatsvindt bij elk request. CSR scoort vaak het slechtst op LCP omdat de content pas zichtbaar wordt na JavaScript-uitvoering.

De optimale combinatie voor AI-zichtbaarheid:

1. SSG of ISR voor de rendering-strategie (zie onze SSR deep-dive)
2. CDN voor distributie
3. Geoptimaliseerde afbeeldingen voor LCP
4. Minimale JavaScript voor INP
5. Expliciete afmetingen voor CLS

Conclusie

Het verband tussen Core Web Vitals en AI-citaties is reëel, maar werkt via meerdere routes. Het directe effect — crawlers die je content niet kunnen ophalen door trage servers — is het meest kritisch. De indirecte effecten via Google- en Bing-rankings zijn subtieler maar cumulatief significant.

Focus op wat AI-crawlers direct raakt: TTFB, HTML-responsegrootte en serverbeschikbaarheid. Optimaliseer daarnaast je Core Web Vitals voor de indirecte effecten op je rankings. Samen vormen ze de technische basis waarop je GEO-strategie rust.

Voor het volledige overzicht van technische GEO-optimalisaties, zie onze Technische GEO-checklist.

Lees ook

• vindbaar worden in AI-zoekmachines