---
title: "Autoload-Optionen in WordPress analysieren und verkleinern"
date: 2026-09-30T21:51:25+02:00
modified: 2026-11-09T13:20:38+01:00
category: wordpress
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/wordpress-autoload-optionen-analysieren-verkleinern
keywords:
  - WordPress
  - Datenbank
  - Performance
  - WP-CLI
  - wp_options
reading_time: 9
---

# Autoload-Optionen in WordPress analysieren und verkleinern

WordPress lädt bei jedem Seitenaufruf mit einer einzigen Datenbankabfrage alle Optionen, die als „automatisch laden“ markiert sind, und hält sie im Arbeitsspeicher. Das ist sinnvoll für Einstellungen, die fast jede Seite braucht. Problematisch wird es, wenn Plugins große Datenmengen dort ablegen oder nach dem Löschen Reste hinterlassen: Dann schleppt jede Anfrage Hunderte Kilobyte unnötiger Daten mit, auch im Adminbereich und bei Cronjobs. Diese Anleitung zeigt, wie Sie die automatisch geladenen Optionen mit Bordmitteln messen, die großen Brocken finden, gezielt umstellen oder entfernen und das Ergebnis im Website-Zustand kontrollieren, ohne dabei Einstellungen aktiver Plugins zu beschädigen.

**Kurzfassung:** Zuerst die Datenbank sichern. Dann unter „Werkzeuge > Website-Zustand“ und mit `wp option list --autoload=on --format=total_bytes` die Gesamtgröße messen. Die größten Einträge per SQL-Abfrage auflisten und jedem Eintrag ein Plugin zuordnen. Reste gelöschter Plugins entfernen Sie mit `wp option delete`, große, selten gebrauchte Optionen aktiver Plugins stellen Sie mit `wp option set-autoload NAME off` um. WordPress meldet ein Problem ab 800.000 Byte automatisch geladener Daten.

## Voraussetzungen

- [ ] **WordPress:** ab Version 6.6, denn seitdem kennt WordPress die Autoload-Werte `on`, `off`, `auto`, `auto-on` und `auto-off`. Geprüft mit WordPress 7.1.2. Im beschriebenen Beispiel läuft das Update auf WordPress 7.1.3 ohne Fehler und ohne Datenbank-Update. `wp option get-autoload` und `wp option set-autoload` arbeiten danach wie beschrieben.
- [ ] **PHP:** eine von WordPress unterstützte Version, im Test PHP 8.4.
- [ ] **Zugriff:** Benutzer mit der Rolle Administrator im Backend sowie SSH mit WP-CLI (im Test 2.12.0). Ohne SSH funktionieren die SQL-Abfragen auch in phpMyAdmin oder Adminer, die Ihr Hoster bereitstellt.
- [ ] **Backup:** eine aktuelle Sicherung der Datenbank, die Sie nachweislich zurückspielen können. Sie ändern direkt die Tabelle `wp_options`, in der alle Einstellungen der Website liegen.
- [ ] **Zeit:** etwa 30 bis 60 Minuten, abhängig von der Zahl der Plugins.

Der Tabellenpräfix `wp_` in den Beispielen ist der Standard. Steht in Ihrer `wp-config.php` ein anderer `$table_prefix`, passen Sie die SQL-Befehle entsprechend an.

## Schritt 1: Datenbank sichern

Jede Änderung in diesem Artikel lässt sich nur über ein Backup rückgängig machen. Löschen Sie versehentlich die Einstellungen eines aktiven Plugins, sind Lizenzschlüssel, Formulare oder Weiterleitungen weg. Exportieren Sie deshalb vorher die Datenbank und legen Sie die Datei außerhalb des Webverzeichnisses ab:

```bash
$ wp db export ~/backup-vor-autoload-$(date +%F).sql
```

Ausführlich, einschließlich Rücksicherung, beschreibt das die Anleitung [WordPress-Datenbank mit WP-CLI sichern und wiederherstellen](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen). Arbeiten Sie bei einem Shop oder einer umfangreichen Website am besten zuerst auf einer Staging-Kopie.

> **Prüfen:** `wp db export` meldet „Success: Exported to …“, und die Datei ist größer als wenige Kilobyte.

## Schritt 2: Umfang messen

