Beïnvloedt lazy loading de zichtbaarheid voor AI? Gemengde signalen hierover

Laat me elk type lazy loading uitleggen.

1. Native lazy loading voor afbeeldingen (loading=“lazy”):

<img src="image.jpg" loading="lazy" alt="Beschrijving">

Impact: Over het algemeen prima voor AI-crawlers.

• Afbeeldings-URL staat in de HTML
• Crawlers zien de verwijzing
• Ze hoeven de afbeelding niet te “renderen” om te weten dat die er is

2. JavaScript lazy loading voor afbeeldingen:

<img data-src="image.jpg" class="lazy">
// JS vervangt data-src naar src bij scrollen

Impact: Mogelijk problematisch.

• Zonder JS-uitvoering is src leeg
• Crawlers zien mogelijk de afbeelding niet
• Gebruik liever loading=“lazy”

3. Intersection Observer voor content:

observer.observe(element);
// Laadt content als het element in de viewport komt

Impact: Problematisch voor AI.

• AI-crawlers hebben geen “viewport”
• Scrollen of triggeren niet
• Content wordt mogelijk nooit geladen

4. Oneindig scrollen:

Impact: Zeer problematisch.

• Content na de eerste pagina is onzichtbaar
• Crawlers scrollen niet om loading te triggeren
• Alleen de eerste pagina van de content zichtbaar

De algemene regel:

Als content gebruikersinteractie of aanwezigheid in de viewport vereist om te laden, zien AI-crawlers het waarschijnlijk niet.

Afweging tussen performance en AI-zichtbaarheid.

Waarom we lazy loaden:

• Snellere initiële laadtijd
• Betere Core Web Vitals
• Minder bandbreedtegebruik voor gebruikers

De spanning:

• Wat goed is voor performance kan de AI-zichtbaarheid schaden
• Zeker bij lazy loading die afhankelijk is van JavaScript

De oplossingsaanpak:

Voor afbeeldingen: Native lazy loading geeft beide voordelen. Gebruik dat.

Voor content: Server-render kritieke content. Lazy load alleen:

• Onder-de-vouw aanvullende content
• Aanbevelingen die geen citaatdoel zijn
• UI-verbeteringen die niet indexeerbare content zijn

De prioriteit:

Identificeer welke content je door AI geciteerd wilt hebben. Die content moet in de initiële HTML staan. De rest kun je performance-optimaliseren.

Praktisch voorbeeld:

Artikelpagina:

• Artikeltekst: Altijd in HTML (citaatdoel)
• Gerelateerde artikelen: Mag lazy loaden (geen citaatdoel)
• Reacties: Mag lazy loaden (geen citaatdoel)
• Deelknoppen: Mag lazy loaden (alleen UI)

Wat we weten over het gedrag van AI-crawlers.

GPTBot:

• Basis HTTP-verzoeken
• Minimale JavaScript-uitvoering
• Volgt links die in de HTML staan

ClaudeBot:

• Vergelijkbaar met GPTBot
• HTML-gericht crawlen
• Beperkte omgang met dynamische content

PerplexityBot:

• Geavanceerder
• Kan wat JavaScript afhandelen
• Maar nog steeds vooral HTML-gericht

Overeenkomsten bij allen:

• Geen scrollen
• Geen simulatie van gebruikersinteractie
• Tijdslimiet voor verwerking
• HTML-content krijgt prioriteit

De implicatie:

Content die vereist:

• Scrollen
• Klikinteracties
• Uitgebreide JavaScript-uitvoering
• Aanwezigheid in de viewport

…is waarschijnlijk onzichtbaar voor deze crawlers.

De teststrategie:

1. Bekijk de paginabron (niet inspecteren)
2. Staat je kritieke content daarin?
3. Zo niet, dan zien crawlers het niet

Simpel maar doorslaggevend.

Aanbevelingen voor implementatie.

Voor nieuwe implementaties:

Afbeeldingen:

<img src="image.jpg" loading="lazy" alt="Beschrijving">

Klaar. Native is het beste.

Contentsecties:

<div class="content">
  <!-- Volledige content in de HTML -->
  Volledige artikeltekst hier
</div>

Lazy load alleen visuele verbeteringen, niet de content.

Lijsten/grids:

<ul class="items">
  <li>Item 1</li>
  <li>Item 2</li>
  <!-- Minimaal 10-20 items in de HTML -->
</ul>
<a href="?page=2">Meer laden</a>

Initiële items in de HTML, paginering voor meer.

Voor bestaande implementaties:

Als je JS-afhankelijke lazy loading hebt:

1. Controleer welke content beïnvloed wordt
2. Geef prioriteit aan kritieke citaatdoelen
3. Migreer deze naar server-rendered
4. Houd lazy loading voor niet-kritieke content

De controle:

Na aanpassingen:

curl -s https://jouwsite.com/page | grep "kritieke content frase"

Als het erin staat, zit je goed.

Monitoringperspectief.

Hoe weet je of lazy loading je schaadt:

1. Controleer Am I Cited-data

• Worden pagina’s met lazy loaded content minder geciteerd?
• Vergelijk soortgelijke pagina’s met verschillende implementaties

2. Handmatige test

• Vraag AI naar content in lazy loaded secties
• Kent het die informatie?
• Zo niet, dan is die content mogelijk onzichtbaar

3. Serverlogs

• Hoe interacteren AI-crawlers met je site?
• Krijgen ze volledige responses?

Wat we hebben gezien:

Sites met veel lazy loading (vooral oneindig scrollen):

• 40-60% minder content zichtbaar voor AI
• Lager aantal citaties voor die content
• Opgelost na implementatie van SSR/paginering

Sites met alleen lazy loading voor afbeeldingen:

• Geen significant effect
• Native loading=“lazy” werkt prima

De aanbeveling:

Audit, test, monitor. Ga er niet zomaar vanuit dat je implementatie goed is. Verifieer het.

Duidelijk actieplan nu.

Wat we behouden:

• Native lazy loading voor afbeeldingen – geen problemen

Wat we wijzigen:

Intersection Observer-secties:

• Kritieke content naar initiële HTML verplaatsen
• Alleen UI-verbeteringen lazy loaden

Oneindig scrollen pagina’s:

• Paginering toevoegen
• Eerste 20 items in HTML
• “Meer laden”-knop voor de rest

Testaanpak:

1. Curl-pagina’s na wijzigingen
2. Controleren of kritieke content in de HTML staat
3. AI-zichtbaarheid monitoren met Am I Cited
4. Citaties vergelijken voor/na

Het principe: Content die we door AI geciteerd willen zien = altijd in de HTML Rest = mag performance-geoptimaliseerd zijn

Bedankt voor de technische duidelijkheid!