De productfoto’s op uw webshop zijn grijze vlakken geworden. Of het logo in de header is een kapot icoontje met een alt-tekst ernaast. Of alles ziet er goed uit, behalve op de telefoon van uw klant. Soms is het zelfs de mediabibliotheek zelf die alleen nog lege rechthoeken toont. De bestanden zijn er wel, u heeft ze zelf geüpload, maar de site laat ze niet zien.

Als afbeeldingen niet zichtbaar zijn in WordPress, zijn er zeven oorzaken die samen vrijwel alle gevallen verklaren. Voordat u er een uitkiest, is het handig om te weten hoe u in dertig seconden achterhaalt in welke richting u moet zoeken. Daarmee beginnen we.

De snelle test: bestaat het bestand?

Klik met de rechtermuisknop op de plek waar de afbeelding hoort te staan en kies “Afbeelding openen in nieuw tabblad” of “Adres van afbeelding kopiëren”. Plak het adres in de adresbalk. Wat u dan ziet, verdeelt de oorzaken in twee groepen:

  • U ziet de afbeelding wél. Het bestand bestaat en is bereikbaar. Het probleem zit dan in de pagina zelf: lazy loading, CSS, een cache of een blokkade in de browser (oorzaak 5, 6 en 7).
  • U krijgt een 404 of een foutmelding. Het bestand staat niet op de plek waar de pagina naar wijst. Dan zit het in paden, rechten of ontbrekende bestanden (oorzaak 1 tot en met 4).

Kijk daarbij ook naar het adres zelf. Staat er een ander domein in dan uw eigen domein, of een adres met http in plaats van https? Dat is vaak meteen het antwoord.

Oorzaak 1: verkeerde adressen na een verhuizing of domeinwijziging

De meest voorkomende. WordPress slaat het volledige adres van elke afbeelding op in de database: https://oudedomein.nl/wp-content/uploads/2024/03/foto.jpg. Na een verhuizing naar een nieuw domein, van een testomgeving naar de live site, of van http naar https, wijzen al die adressen nog naar de oude plek. De pagina’s laden, want die worden opnieuw opgebouwd, maar de afbeeldingen zoeken op de oude locatie.

De oplossing is een zoek-en-vervangactie in de database, met een gereedschap dat ook met geserialiseerde data overweg kan (Better Search Replace of WP-CLI). Vervang het oude adres door het nieuwe, inclusief het protocol. Doe dit nooit met een gewone SQL-opdracht; die beschadigt instellingen van thema’s en pagebuilders. En maak eerst een back-up.

Oorzaak 2: de uploadmap is niet meegekomen

Bij een verhuizing of het terugzetten van een back-up is soms wel de database overgezet maar niet de map wp-content/uploads, of maar een deel ervan. De adressen kloppen dan, maar de bestanden ontbreken. Controleer via FTP of de map bestaat en of de jaar- en maandmappen erin gevuld zijn. Ontbreken bestanden, dan haalt u ze uit de back-up of van de oude server.

Oorzaak 3: bestandsrechten

Staan de bestanden er wel maar geeft de server een 403 (Forbidden), dan mag de webserver ze niet lezen. Dat gebeurt na een verhuizing tussen servers, na een handmatige upload via een verkeerde gebruiker, of na een beveiligingsplugin die te enthousiast rechten heeft aangepast. De gangbare instellingen zijn 755 voor mappen en 644 voor bestanden. Uw hostingpaneel heeft meestal een functie om rechten in één keer te herstellen.

Oorzaak 4: de afbeeldingsformaten zijn nooit gemaakt

WordPress maakt van elke upload meerdere formaten: thumbnail, medium, large en wat het thema erbij vraagt. Als de pagina een formaat opvraagt dat niet bestaat, bijvoorbeeld omdat het thema na de upload is gewisseld of de server tijdens het uploaden te weinig geheugen had, blijft de plek leeg terwijl het origineel wel bestaat. Een plugin als Regenerate Thumbnails maakt alle ontbrekende formaten opnieuw aan. Bij een grote mediabibliotheek kan dat een uur duren; laat het op een rustig moment draaien.

Oorzaak 5: lazy loading dat niet loslaat

Lazy loading stelt het laden van afbeeldingen uit tot ze in beeld komen. Als het JavaScript dat daarvoor zorgt niet werkt, bijvoorbeeld door een conflict na een update, worden afbeeldingen nooit “wakker” en blijven ze leeg of vervaagd. Kenmerkend: de afbeeldingen boven in de pagina zijn er wel, verderop niet, en bij het scrollen gebeurt niets. Zet lazy loading tijdelijk uit in uw optimalisatieplugin en kijk of de afbeeldingen terugkomen. Meer over wanneer deze techniek averechts werkt, leest u in onze uitleg over lazy loading.

Oorzaak 6: cache, CDN of optimalisatieplugin

Een CDN of een plugin die afbeeldingen naar WebP omzet, serveert de afbeeldingen vanaf een andere plek of onder een andere naam. Als die dienst uitvalt, het abonnement is verlopen of de omzetting is mislukt, verwijst de pagina naar bestanden die niet bestaan. U herkent dit aan een afbeeldingsadres met een vreemd domein of met .webp erachter. Schakel de plugin tijdelijk uit of zet de CDN-functie uit en leeg alle caches.

Oorzaak 7: de browser van de bezoeker blokkeert

Ziet u de afbeeldingen zelf wel, maar meldt een klant dat ze ontbreken? Dan kan het aan de bezoeker liggen. Adblockers blokkeren soms afbeeldingen met “banner”, “ad” of “sponsor” in de bestandsnaam. Een strenge beveiligingsheader (Content Security Policy) op uw site kan afbeeldingen van externe bronnen tegenhouden. En een pagina die via https laadt maar een afbeelding via http opvraagt, wordt door alle moderne browsers geblokkeerd; dat heet mixed content. In de browserconsole (F12) staat in alle gevallen precies welke afbeelding waarom is geweigerd.

Wat u zelf doet en wanneer u hulp inschakelt

Zelf: de snelle test, caches legen, lazy loading en optimalisatieplugins tijdelijk uitzetten, thumbnails opnieuw genereren en bestandsrechten herstellen via het hostingpaneel. Daar kan weinig bij misgaan.

Hulp inschakelen bij de zoek-en-vervangactie in de database, bij het terughalen van een ontbrekende uploadmap van een oude server, en bij mixed content dat in de themacode zit. Dat is typisch werk voor een WordPress-bugfixingdienst: een uur werk, met een back-up vooraf en een controle van de hele site achteraf.

Een meubelmaker uit Eindhoven zag na een verhuizing naar een nieuwe hoster alle 600 productfoto’s verdwijnen. De uploadmap was overgezet, de rechten klopten, maar de database wees nog naar het tijdelijke adres dat de hoster tijdens de verhuizing had gebruikt. Eén zoek-en-vervangactie en alles stond er weer.

Conclusie

Begin bij een ontbrekende afbeelding altijd met het adres: open het in een nieuw tabblad. Een 404 stuurt u naar paden, bestanden en rechten; een afbeelding die wél laadt stuurt u naar lazy loading, cache en de browser. Werk de zeven oorzaken in die volgorde af en u heeft de schuldige meestal binnen een kwartier. En bij elke verhuizing: eerst zoeken-en-vervangen, dan pas de oude server opzeggen.