Den schnellsten Überblick gibt WordPress selbst. Öffnen Sie **Werkzeuge > Website-Zustand**. Solange die Summe unter der Grenze liegt, finden Sie unter den bestandenen Tests den Eintrag „Die automatisch geladenen Optionen sind akzeptabel“ mit Anzahl und Größe. Überschreitet die Summe den Grenzwert, erscheint oben die Meldung „Automatisch geladene Optionen können die Leistung beeinflussen“. Der Grenzwert liegt laut Quelltext von WordPress 7.1 bei 800.000 Byte und lässt sich über den Filter `site_status_autoloaded_options_size_limit` ändern.

Genauer messen Sie mit WP-CLI:

```bash
$ wp option list --autoload=on --format=count
$ wp option list --autoload=on --format=total_bytes
```

Beachten Sie eine Eigenheit: `--autoload=on` erfasst im Test nur Einträge mit dem Wert `on`. WordPress lädt aber auch Optionen mit `yes`, `auto-on` und `auto` automatisch; das legt die Funktion `wp_autoload_values_to_autoload()` fest. In der frischen Testinstallation zählte WP-CLI 100 Optionen mit 28.732 Byte, der Website-Zustand dagegen 117 Optionen. Die vollständige Summe liefert diese Abfrage:

```sql
SELECT COUNT(*) AS anzahl, SUM(LENGTH(option_value)) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
```

```bash
$ wp db query "SELECT COUNT(*), SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto')"
```

Als Orientierung: Eine frische Installation liegt bei rund 30 KB. Websites mit vielen Plugins erreichen oft mehrere Hundert Kilobyte. Ein einzelner Eintrag mit mehreren Hundert Kilobyte ist fast immer ein Fall für eine genauere Prüfung.

> **Prüfen:** Sie haben Anzahl und Gesamtgröße notiert, damit Sie am Ende vergleichen können.

## Schritt 3: Die größten Einträge finden

Größe ist wichtiger als Anzahl. Hundert kleine Einstellungen kosten weniger als ein einzelner Eintrag, in dem ein Plugin ein Protokoll oder einen Cache ablegt. Listen Sie die größten automatisch geladenen Optionen auf:

```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 20"
```

Die Ausgabe der Testinstanz, nachdem wir zur Simulation eine 900 KB große Option eines fiktiven Plugins angelegt hatten, auszugsweise:

```plaintext
option_name	bytes	autoload
altes_plugin_cache	900000	on
_transient_wp_core_block_css_files	23778	on
wp_user_roles	3133	on
cron	1392	on
```

Mit dieser einen Option sprang der Website-Zustand auf „Automatisch geladene Optionen können die Leistung beeinflussen“ bei 118 Optionen und 908 KB. Schauen Sie sich bei auffälligen Einträgen den Inhalt an, um die Herkunft zu erkennen:

```bash
$ wp option get NAME_DER_OPTION --format=json | head -c 500
```

> **Prüfen:** Für jeden der größten Einträge wissen Sie, ob er zu WordPress selbst, zu einem aktiven Plugin, zum Theme oder zu einem nicht mehr installierten Plugin gehört.

## Schritt 4: Einträge zuordnen und bewerten

Der Optionsname verrät meist das Plugin, etwa über ein Kürzel am Anfang. Gleichen Sie ihn mit der Liste der installierten Plugins ab:

```bash
$ wp plugin list --fields=name,status
$ wp theme list --fields=name,status
```

Ordnen Sie danach jeden großen Eintrag einer von vier Gruppen zu:

| Gruppe | Beispiel | Vorgehen |
| --- | --- | --- |
| WordPress-Kern | `wp_user_roles`, `cron`, `active_plugins`, `siteurl` | Nicht anfassen |
| Aktives Plugin, täglich gebraucht | Grundeinstellungen eines Formular- oder SEO-Plugins | Belassen |
| Aktives Plugin, selten gebraucht | Große Statistik-, Protokoll- oder Importdaten | Autoload abschalten (Schritt 5) |
| Rest eines gelöschten Plugins | Kürzel passt zu keinem installierten Plugin | Löschen (Schritt 6) |

Einträge, die mit `_transient_` oder `_site_transient_` beginnen, sind zwischengespeicherte Daten mit Ablaufzeit. WordPress und Plugins erzeugen sie bei Bedarf neu. Abgelaufene Transients entfernen Sie gefahrlos mit `wp transient delete --expired`. Bleibt die Zuordnung unklar, lassen Sie den Eintrag unverändert. Ein nicht optimierter Eintrag kostet etwas Leistung, eine falsch gelöschte Einstellung kann eine Funktion der Website abschalten.

