wp_options<\/code><\/a> ist daf\u00fcr ein gutes Beispiel: Sie speichert nicht nur WordPress-Kerneinstellungen, sondern auch Konfigurationsdaten jedes installierten Plugins, Widget-Einstellungen, Theme-Optionen und tempor\u00e4re Eintr\u00e4ge. Je l\u00e4nger eine WordPress-Installation l\u00e4uft und je mehr Plugins im Laufe der Zeit installiert und wieder entfernt wurden, desto gr\u00f6\u00dfer wird diese Tabelle \u2013 oft auf mehrere tausend Zeilen, von denen ein Gro\u00dfteil keine aktive Funktion mehr erf\u00fcllt.<\/p>\nRevisionen: Das stille Datenwachstum<\/h2>\n
Einer der h\u00e4ufigsten Verursacher von Datenbankballast ist das Revisionssystem von WordPress. Jedes Mal, wenn ein Beitrag oder eine Seite gespeichert wird \u2013 auch bei kleinen \u00c4nderungen oder versehentlichem Klick auf \u201eSpeichern” \u2013, legt WordPress automatisch eine Kopie des bisherigen Zustands an. Diese Revisionen<\/a> werden dauerhaft in der Datenbank gespeichert und standardm\u00e4\u00dfig nicht automatisch gel\u00f6scht.<\/p>\nBei einem aktiv gepflegten Blog oder einer Website mit vielen Seiten summiert sich das schnell: Ein einziger Beitrag, der zwanzig Mal \u00fcberarbeitet wurde, erzeugt zwanzig Revisionseintr\u00e4ge in der Tabelle wp_posts<\/code><\/a> \u2013 jeweils mit vollst\u00e4ndigem Inhalt, Titel und allen zugeh\u00f6rigen Metadaten in wp_postmeta<\/code>. Bei hundert solchen Beitr\u00e4gen sind das potenziell tausende Zeilen, die keinen aktiven Nutzen mehr haben.<\/p>\nWordPress erlaubt es, die Anzahl der aufzubewahrenden Revisionen per Konfiguration zu begrenzen. Wer das nicht aktiv tut, akkumuliert Revisionen unbegrenzt.<\/p>\n
Papierkorb-Eintr\u00e4ge und Entw\u00fcrfe<\/h2>\n
\u00c4hnlich verh\u00e4lt es sich mit gel\u00f6schten Inhalten. WordPress verschiebt gel\u00f6schte Beitr\u00e4ge, Seiten und Medien standardm\u00e4\u00dfig in den Papierkorb, anstatt sie sofort zu l\u00f6schen. Der Papierkorb wird automatisch nach 30 Tagen geleert \u2013 aber nur, wenn der entsprechende Cronjob zuverl\u00e4ssig l\u00e4uft. Auf vielen Shared-Hosting-Umgebungen ist der WP-Cron<\/a> nicht zuverl\u00e4ssig konfiguriert, sodass Papierkorb-Eintr\u00e4ge deutlich l\u00e4nger als geplant in der Datenbank verbleiben.<\/p>\nHinzu kommen Entw\u00fcrfe, die nie ver\u00f6ffentlicht wurden: Angefangene Artikel, Testseiten, automatisch gespeicherte Arbeitskopien. All das liegt in wp_posts<\/code> mit dem Status draft<\/code> oder auto-draft<\/code> \u2013 und bleibt dort, bis es aktiv gel\u00f6scht wird.<\/p>\nTransients: Tempor\u00e4re Daten, die nicht verschwinden<\/h2>\n
Transients<\/a> sind ein Mechanismus in WordPress, mit dem Plugins und Themes tempor\u00e4re Daten zwischenspeichern k\u00f6nnen \u2013 \u00e4hnlich einem einfachen Cache. Der Gedanke dahinter ist sinnvoll: Statt bei jedem Seitenaufruf eine aufwendige Berechnung oder API-Abfrage durchzuf\u00fchren, wird das Ergebnis kurzzeitig in der Datenbank gespeichert und wiederverwendet.<\/p>\nDas Problem: Transients haben zwar eine Ablaufzeit, werden aber nicht automatisch gel\u00f6scht, wenn sie ablaufen. Sie bleiben als inaktive Eintr\u00e4ge in wp_options<\/code> stehen, bis WordPress sie beim n\u00e4chsten Zugriff \u00fcberschreibt oder ein Aufr\u00e4umprozess sie entfernt. Bei viel genutzten Websites oder nach der Deinstallation von Plugins, die intensiv von Transients Gebrauch gemacht haben, k\u00f6nnen sich Hunderte oder sogar Tausende solcher Eintr\u00e4ge ansammeln \u2013 ohne dass sie noch irgendeinem Zweck dienen.<\/p>\nPlugin-Deinstallationen hinterlassen Spuren<\/h2>\n
Wer WordPress \u00fcber l\u00e4ngere Zeit betreibt, installiert und deinstalliert typischerweise viele Plugins. Das ist normal \u2013 man probiert etwas aus, stellt fest, dass es nicht passt, und entfernt es wieder. Was dabei oft \u00fcbersehen wird: Viele Plugins hinterlassen nach ihrer Deinstallation Datenbankeintr\u00e4ge.<\/p>\n
Das liegt daran, dass WordPress bei der Deinstallation eines Plugins nur die Plugin-Dateien entfernt. Ob das Plugin dabei auch seine eigenen Datenbankeintr\u00e4ge aufr\u00e4umt, h\u00e4ngt davon ab, ob der Plugin-Entwickler eine entsprechende Deinstallationsroutine implementiert hat. Viele \u00e4ltere oder schlecht gewartete Plugins tun das nicht.<\/p>\n
Die Folge: Eigene Tabellen, die das Plugin angelegt hat, bleiben in der Datenbank bestehen. Einstellungen in wp_options<\/code> bleiben erhalten. Post-Meta-Eintr\u00e4ge<\/a> in wp_postmeta<\/code>, die das Plugin f\u00fcr 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.<\/p>\n![\"Illustration](\"https:\/\/furthmueller.info\/plugins\/wp-content\/uploads\/sites\/4\/2026\/06\/datenbank.png\")
Deinstallierte Plugins hinterlassen Tabelleneintr\u00e4ge, Einstellungen und Post-Meta \u2013 die Datenbank w\u00e4chst, auch wenn das Plugin l\u00e4ngst weg ist. \u00a9 2026 SJF.solutions \u00b7 Illustration erstellt mit ChatGPT (DALL\u00b7E)<\/figcaption><\/figure>\nSpam-Kommentare und Kommentar-Metadaten<\/h2>\n
Auf \u00f6ffentlich zug\u00e4nglichen 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 \u2013 aber auch dort bleiben sie zun\u00e4chst gespeichert. Wer den Spam-Ordner nicht regelm\u00e4\u00dfig leert, sammelt \u00fcber Monate tausende Eintr\u00e4ge in wp_comments<\/code> an, die keinerlei Informationswert haben.<\/p>\nZu jedem Kommentar k\u00f6nnen au\u00dferdem Metadaten in wp_commentmeta<\/code> gespeichert werden. Auch diese Eintr\u00e4ge bleiben nach dem L\u00f6schen von Kommentaren manchmal als verwaiste Datens\u00e4tze zur\u00fcck, wenn die L\u00f6schroutine nicht vollst\u00e4ndig arbeitet.<\/p>\nMedien-Duplikate und nicht zugewiesene Dateien<\/h2>\n
Die WordPress-Mediathek ist ein weiterer Bereich, in dem sich ungenutztes Material ansammelt. Wenn Bilder mehrfach hochgeladen werden \u2013 etwa weil ein Beitrag \u00fcberarbeitet und das Bild noch einmal eingef\u00fcgt wurde \u2013, entstehen Duplikate sowohl auf dem Server als auch in der Datenbank. WordPress erzeugt beim Upload au\u00dferdem automatisch mehrere Bildgr\u00f6\u00dfen (Thumbnail, Medium, Large sowie custom sizes, die Themes definieren), die ebenfalls gespeichert werden.<\/p>\n
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<\/a> in wp_posts<\/code>, die keinem \u00fcbergeordneten Beitrag zugeordnet sind.<\/p>\nAutoload-Optionen und Performance<\/h2>\n
Ein oft untersch\u00e4tztes Problem ist die autoload<\/code>-Spalte<\/a> in wp_options<\/code>. Eintr\u00e4ge, die dort auf yes<\/code> gesetzt sind, werden bei jedem einzelnen Seitenaufruf vollst\u00e4ndig in den Arbeitsspeicher geladen \u2013 unabh\u00e4ngig davon, ob sie gerade gebraucht werden. Je mehr Plugins ihre Einstellungen mit autoload=yes<\/code> speichern, desto gr\u00f6\u00dfer wird diese initiale Datenbankabfrage bei jedem Seitenaufruf.<\/p>\nBei 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 \u2013 auch wenn der Effekt auf modernen Servern oft erst unter Last sp\u00fcrbar wird.<\/p>\n
Warum WordPress das nicht automatisch bereinigt<\/h2>\n
Man k\u00f6nnte fragen: Warum r\u00e4umt WordPress das nicht einfach automatisch auf? Die Antwort liegt in der Philosophie des Systems. WordPress ist darauf ausgelegt, keine Daten ohne explizite Nutzerbest\u00e4tigung zu l\u00f6schen. Das ist in vielen F\u00e4llen das richtige Verhalten \u2013 niemand m\u00f6chte, dass WordPress selbstst\u00e4ndig entscheidet, welche alten Daten noch gebraucht werden und welche nicht.<\/p>\n
Die Kehrseite ist, dass der Nutzer selbst aktiv werden muss. WordPress bietet daf\u00fcr einige Grundfunktionen (manuelles Leeren des Papierkorbs, Limit f\u00fcr Revisionen per wp-config.php<\/code>), aber keine umfassende automatisierte Bereinigung. Das ist bewusst so gestaltet \u2013 und erkl\u00e4rt, warum die Datenbankverwaltung f\u00fcr WordPress-Betreiber eine regelm\u00e4\u00dfige Wartungsaufgabe ist, die nicht von selbst erledigt wird.<\/p>\nFazit<\/h2>\n
Datenbankballast bei WordPress ist kein Zeichen einer kaputten oder schlecht konfigurierten Installation. Er ist die nat\u00fcrliche Folge davon, wie WordPress gebaut ist: flexibel, datenbasiert, mit einem starken Fokus auf Datensicherheit statt automatischer Bereinigung. Wer das versteht, kann gezielt gegensteuern \u2013 durch Konfiguration (Revisionslimit, WP-Cron<\/a>-Zuverl\u00e4ssigkeit), regelm\u00e4\u00dfige manuelle Bereinigung und ein Bewusstsein daf\u00fcr, welche Plugins wie intensiv mit der Datenbank interagieren.<\/p>\nEine gut gepflegte WordPress-Datenbank ist kein einmaliges Projekt, sondern ein Teil der laufenden Website-Wartung \u2013 \u00e4hnlich wie das Einspielen von Updates oder das Pr\u00fcfen von Backups.<\/p>\n
\n