WordPress ist das meistgenutzte Content-Management-System der Welt – und gleichzeitig eines der Systeme, das am schnellsten eine übervolle Datenbank produziert. Wer eine WordPress-Website über Monate oder Jahre betreibt, ohne sich um die Datenbank zu kümmern, wird irgendwann feststellen: Die Seite wird langsamer, Backups wachsen ins Unermessliche, und Datenbankabfragen dauern länger als nötig. Der Grund dafür liegt nicht in einem Fehler von WordPress – sondern in der Art, wie das System von Grund auf konstruiert ist.
Die Architektur als Ursache
WordPress speichert nahezu alles in einer einzigen MySQL-Datenbank. Inhalte, Einstellungen, Nutzerdaten, Metadaten, Cache-Einträge, Protokolle – alles landet in denselben Tabellen. Das macht WordPress flexibel und leicht erweiterbar, führt aber dazu, dass Daten sich über die Zeit unkontrolliert anhäufen.
Die zentrale Tabelle wp_options ist dafür ein gutes Beispiel: Sie speichert nicht nur WordPress-Kerneinstellungen, sondern auch Konfigurationsdaten jedes installierten Plugins, Widget-Einstellungen, Theme-Optionen und temporäre Einträge. Je länger eine WordPress-Installation läuft und je mehr Plugins im Laufe der Zeit installiert und wieder entfernt wurden, desto größer wird diese Tabelle – oft auf mehrere tausend Zeilen, von denen ein Großteil keine aktive Funktion mehr erfüllt.
Revisionen: Das stille Datenwachstum
Einer der häufigsten Verursacher von Datenbankballast ist das Revisionssystem von WordPress. Jedes Mal, wenn ein Beitrag oder eine Seite gespeichert wird – auch bei kleinen Änderungen oder versehentlichem Klick auf „Speichern” –, legt WordPress automatisch eine Kopie des bisherigen Zustands an. Diese Revisionen werden dauerhaft in der Datenbank gespeichert und standardmäßig nicht automatisch gelöscht.
Bei einem aktiv gepflegten Blog oder einer Website mit vielen Seiten summiert sich das schnell: Ein einziger Beitrag, der zwanzig Mal überarbeitet wurde, erzeugt zwanzig Revisionseinträge in der Tabelle wp_posts – jeweils mit vollständigem Inhalt, Titel und allen zugehörigen Metadaten in wp_postmeta. Bei hundert solchen Beiträgen sind das potenziell tausende Zeilen, die keinen aktiven Nutzen mehr haben.
WordPress erlaubt es, die Anzahl der aufzubewahrenden Revisionen per Konfiguration zu begrenzen. Wer das nicht aktiv tut, akkumuliert Revisionen unbegrenzt.
Papierkorb-Einträge und Entwürfe
Ähnlich verhält es sich mit gelöschten Inhalten. WordPress verschiebt gelöschte Beiträge, Seiten und Medien standardmäßig in den Papierkorb, anstatt sie sofort zu löschen. Der Papierkorb wird automatisch nach 30 Tagen geleert – aber nur, wenn der entsprechende Cronjob zuverlässig läuft. Auf vielen Shared-Hosting-Umgebungen ist der WP-Cron nicht zuverlässig konfiguriert, sodass Papierkorb-Einträge deutlich länger als geplant in der Datenbank verbleiben.
Hinzu kommen Entwürfe, die nie veröffentlicht wurden: Angefangene Artikel, Testseiten, automatisch gespeicherte Arbeitskopien. All das liegt in wp_posts mit dem Status draft oder auto-draft – und bleibt dort, bis es aktiv gelöscht wird.
Transients: Temporäre Daten, die nicht verschwinden
Transients sind ein Mechanismus in WordPress, mit dem Plugins und Themes temporäre Daten zwischenspeichern können – ähnlich einem einfachen Cache. Der Gedanke dahinter ist sinnvoll: Statt bei jedem Seitenaufruf eine aufwendige Berechnung oder API-Abfrage durchzuführen, wird das Ergebnis kurzzeitig in der Datenbank gespeichert und wiederverwendet.
Das Problem: Transients haben zwar eine Ablaufzeit, werden aber nicht automatisch gelöscht, wenn sie ablaufen. Sie bleiben als inaktive Einträge in wp_options stehen, bis WordPress sie beim nächsten Zugriff überschreibt oder ein Aufräumprozess sie entfernt. Bei viel genutzten Websites oder nach der Deinstallation von Plugins, die intensiv von Transients Gebrauch gemacht haben, können sich Hunderte oder sogar Tausende solcher Einträge ansammeln – ohne dass sie noch irgendeinem Zweck dienen.
Plugin-Deinstallationen hinterlassen Spuren
Wer WordPress über längere Zeit betreibt, installiert und deinstalliert typischerweise viele Plugins. Das ist normal – man probiert etwas aus, stellt fest, dass es nicht passt, und entfernt es wieder. Was dabei oft übersehen wird: Viele Plugins hinterlassen nach ihrer Deinstallation Datenbankeinträge.
Das liegt daran, dass WordPress bei der Deinstallation eines Plugins nur die Plugin-Dateien entfernt. Ob das Plugin dabei auch seine eigenen Datenbankeinträge aufräumt, hängt davon ab, ob der Plugin-Entwickler eine entsprechende Deinstallationsroutine implementiert hat. Viele ältere oder schlecht gewartete Plugins tun das nicht.
Die Folge: Eigene Tabellen, die das Plugin angelegt hat, bleiben in der Datenbank bestehen. Einstellungen in wp_options bleiben erhalten. Post-Meta-Einträge in wp_postmeta, die das Plugin für seine Funktion geschrieben hat, bleiben erhalten. Nach Jahren mit dutzenden installierten und wieder entfernten Plugins kann sich so eine erhebliche Menge an verwaisten Daten ansammeln.
Spam-Kommentare und Kommentar-Metadaten
Auf öffentlich zugänglichen WordPress-Seiten mit aktivierten Kommentaren landen unweigerlich Spam-Kommentare. Akismet und andere Spam-Filter fangen viele davon ab und verschieben sie in den Spam-Ordner – aber auch dort bleiben sie zunächst gespeichert. Wer den Spam-Ordner nicht regelmäßig leert, sammelt über Monate tausende Einträge in wp_comments an, die keinerlei Informationswert haben.
Zu jedem Kommentar können außerdem Metadaten in wp_commentmeta gespeichert werden. Auch diese Einträge bleiben nach dem Löschen von Kommentaren manchmal als verwaiste Datensätze zurück, wenn die Löschroutine nicht vollständig arbeitet.
Medien-Duplikate und nicht zugewiesene Dateien
Die WordPress-Mediathek ist ein weiterer Bereich, in dem sich ungenutztes Material ansammelt. Wenn Bilder mehrfach hochgeladen werden – etwa weil ein Beitrag überarbeitet und das Bild noch einmal eingefügt wurde –, entstehen Duplikate sowohl auf dem Server als auch in der Datenbank. WordPress erzeugt beim Upload außerdem automatisch mehrere Bildgrößen (Thumbnail, Medium, Large sowie custom sizes, die Themes definieren), die ebenfalls gespeichert werden.
Hinzu kommen Medien, die hochgeladen, aber nie in einem Beitrag oder einer Seite verwendet wurden: Testbilder, veraltete Versionen, Importe aus alten Systemen. In der Datenbank sind das verwaiste Attachments in wp_posts, die keinem übergeordneten Beitrag zugeordnet sind.
Autoload-Optionen und Performance
Ein oft unterschätztes Problem ist die autoload-Spalte in wp_options. Einträge, die dort auf yes gesetzt sind, werden bei jedem einzelnen Seitenaufruf vollständig in den Arbeitsspeicher geladen – unabhängig davon, ob sie gerade gebraucht werden. Je mehr Plugins ihre Einstellungen mit autoload=yes speichern, desto größer wird diese initiale Datenbankabfrage bei jedem Seitenaufruf.
Bei einer frischen WordPress-Installation ist das kein Problem. Nach Jahren mit vielen Plugins kann die Summe der Autoload-Daten jedoch mehrere Megabyte erreichen. Das wirkt sich direkt auf die Ladezeit jeder einzelnen Seite aus – auch wenn der Effekt auf modernen Servern oft erst unter Last spürbar wird.
Warum WordPress das nicht automatisch bereinigt
Man könnte fragen: Warum räumt WordPress das nicht einfach automatisch auf? Die Antwort liegt in der Philosophie des Systems. WordPress ist darauf ausgelegt, keine Daten ohne explizite Nutzerbestätigung zu löschen. Das ist in vielen Fällen das richtige Verhalten – niemand möchte, dass WordPress selbstständig entscheidet, welche alten Daten noch gebraucht werden und welche nicht.
Die Kehrseite ist, dass der Nutzer selbst aktiv werden muss. WordPress bietet dafür einige Grundfunktionen (manuelles Leeren des Papierkorbs, Limit für Revisionen per wp-config.php), aber keine umfassende automatisierte Bereinigung. Das ist bewusst so gestaltet – und erklärt, warum die Datenbankverwaltung für WordPress-Betreiber eine regelmäßige Wartungsaufgabe ist, die nicht von selbst erledigt wird.
Fazit
Datenbankballast bei WordPress ist kein Zeichen einer kaputten oder schlecht konfigurierten Installation. Er ist die natürliche Folge davon, wie WordPress gebaut ist: flexibel, datenbasiert, mit einem starken Fokus auf Datensicherheit statt automatischer Bereinigung. Wer das versteht, kann gezielt gegensteuern – durch Konfiguration (Revisionslimit, WP-Cron-Zuverlässigkeit), regelmäßige manuelle Bereinigung und ein Bewusstsein dafür, welche Plugins wie intensiv mit der Datenbank interagieren.
Eine gut gepflegte WordPress-Datenbank ist kein einmaliges Projekt, sondern ein Teil der laufenden Website-Wartung – ähnlich wie das Einspielen von Updates oder das Prüfen von Backups.
Fachbegriffe wie Transient, Autoload, WP-Cron oder wp_options werden im WordPress-Glossar erklärt.
