Je hebt je content geoptimaliseerd. Je site heeft expertise, gezag en signalen van vertrouwen. Maar als een AI-crawler je pagina bereikt en tegen een time-out aanloopt, doordat je server er 6 seconden over doet om te reageren of doordat LCP na 5 seconden nog niet is opgebouwd, gaat de crawler verder. Je content wordt nooit geïndexeerd. Je vermeldingen komen er nooit.
Traagheid doodt zichtbaarheid. Niet langzaam, maar direct en definitief.
AI-crawlers werken met beperkingen die gewone zoekmachines niet hebben. Ze hebben strikte time-outs, beperkte rekenbudgetten en weinig geduld. Een pagina die perfect scoort op Google, kan volledig onzichtbaar zijn voor ChatGPT, Perplexity of Claude omdat ze niet binnen de deadline van de crawler laadt. Dit hoofdstuk legt uit hoe Core Web Vitals werken voor AI, welke metrics het zwaarst tellen en wat je moet veranderen.
Wat Core Web Vitals meten en waarom ze bestaan
Core Web Vitals zijn drie metrics die Google heeft gemaakt om de echte ervaring van gebruikers te meten. Ze leggen vast wanneer de browser content begint te tonen, wanneer gebruikers met de pagina kunnen werken en hoe stabiel de opmaak blijft tijdens het laden. Google behandelt ze als rankingfactoren. Maar voor AI-crawlers zijn ze een kwestie van overleven.
De drie metrics zijn:
Largest Contentful Paint (LCP): hoe lang het duurt voordat het grootste visuele element is geladen. Het doel is onder 2,5 seconden. Dit is wat gebruikers als eerste zien. Als je hoofdafbeelding, kop of belangrijkste stuk content er 4 seconden over doet om te verschijnen, moeten zowel mensen als crawlers wachten.
Interaction to Next Paint (INP): hoe lang het duurt voordat de browser reageert nadat een gebruiker ergens op klikt. Het doel is onder 200 milliseconden. Deze metric test of je JavaScript te zwaar is of je pagina vastloopt als crawlers interactie nabootsen.
Cumulative Layout Shift (CLS): hoeveel de pagina rondspringt tijdens het laden. Het doel is onder 0,1. Als elementen onverwacht verschuiven, halen crawlers verhaspelde of onvolledige content op. Je zorgvuldig geschreven alinea's komen door elkaar bij de crawler terecht.
Voor gewoon zoeken zijn dit aanwijzingen. Voor AI-crawlers zijn het harde grenzen.
Waarom AI-crawlers andere eisen aan snelheid stellen dan Google
De crawler van Google verdeelt het werk. Hij crawlt miljoenen URL's over duizenden servers. Hij kan het zich permitteren 10 seconden te wachten tot een pagina laadt, omdat die wachttijd over een enorme infrastructuur wordt verspreid.
AI-crawlers werken per zoekopdracht. Als een gebruiker ChatGPT een vraag stelt, heeft Perplexity 3 tot 5 seconden om je content te vinden, op te halen en te lezen voordat het antwoord moet beginnen. Elke seconde telt. Elke milliseconde gaat af van het crawlbudget.
Onderzoeken naar het gedrag van AI-crawlers laten zien dat sites met een First Contentful Paint onder 0,4 seconden gemiddeld 6,7 vermeldingen krijgen, terwijl sites die er meer dan 1,13 seconden over doen, gemiddeld 2,1 vermeldingen krijgen. Dat is geen toeval. Dat is oorzaak en gevolg. Trage pagina's worden overgeslagen.
De crawler van ChatGPT voor het ophalen van pagina's heeft een gedocumenteerde grens voor time-outs. Pagina's die niet binnen dat venster reageren, worden gemarkeerd als onbereikbaar en krijgen bij latere pogingen minder voorrang. De bot van Perplexity doet hetzelfde. Een site die er 6 seconden over doet om te reageren, krijgt geen tweede kans.
Time to First Byte (TTFB): de metric waar AI-crawlers het meest om geven
TTFB meet het moment tussen het sturen van een verzoek en het ontvangen van de eerste byte van de server. Het is de zuiverste maat voor hoe snel je server reageert.
Voor AI-crawlers bepaalt TTFB of ze het renderen überhaupt proberen. Als je server er 700 milliseconden over doet om te reageren, heeft de crawler 700 milliseconden van zijn venster van 3 tot 5 seconden verspild. De crawler laat het renderen helemaal vallen en leest alleen de HTML. Dat betekent dat content die met JavaScript wordt opgebouwd, onzichtbaar wordt.
De richtwaarden zijn duidelijk. Een TTFB onder 200 milliseconden is uitstekend. 200 tot 500 milliseconden is acceptabel maar niet ideaal. Boven 600 milliseconden heb je een probleem met je serverinfrastructuur.
De meeste artikelen over snelheid zien TTFB als minder belangrijk dan visuele metrics. Voor AI-crawlers is het de poortwachter. Als TTFB faalt, doet niets anders ertoe.
Veelvoorkomende oorzaken van een trage TTFB zijn trage databasequery's bij elke paginalading, overbelaste hosting met te veel sites per server, slechte geografische routering van verzoeken en het ontbreken van caching via een content delivery network (CDN). Dit zijn geen ontwerpproblemen. Dit zijn infrastructuurproblemen.
Largest Contentful Paint (LCP): wachten op het grote element
LCP meet de tijd tot het grootste visuele element helemaal is geladen. Dat is meestal een hoofdafbeelding, een achtergrondafbeelding of een groot stuk tekst. Bij pagina's met veel content is het het gebied met de hoofdinhoud.
Een LCP onder 2,5 seconden is de grens voor "goed". AI-crawlers halen pagina's in dit bereik 2,8 keer vaker aan dan pagina's met een tragere LCP. Het verschil is niet subtiel.
De crawler wacht niet tot elk element is geladen. Maar hij wacht wel tot de hoofdinhoud verschijnt. Is je hoofdafbeelding 4 megabyte en heb je haar niet geoptimaliseerd voor het web, dan zit de crawler stil te wachten terwijl de afbeelding downloadt. Tegen de tijd dat de afbeelding klaar is met laden, zit je al over de time-out van de crawler.
Veelvoorkomende oorzaken van een trage LCP zijn te grote afbeeldingen zonder compressie, niet-geoptimaliseerde ingesloten video's die het renderen blokkeren, webfonts die niet zijn beperkt tot de tekens die je nodig hebt en niet snel laden, en scripts van derden die boven de vouw worden opgebouwd. Elk daarvan voegt seconden toe aan LCP.
De oplossing is niet langer wachten. De oplossing is LCP sneller laten gebeuren. Dat betekent afbeeldingen optimaliseren, content onder de vouw pas laden als die nodig is (lazy loading), scripts asynchroon laden en eventueel zware ingesloten onderdelen van derden vervangen door statische HTML.
Interaction to Next Paint (INP): hoe goed JavaScript wordt uitgevoerd
INP meet hoe snel de pagina reageert. Als een gebruiker (of een crawler die een gebruiker nabootst) iets doet op de pagina, hoe lang duurt het voordat er iets verandert op het scherm? Het doel is onder 200 milliseconden.
Voor AI-crawlers laat INP zien of je JavaScript is geoptimaliseerd of te zwaar is. Een slechte INP-score laat zien dat je pagina te veel code op de hoofdthread draait, of dat code niet goed is opgedeeld en uitgesteld.
Crawlers die interactie nabootsen, doen dat om dynamische content op te halen. Laadt je pagina statische HTML maar hangt ze af van JavaScript om formulieren, voorwaardelijke content of interactieve onderdelen op te bouwen, dan moet de crawler dat JavaScript uitvoeren. Is het JavaScript traag, dan krijgt de crawler een slechte INP-score en markeert hij je pagina als inefficiënt.
Het verborgen probleem van renderen aan de kant van de bezoeker is dat de meeste AI-crawlers helemaal geen JavaScript renderen. Onderzoek laat zien dat statische HTML met schema-markup 94% van de keren goed wordt gelezen, terwijl content die met JavaScript wordt opgebouwd op 23% uitkomt. Dat betekent dat als je content achter JavaScript zit, AI-crawlers haar misschien nooit zien.
Gebruikt je site rendering aan de kant van de bezoeker, dan wordt het INP-probleem een zichtbaarheidsprobleem. De crawler kan niet wachten tot JavaScript is uitgevoerd, dus slaat hij content over die van JavaScript afhangt.
Cumulative Layout Shift (CLS): stabiliteit tijdens het ophalen
CLS meet visuele instabiliteit. Als elementen op de pagina tijdens het laden verschuiven, stijgt de Cumulative Layout Shift. Het doel is onder 0,1.
Voor crawlers gaat CLS niet over gebruikservaring. Het gaat over hoe nauwkeurig ze content lezen. Als de DOM verschuift terwijl de crawler content ophaalt, pakt hij misschien de verkeerde elementen. Een kop kan in de ruimte van een andere kop schuiven. Een zijbalk kan de hoofdinhoud van zijn plek duwen. De crawler haalt de tekst op die op een positie staat, niet de tekst die er logisch hoort.
Veelvoorkomende oorzaken van een hoge CLS zijn advertentieruimtes die laat laden en content naar beneden duwen, afbeeldingen zonder opgegeven afmetingen die laden en de opmaak verschuiven, webfonts die wisselen en de afstanden veranderen, en carrousels die automatisch afspelen en content verschuiven. Elk daarvan laat de opmaak bewegen.
De oplossing is ruimte reserveren voor alles wat nog laadt. Geef afmetingen van afbeeldingen op in HTML. Stel font-display in op swap, zodat fonts het renderen niet blokkeren. Laad advertenties en dynamische content in gereserveerde vakken die de opmaak niet laten verschuiven.
Zo optimaliseer je voor de snelheid van AI-crawlers
Snelheid optimaliseren voor AI-crawlers is anders dan snelheid optimaliseren voor mensen. Gebruikers letten op wanneer ze de pagina zien en wanneer ze ermee kunnen werken. Crawlers letten op wanneer de server reageert en of alle content klaar is met renderen.
Begin met TTFB. Als je server er meer dan 500 milliseconden over doet om te reageren, doet niets anders ertoe. Controleer je databasequery's, stap over naar snellere hosting, voer caching in op het niveau van de applicatie of gebruik een CDN. Wat je in TTFB investeert, verdien je meteen terug in dekking door crawlers.
Optimaliseer afbeeldingen. Elke afbeelding op je pagina moet worden gecomprimeerd, verkleind tot de getoonde afmetingen en geleverd in moderne formaten zoals WebP, met PNG als terugvaloptie. Gebruik een tool voor het comprimeren van afbeeldingen. Gebruik voor hoofdafbeeldingen een CDN met automatische optimalisatie.
Stel JavaScript uit dat niet kritiek is. Laad alleen JavaScript dat absoluut nodig is om de crawler de content te laten zien. Scripts die analyses bijhouden, advertenties laden of interactieve functies aansturen, moet je uitstellen of asynchroon laden. Zo blijft de hoofdthread vrij en gaat het uitvoeren snel.
_blocked_ kritieke content op de server. Gebruikt je site een clientframework, _blocked_ dan het kritieke pad op de server en maak het interactief aan de kant van de bezoeker. Zo zien crawlers de content direct. Statische sitegeneratie (SSG) is nog beter: bouw je pagina's bij het uitrollen om tot HTML.
Vermijd grote ingesloten onderdelen van derden. Sluit je videospelers, muziekspelers of grote externe widgets in, dan blokkeren die het renderen. Vervang ze door plaatshouders die pas laden na een klik, of zet de essentiële informatie in statische HTML.
Reserveer ruimte voor dynamische content. Geef duidelijke afmetingen op voor afbeeldingen, advertenties en dynamische onderdelen. Zo voorkom je verschuivingen in de opmaak en haalt de crawler de juiste content op.
Gebruik een CDN. Een content delivery network stuurt verzoeken naar de server die geografisch het dichtstbij staat, zodat de vertraging en TTFB dalen. De meeste CDN's bieden ook automatische optimalisatie en compressie van afbeeldingen.
Wat WEMASY biedt voor snelheid en optimalisatie voor crawlers
De websitebouwer van WEMASY bevat hosting met automatische CDN-caching, optimalisatie van afbeeldingen bij het uploaden en rendering op de server van alle content van je site. Pagina's die met WEMASY zijn gebouwd, voldoen standaard aan de normen van Core Web Vitals.
Als je een site publiceert met WEMASY, wordt je TTFB geoptimaliseerd via ons CDN, worden je afbeeldingen automatisch verkleind en gecomprimeerd en worden je pagina's als statische HTML geleverd, niet op aanvraag gemaakt. Dat betekent dat AI-crawlers je content direct zien, zonder te wachten op renderen of verwerken.
Bekijk wat er zit in de abonnementen van WEMASY.
Veelgestelde vragen
Beïnvloedt de snelheid van een pagina AI-vermeldingen meer dan gewone SEO?
AI-crawlers zijn gevoeliger voor snelheid, omdat ze met strengere tijdslimieten werken. Gewone crawlers van Google kunnen 10 seconden wachten tot een pagina laadt. AI-crawlers geven meestal na 3 tot 5 seconden een time-out. Bij gewone SEO is snelheid een rankingsignaal. Bij GEO is snelheid een drempel. Haal je die niet, dan komen er helemaal geen vermeldingen. Met de websitebouwer van WEMASY zet je dit direct op je eigen website.
Hoe weet ik of mijn TTFB snel genoeg is voor AI-crawlers?
Gebruik een gratis tool die de snelheid van je pagina's test (test de desktopversie, alsof je een crawler bent). Zoek naar een TTFB onder 500 ms. Is die hoger, dan moet je je hosting, database of applicatiecode onderzoeken. Ook andere gratis tools laten TTFB zien. Is je TTFB steeds hoger dan 600 ms, neem dan contact op met je hostingaanbieder of overweeg over te stappen naar snellere hosting.
Moet ik optimaliseren voor Core Web Vitals als ik mijn gewone posities op Google niet volg?
Ja. Core Web Vitals hebben direct invloed op zichtbaarheid in AI. Onderzoek laat zien dat 85% van de sites die AI-platforms aanhalen, aan alle drie de drempels van Core Web Vitals voldoet. Ook als je posities op Google niet belangrijk zijn voor je bedrijf, is zichtbaarheid in AI dat wel. De optimalisatie is dezelfde.
Is het de moeite waard om over te stappen naar snellere hosting alleen voor Core Web Vitals?
Als je huidige TTFB boven 600 ms ligt, ja. Het prijsverschil tussen basishosting en snelle hosting is meestal $5 tot $15 per maand. Het rendement van meer vermeldingen in AI en meer dekking door crawlers is aanzienlijk hoger. Snelle hosting verbetert ook de gebruikservaring en de conversie, niet alleen hoe goed crawlers je site kunnen lezen.
Verbetert caching Core Web Vitals?
Caching is onmisbaar. Caching in de browser zorgt dat de browsers van bezoekers afbeeldingen en statische bestanden lokaal bewaren, zodat ze die niet opnieuw hoeven te downloaden. Caching op de server bewaart volledig opgebouwde pagina's in het geheugen, zodat ze niet steeds opnieuw hoeven te worden gebouwd. Beide verlagen TTFB en LCP sterk. Stel cacheheaders ruim in en gebruik een CDN met automatische caching.
Schaadt optimaliseren voor de snelheid van AI-crawlers de gebruikservaring?
Nee. Optimalisaties voor de snelheid van crawlers, zoals snellere servers, compressie van afbeeldingen en uitstellen van JavaScript, verbeteren de gebruikservaring over de hele linie. Pagina's die sneller laden voor crawlers, laden ook sneller voor mensen. De enige uitzondering is als je puur voor crawlers probeert te optimaliseren door afbeeldingen te verwijderen of content af te kappen, want dat schaadt gebruikers. Doe dat niet. Optimaliseer voor snelheid zonder waarde weg te halen.