- Die WordPress-Datenbank wächst durch Revisionen, abgelaufene Transients, Trash-Einträge und Überreste deinstallierter Plugins langsam aber sicher an.
- Eine Bereinigung ist Hygiene, kein Performance-Wunder: Ladezeit-Gewinne sind in den meisten Fällen kaum messbar, das eigentliche Ziel ist eine saubere, übersichtliche Datenbasis.
- Revisionen per
WP_POST_REVISIONSbegrenzen ist der wirksamste Schritt, den Sie einmal in der wp-config.php erledigen und dann vergessen können. - Immer zuerst sichern: ein aktuelles Backup ist keine Option, sondern Bedingung, bevor irgendein Bereinigungswerkzeug startet.
Viele WordPress-Betreiber bereinigen ihre Datenbank aus einem vagen Pflichtgefühl heraus oder weil ein Plugin ihnen eine rote Warnung zeigt. Dabei lohnt es sich, vorher kurz zu fragen, was da eigentlich bereinigt werden soll, ob es wirklich nötig ist, und ob das erhoffte Ergebnis realistisch ist. Dieser Ratgeber erklärt, was in einer WordPress-Datenbank anwächst, welche Bereinigung tatsächlich nützt und wo der Aufwand den Nutzen kaum übersteigt.
Was eine WordPress-Datenbank aufbläht
Die WordPress-Datenbank ist kein statisches Gebilde. Jede Bearbeitung, jeder Plugin-Prozess und jeder Kommentar hinterlässt Spuren. Manche davon sind nützlich und gewollt, andere sind schlicht digitaler Hausrat.
Post-Revisionen
Jedes Mal, wenn Sie einen Beitrag oder eine Seite speichern, legt WordPress eine Revisionskopie an und speichert sie in der wp_posts-Tabelle mit dem Typ revision als Kind des jeweiligen Beitrags. Laut WordPress-Dokumentation zu Revisionen speichert WordPress standardmäßig jede Version ohne Limit. Ein Beitrag, den Sie über zwei Jahre hinweg hundert Mal überarbeitet haben, hat hundert Revisionszeilen in der Datenbank.
Ebenfalls als Revision gespeichert sind Autosave-Einträge. Hier hält WordPress jedoch pro Nutzer und Beitrag maximal einen Autosave, der beim nächsten Autosave überschrieben wird. Auto-Drafts, also die vorläufigen Entwürfe, die beim ersten Öffnen des Editors entstehen, werden von WordPress nach 7 Tagen automatisch gelöscht.
Trash-Einträge
Beiträge, Seiten und Kommentare, die in den Papierkorb verschoben wurden, verbleiben dort standardmäßig 30 Tage, bevor sie WordPress automatisch endgültig löscht. Das ist durch die Konstante EMPTY_TRASH_DAYS gesteuert. Wer regelmäßig Inhalte löscht und den Papierkorb nie manuell leert, sammelt über Monate hinweg eine stattliche Menge an Einträgen an.
Abgelaufene Transients
Transients sind temporäre Zwischenspeicher, die Plugins und WordPress selbst in der wp_options-Tabelle ablegen. Laut WordPress Transients API haben sie eine Ablaufzeit, werden danach aber nicht sofort aktiv gelöscht, sondern erst, wenn das nächste Mal auf denselben Schlüssel zugegriffen wird. Plugin-Code, der Transients setzt und dann nie mehr aufruft, hinterlässt so abgelaufene Einträge, die still in der Datenbank bleiben. Bei Installationen mit vielen Plugins können sich dort hunderte oder tausende veraltete Einträge ansammeln.
Wichtig: Wenn ein Caching-Plugin oder ein Object-Cache-Backend wie Redis oder Memcached aktiv ist, werden Transients im Arbeitsspeicher statt in der Datenbank gehalten. Dann entfällt dieses Problem vollständig.
Verwaiste Postmeta
Jeder Beitrag kann beliebig viele Meta-Felder haben, gespeichert in wp_postmeta. Wird ein Beitrag gelöscht, löscht WordPress die zugehörigen Meta-Daten in den meisten Fällen mit. Was übrig bleibt, sind Einträge von Plugins, die Meta auf Objekte schreiben und die Bereinigung nicht sauber implementieren, oder Einträge, deren übergeordneter Beitrag aus der Datenbank entfernt wurde, ohne dass die Kaskade korrekt gefeuert hat. Das ist selten ein großes Volumen, aber es kommt vor.
Überreste deinstallierter Plugins
Viele Plugins legen bei der Aktivierung eigene Tabellen oder Optionseinträge in wp_options an. Gut geschriebene Plugins räumen das bei der Deinstallation auf, indem sie einen Uninstall-Hook nutzen. Andere hinterlassen ihre Tabellen dauerhaft. Eine deinstallierte SEO-Suite kann leicht mehrere MB an eigenen Tabellen zurücklassen. Das ist zwar kein unmittelbares Leistungsproblem, aber es ist unnötiger Ballast.
Spam-Kommentare
WordPress markiert erkannten Spam-Kommentare, löscht sie aber nicht automatisch. Wer die Spam-Warteschlange selten prüft, sammelt über Zeit eine große Anzahl an Einträgen, die in wp_comments und wp_commentmeta liegen. Bei aktiv beworbenen Seiten ohne wirksamen Spam-Filter können das tausende Einträge sein.
Was sich lohnt und was überschätzt wird
Nicht alles, was bereinigt werden kann, lohnt den Aufwand. Die folgende Tabelle zeigt, was wirklich nützt, was überschätzt wird, und was das Risiko ist, wenn man dabei nicht aufpasst.
| Was bereinigt wird | Echter Nutzen | Überschätzt? | Risiko |
|---|---|---|---|
| Revisionen begrenzen (WP_POST_REVISIONS) | Weniger Datenbankzeilen, sauberere wp_posts-Tabelle, langfristig Wachstum stoppen | Nein, klarer dauerhafter Nutzen | Kein Risiko, wenn nach vorne wirkend eingestellt; alte Revisionen bleiben |
| Alte Revisionen löschen | Volumenreduktion, besonders bei langer Laufzeit | Ladezeit-Gewinn in den meisten Fällen nicht spürbar | Verlust der Versionsgeschichte; kein Zurück ohne Backup |
| Abgelaufene Transients löschen | Sauberere wp_options, etwas weniger Lookup-Aufwand | Ja; bei Object Cache ohnehin irrelevant | Gering; Transients werden bei Bedarf neu geschrieben |
| Trash leeren | Sofortiger Volumenabbau bei großen Beständen | Nein, klarer Nutzen | Hoch: gelöschte Inhalte lassen sich ohne Backup nicht wiederherstellen |
| Spam-Kommentare löschen | Reduziert wp_comments und wp_commentmeta | Nein | Kein Risiko, Spam hat keinen Wert |
| Verwaiste Postmeta löschen | Kleine Volumenreduktion | Ja; Abfragen laufen über Index, wenige tausend Zeilen machen kaum Unterschied | Mittel: fehlerhaft erkannte Einträge können laufende Plugins brechen |
| Tabellen alter Plugins entfernen | Saubere Datenbankstruktur | Volumenmäßig meist gering | Hoch: ist das Plugin noch aktiv, gehen Daten verloren; erst prüfen |
| Tabellen-Optimierung (OPTIMIZE TABLE) | Fragmentierung bereinigen, Platz freigeben | Ja; bei modernem InnoDB selten nötig, greift für InnoDB ohnehin anders als für MyISAM | Gering; bei InnoDB läuft OPTIMIZE TABLE intern als ALTER TABLE … FORCE über Online DDL, sodass paralleles DML möglich ist, ein kurzer exklusiver Table-Lock wird aber weiterhin in der Prepare- und der Commit-Phase gehalten; bei MyISAM kurzzeitiger Table-Lock |
Zu den Erwartungen sollte man ehrlich sein: WordPress fragt bei Datenbankabfragen in der Regel über Indizes ab, nicht über Volumen-Scans. Eine wp_posts-Tabelle mit 50.000 statt 5.000 Einträgen verlangsamt eine korrekt indizierte Abfrage nicht spürbar. Der Gewinn durch das Löschen von Tausenden Revisionen liegt meist im Bereich von Millisekunden oder darunter. Den größten praktischen Nutzen hat die Bereinigung für die Übersichtlichkeit und das Backup-Volumen: kleinere Datenbank bedeutet kleinere Backups und kürzere Restore-Zeiten.
Für Entwickler · überspringbar
Für Technikaffine: wp-config.php und WP-CLI
Dieser Abschnitt richtet sich an alle, die direkt in den Code gehen wollen. Einsteiger können ihn überspringen und mit dem nächsten Abschnitt zu Plugins weitermachen.
Revisionen dauerhaft begrenzen
Die effektivste und nachhaltigste Maßnahme ist die Begrenzung über WP_POST_REVISIONS in der wp-config.php. Laut offizieller wp-config.php-Dokumentation gilt:
// Maximale Anzahl Revisionen pro Beitrag auf 5 begrenzen
define( 'WP_POST_REVISIONS', 5 );
// Revisionen komplett deaktivieren (nicht empfohlen, kein Versionsschutz mehr)
define( 'WP_POST_REVISIONS', false );
// Trash nach 14 statt 30 Tagen automatisch leeren
define( 'EMPTY_TRASH_DAYS', 14 );
Eine Zahl von 3 bis 5 ist für die meisten Websites ein pragmatischer Wert: genug, um Tippfehler rückgängig zu machen, aber kein unbeschränktes Wachstum. Diese Einstellung wirkt nur nach vorne. Bestehende Revisionen werden nicht berührt.
Alte Revisionen per WP-CLI löschen
Wer WP-CLI hat und die bestehenden Revisionen in einem Rutsch entfernen will, geht so vor:
# Alle Revisionen auflisten (Trockentest)
wp post list --post_type=revision --fields=ID,post_parent,post_date --format=table
# Alle Revisionen löschen (kein Backup nötig? Trotzdem erst sichern!)
wp post delete $(wp post list --post_type=revision --format=ids) --force
# Bei sehr vielen Revisionen (zehntausende) umgeht diese Variante das Limit der Kommandozeilenlänge:
wp post list --post_type=revision --format=ids | xargs wp post delete --force
Das --force überspringt den Papierkorb und löscht dauerhaft. Ohne aktuelles Backup sollte dieser Schritt nicht ausgeführt werden.
Abgelaufene Transients per WP-CLI löschen
wp transient delete --expired
Dieser Befehl entfernt ausschließlich abgelaufene Transients. Gültige Transients, die aktive Plugins gerade nutzen, bleiben unangetastet. Ein wp transient delete --all würde alle löschen, inklusive aktiver, was Plugins kurzzeitig langsamer macht, bis sie ihre Caches neu aufgebaut haben.
Plugin oder manuell: WP-Optimize und Alternativen
Für die meisten WordPress-Betreiber ohne direkten Serverzugang ist ein Plugin der praktikabelste Weg. Das meistverwendete Werkzeug ist WP-Optimize (kostenlos, über 1 Million aktive Installationen laut wordpress.org). Es bietet eine Übersicht der Datenbankgröße, lässt gezielt Revisionen, Transients, Trash und Spam löschen und kann die Bereinigung nach Zeitplan automatisch ausführen.
Alternativen sind Advanced Database Cleaner oder das WP-CLI-Vorgehen, wenn Shell-Zugang vorhanden ist. Was alle Wege gemeinsam haben: Sie setzen ein aktuelles Backup voraus. Kein Plugin ist unfehlbar, und das automatische Löschen von Datenbankzeilen ist eine Operation, die sich ohne Backup nicht rückgängig machen lässt.
Einen breiten WordPress-Wartungsvertrag, der Backup, Updates und gelegentliche Datenbankpflege einschließt, erklärt unser Wartungsratgeber. Wenn Sie lieber die laufende Pflege abgeben wollen, finden Sie einen Überblick zu unseren Betreuungspaketen unter WordPress Care Service.
Aus der Praxis: ein konkretes Beispiel
In einem Kundenprojekt sahen wir eine WordPress-Installation, die seit vier Jahren ohne WP_POST_REVISIONS-Begrenzung betrieben wurde. Der Kundenbereich des Shops hatte rund 120 Beiträge und Seiten, aber über 3.400 Revisionseinträge in wp_posts, der dreifache Umfang des eigentlichen Inhalts. Die Datenbankgröße lag bei knapp 280 MB, ein Großteil davon in wp_posts und wp_postmeta.
Nach dem Backup, dem Löschen der Revisionen und dem Setzen von WP_POST_REVISIONS auf 5 schrumpfte die Datenbank auf rund 90 MB. Die gemessene Ladezeit änderte sich kaum, was unsere Erwartung bestätigte: Der Server nutzte Caching, und WordPress fragte über Indizes ab. Der echte Gewinn war ein um Faktor 3 kleines Backup, ein schnellerer Restore im Notfall, und eine Datenbankstruktur, die bei Debugging und Migration keine unerwarteten Volumen produziert. Das war es wert.
Was diese Bereinigung nicht leistete: eine spürbar schnellere Website. Wer das möchte, findet die relevanten Hebel in unserem Artikel WordPress Speed-Optimierung.
Schritt-für-Schritt: Sicher vorgehen
- Gibt es ein aktuelles Datenbankbackup, das vor der Bereinigung gemacht wurde?
- Ist
WP_POST_REVISIONSin der wp-config.php auf einen sinnvollen Wert (3 bis 5) gesetzt? - Wurden abgelaufene Transients über WP-CLI oder Plugin gelöscht (bei Object Cache nicht nötig)?
- Ist der Papierkorb für Beiträge und Kommentare geleert?
- Sind Spam-Kommentare gelöscht?
- Wurden Tabellen deinstallierter Plugins identifiziert und bewusst entschieden (behalten oder löschen)?
- Ist nach der Bereinigung die Website auf Funktion getestet (Startseite, Shop, Formulare)?
- Die WordPress-Datenbank wächst vor allem durch Revisionen, Transients und Trash. Das ist normal, aber steuerbar.
- Wirksamste dauerhafte Maßnahme:
WP_POST_REVISIONSeinmal in der wp-config.php setzen, dann nie wieder anfassen müssen. - Ladezeit-Gewinne durch Datenbankbereinigung sind in den meisten Fällen marginal. Backup-Größe und Ordnung sind die eigentlichen Vorteile.
- Vor jeder Bereinigung: Backup. Gelöschte Datenbankzeilen gibt es ohne Backup nicht zurück.
Häufige Fragen
Bringt das Bereinigen der WordPress-Datenbank mehr Geschwindigkeit?
In den meisten Fällen kaum messbar. WordPress fragt über Datenbankindizes ab, nicht über Volumen. Bei einer Site mit Caching und vernünftigem Hosting liegt der Ladezeit-Effekt im Sub-Millisekunden-Bereich. Den echten Unterschied machen Caching, ein schnelles Hosting und optimierte Bilder, nicht das Löschen von Revisionen. Details dazu im Artikel WordPress Speed-Optimierung.
Wie oft sollte man die WordPress-Datenbank bereinigen?
Bei gesetztem WP_POST_REVISIONS und automatischem Trash-Leeren (Standard: 30 Tage) ist keine regelmäßige manuelle Bereinigung nötig. Abgelaufene Transients zu löschen lohnt einmal im Quartal oder nach der Deinstallation von Plugins, wenn kein Object-Cache aktiv ist.
Kann ich die Datenbank bereinigen ohne Plugin?
Ja, mit WP-CLI oder direkt per SQL. WP-CLI ist für technisch versierte Nutzer der sauberere Weg, weil er ohne Zusatz-Plugin auskommt und präzise steuerbar ist. Ein Backup ist in beiden Fällen Pflicht.
Was passiert, wenn ich alle Revisionen lösche?
Sie verlieren die Versionsgeschichte aller betroffenen Beiträge und Seiten. Das lässt sich ohne Backup nicht rückgängig machen. Ob Sie das in Kauf nehmen wollen, hängt davon ab, ob Sie die alten Versionen noch brauchen. Für aktive Redaktionssysteme ist Vorsicht geboten.
Was sind abgelaufene Transients genau?
Transients sind temporäre Zwischenspeicher, die Plugins und WordPress in der wp_options-Tabelle ablegen. Sie haben eine Ablaufzeit, werden nach dem Ablauf aber nicht sofort aktiv gelöscht, sondern erst beim nächsten Zugriff auf denselben Schlüssel. Das führt dazu, dass abgelaufene Einträge still in der Datenbank bleiben, bis sie jemand oder ein Plugin aktiv aufräumt. Mehr zur Transients API erklärt die offizielle WordPress-Entwicklerdokumentation.
Woran erkenne ich Tabellen von deinstallierten Plugins?
Per phpMyAdmin oder WP-CLI (wp db tables) kann man alle Tabellen der Installation auflisten. Tabellen, die nicht zum WordPress-Standard gehören und deren Plugin nicht mehr aktiv ist, lassen sich oft am Präfix erkennen, zum Beispiel wp_yith_… oder wp_<pluginname>_… bei deinstallierten Drittanbieter-Erweiterungen. Vor dem Löschen prüfen, ob das Plugin wirklich weg ist und ob die Daten noch gebraucht werden.
Hilft WP-Optimize wirklich oder ist es Placebo?
WP-Optimize erledigt real die Datenbankoperationen, die man auch manuell per WP-CLI oder SQL ausführen könnte. Es ist kein Placebo, aber die Erwartungshaltung muss passen: ein saubereres, kleineres Datenbankschema, keine Wunderheilung für eine langsame Website. Wer zu viele Plugins betreibt und das als Ursache für Trägheit vermutet, findet dazu mehr in unserem Artikel WordPress Plugin-Bloat.
Brauche ich wirklich ein Backup davor?
Ja. Eine Datenbankbereinigung löscht Zeilen dauerhaft. Anders als beim Löschen von Dateien gibt es keinen Papierkorb und keine Rückgängig-Funktion im laufenden Betrieb. Ohne Backup ist ein Fehler unwiderruflich. Die Backup-Strategie für WordPress erläutert unser Artikel WordPress Backup automatisieren.