WordPress-Datenbank aufräumen: Revisionen, Transients und Autoload-Optionen

Eine WordPress-Datenbank wächst mit jedem gespeicherten Entwurf, jedem Plugin und jedem Spam-Kommentar. Das meiste davon ist harmlos. Spürbar wird es an zwei Stellen: bei automatisch geladenen Optionen, die WordPress bei jedem Seitenaufruf komplett in den Speicher liest, und bei Tausenden alter Revisionen, die Sicherungen und Wiederherstellungen verlangsamen. Diese Anleitung zeigt, wie Sie mit WP-CLI und dem Werkzeug „Website-Zustand“ messen, gezielt aufräumen und künftiges Wachstum begrenzen. Alle Befehle und Meldungen stammen aus einem Test mit WordPress 7.1.2.

Voraussetzungen

• WordPress: geprüft mit WordPress 7.1.2. Die Autoload-Werte on, off, auto, auto-on und auto-off gibt es seit WordPress 6.6. Ältere Installationen kennen nur yes und no.
• PHP: WordPress empfiehlt derzeit mindestens PHP 7.4, getestet wurde mit PHP 8.4.
• WP-CLI und SSH: SSH-Zugang zum Server und WP-CLI (getestet mit 2.12.0). Viele Hoster stellen WP-CLI im SSH-Zugang als Befehl wp bereit. Ohne SSH können Sie Schritt 1 und die Kontrolle im Backend trotzdem nutzen.
• Rolle: ein Konto mit der Rolle Administrator für den Bereich Werkzeuge > Website-Zustand.
• Backup: eine aktuelle, geprüfte Sicherung von Datenbank und Dateien. Gelöschte Revisionen, Kommentare und Optionen lassen sich ohne Backup nicht zurückholen.
• Zeitfenster: für große Datenbanken eine ruhige Zeit ohne Bestellungen oder Redaktionsbetrieb, weil wp db optimize Tabellen neu aufbaut.

Schritt 1: Datenbank sichern und Ausgangslage messen

Aufräumen heißt löschen. Legen Sie deshalb vor dem ersten Befehl eine Sicherung außerhalb des Webroots an. Die Einzelheiten zu Export, Prüfung und Rückspielen beschreibt die Anleitung WordPress-Datenbank mit WP-CLI sichern und wiederherstellen.

cd /var/www/html
wp db export ~/backup/vor-bereinigung-$(date +%F).sql
wp db size --size_format=kb
wp db size --tables --size_format=kb
wp db prefix

Die Tabellenliste zeigt, wo das Volumen liegt. Wächst wp_posts deutlich schneller als die Zahl Ihrer Beiträge, sind meist Revisionen der Grund. Ist wp_options groß, lohnt der Blick auf Transients und Autoload. Die SQL-Beispiele verwenden das Standardpräfix wp_, Ihres zeigt wp db prefix.

Zählen Sie dann die Beitragstypen für den späteren Vergleich:

wp db query "SELECT post_type, COUNT(*) FROM wp_posts GROUP BY post_type"
wp post list --post_type=revision --format=count

Verifizieren: Der Export endet mit Success: Exported to '...', die Datei ist größer als null Byte, und Sie haben die Gesamtgröße sowie die Zahl der Revisionen notiert.

Schritt 2: Automatisch geladene Optionen prüfen

In der Tabelle wp_options speichern WordPress, Themes und Plugins ihre Einstellungen. Optionen mit Autoload lädt WordPress bei jedem Seitenaufruf gesammelt über wp_load_alloptions(), auch wenn die Seite sie gar nicht braucht. Ein Plugin, das dort einen großen Cache ablegt, bremst damit jede Anfrage.

Den schnellsten Überblick liefert das Backend: Öffnen Sie Werkzeuge > Website-Zustand. Überschreiten die automatisch geladenen Optionen den Grenzwert von 800.000 Byte, erscheint im Test ein kritischer Hinweis mit dem Titel „Automatisch geladene Optionen können die Leistung beeinflussen“ samt Anzahl und Größe. Im Labor zeigte WordPress nach dem Anlegen einer 900 KB großen Testoption „119 automatisch geladene Optionen (Größe: 909 KB)“.

