Lazy loading en AI-crawlers: wanneer het je zichtbaarheid schaadt
Wat is lazy loading en waarom gebruik je het?
Ik ben een groot fan van lazy loading. Echt. Als iemand die al twintig jaar bezig is met webperformance, heb ik de evolutie meegemaakt van "alles in een keer laden en hopen dat het goed komt" naar slimme technieken die alleen laden wat nodig is. Lazy loading is daar een van de mooiste voorbeelden van.
Het idee is simpel: afbeeldingen, video's en soms hele contentblokken laad je pas in als de bezoeker er naartoe scrollt. Snellere pagina, minder bandbreedte, betere Core Web Vitals. Iedereen blij.
Maar wacht. Niet iedereen.
Want er is een groep "bezoekers" die nooit scrollt, nooit klikt en geen JavaScript uitvoert. AI-crawlers. En die groep wordt steeds belangrijker.
GPTBot, ClaudeBot, PerplexityBot: ze gedragen zich als een simpele HTTP-client. HTML ophalen, lezen, weg. Geen scroll-events, geen IntersectionObserver, geen JavaScript. Content die achter lazy loading zit? Die bestaat voor hen letterlijk niet.
Niet alle lazy loading is even schadelijk
Hier moet ik eerlijk zijn: ik heb zelf maandenlang het onderscheid niet scherp genoeg gemaakt. Lazy loading op afbeeldingen via `loading="lazy"` is prima. De HTML staat er gewoon, inclusief alt-tekst en src. Alleen het bestand zelf wordt later geladen. AI-crawlers lezen de context, niet de pixels. Geen probleem.
Maar dan heb je de andere variant. De variant waar ik koude rillingen van krijg.
- JavaScript-gestuurde content via fetch of XHR na pageload: volledig onzichtbaar voor AI-crawlers.
- Tabs en accordions waar content pas laden bij een klik: AI-bots klikken niet.
- Infinite scroll of "laad meer"-knoppen: AI ziet alleen de eerste batch.
- Skeleton screens die via API-calls worden gevuld: de crawler ziet een leeg skelet. Letterlijk.
Wat ik bij klanten tegenkom
Bij Kobalt zien we dit patroon verrassend vaak. Laatst nog bij een e-commerce klant. Prachtige productpagina's. Uitgebreide specificaties, reviews, technische documenten. Alles netjes verdeeld over tabs.
Het probleem? De "Specificaties"- en "Reviews"-tabs laden hun content pas als je erop klikt. Voor Google is dat anno 2026 niet meer zo'n ramp, want Googlebot rendert JavaScript. Maar AI-crawlers? Die zien de tab-labels en verder niets.
Ik heb letterlijk tegen die klant gezegd: "Je hebt fantastische content geschreven die voor de helft van het internet niet bestaat." Dat was een ontnuchterende meeting.
Praktische alternatieven die performance en zichtbaarheid combineren
Gelukkig hoef je niet te kiezen. Dit is niet een of-of-situatie. Het is een kwestie van slim bouwen. Soms moet je gewoon een bunt leggen in plaats van een homerun proberen te slaan.
- Zet kritieke content altijd in de server-rendered HTML. Tekst en structured data horen daar. Decoratieve elementen en zware afbeeldingen mogen lazy loaden.
- Gebruik CSS-only accordions met `` en `
`. De content staat in de HTML, crawlers lezen het gewoon. De browser verbergt het visueel. Elegant en effectief.
- Vervang JavaScript-tabs door een sectie-layout. Alle content op de pagina, CSS doet de visuele structurering. Nul JavaScript, nul crawler-problemen.
- Moet je toch JavaScript-lazy-loading gebruiken? Overweeg server-side rendering voor de content die ertoe doet.
- De `
Open je terminal en doe een simpele curl naar je eigen pagina. Wat je dan ziet, is wat AI-crawlers ook zien. Zoek in die output naar je belangrijkste content. Staat het er niet in? Dan heb je een probleem. Zo simpel is het.
De balans vinden
Kijk, ik ga niet zeggen dat je al je lazy loading moet weggooien. Dat zou hypocriet zijn van iemand die ooit een hele avond heeft besteed aan het shaven van 12 milliseconden van een TTFB. (Mijn vrouw vond het minder indrukwekkend dan ik.)
Maar de balans is zoek bij veel websites. Ze optimaliseren zo agressief voor snelheid dat ze vergeten dat er een groeiende groep bots is die hun content simpelweg niet kan lezen. En die bots bepalen steeds meer of jouw expertise zichtbaar is in AI-antwoorden.
Een goed gebouwde website is als een ecosysteem: alles hangt samen. Performance en zichtbaarheid zijn geen tegenpolen. Ze versterken elkaar, mits je de juiste technische keuzes maakt.
Performance en AI-zichtbaarheid zijn geen tegenpolen. Met de juiste technische keuzes bereik je beide. Maar dan moet je wel bewust kiezen, want de standaard aanpak van veel frameworks gooit content achter JavaScript-muren. Wil je weten hoe jouw site scoort? Onze gratis AEO-scan laat het zien.
Veelgestelde vragen
Heeft lazy loading invloed op mijn reguliere Google-rankings?
Minder dan je denkt, omdat Googlebot JavaScript uitvoert en rendered HTML crawlt. Maar het kost Google meer resources, wat indirect je crawl budget kan beinvloeden. Voor AI-crawlers is het een veel groter probleem. Mijn advies: zet kritieke content altijd in de statische HTML. Dan ben je voor alles gedekt.
Is het `loading="lazy"` attribuut op afbeeldingen een probleem?
Nee. Veilig. De alt-tekst, bestandsnaam en structurele context staan gewoon in de HTML. Het enige wat later wordt geladen is het daadwerkelijke bestand. AI-crawlers lezen geen pixels, dus dat maakt niet uit.
Mijn CMS genereert JavaScript-lazy-loading automatisch. Wat nu?
Check of je CMS server-side rendering kan inschakelen voor kritieke content. Bij WordPress zijn er plugins die JavaScript-output omzetten naar statische HTML. Lukt dat niet? Overweeg een headless aanpak met een statische HTML-laag bovenop je CMS. Meer werk, maar het lost het probleem structureel op. Bij Kobalt helpen we hier regelmatig mee.
Hoe scoort jouw website op AI-gereedheid?
Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.
