---
title: "WordPress-Datenbank aufräumen: Revisionen, Transients und Autoload-Optionen"
date: 2026-09-30T21:49:25+02:00
modified: 2026-10-14T15:26:31+02:00
category: wordpress
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/wordpress-datenbank-aufraeumen-revisionen-transients-autoload
keywords:
  - WordPress
  - Datenbank
  - WP-CLI
  - Performance
  - Wartung
reading_time: 10
---

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

Eine WordPress-Datenbank wächst mit jedem gespeicherten Entwurf, jedem Plugin und jedem Spam-Kommentar. 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.

**Kurzfassung:** Sichern Sie die Datenbank vor jedem Eingriff mit `wp db export`. Messen Sie zuerst Größe und Autoload-Volumen, denn Autoload ist der Wert mit dem größten Einfluss auf die Ladezeit. Große Optionen stellen Sie mit `wp option set-autoload NAME off` um, statt sie zu löschen. Abgelaufene Transients entfernen Sie mit `wp transient delete --expired`, alte Revisionen mit `wp post delete ... --force`. Die Konstante `WP_POST_REVISIONS` in der `wp-config.php` begrenzt die Revisionen dauerhaft.

## 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 PHP 8.3 oder neuer, PHP 7.4 ist nur noch die Mindestversion. 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

Legen Sie 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](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen).

```bash
$ 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:

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

> **Prüfen:** 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.

```bash
$ 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.

> **Prüfen:** 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.

```bash
# Option behalten, aber nicht mehr bei jedem Aufruf laden
```

```bash
$ wp option set-autoload mein_plugin_cache off
$ wp option get-autoload mein_plugin_cache
```

```bash
# Nur bei Resten eines entfernten Plugins: Option löschen
```

```bash
$ 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.

> **Prüfen:** 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.

```bash
$ 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:

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

> **Prüfen:** `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.

```bash
$ 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`).

```bash
$ 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.

> **Prüfen:** `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.

```bash
$ 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. 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:

```bash
$ 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.

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 monatlich zusammen mit Updates und Backups ein. Einen Rahmen dafür bietet der [WordPress-Wartungsplan](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich). Wer Updates und Sicherungen abgeben möchte: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=53) 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.

> **Prüfen:** `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.

## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=53) eine Möglichkeit.

## Weiterführende Anleitungen und Quellen

- [WordPress-Datenbank mit WP-CLI sichern und wiederherstellen](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen)
- [WordPress vor Änderungen sichern](https://s-edv.com/anleitungen/wordpress-vor-aenderungen-sichern-snapshot-eigenes-backup)
- [WordPress-Wartungsplan: wöchentlich, monatlich, jährlich](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich)
- [Make WordPress Core: Options API, disabling autoload for large options](https://make.wordpress.org/core/2024/06/18/options-api-disabling-autoload-for-large-options/)
- [WP-CLI: wp option set-autoload](https://developer.wordpress.org/cli/commands/option/set-autoload/)
- [WP-CLI: wp transient delete](https://developer.wordpress.org/cli/commands/transient/delete/)
- [WordPress Developer: Transients API](https://developer.wordpress.org/apis/transients/)
- [WordPress Developer: wp-config.php (WP_POST_REVISIONS, EMPTY_TRASH_DAYS)](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/)
- [WP-CLI: wp db optimize](https://developer.wordpress.org/cli/commands/db/optimize/)