WordPress mediabibliotheek opschonen in 6 stappen

Als je je WordPress mediabibliotheek opschonen wilt zonder je site te breken, begin dan met een back-up en een staging-kopie. In een doorsnee WordPress-installatie zit 60 tot 80 procent van de opgeslagen afbeeldingen niet meer zichtbaar op een pagina. Deze how-to loopt in zes stappen door de opruiming heen: veilig, controleerbaar en zonder plugin-magie waar je later spijt van krijgt.

De valkuil zit in wat een tool niet ziet. Pagebuilders slaan image-referenties op als serialized JSON. Widgets, ACF-velden en logo’s zitten los van je posts. Blind een cleaner draaien en op “delete all unused” klikken is de snelste manier om zichtbare afbeeldingen kwijt te raken. Ik doe het rustig, met een prullenbak-workflow, WP-CLI-alternatieven en een handmatige eindcontrole.

Waarom je WordPress mediabibliotheek opschonen loont

Een uploads-map die jarenlang aangroeit heeft drie kosten. Ten eerste schijfruimte: hostingpakketten met een limiet van 10 of 20 GB lopen sneller vol dan je denkt. Ten tweede back-up-tijd: elke nightly back-up sleept die 10 GB opnieuw mee. Ten derde migraties: verhuizen naar een andere host wordt trager en duurder naarmate je uploads-map groter is.

WordPress genereert standaard 3 tot 5 thumbnail-varianten per upload. Voeg thema-specifieke sizes en een pagebuilder toe, en één origineel wordt zomaar 7 tot 10 bestanden. Een site met 5.000 originele uploads bewaart dan meer dan 30.000 files op disk. Het meeste daarvan wordt nooit geladen.