Welche Option dafür verantwortlich ist, zeigt eine SQL-Abfrage. Wichtig ist die Liste der Werte: WordPress lädt seit Version 6.6 alle Optionen mit yes, on, auto-on und auto automatisch.

wp db query "SELECT option_name, LENGTH(option_value) AS bytes, autoload FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY bytes DESC LIMIT 15"
wp db query "SELECT COUNT(*) AS anzahl, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto')"

Warum nicht einfach wp option list --autoload=on? Im Test zählte dieser Befehl 101 Optionen, WordPress selbst lud aber 120. Die Differenz waren Optionen mit dem Wert auto, die WP-CLI 2.12.0 bei diesem Filter nicht mitzählt. Für eine schnelle Größenangabe taugt wp option list --autoload=on --format=total_bytes trotzdem, die SQL-Abfrage ist aber vollständig.

Der Optionsname beginnt meist mit dem Kürzel des Plugins. Optionen wie cron, wp_user_roles oder active_plugins gehören zu WordPress und bleiben unangetastet.

Verifizieren: Sie kennen die Gesamtgröße der automatisch geladenen Optionen und die fünf bis zehn größten Einträge mit ihrem zugehörigen Plugin.

Schritt 3: Große Optionen vom Autoload ausnehmen

Für eine große Option gibt es zwei Wege, und die Reihenfolge ist wichtig. Stammt sie von einem aktiven Plugin, stellen Sie nur den Autoload ab. Die Option bleibt erhalten, WordPress liest sie erst, wenn das Plugin sie anfordert. Stammt sie von einem Plugin, das längst deinstalliert ist, dürfen Sie sie löschen.

# Option behalten, aber nicht mehr bei jedem Aufruf laden
wp option set-autoload mein_plugin_cache off
wp option get-autoload mein_plugin_cache

# Nur bei Resten eines entfernten Plugins: Option löschen
wp option delete altes_plugin_einstellungen

Im Test meldete WP-CLI Success: Updated autoload value for 'mein_plugin_cache' option., danach zeigte der Website-Zustand „Die automatisch geladenen Optionen sind akzeptabel“.

Zum Hintergrund: Seit WordPress 6.6 erhalten neue Optionen ohne ausdrückliche Autoload-Angabe den Wert auto. Ist eine solche Option größer als 150.000 Byte, speichert WordPress sie als auto-off und lädt sie nicht automatisch. Das ließ sich im Labor nachvollziehen: Eine 200.000 Byte große Option ohne Angabe landete als auto-off. Plugins, die Autoload ausdrücklich einschalten, umgehen diese Grenze.

Ein Trade-off gehört dazu: Manche Plugins setzen den Autoload bei einem Update oder beim Speichern ihrer Einstellungen wieder auf on. Prüfen Sie nach Plugin-Updates erneut und melden Sie dauerhaft große Autoload-Optionen dem Plugin-Autor im Support-Forum auf wordpress.org.

Verifizieren: Die SQL-Summe aus Schritt 2 ist gesunken, und Werkzeuge > Website-Zustand zeigt keinen kritischen Hinweis zu automatisch geladenen Optionen mehr. Website und Einstellungsseite des Plugins funktionieren wie vorher.

Schritt 4: Abgelaufene Transients entfernen

Transients sind Zwischenspeicher mit Ablaufzeit, etwa für API-Antworten oder berechnete Listen. Ohne persistenten Objekt-Cache legt WordPress sie in wp_options ab, jeweils als _transient_NAME plus _transient_timeout_NAME. WordPress entfernt abgelaufene Transients selbst über das tägliche Cron-Ereignis delete_expired_transients. Dieses Ereignis wird geplant, sobald jemand das Backend aufruft. Läuft WP-Cron auf Ihrer Website unzuverlässig, bleiben Reste liegen.

wp transient type
wp transient list --fields=name,expiration
wp transient delete --expired

wp transient type zeigt, wo Transients liegen. Die Meldung Transients are saved to the database. bedeutet: Die Bereinigung betrifft Ihre Datenbank. Mit Redis oder Memcached als Objekt-Cache liegen Transients dort. Im Test entfernte wp transient delete --expired einen abgelaufenen Eintrag mit der Meldung Success: 1 expired transient deleted from the database., der noch gültige blieb erhalten.

