Een website van vijf jaar oud heeft vaak een database die drie keer zo groot is als nodig. Niemand heeft dat bewust gedaan. Het gebeurt gewoon: elke bewerking van een pagina laat een revisie achter, elke plugin schrijft zijn eigen instellingen weg en tijdelijke gegevens blijven hangen lang nadat ze verlopen zijn. De site werkt nog, maar het beheer voelt stroperig en de back-ups worden elke maand groter.

Uw WordPress-database opschonen klinkt als een klus voor techneuten, en deels is dat ook zo. Maar het grootste deel is vooral een kwestie van weten wat er in die database zit en wat daar met een gerust hart uit mag. In dit artikel neem ik u daar stap voor stap in mee, inclusief de dingen waar u met uw handen vanaf blijft.

Wat er eigenlijk in een WordPress-database staat

WordPress slaat vrijwel alles wat u in het beheer doet op in een MySQL- of MariaDB-database. Een standaardinstallatie heeft twaalf tabellen. De belangrijkste voor dit verhaal:

  • wp_posts: pagina’s, berichten, producten, menu-items, maar ook revisies en concepten.
  • wp_postmeta: extra gegevens bij die posts, zoals uitgelichte afbeeldingen, SEO-velden en productprijzen.
  • wp_options: instellingen van WordPress en plugins, plus zogeheten transients (tijdelijke cachegegevens).
  • wp_comments en wp_commentmeta: reacties, inclusief spam en prullenbak.

Plugins voegen daar vaak eigen tabellen aan toe. Een formulierplugin bewaart inzendingen, een beveiligingsplugin logt inlogpogingen, een statistiekplugin registreert elke paginaweergave. Die laatste categorie is in onze ervaring de grootste boosdoener: logtabellen van honderden megabytes zijn geen uitzondering.

Wat u veilig kunt verwijderen

Dit zijn de categorieën die vrijwel altijd zonder gevolgen weg kunnen. Ik zet ze in volgorde van laag naar iets meer aandacht.

  1. Spamreacties en reacties in de prullenbak. Nul risico. Als u reacties helemaal niet gebruikt, kunt u ook overwegen ze uit te schakelen.
  2. Verlopen transients. Dit zijn tijdelijke waarden die een plugin heeft opgeslagen met een houdbaarheidsdatum. Is die datum verstreken, dan maakt WordPress ze gewoon opnieuw aan als dat nodig is.
  3. Automatische concepten (auto-drafts). WordPress maakt er een aan zodra u op “Nieuwe pagina” klikt, ook als u daarna niets opslaat.
  4. Items in de prullenbak. Pagina’s en berichten die u zelf al hebt weggegooid. WordPress ruimt die standaard na dertig dagen op, maar niet alle sites hebben dat goed staan.
  5. Oude revisies. Elke keer dat u een pagina bijwerkt, bewaart WordPress de vorige versie. Bij een pagina die tachtig keer is aangepast staan er dus tachtig kopieën in de database. De laatste paar bewaren is verstandig, de rest mag weg. Hoe u voorkomt dat dit opnieuw ontstaat, leest u in ons artikel over het beperken van revisies.
  6. Verweesde metadata. Regels in wp_postmeta die horen bij een post die niet meer bestaat. Ze doen niets meer, maar nemen wel ruimte in.

Een opschoonplugin zoals WP-Optimize of Advanced Database Cleaner laat per categorie zien hoeveel rijen het betreft. Dat is prettig: u ziet meteen of het om twintig regels gaat of om twintigduizend.

Waar u vanaf blijft