Meten voor je opschoont: log in via SSH en draai du -sh wp-content/uploads/*. Je ziet dan per jaar-map hoeveel ruimte er in gaat zitten. In mijn ervaring is de sprong tussen 2020 en 2023 vaak het grootst, omdat pagebuilders in die periode grote hero-images zijn gaan produceren.

De opschoning zelf raakt ook aan de laadsnelheid van je site. Als je uploads-map traag reageert op disk-niveau of je hostingpakket bij een quota-limiet komt, merk je dat aan de TTFB. Voor die kant van het werk heb ik een aparte pagina over snelheid-optimalisatie van je WordPress.

Wat je NIET wilt kwijtraken

Het gevaarlijkste woord in een media-cleaner is “unattached”. Dat betekent: niet gekoppeld aan een specifieke post via wp_posts.post_parent. Het betekent niet: nergens getoond op de site. Vier categorieën die vrijwel altijd unattached staan én actief in gebruik zijn:

• Logo, favicon en site-icon (staan in de theme customizer).
• Achtergrondafbeeldingen van widgets en menu’s.
• Afbeeldingen in ACF-velden (ook op post- en gebruikersniveau).
• Alles wat een pagebuilder in JSON-postmeta opslaat: Elementor _elementor_data, Divi builder-shortcodes, Bricks-elementen.

Elementor is de klassieke valkuil. Hij bewaart image-IDs binnen een serialized JSON-blob. Sommige cleaners scannen die blob, andere niet. Zonder scan verdwijnen jouw hero-images terwijl de admin nog steeds “afbeelding geselecteerd” toont.

Concrete tip: als je met een pagebuilder werkt, controleer eerst welke cleaner de builder ondersteunt. Media Cleaner van Meow Apps heeft filters voor Elementor, WPBakery en Beaver Builder. WP Media Cleanup van het Duplicator-team houdt een 30-daagse recovery-map aan, wat een prima vangnet is.

Stap 1 tot 3: back-up, staging en inventariseren

De eerste drie stappen kosten samen minder dan een uur en voorkomen alle grote ongelukken.

Stap 1: back-up van uploads-map plus database. Een SQL-dump van wp_posts en wp_postmeta is het minimum. Voor de meeste sites is een volledige DB-dump handiger. Voeg een tarball van wp-content/uploads/ toe via SSH: tar -czf uploads-backup.tar.gz wp-content/uploads/. Bewaar die twee bestanden lokaal of in een aparte cloud-map, niet op dezelfde server.

Stap 2: staging-kopie. Vrijwel elke moderne host (Hostinger, Kinsta, WP Engine, SiteGround) heeft een one-click staging. Zo niet: Duplicator Pro of WP Staging maken een clone binnen tien minuten. Draai de opschoning eerst op staging en pas daarna op productie.

Stap 3: inventariseren wat je hebt. Draai via SSH:

du -sh wp-content/uploads/
du -sh wp-content/uploads/*
find wp-content/uploads/ -type f | wc -l

De eerste regel toont totale grootte, de tweede geeft de verdeling per jaar-map, de derde telt het aantal files. Noteer deze drie getallen. Aan het einde van de opschoning meet je ze opnieuw en zie je het verschil zwart-op-wit.

Stap 4 en 5: dubbelingen en ongebruikte bestanden verwijderen

Dit is het hart van de opschoning en waar de meeste tijd in gaat zitten.

Stap 4: dubbelingen weg met Media Deduper. Deze plugin scant op file-hash en toont exacte duplicaten. Meestal komen die van herhaalde uploads van hetzelfde logo of van themes die stock-fotos meebrengen. Media Deduper laat je per duplicaat kiezen welke je behoudt. Doe deze stap eerst, want dat maakt stap 5 sneller.

Stap 5: ongebruikte bestanden met een cleaner. Ik gebruik Media Cleaner van Meow Apps, omdat die een dry-run heeft, per file laat zien waarom hij als ongebruikt gemarkeerd is, en een prullenbak-tussenstap kent. De workflow:

1. Draai eerst een scan zonder te verwijderen.
2. Sorteer de resultaten op grootte (grootste eerst, meeste winst).
3. Loop de top-50 door en check per bestand of hij écht ongebruikt is (klik op de referentie-details).
4. Verplaats geselecteerde bestanden naar de prullenbak, niet naar delete.
5. Wacht 7 tot 14 dagen. Test in die periode de site: elke pagina, elk product, elke pagebuilder-template.
6. Pas daarna leeg je de prullenbak permanent.

Op grote sites (50.000+ files) is de WP-CLI-route sneller: wp media-cleaner scan en wp media-cleaner delete draaien in de terminal en belasten de admin niet.

Stap 6: thumbnails opschonen en regenereren

Dit is de stap die het meeste ruimte oplevert en die de meeste mensen overslaan.

Elk WordPress-thema registreert eigen image sizes via add_image_size(). Wissel je van thema, dan blijven de oude sizes als bestanden achter zonder dat een cleaner ze als “ongebruikt” markeert (ze horen immers bij een geldig origineel). Dezelfde 3.000 originelen kunnen daardoor 6 losse thumbnail-sets meeslepen: één per thema dat de site ooit heeft gehad.

De aanpak in drie zetten:

1. Inventariseer geregistreerde sizes. In de admin via de plugin “Image Sizes Info”, of via WP-CLI: wp media image-size. Vergelijk deze lijst met de bestanden op disk (via ls wp-content/uploads/2024/06/ bijvoorbeeld). Wat je ziet en niet in de actieve lijst staat: kandidaat om weg te halen.
2. Verwijder oude sizes. De plugin “Force Regenerate Thumbnails” gooit alle bestaande thumbnails weg en bouwt alleen de actieve sizes opnieuw op. Doe dit na een back-up en op een moment dat de site rustig is.
3. Regenereer. Via de plugin “Regenerate Thumbnails” of via WP-CLI: wp media regenerate --yes. Dat laatste is op grote sites de betrouwbaarste route omdat het niet in een admin-timeout loopt.

Voor de exacte werking van image sizes en hoe je ze in code registreert is de officiële WordPress-documentatie voor image sizes de bron.

Handmatig controleren voor de zekerheid

Na een opschoning is een menselijke check verstandig. Vier steekproeven die ik altijd doe:

• Front-end scan. Open de homepage, drie productpagina’s of dienstpagina’s, en één blogpost. Kijk of alle beelden nog laden. Chrome DevTools op tab “Network”, filter op “img”, en scan op 404’s.
• 404-logs checken. In de server-error-log verschijnen 404’s op /wp-content/uploads/... als iets ontbreekt. Een gratis plugin als Redirection logt 404’s ook per URL.
• RSS-feed check. Sommige oude feed-consumers halen thumbnail-URLs op die inmiddels weg zijn.
• Sitemap-scan. Als je Yoast of Rank Math draait: laad sitemap_index.xml en check dat er geen image-URLs staan die niet meer bestaan.

Vind je één 404, dan restore je die ene file uit de prullenbak of uit de back-up. Vind je patronen (bijvoorbeeld: hele Elementor-headers missen images), dan zet je de cleaner terug en pas je je filter aan.

Wanneer laten opschonen door een webmaster

Voor een kleine site (minder dan 5 GB uploads, geen zware pagebuilder) is dit een taak die je zelf doet in een middag. Voor sites boven de 20 GB, met Elementor of Divi, of met een WooCommerce-productcatalogus van duizenden items wordt het risico groter dan de opbrengst.

Een kleine opschoning past bij mij binnen een uur onder het standaardtarief van 70 euro. Een grotere sessie met pagebuilder-audit en migratie-voorbereiding zit op 95 euro per uur voor het serverwerk. Bij zeer grote sites (50 GB en meer, of complexe custom themes) is 105 euro per uur voor technische specialistiek werk realistisch.

Verbeteren boven herbouwen: je site is dit niet vergeten, je bibliotheek is alleen groter geworden. Ik werk in de source-code, controleer per pagebuilder-blok, en laat de site na afloop meetbaar sneller en lichter achter. Voor het bredere kader van doorlopend werk verwijs ik naar het basis-onderhoud van je WordPress site.

Dezelfde denklijn geldt voor andere stacks. Joomla heeft de ingebouwde Media Manager plus de tool Duplicate Media Files. Drupal werkt met File entity en drush voor bulk-scans. Shopify houdt product-images netjes (Files-tab is meestal het kleinere probleem). Voor elk platform geldt de kern: back-up, dry-run, prullenbak, check, delete.