wp transient delete --all löscht auch gültige Einträge. Plugins erzeugen sie neu, das kostet aber Rechenzeit und zusätzliche Anfragen an externe Dienste. Für die Pflege genügt --expired.

Prüfen Sie außerdem, ob das Cron-Ereignis geplant ist:

wp cron event list --fields=hook,recurrence | grep delete_expired_transients

Verifizieren: wp transient list zeigt keine Einträge mit einer Ablaufzeit in der Vergangenheit mehr, und das Ereignis delete_expired_transients erscheint mit der Wiederholung „1 day“.

Schritt 5: Revisionen, Papierkorb und Spam bereinigen

WordPress speichert standardmäßig jede Version eines Beitrags als Revision, ohne Obergrenze. Das ist nützlich, weil Sie im Editor ältere Fassungen vergleichen und zurückholen können. Bei langjährig gepflegten Seiten entstehen so aber Hunderte Einträge pro Seite. Klären Sie vorher, ob alte Fassungen noch als Nachweis gebraucht werden, etwa bei Rechtstexten.

wp post list --post_type=revision --fields=ID,post_parent,post_date
wp post delete $(wp post list --post_type=revision --format=ids) --force

Die Option --force ist nötig. Ohne sie bricht WP-CLI ab mit: Warning: Posts of type 'revision' do not support being sent to trash. Please use the --force flag to skip trash and delete them permanently. Beim Löschen über wp post delete entfernt WordPress auch die zugehörigen Metadaten. Im Test blieben danach keine verwaisten Einträge in wp_postmeta zurück. Direkte SQL-Befehle wie DELETE FROM wp_posts WHERE post_type='revision' sollten Sie deshalb meiden.

Papierkorb und Spam leeren Sie auf dieselbe Weise. WordPress löscht Inhalte im Papierkorb ohnehin nach 30 Tagen (Konstante EMPTY_TRASH_DAYS).

wp post delete $(wp post list --post_status=trash --format=ids) --force
wp comment delete $(wp comment list --status=spam --format=ids) --force

Ist die Liste leer, gibt WP-CLI nur die Kurzhilfe usage: wp post delete <id>... [--force] [--defer-term-counting] aus, weil keine ID übergeben wurde. Dann gibt es nichts zu löschen.

Verifizieren: wp post list --post_type=revision --format=count gibt 0 aus, wp comment list --status=spam --format=count ebenfalls. Öffnen Sie zwei, drei Beiträge im Editor und prüfen Sie, ob der Inhalt vollständig ist.

Schritt 6: Revisionen begrenzen und Tabellen optimieren

Damit die Datenbank nicht wieder anwächst, begrenzen Sie die Revisionen je Beitrag in der wp-config.php. Fünf Fassungen reichen für die meisten Redaktionen, um einen Fehler zurückzunehmen.

wp config set WP_POST_REVISIONS 5 --raw

Das schreibt die Zeile define( 'WP_POST_REVISIONS', 5 ); in die Konfiguration. Ohne WP-CLI tragen Sie sie per SFTP vor der Zeile „That's all, stop editing!“ ein. Der Wert false schaltet Revisionen ganz ab, davon raten wir ab, weil dann versehentliche Änderungen nicht mehr rückgängig zu machen sind. Die Grenze greift beim nächsten Speichern eines Beitrags: Im Test hatte ein Beitrag sechs Revisionen, nach der nächsten Aktualisierung waren es fünf.

Zum Schluss geben Sie den freien Platz in den Tabellen frei:

wp db optimize

Bei InnoDB-Tabellen, dem Standard aktueller MySQL- und MariaDB-Versionen, meldet der Befehl Table does not support optimize, doing recreate + analyze instead. Die Tabelle wird neu aufgebaut, am Ende steht Success: Database optimized. Bei großen Tabellen dauert das und belegt kurzzeitig zusätzlichen Speicherplatz.