> **Prüfen:** Jeder Eintrag, den Sie ändern wollen, hat eine eindeutige Zuordnung und eine der vier Kategorien.

## Schritt 5: Autoload für selten gebrauchte Optionen abschalten

Abschalten ist die vorsichtige Variante: Die Option bleibt erhalten, WordPress lädt sie aber nur noch, wenn ein Plugin sie tatsächlich mit `get_option()` anfordert. Das kostet dann eine zusätzliche Datenbankabfrage an genau dieser Stelle, spart aber auf allen anderen Seiten den Speicher.

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

Im Test meldete WP-CLI „Success: Updated autoload value for 'altes_plugin_cache' option.“, danach lieferte `get-autoload` den Wert `off`. Verwenden Sie `off` statt des älteren `no`: WP-CLI akzeptiert beide Werte, schreibt `no` im Test aber unverändert in die Tabelle. Für eigene Plugins oder Code-Snippets bietet WordPress die Funktion `wp_set_option_autoload_values()`, mit der Sie mehrere Optionen auf einmal umstellen.

Ein Plugin kann den Wert beim nächsten Speichern seiner Einstellungen wieder auf „automatisch laden“ setzen. Kontrollieren Sie die Liste deshalb nach Plugin-Updates erneut. Seit WordPress 6.6 legt WordPress neue Optionen über 150.000 Byte übrigens selbst mit `auto-off` an, wenn das Plugin keinen Wert vorgibt. Im Test ergab eine neue Option mit 200.000 Byte genau diesen Wert. Der Grenzwert stammt aus dem Filter `wp_max_autoloaded_option_size`.

> **Prüfen:** `wp option get-autoload NAME` zeigt `off`, die betroffene Plugin-Funktion arbeitet weiterhin, und die Summe aus Schritt 2 ist kleiner.

## Schritt 6: Reste gelöschter Plugins entfernen

Viele Plugins entfernen ihre Optionen beim Deinstallieren nicht. Solche Reste werden weiter bei jedem Aufruf geladen, obwohl kein Code sie mehr liest. Prüfen Sie vor dem Löschen noch einmal: Plugin wirklich nicht installiert, auch nicht deaktiviert? Kein anderes Plugin desselben Herstellers nutzt das Kürzel?

```bash
$ wp option list --search="kuerzel_*" --fields=option_name,autoload
$ wp option delete kuerzel_einstellungen
```

