Technische SEO voor afbeeldingen

Afbeeldingen maken een pagina sterker.

Ze laten producten zien.
Ze ondersteunen uitleg.
Ze geven sfeer.
Ze maken content scanbaar.
Ze kunnen verkeer opleveren via Google Afbeeldingen.

Maar afbeeldingen kunnen je technische SEO ook flink in de weg zitten.

Een te zware hero-afbeelding kan je LCP vertragen. Een afbeelding zonder vaste afmetingen kan layout shifts veroorzaken. Een belangrijke productfoto die alleen via JavaScript verschijnt, kan lastiger te ontdekken zijn. En een CDN-pad dat geblokkeerd is in robots.txt kan ervoor zorgen dat crawlers niet goed bij je afbeeldingen kunnen.

Daarom gaat technische SEO voor afbeeldingen niet alleen over “mooie plaatjes”.

Het gaat over de vraag:

kan een zoekmachine je afbeeldingen vinden, verwerken en tonen zonder dat ze je pagina onnodig traag of instabiel maken?

Dat maakt afbeeldingen een belangrijk technisch SEO-onderwerp.

Zeker bij webshops, kennisbanken, blogs, portfolio’s, platforms en websites waar visuele content een grote rol speelt.

🧭 Waarom technische SEO voor afbeeldingen belangrijk is

Afbeeldingen hebben twee kanten.

Aan de ene kant kunnen ze SEO versterken.

Bijvoorbeeld doordat ze:

• een pagina duidelijker maken
• productinformatie ondersteunen
• uitleg visueel maken
• kansen geven in Google Afbeeldingen
• gebruikt kunnen worden in rijke zoekresultaten of visuele oppervlakken
• bijdragen aan een betere gebruikerservaring

Aan de andere kant kunnen afbeeldingen technische problemen veroorzaken.

Bijvoorbeeld:

• trage laadtijd
• slechte LCP
• layout shifts
• te veel dataverbruik op mobiel
• gebroken afbeelding-URL’s
• onnodige redirects
• crawlproblemen
• verkeerd geladen formaten
• zware sliders of galleries

Een afbeelding is dus niet automatisch SEO-vriendelijk omdat hij mooi is.

Hij moet ook technisch kloppen.

Een productfoto van 4 MB kan er prachtig uitzien, maar als hij bovenaan de pagina staat en traag laadt, voelt de pagina langzaam. Een banner kan visueel sterk zijn, maar als hij later ruimte opeist, springt de layout. En een infographic kan inhoudelijk waardevol zijn, maar als Google hem niet goed kan ontdekken, haal je er minder uit.

Technische SEO voor afbeeldingen draait daarom om balans.

Goede kwaliteit.
Lage bestandsgrootte.
Snelle levering.
Stabiele weergave.
Crawlbare URL’s.
Logische inbedding in de pagina.

🖼️ Wat technische SEO voor afbeeldingen inhoudt

Technische SEO voor afbeeldingen gaat over de technische voorwaarden waardoor afbeeldingen goed kunnen werken binnen SEO.

Denk aan:

• bestandstype
• bestandsgrootte
• compressie
• afbeeldingsafmetingen
• responsive images
• srcset en sizes
• lazy loading
• LCP-afbeeldingen
• width- en height-attributen
• crawlbaarheid
• indexeerbaarheid
• CDN en caching
• image sitemaps
• gebroken afbeelding-URL’s
• afbeeldingen in JavaScript of CSS

Alt-tekst, bestandsnamen en context zijn ook belangrijk.

Maar die zitten meer aan de inhoudelijke kant van image SEO.

Die bepalen vooral wat een afbeelding betekent.

Dit artikel kijkt vooral naar de technische laag eronder:

hoe wordt de afbeelding geladen, gevonden, verwerkt en weergegeven?

Dat onderscheid is belangrijk.

Want een afbeelding kan een perfecte alt-tekst hebben, maar technisch alsnog slecht zijn.

Bijvoorbeeld omdat het bestand veel te zwaar is.
Omdat de afbeelding pas laat via JavaScript verschijnt.
Omdat hij geen vaste afmetingen heeft.
Of omdat mobiel dezelfde enorme afbeelding downloadt als desktop.

🔎 Kunnen zoekmachines je afbeeldingen vinden?

De eerste vraag is simpel:

kan Google je afbeelding ontdekken?