Eine Datenbankbereinigung ist keine einmalige Aktion. Plugins legen neue Optionen an, und Updates können den Autoload ändern. Planen Sie die Prüfung aus Schritt 2 und die Befehle aus Schritt 4 und 5 als festen Punkt, etwa monatlich, zusammen mit Updates und Backups ein. Einen Rahmen dafür bietet der WordPress-Wartungsplan. Wer Updates und Sicherungen nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und legt wöchentlich ein Backup auf externem Speicher ab, das vier Wochen aufbewahrt wird.

Verifizieren: wp config get WP_POST_REVISIONS gibt 5 aus, wp db optimize endet mit Success: Database optimized., und wp db size --size_format=kb liegt unter dem Wert aus Schritt 1.

Typische Fehler

• Warning: Posts of type 'revision' do not support being sent to trash. Revisionen haben keinen Papierkorb. Ergänzen Sie --force.
• Warning: Could not delete 'NAME' option. Does it exist? Der Name ist falsch geschrieben oder die Option wurde schon entfernt. Prüfen Sie mit wp option list --search="teil*".
• Autoload-Summe weicht zwischen WP-CLI und Website-Zustand ab. wp option list --autoload=on zählt keine Optionen mit auto. Verwenden Sie die SQL-Abfrage aus Schritt 2.
• Autoload ist nach einem Update wieder on. Das Plugin setzt den Wert selbst. Wiederholen Sie Schritt 3 und melden Sie das Verhalten dem Plugin-Autor.
• ERROR 1146 (42S02) ... Table '...' doesn't exist Ihre Installation verwendet ein anderes Präfix als wp_. Passen Sie die Tabellennamen an die Ausgabe von wp db prefix an.
• Nach dem Löschen einer Option fehlen Einstellungen. Die Option gehörte zu einem aktiven Plugin. Spielen Sie die Sicherung aus Schritt 1 zurück oder speichern Sie die Plugin-Einstellungen neu.

Häufige Fragen

Geht das auch mit einem Plugin?

Optimierungs-Plugins fassen ähnliche Schritte in einer Oberfläche zusammen und sind ohne SSH eine Alternative. Mit WP-CLI sehen Sie genau, was gelöscht wird, und installieren kein zusätzliches Plugin. Ein Backup brauchen Sie in beiden Fällen.

Wird die Website durch das Aufräumen schneller?

Spürbar meist nur, wenn die automatisch geladenen Optionen zu groß waren. Das Löschen von Revisionen verkleinert vor allem Backups und beschleunigt Exporte, auf die Ladezeit einzelner Seiten wirkt es kaum. Messen Sie vorher und nachher, statt einen Effekt anzunehmen.

Wie oft sollte die Bereinigung laufen?

Für die meisten Firmenwebsites genügt eine monatliche Kontrolle von Autoload und Transients.

Testumfang

Wir haben die Schritte in einer Testumgebung mit WordPress 7.1.2 durchgespielt, vom Export über die Autoload-Prüfung bis zum Aufräumen von Revisionen und Transients. Auffällig war, dass WordPress eine 900 KB große Testoption im Website-Zustand meldete und automatisch als auto-off einstufte. Nicht geprüft haben wir Umgebungen mit WooCommerce, Multisite, Redis oder Optimierungs-Plugins. Nutzen Sie so etwas, sollten Sie die Schritte zuerst auf einer Kopie testen.

Fazit

Den größten Effekt hat die Kontrolle der automatisch geladenen Optionen, denn sie wirkt auf jeden Seitenaufruf. Revisionen, Transients und Spam räumen Sie mit wenigen WP-CLI-Befehlen auf, WP_POST_REVISIONS hält die Datenbank danach klein. Voraussetzung für jeden Schritt ist eine frische Sicherung. Soll jemand anderes Updates und Backups regelmäßig übernehmen, ist die betreute WordPress-Wartung eine Möglichkeit.

Weiterführende Anleitungen und Quellen

• WordPress-Datenbank mit WP-CLI sichern und wiederherstellen
• WordPress vor Änderungen sichern
• WordPress-Wartungsplan: wöchentlich, monatlich, jährlich
• Make WordPress Core: Options API, disabling autoload for large options
• WP-CLI: wp option set-autoload
• WP-CLI: wp transient delete
• WordPress Developer: Transients API
• WordPress Developer: wp-config.php (WP_POST_REVISIONS, EMPTY_TRASH_DAYS)
• WP-CLI: wp db optimize