WooCommerce database opschonen: praktische opruiming voor snellere webshops

Een WooCommerce-database groeit hard. Twee jaar oude shop, dertig producten, nooit naar gekeken: zomaar zes tot acht keer zo groot als nodig. En dat merk je. Pagina’s laden trager, checkout hapert, backups duren twee keer zo lang.

De goede kant: een database opschonen is een van de meest dankbare onderhoudstaken in WooCommerce. Geen herbouw, geen migratie. Gewoon weghalen wat al weg had gemoeten.

Dit artikel gaat over WooCommerce database opschonen in de praktijk. Welke tabellen opzwellen, wat je veilig kunt verwijderen en hoe je het doet zonder iets stuk te maken.

Waar de meeste rommel zich verzamelt

Voor je iets weghaalt, kijk je eerst waar het zit. Open phpMyAdmin of een vergelijkbare database-tool en sorteer je tabellen op grootte. Bij een WooCommerce-shop kom je vrijwel altijd dezelfde verdachten tegen.

wp_options

De algemene optie-tabel van WordPress. Hoort klein te zijn (een paar MB), maar wordt vaak het kerkhof voor “transient options” die plugins achterlaten. Ik zie regelmatig wp_options-tabellen van vijftig MB of meer, terwijl ze tien moeten zijn.

wp_postmeta

Hier staat de meta-informatie bij elke post en elk product. Een WooCommerce-product heeft tientallen meta-velden. Vermenigvuldig dat met revisies, oude conceptversies en plugins die meta-velden achterlaten na deactivatie, en de tabel zwelt.

wp_woocommerce_sessions

Sessies van bezoekers en winkelwagens. WooCommerce ruimt sessies normaal automatisch op, maar bij sommige instellingen of plugins blijven ze hangen. Ik ben tabellen tegengekomen met honderdduizenden rijen op een shop met een paar honderd bezoekers per dag.

wp_actionscheduler_actions en wp_actionscheduler_logs

Action Scheduler is een achtergrondsysteem dat WooCommerce gebruikt voor terugkerende taken. Bij actieve shops met veel automatisering kunnen deze tabellen miljoenen rijen krijgen. Wat klaar is en oud is, mag opgeschoond worden.

wp_comments en wp_commentmeta

Spam-comments. Ook als je commentaar uit hebt staan, kunnen plugins ze achterlaten. Een check waard.

Concrete dingen die veilig weg kunnen

Niet alles in de database mag zomaar weg. Sommige tabellen zien er groot uit maar zijn essentieel. Hieronder wat er bij vrijwel elke WooCommerce-shop veilig opgeruimd kan worden, mits met backup.

• Verlopen transient options. Cache-resten die hun verloopdatum gepasseerd zijn. Vrijwel altijd vergeten boedel.
• Verlaten winkelwagens ouder dan dertig dagen. Wat al maanden niets meer doet, doet ook niets meer.
• Post revisies ouder dan zes maanden. WordPress bewaart elke wijziging in een product- of pagina-inhoud als revisie. Handig voor één week, ballast na een jaar.
• Spam en trash comments. Wat in de prullenbak zit, mag echt weg.
• Voltooide Action Scheduler-taken ouder dan dertig dagen. Logs van afgelopen acties, niet meer nodig.
• Auto-drafts en geannuleerde bestellingen ouder dan een jaar. Tenzij je administratie het anders verlangt.

Wat je nooit zonder begrip aanraakt:

• bestaande producten of bestellingen die nog actief zijn
• meta-velden van plugins die je nog gebruikt
• de wp_users-tabel
• iets in wp_options waarvan je niet weet wat het is

Drie manieren om het te doen

Database opschonen kan op meerdere niveaus. Welke je kiest, hangt af van hoe technisch je bent en hoe groot de shop is.

Niveau 1: plugin (voor wie geen toegang heeft tot de server)

Plugins als WP-Optimize, Advanced Database Cleaner of WP Rocket (premium) doen het meeste werk via een grafische interface. Voor wie nooit met phpMyAdmin gewerkt heeft, is dit het veiligste startpunt.

Mijn favoriet voor een shop-eigenaar die zelf wil opschonen: WP-Optimize. Gratis versie volstaat voor de basis. Het toont wat het wil verwijderen voordat het iets doet, en je kunt selectief vinkjes uitzetten.

Niveau 2: WP-CLI (voor wie shell-toegang heeft)

WP-CLI is de commandoregel-tool van WordPress. Sneller en preciezer dan een plugin. Een paar commands die ik regelmatig gebruik:

wp transient delete --all
wp post delete $(wp post list --post_status=trash --format=ids) --force
wp db optimize

De WP-CLI documentatie geeft het volledige overzicht. Voor wie ermee werkt, is dit dagelijks gereedschap.

Niveau 3: directe SQL (voor wie weet wat hij doet)

Voor specifieke opruiming kun je SQL-queries draaien in phpMyAdmin of via de command line. Bijvoorbeeld om verlaten WooCommerce-sessies ouder dan dertig dagen te verwijderen:

sql