Als een afbeelding belangrijk is voor SEO, moet hij niet verstopt zitten.

Gebruik waar mogelijk normale HTML-image-elementen.

Bijvoorbeeld:

<img src="/images/zwarte-hardloopschoenen.jpg" alt="Zwarte hardloopschoenen voor heren" />

Of een moderne variant met responsive images:

<picture>
  <source srcset="/images/schoenen.avif" type="image/avif">
  <source srcset="/images/schoenen.webp" type="image/webp">
  <img src="/images/schoenen.jpg" alt="Zwarte hardloopschoenen voor heren">
</picture>

Voor decoratieve achtergrondbeelden kan CSS prima zijn.

Maar belangrijke contentafbeeldingen zet je liever niet alleen als background-image in CSS. Denk aan productfoto’s, belangrijke visuals, infographics, stappenafbeeldingen of afbeeldingen die je terug wilt zien in Google Afbeeldingen.

Die wil je duidelijk in de HTML hebben.

Afbeeldingen moeten bereikbaar zijn

Een afbeelding is ook gewoon een URL.

Die URL moet werken.

Controleer daarom of:

• de afbeelding een 200-status geeft
• de afbeelding niet redirect naar een andere URL
• de afbeelding niet op een 404 uitkomt
• de afbeelding niet geblokkeerd is via robots.txt
• de CDN-URL bereikbaar is
• de afbeelding via HTTPS geladen wordt
• de afbeelding niet alleen na een gebruikersactie verschijnt
• de pagina waarop de afbeelding staat crawlbaar is

Dit klinkt technisch.

Maar in de praktijk gaat het vaak mis.

Bijvoorbeeld na een migratie waarbij oude image-URL’s verdwijnen. Of bij een CDN-configuratie waarbij crawlers bepaalde paden niet mogen ophalen. Of bij lazy loading die zo is gebouwd dat afbeeldingen pas verschijnen na scrollacties die een crawler niet goed kan nabootsen.

De basis blijft:

belangrijke afbeelding?
Dan moet hij technisch vindbaar, bereikbaar en logisch ingebed zijn.

⚡ Afbeeldingen en Core Web Vitals

Afbeeldingen hebben direct invloed op Core Web Vitals.

Vooral op LCP en CLS.

Soms ook indirect op INP.

LCP: de belangrijkste afbeelding boven de vouw

LCP meet wanneer het grootste zichtbare contentblok in beeld is geladen.

Op veel pagina’s is dat een afbeelding.

Bijvoorbeeld:

• een hero-afbeelding
• een productfoto
• een categoriebeeld
• een banner
• een grote visual bovenaan een artikel
• een video-thumbnail
• een afbeelding in een card of module

Als die afbeelding traag laadt, wordt je LCP slechter.

Dat gebeurt vaak bij afbeeldingen die te groot zijn, te laat worden ontdekt of onnodig lazy loaded zijn.

CLS: afbeeldingen zonder gereserveerde ruimte

CLS gaat over onverwachte layout shifts.

Afbeeldingen kunnen CLS veroorzaken als de browser vooraf niet weet hoeveel ruimte ze nodig hebben.

De pagina laadt.

Tekst staat al in beeld.

Daarna komt een afbeelding binnen.

En ineens schuift alles naar beneden.

Dat voelt onrustig.

Daarom zijn vaste afmetingen of een duidelijke aspect ratio belangrijk.

INP: zware galleries, sliders en scripts

Afbeeldingen raken INP minder direct.

Maar zware image sliders, galleries, carousels of scripts rond afbeeldingen kunnen interacties vertragen.

Denk aan een productpagina met veel afbeeldingen, zoomfunctionaliteit, thumbnails, sliders en tracking. De afbeeldingen zelf zijn dan niet altijd het probleem, maar de scripts eromheen kunnen de pagina zwaarder maken.

Daarom moet je bij image SEO niet alleen naar bestanden kijken.

Maar ook naar hoe afbeeldingen technisch worden gebruikt.

🧱 Bestandstype en compressie: welk formaat gebruik je?

Niet elk afbeeldingsformaat is geschikt voor elke situatie.

Kies het formaat op basis van het type afbeelding, de gewenste kwaliteit, transparantie, browserondersteuning en bestandsgrootte.

JPEG

JPEG is geschikt voor foto’s.

Bijvoorbeeld:

• productfoto’s
• sfeerbeelden
• teamfoto’s
• blogafbeeldingen
• fotografie met veel kleurverloop

JPEG is breed ondersteund en vaak prima te comprimeren. Maar bij te veel compressie krijg je zichtbare kwaliteitsproblemen, zoals blokkerigheid of vage randen.

PNG

PNG is geschikt voor afbeeldingen waarbij transparantie of scherpe lijnen belangrijk zijn.

Bijvoorbeeld:

• logo’s
• iconen
• screenshots
• grafische elementen
• afbeeldingen met tekst

Maar PNG-bestanden kunnen zwaar worden.

Gebruik PNG dus niet automatisch voor grote foto’s.

Een PNG van 2 MB voor een kleine screenshot in een blogartikel is meestal geen goed idee.

WebP

WebP is een modern en efficiënt formaat.

Het kan vaak kleinere bestanden opleveren dan JPEG of PNG, met goede kwaliteit. Voor veel websites is WebP daarom een sterke standaardoptie.

Vooral bij:

• productfoto’s
• blogafbeeldingen
• categoriebeelden
• thumbnails
• visuele content op grote schaal

Let wel op implementatie.

Je wilt niet alleen WebP-bestanden maken.

Je wilt ook zorgen dat browsers de juiste versie krijgen.

AVIF

AVIF kan nog efficiënter zijn dan WebP.

Het kan dus zeer kleine bestanden opleveren bij goede kwaliteit.

Maar AVIF vraagt ook om goede implementatie en testing. Afhankelijk van je CMS, CDN, browserondersteuning en workflow kan WebP soms praktischer zijn.

Zie AVIF dus als krachtige optie.

Niet als automatische vervanger voor alles zonder controle.

SVG

SVG is geschikt voor vectorafbeeldingen.

Bijvoorbeeld:

• logo’s
• iconen
• eenvoudige illustraties
• grafische vormen

SVG schaalt scherp mee zonder kwaliteitsverlies.

Maar gebruik SVG niet zomaar voor complexe foto’s.

Daar is het niet voor bedoeld.

Let bij SVG ook op veiligheid en schone code, zeker wanneer bestanden door gebruikers of externe bronnen worden aangeleverd.

GIF

GIF wordt nog vaak gebruikt voor simpele animaties.

Maar voor zware animaties is GIF meestal inefficiënt.

Een korte animatie als videoformaat kan vaak veel kleiner en sneller zijn dan een grote GIF.

Gebruik GIF dus spaarzaam.

Zeker boven de vouw.

De praktische regel

Kies niet één formaat voor alles.

Gebruik:

• JPEG of WebP voor foto’s
• WebP of AVIF voor moderne optimalisatie
• PNG waar transparantie of scherpe details nodig zijn
• SVG voor logo’s en iconen
• video in plaats van zware GIF’s wanneer animatie belangrijk is

En comprimeer altijd.

Niet tot alles lelijk wordt.

Wel tot de bestandsgrootte logisch is voor de plek waar de afbeelding wordt gebruikt.

Een thumbnail hoeft geen origineel bestand van 3000 pixels breed te laden.

📐 Afbeeldingsafmetingen en responsive images

Een veelgemaakte fout is dat websites één groot afbeeldingsbestand gebruiken voor alle schermen.

Desktop.
Tablet.
Mobiel.
Retina-scherm.
Kleine kaart.
Grote hero.

Allemaal hetzelfde bestand.

Dat is zonde.

Een mobiele gebruiker hoeft meestal geen enorme desktopafbeelding te downloaden. En een kleine thumbnail hoeft geen volledige productfoto op maximale resolutie te laden.

Responsive images lossen dit op.

Met srcset geef je meerdere afbeeldingsvarianten mee. Met sizes vertel je de browser hoe groot de afbeelding ongeveer wordt weergegeven in de layout.

Bijvoorbeeld:

<img
  src="/images/schoenen-800.jpg"
  srcset="/images/schoenen-400.jpg 400w, /images/schoenen-800.jpg 800w, /images/schoenen-1200.jpg 1200w"
  sizes="(max-width: 600px) 400px, 800px"
  alt="Zwarte hardloopschoenen"
/>

In gewone taal zeg je hiermee:

er zijn meerdere formaten beschikbaar.

Browser, kies zelf de beste versie voor dit scherm en deze layout.

Dat helpt vooral bij websites met veel afbeeldingen.