WP-CLI bestätigt mit „Success: Deleted 'kuerzel_einstellungen' option.“ Existiert der Name nicht, meldet es zum Beispiel „Error: Could not get 'gibtsnicht' option. Does it exist?“. Planen Sie ein Plugin später wieder einzusetzen, schalten Sie statt zu löschen nur den Autoload ab. Wie Sie ungenutzte Plugins generell erkennen, beschreibt die Anleitung [veraltete und aufgegebene Plugins erkennen und ersetzen](https://s-edv.com/anleitungen/wordpress-veraltete-aufgegebene-plugins-erkennen-ersetzen).

> **Prüfen:** `wp option get kuerzel_einstellungen` liefert einen Fehler, und die Website funktioniert im Frontend und Backend wie zuvor.

## Schritt 7: Ergebnis kontrollieren und regelmäßig wiederholen

Messen Sie erneut mit der SQL-Abfrage aus Schritt 2 und öffnen Sie **Werkzeuge > Website-Zustand**. In unserem Test verschwand die Warnung, nachdem die große Option auf `off` stand; die Summe lag wieder bei rund 29 KB. Rufen Sie danach die wichtigsten Seiten auf: Startseite, Kontaktformular, Shop-Kasse, Anmeldung. Leeren Sie vorher Seiten- und Objekt-Cache, sonst sehen Sie alte Zustände.

Setzen Sie einen persistenten Objekt-Cache ein, etwa mit Redis, liegt der Block der automatisch geladenen Optionen dort. Die Menge wirkt sich dann weniger auf die Datenbank aus, belegt aber weiterhin Speicher in Redis und in PHP. Mehr dazu in der Anleitung [Redis als Objekt-Cache für WordPress](https://s-edv.com/anleitungen/wordpress-redis-object-cache-einrichten).

Die Tabelle wächst mit jedem neuen Plugin und jedem Update wieder. Planen Sie die Kontrolle deshalb als festen Punkt der Wartung ein, zum Beispiel vierteljährlich oder nach größeren Umbauten. Wer die laufende Pflege nicht selbst im Kalender halten möchte, kann sie abgeben: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=60) übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung sowie wöchentliche Backups auf externen Speicher.

> **Prüfen:** Der Website-Zustand zeigt „Die automatisch geladenen Optionen sind akzeptabel“, und alle geprüften Seiten funktionieren.

## Typische Fehler

| Beobachtung | Ursache | Lösung |
| --- | --- | --- |
| WP-CLI zählt weniger Optionen als der Website-Zustand | `--autoload=on` erfasst nur den Wert `on` | SQL-Abfrage mit allen vier Werten nutzen |
| `Error: Parameter errors: Invalid value specified for 'orderby'` | `wp option list` sortiert nur nach `option_id`, `option_name` oder `option_value`, nicht nach Größe | Sortierung per SQL mit `ORDER BY LENGTH(option_value)` |
| `Error: Could not get '…' option. Does it exist?` | Tippfehler oder anderer Tabellenpräfix | Namen per `wp option list --search` prüfen |
| Plugin verliert Einstellungen | Option eines aktiven Plugins gelöscht | Tabelle `wp_options` aus dem Backup zurückspielen |
| Option ist nach Tagen wieder automatisch geladen | Plugin speichert mit festem Autoload-Wert | Plugin-Einstellungen oder Support prüfen, erneut umstellen |

## Häufige Fragen

### Gibt es ein Plugin dafür?

Ja, mehrere Plugins zeigen automatisch geladene Optionen an. Für eine einmalige Analyse genügen jedoch Website-Zustand, WP-CLI oder phpMyAdmin. Jedes zusätzliche Plugin muss selbst wieder gepflegt werden.

### Wie groß ist zu groß?

WordPress warnt ab 800.000 Byte. Das ist eine Obergrenze, kein Zielwert. Einzelne Einträge über 150.000 Byte legt WordPress seit Version 6.6 ohne ausdrücklichen Wert gar nicht mehr als automatisch geladen an; das ist ein guter Anhaltspunkt für die Prüfung einzelner Optionen.

### Kann ich einfach alle Optionen auf „off“ setzen?

Nein. Dann holt WordPress jede Einstellung einzeln aus der Datenbank, was deutlich mehr Abfragen erzeugt und die Website verlangsamt. Kern-Optionen wie `siteurl` oder `active_plugins` gehören immer in den automatisch geladenen Block.

### Was bedeuten „auto-on“ und „auto-off“?

Diese Werte setzt WordPress, wenn ein Plugin keinen ausdrücklichen Wert vorgibt und WordPress selbst entscheidet. `auto-off` steht für große Optionen, die nicht geladen werden. `on` und `off` sind ausdrückliche Vorgaben.

## Fazit

Die automatisch geladenen Optionen sind schnell gemessen und meist mit wenigen Befehlen bereinigt. Entscheidend ist die Reihenfolge: sichern, messen, jedem großen Eintrag eine Herkunft zuordnen, im Zweifel nur den Autoload abschalten statt zu löschen, dann kontrollieren. Die Aufgabe kehrt mit jedem neuen Plugin wieder; wer die regelmäßige Pflege abgeben möchte, findet sie in der [WordPress-Wartung](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=60) von Marcel Schönfelder.

## Weiterführende Anleitungen und Quellen

- [WordPress-Datenbank mit WP-CLI sichern und wiederherstellen](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen)
- [Redis als Objekt-Cache für WordPress einrichten](https://s-edv.com/anleitungen/wordpress-redis-object-cache-einrichten)
- [Veraltete und aufgegebene Plugins erkennen und ersetzen](https://s-edv.com/anleitungen/wordpress-veraltete-aufgegebene-plugins-erkennen-ersetzen)
- [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/) und [wp option list](https://developer.wordpress.org/cli/commands/option/list/)
- [wp_set_option_autoload_values()](https://developer.wordpress.org/reference/functions/wp_set_option_autoload_values/) und [site_status_autoloaded_options_size_limit](https://developer.wordpress.org/reference/hooks/site_status_autoloaded_options_size_limit/)