DELETE FROM wp_woocommerce_sessions
WHERE session_expiry < UNIX_TIMESTAMP(NOW() - INTERVAL 30 DAY);

Dit is krachtiger dan een plugin, maar één verkeerd geplaatste komma maakt veel kapot. Niet doen als je het niet vaker hebt gedaan, of zonder verse backup.

Een werkvolgorde die in de praktijk werkt

Een opruiming die ik aanhoud voor een mkb-WooCommerce-shop, in deze volgorde:

1. Volledige backup van database en bestanden. Op een aparte locatie, niet alleen op dezelfde server. Geen uitzondering.
2. Database-grootte noteren. phpMyAdmin laat de huidige grootte zien per tabel. Maak een screenshot.
3. Een staging-omgeving opzetten als je er nog geen hebt. Voor grote opruimingen is dat de plek om te testen.
4. Transient options leegmaken. Snel resultaat, lage risico.
5. Spam-comments en trash leegmaken. Idem.
6. Verlaten winkelwagens ouder dan dertig dagen verwijderen. Soms duizenden rijen tegelijk.
7. Post revisies inkorten via wp-config.php. Voeg toe: define('WP_POST_REVISIONS', 5);. Dan bewaart WordPress nog maar vijf revisies per post.
8. Action Scheduler opruimen. WP-Optimize heeft hier een aparte optie voor.
9. wp_options doorlopen op autoload-grootte. Dat is een aparte aanpak (zie volgende sectie).
10. Database optimaliseren (OPTIMIZE TABLE). Defragmenteert tabellen en geeft schijfruimte terug.
11. Snelheid opnieuw meten. PageSpeed Insights en Query Monitor op een productpagina en een checkout.
12. Een paar dagen wachten en opnieuw kijken. Vooral op de checkout, om te zien of er niks stuk is.

Werktijd voor een normale shop: drie tot vijf uur, exclusief het opzetten van staging. Voor een grotere shop met tienduizenden producten en orders kan het oplopen naar een dag of twee.

Het wp_options-probleem en autoload

Specifiek wp_options verdient aparte aandacht. Daar gaat namelijk een instelling in schuil die op elke pagina meeglift: autoload.

Elke optie die op autoload = yes staat, wordt bij elke paginalading uit de database gehaald. Plugins die hun configuratie als autoload markeren en daar tonnen data in stoppen, vertragen je hele site, niet alleen één pagina. Een autoload-blok van vijf MB betekent dat elke pageview vijf MB ophaalt uit de database.

Om de grootste boosdoeners te vinden, draai je deze query:

sql

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

De top twintig op een normale shop is een paar honderd KB. Vind je daar opties van enkele MB, dan is daar werk. Soms is de oplossing om autoload uit te schakelen voor die optie, soms moet de hele optie weg. Welke van de twee hangt af van wat erin zit.

Dit is geen plug-and-play werk. Voor wie er niet ervaring mee heeft, is het beter om de hulp van iemand in te schakelen die het vaker doet.

Voorbeeldscenario: een opgezwollen database

Een fictief maar realistisch beeld. Dit is een voorbeeldscenario, niet een echte klant.

Stel: een WooCommerce-shop die vier jaar draait, ongeveer driehonderd producten, tienduizenden bestellingen in totaal. Database-grootte 2,4 GB, terwijl een vergelijkbare schone shop rond de 400 MB zou zitten.

Bij analyse:

• wp_options bevat 47 MB aan autoload-data, vooral van twee plugins die niet meer geïnstalleerd zijn
• wp_postmeta heeft 1,2 GB, gevuld met meta-velden van een oude bestelplugin
• wp_actionscheduler_logs heeft 5,8 miljoen rijen, geen onderhoud sinds installatie
• wp_woocommerce_sessions heeft 220.000 verlaten sessies van twee jaar oud

Wat erin gaat: oude plugin-meta gericht opruimen (op SKU-niveau zoeken naar verwezen velden), Action Scheduler met de juiste tool inkorten tot dertig dagen, sessies verwijderen, autoload-grootte terugbrengen tot wat normaal is. Doorlooptijd: een dag of twee zorgvuldig werk, plus een week monitoring.

Geen wondermiddel, wel duidelijk werk met meetbaar effect. Het soort taak waar database-werk echt verschil maakt.

Wat ik niet doe

Een paar dingen waar database-opschoning bewust ophoudt:

• Geen “database repair”-plugins zonder backup. Sommige plugins beloven wondermutaties die in werkelijkheid data verminken.
• Geen rechtstreekse DELETE-queries zonder WHERE-clause. Klinkt vanzelfsprekend, maar het gaat regelmatig fout bij wie haastig werkt.
• Geen database-aanpassingen tijdens drukke uren. Een opschoning doe je ’s avonds of in een laagseizoen, met staging.

Ik ben technisch implementeerder, geen SEO-strateeg. Database opschonen is implementatiewerk. De vraag of de gewonnen snelheid leidt tot meer omzet, hoort thuis bij een marketingadviseur. Verbeteren boven herbouwen geldt overigens wél hier: een opgeruimde database is bijna altijd beter dan een vers nieuwe shop.