Zoals:

• webshops
• blogs
• kennisbanken
• portfolio’s
• magazines
• receptenwebsites
• platforms
• vacaturebanken met bedrijfslogo’s of visuals

Wanneer gebruik je <picture>?

Het <picture>-element gebruik je wanneer je meer controle nodig hebt.

Bijvoorbeeld omdat je:

• AVIF of WebP wilt aanbieden met fallback
• op mobiel een andere uitsnede wilt tonen dan op desktop
• verschillende beeldverhoudingen gebruikt
• art direction nodig hebt

Voorbeeld:

<picture>
  <source srcset="/images/schoenen.avif" type="image/avif">
  <source srcset="/images/schoenen.webp" type="image/webp">
  <img
    src="/images/schoenen.jpg"
    width="800"
    height="500"
    alt="Zwarte hardloopschoenen"
  >
</picture>

Belangrijk:

<picture> vervangt de gewone <img> niet volledig.

Er hoort altijd een <img> binnen te staan als fallback.

📏 Width, height en CLS voorkomen

Een afbeelding heeft ruimte nodig.

De browser moet het liefst vóór het laden al weten hoeveel ruimte dat is.

Daarom zijn width en height belangrijk.

Bijvoorbeeld:

<img
  src="/images/schoenen.jpg"
  width="800"
  height="500"
  alt="Zwarte hardloopschoenen"
/>

Dat betekent niet dat de afbeelding altijd exact 800 bij 500 pixels op het scherm moet staan.

CSS kan hem nog steeds responsive schalen.

Maar de browser weet alvast de verhouding.

En daardoor kan hij ruimte reserveren.

Dat helpt layout shifts voorkomen.

Zonder gereserveerde ruimte kan dit gebeuren:

de tekst laadt eerst.
De afbeelding komt later.
De afbeelding eist ruimte op.
De tekst schuift naar beneden.

Dat is slecht voor CLS.

En irritant voor gebruikers.

Je kunt ruimte ook reserveren met CSS, bijvoorbeeld via aspect-ratio.

Belangrijk is vooral dat de browser weet:

hier komt een afbeelding, en zoveel ruimte heeft die ongeveer nodig.

Let hier extra op bij:

• hero-afbeeldingen
• productfoto’s
• banners
• thumbnails
• embeds
• galleries
• carousels
• afbeeldingen in contentblokken

CLS is vaak geen ingewikkeld probleem.

Maar je moet wel consequent zijn.

🚀 LCP-afbeeldingen: wat doe je met hero images?

De belangrijkste afbeelding boven de vouw is vaak het LCP-element.

Dat maakt hero-afbeeldingen extra gevoelig.

Denk aan:

• grote headers
• productafbeeldingen bovenaan
• categoriebeelden
• visual banners
• video-posters
• grote blogafbeeldingen
• afbeeldingen in de eerste contentkaart

Als zo’n afbeelding traag laadt, voelt de hele pagina traag.

Ook als de rest best snel is.

Lazy-load je LCP-afbeelding meestal niet

Lazy loading is nuttig voor afbeeldingen lager op de pagina.

Maar een LCP-afbeelding wil je meestal niet lazy loaden.

Die moet juist snel beschikbaar zijn.

Als je de belangrijkste afbeelding boven de vouw lazy loadt, zeg je eigenlijk tegen de browser:

wacht nog even met deze afbeelding.

Terwijl die afbeelding juist direct nodig is.

Dat kan je LCP verslechteren.

Gebruik passende afmetingen en compressie

Een LCP-afbeelding moet scherp genoeg zijn.

Maar niet onnodig zwaar.

Controleer dus:

• is de afbeelding niet veel groter dan nodig?
• is het formaat geschikt?
• is compressie toegepast?
• wordt mobiel een passende variant geladen?
• is er een moderne versie zoals WebP of AVIF beschikbaar?
• wordt de afbeelding niet via een onnodige redirect geladen?

Gebruik fetchpriority bewust

Voor belangrijke afbeeldingen boven de vouw kan fetchpriority="high" helpen.

Bijvoorbeeld:

<img
  src="/images/hero-schoenen.webp"
  width="1200"
  height="700"
  alt="Nieuwe collectie hardloopschoenen"
  fetchpriority="high"
/>

Daarmee geef je de browser een hint dat deze afbeelding belangrijk is.

Gebruik dit vooral voor de echte LCP-kandidaat.