Hier gaat het in de praktijk mis. Sommige opschoonplugins bieden opties aan die er onschuldig uitzien, maar die schade aanrichten als u niet precies weet wat u doet.

  • Tabellen van “inactieve” plugins. Een plugin die u tijdelijk hebt uitgeschakeld heeft zijn instellingen nog nodig zodra u hem weer inschakelt. Verwijder alleen tabellen van plugins die u definitief hebt gedeïnstalleerd, en dan nog: controleer eerst of de naam van de tabel echt bij die plugin hoort.
  • Onbekende opties in wp_options. Plugins geven hun opties niet altijd een herkenbare naam. Een rij die er verweesd uitziet, kan van uw thema zijn.
  • Bestellingen en klantgegevens in WooCommerce. Oude bestellingen zijn geen rommel. U hebt ze nodig voor uw administratie, en de Belastingdienst verwacht dat u ze zeven jaar bewaart.
  • Formulierinzendingen. Die kunt u best opruimen, maar doe dat vanuit de plugin zelf en alleen als u zeker weet dat ze niet meer nodig zijn.
  • Het optimaliseren van tabellen tijdens drukte. De opdracht OPTIMIZE TABLE vergrendelt een tabel kort. Op een drukke webshop doet u dat ‘s nachts.

Stappenplan: zo pakt u het aan

De volgorde hieronder is de volgorde die wij zelf aanhouden. Sla stap 1 nooit over.

  1. Maak een volledige back-up, inclusief database. Test liefst ook of u die kunt terugzetten. Mocht er iets misgaan, dan wilt u niet op dat moment ontdekken dat de back-up onvolledig was. Wat daar allemaal bij komt kijken staat in het stappenplan voor het terugzetten van een back-up.
  2. Bekijk de omvang per tabel. Via phpMyAdmin bij uw hostingpartij, of via het tabblad “Tabellen” in WP-Optimize. Sorteer op grootte. Meestal springen er twee of drie uit.
  3. Begin met de veilige categorieën: spam, prullenbak, verlopen transients, auto-drafts. Voer ze een voor een uit en controleer tussendoor of de site nog normaal werkt.
  4. Beperk daarna de revisies. Bewaar er bijvoorbeeld vijf per pagina en verwijder de rest.
  5. Onderzoek de grote plugintabellen. Een logtabel van een beveiligingsplugin kunt u meestal vanuit de instellingen van die plugin zelf leegmaken of beperken tot dertig dagen. Dat is netter dan direct in de database ingrijpen.
  6. Optimaliseer de tabellen als laatste stap, buiten kantooruren.
  7. Controleer de site: homepage, een paar diepere pagina’s, het contactformulier en bij een webshop een testbestelling.

Een voorbeeld uit de praktijk

Een installatiebedrijf uit Apeldoorn had een website die in het beheer steeds trager werd. De database bleek 1,4 GB groot, terwijl de site zelf nog geen honderd pagina’s telde. Ruim 1,1 GB daarvan zat in één tabel van een statistiekplugin die al twee jaar niet meer werd bekeken, en nog eens honderd megabyte in revisies van een pagina met projectfoto’s die wekelijks werd bijgewerkt.

De aanpak: back-up, statistiekplugin verwijderen inclusief tabel, revisies terugbrengen tot vijf per pagina, transients opruimen, tabellen optimaliseren. Daarna was de database ruim 60 MB. De back-up die eerst twintig minuten duurde, was in een minuut klaar en het beheer reageerde weer normaal. Geen ingewikkelde techniek, wel een middag geconcentreerd werk.

Hoe vaak is dit nodig?

Voor een gewone bedrijfssite is een opschoonbeurt per kwartaal ruim voldoende, mits revisies zijn beperkt en logplugins hun eigen opruiming doen. Een webshop met veel verkeer of een site met veel redacteuren heeft er baat bij dit maandelijks te doen. Wie dit liever niet zelf bijhoudt, kan het onderbrengen in een vast onderhoudsabonnement; bij WebMaintor zit databaseonderhoud standaard in de maandelijkse ronde, met een back-up vooraf.

Het belangrijkste is dat het gebeurt. Een database die nooit wordt opgeschoond, wordt niet vanzelf beter. En de dag dat u snel een back-up moet terugzetten, bent u blij dat die niet anderhalve gigabyte groot is.

Conclusie

Het opschonen van de database is een van de meest dankbare onderhoudsklussen: weinig risico als u de volgorde aanhoudt, en direct merkbaar in het beheer en in de back-uptijd. Maak eerst een back-up, begin bij de veilige categorieën en laat tabellen die u niet herkent met rust. Plan de eerste ronde in voor een rustig moment, kijk wat de grootste tabellen zijn en pak die als eerste aan.