Niet voor elke afbeelding.

Als je alles hoge prioriteit geeft, heeft prioriteit weinig betekenis meer.

Preload alleen bewust

Soms kan preload nuttig zijn voor een belangrijke afbeelding die anders laat ontdekt wordt.

Maar ook hier geldt:

niet alles preloaden.

Preload is vooral nuttig wanneer een belangrijke afbeelding laat in de broncode staat of via CSS/JavaScript pas later ontdekt wordt.

Gebruik het gericht.

Anders maak je de pagina juist drukker in de kritieke laadfase.

Pas op met sliders

Sliders lijken visueel aantrekkelijk.

Maar technisch zijn ze vaak zwaar.

Ze laden meerdere afbeeldingen.
Ze gebruiken JavaScript.
Ze kunnen layout shifts veroorzaken.
Ze maken de LCP-kandidaat minder duidelijk.

Niet elke slider is slecht.

Maar een zware slider bovenaan een pagina is vaak geen performancecadeau.

Vraag je dus af:

moet dit echt een slider zijn?

Of kan één sterke afbeelding beter werken?

🕓 Lazy loading: wanneer wel en niet gebruiken?

Lazy loading betekent dat een afbeelding pas wordt geladen wanneer hij bijna nodig is.

Bijvoorbeeld wanneer hij lager op de pagina staat en de gebruiker naar beneden scrollt.

Dat is vaak slim.

Waarom zou je alle afbeeldingen direct laden als de gebruiker ze misschien nooit ziet?

Lazy loading is vooral nuttig voor:

• afbeeldingen onder de vouw
• lange blogartikelen
• galleries lager op de pagina
• productoverzichten lager in de lijst
• secundaire contentblokken
• gerelateerde artikelen
• extra screenshots
• reviews met afbeeldingen

Een simpel voorbeeld:

<img
  src="/images/detailfoto.jpg"
  width="800"
  height="500"
  loading="lazy"
  alt="Detail van zwarte hardloopschoen"
/>

Maar lazy loading is niet voor alles.

Gebruik het voorzichtig of liever niet voor:

• hero-afbeeldingen
• LCP-afbeeldingen
• logo’s bovenaan
• belangrijke visuals in de eerste viewport
• afbeeldingen die direct nodig zijn voor de eerste indruk

De vuistregel:

onder de vouw lazy loaden is vaak goed.
boven de vouw lazy loaden is vaak riskant.

Let ook op de implementatie.

Lazy loading moet niet betekenen dat afbeeldingen alleen verschijnen na een complexe gebruikersactie die crawlers niet goed kunnen uitvoeren.

Als belangrijke content pas zichtbaar wordt na scroll, klik of scriptgedrag dat niet goed werkt bij rendering, kan dat discovery en indexatie beïnvloeden.

🗺️ Image sitemaps: wanneer zijn ze nuttig?

Meestal ontdekt Google afbeeldingen via de pagina zelf.

Als een afbeelding netjes in de HTML staat en de pagina crawlbaar is, is dat vaak voldoende.

Maar image sitemaps kunnen nuttig zijn.

Vooral bij websites met veel of belangrijke visuele content.

Denk aan:

• webshops
• portfolio’s
• fotografie-websites
• receptenwebsites
• magazines
• vastgoedwebsites
• productcatalogi
• galleries
• grote kennisbanken met veel visuals

Een image sitemap helpt zoekmachines afbeeldingen ontdekken die anders lastiger te vinden zijn.

Je kunt afbeeldingen opnemen in je normale sitemap.

Of werken met een aparte image sitemap.

Belangrijk:

een image sitemap is geen vervanging voor goede implementatie.

Als je afbeeldingen geblokkeerd zijn, slecht laden of op pagina’s staan die niet goed crawlbaar zijn, lost een sitemap dat niet automatisch op.

Zie het als extra hulp.

Niet als reparatie voor een slechte basis.

🌐 CDN, caching en afbeelding-URL’s

Afbeeldingen zijn vaak grote bestanden.

Daarom hebben CDN en caching veel invloed.

Een CDN kan afbeeldingen sneller leveren vanaf servers dichter bij de gebruiker. Caching zorgt ervoor dat dezelfde afbeelding niet steeds opnieuw volledig hoeft te worden opgehaald.

Dat is vooral belangrijk bij:

• internationale websites
• webshops
• sites met veel terugkerende bezoekers
• platforms met veel media
• pagina’s met veel thumbnails
• websites met veel productafbeeldingen

Maar let op:

een CDN maakt image SEO niet automatisch goed.

De afbeelding-URL’s moeten nog steeds technisch kloppen.

Controleer bijvoorbeeld:

• worden afbeeldingen via HTTPS geladen?
• geven image-URL’s een 200-status?
• zijn er geen onnodige redirects?
• zijn oude image-URL’s goed afgehandeld na migratie?
• blokkeert robots.txt geen CDN-pad?
• zijn cache headers logisch ingesteld?
• blijven belangrijke image-URL’s stabiel?
• ontstaat er geen mixed content met HTTP-afbeeldingen op HTTPS-pagina’s?

Een afbeelding is geen los bestandje buiten SEO.

Het is een URL.

En die URL moet technisch netjes werken.

🧪 Hoe controleer je technische SEO voor afbeeldingen?

Technische SEO voor afbeeldingen controleer je op meerdere manieren.

Niet alleen door te kijken of afbeeldingen zichtbaar zijn.

Want zichtbaar voor jou betekent niet automatisch technisch goed.

PageSpeed Insights

PageSpeed Insights is handig om performanceproblemen met afbeeldingen te vinden.

Let vooral op signalen zoals:

• wat is het LCP-element?
• is het LCP-element een afbeelding?
• worden afbeeldingen in moderne formaten geleverd?
• zijn afbeeldingen goed geschaald?
• zijn offscreen images lazy loaded?
• mist er width of height?
• zijn afbeeldingen te zwaar?
• vertragen afbeeldingen de eerste render?
• zijn er render-blocking resources die de afbeelding laat zichtbaar maken?

PageSpeed Insights is vooral sterk voor losse URL’s.

Test dus verschillende templates.

Niet alleen de homepage.

Bijvoorbeeld:

• productpagina
• categoriepagina
• blogartikel
• kennisbankartikel
• landingspagina
• hubpagina

Een homepage kan prima scoren, terwijl productpagina’s structureel te zware afbeeldingen laden.

Screaming Frog

Met Screaming Frog kun je afbeeldingen op schaal controleren.

Bijvoorbeeld:

• afbeeldingbestandsgrootte
• ontbrekende alt-teksten
• gebroken image-URL’s
• afbeelding-redirects
• welke pagina’s welke afbeeldingen gebruiken
• afbeeldingen boven een bepaalde bestandsgrootte
• HTTP-afbeeldingen op HTTPS-pagina’s
• image-URL’s met statuscodeproblemen

Met de PageSpeed Insights API-integratie kun je ook performance-opportunities meenemen in je crawl.

Bijvoorbeeld:

• afbeeldingen juist schalen
• offscreen images uitstellen
• moderne formaten gebruiken
• afbeeldingen efficiënt encoden
• ontbrekende width en height herkennen

Dat maakt het praktisch bij grotere websites.

Je hoeft dan niet één pagina handmatig te beoordelen.

Je ziet patronen.

Bijvoorbeeld:

alle productpagina’s laden thumbnails als origineel bestand.
Alle blogafbeeldingen missen vaste afmetingen.
Alle categoriepagina’s hebben een zware hero-afbeelding.
Alle images op een oude CDN-map redirecten.

Dat zijn precies de inzichten die je nodig hebt.

Google Search Console

In Google Search Console kun je prestaties in Google Afbeeldingen bekijken.

Dat doe je door bij prestaties het zoektype Afbeelding te kiezen.

Daar zie je bijvoorbeeld:

• klikken uit Google Afbeeldingen
• vertoningen in Google Afbeeldingen
• zoekopdrachten
• pagina’s
• landen
• apparaten

Dit is vooral nuttig als afbeeldingen een belangrijk verkeerskanaal zijn.

Bijvoorbeeld bij producten, recepten, inspiratiecontent, interieur, mode, fotografie of visuele handleidingen.

Gebruik Search Console ook om bredere indexerings- of crawlproblemen te onderzoeken.

Bij twijfel kun je met URL-inspectie kijken hoe Google een pagina ziet en of belangrijke resources geladen worden.

Browser DevTools

Browser DevTools is handig voor technische verdieping.

Vooral de Network-tab.

Daar kun je zien:

• welke afbeeldingen worden geladen
• hoe zwaar ze zijn
• wanneer ze worden geladen
• of ze uit cache komen
• of er redirects zijn
• welk formaat wordt geleverd
• welke afbeeldingvariant mobiel of desktop krijgt
• of lazy loading werkt zoals bedoeld

Dit is vooral nuttig wanneer PageSpeed Insights zegt dat er iets misgaat, maar je wilt weten wat er technisch precies gebeurt.

Handmatige checks

Sommige dingen kun je ook gewoon handmatig controleren.

Bijvoorbeeld:

• wordt de juiste afbeelding getoond op mobiel?
• springt de layout tijdens het laden?
• is de afbeelding scherp genoeg?
• is hij niet overdreven zwaar?
• wordt een hero-afbeelding direct geladen?
• zijn belangrijke afbeeldingen niet verstopt achter interacties?
• blijft de pagina bruikbaar zonder slider of script?

Technische SEO is niet alleen tools draaien.

Het is ook kijken of het gedrag logisch is.

⚠️ Veelgemaakte fouten met afbeeldingen in technische SEO

Afbeeldingen gaan vaak mis door standaardinstellingen.

Niet omdat iemand bewust slechte SEO wil.

Maar omdat CMS’en, thema’s, plugins en workflows niet altijd automatisch de beste technische keuzes maken.

❌ Enorme afbeeldingen uploaden en klein tonen

Dit is een klassieker.

Een afbeelding wordt als groot bestand geüpload, maar op de pagina klein weergegeven.

Bijvoorbeeld een foto van 3000 pixels breed die als kaart van 300 pixels wordt getoond.

Dan downloadt de gebruiker onnodig veel data.

❌ Geen responsive images gebruiken

Zonder responsive images krijgt mobiel vaak dezelfde zware afbeelding als desktop.

Dat maakt pagina’s onnodig traag.

Zeker bij webshops, blogs en kennisbanken met veel afbeeldingen.

❌ De LCP-afbeelding lazy loaden

Lazy loading is goed voor afbeeldingen lager op de pagina.

Maar niet voor de belangrijkste afbeelding boven de vouw.

Als de LCP-afbeelding te laat wordt geladen, verslechtert de ervaren laadsnelheid.

❌ Geen width en height meegeven

Zonder vaste afmetingen of aspect ratio kan de browser geen ruimte reserveren.

Daardoor kan de layout verspringen zodra afbeeldingen laden.

Dat veroorzaakt CLS-problemen.

❌ Belangrijke afbeeldingen als CSS-background gebruiken

CSS-backgrounds zijn prima voor decoratie.

Maar belangrijke contentafbeeldingen wil je meestal in HTML hebben.

Zeker als ze relevant zijn voor Google Afbeeldingen of inhoudelijke betekenis hebben.

❌ Image- of CDN-paden blokkeren

Soms worden image-mappen of CDN-paden geblokkeerd in robots.txt.

Dan kunnen crawlers belangrijke afbeeldingbestanden mogelijk niet goed ophalen.

Controleer dit altijd bij migraties, CDN-wijzigingen en technische audits.

❌ Gebroken afbeelding-URL’s laten bestaan

Een gebroken afbeelding geeft een slechte gebruikerservaring.

En technisch is het rommelig.

Controleer daarom op 404’s, redirects en verkeerde image-paden.

❌ Thumbnails originele bestanden laten laden

Een thumbnail moet een kleine variant zijn.

Niet hetzelfde zware bestand als de grote afbeelding.

Dit zie je vaak bij productoverzichten, blogkaarten en gerelateerde contentblokken.

❌ Te zware sliders en galleries gebruiken

Sliders en galleries kunnen veel afbeeldingen en scripts laden.

Dat kan LCP, INP en algemene pagespeed verslechteren.

Gebruik ze bewust.

En test ze op mobiel.

❌ Alleen de homepage testen

De homepage is niet genoeg.

Afbeeldingsproblemen zitten vaak in templates.

Bijvoorbeeld productpagina’s, categoriepagina’s, blogartikelen of kennisbankartikelen.

Test dus meerdere paginatypes.

👉 Volgende stap

Nu je weet hoe afbeeldingen technisch invloed hebben op laadtijd, crawlbaarheid en gebruikerservaring, gaan we door naar het bredere mobiele plaatje:

Mobielvriendelijkheid en responsive SEO.

❓ Vragen beantwoord in dit artikel