wp_options-Tabelle – Autoloaded Optionen bereinigen

wp_options-Tabelle – Autoloaded Optionen bereinigen

Was ist das wp_options-Verzeichnis?

Das wp_options-Verzeichnis enthält alle Arten von Daten für deine WordPress-Seite, wie zum Beispiel:

-Site – URL, Home – URL, Admin – E – Mail, Standardkategorie, Beiträge pro Seite, Zeitformat usw.
-Einstellungen für Plugins, Themes, Widgets
-Vorübergehend zwischengespeicherte Daten

wp_options-Verzeichnis
wp_options-Verzeichnis

Das Verzeichnis enthält die folgenden Felder, von denen eines mehr Wert auf Leistung legt:

option_id
option_name
option_value
autoload

Die wp_options‑Tabelle ist ein kritischer Performance‑Faktor in WordPress, weil alle Einträge mit autoload = ‚yes‘ bei jedem Seitenaufruf in den Speicher geladen werden. Wenn sich dort alte Plugin‑Reste und unnötig große Datenstrukturen ansammeln, wird deine Seite spürbar langsamer.

Grundlagen: wp_options und autoload verstehen

In der Tabelle wp_options liegen globale Einstellungen von WordPress, Themes und Plugins; relevant sind vor allem die Spalten option_name, option_value und autoload. Der autoload‑Wert entscheidet, ob diese Option bei jedem Aufruf geladen wird („yes“) oder nur bei Bedarf („no“), weshalb große Autoload‑Daten ein unmittelbares Performance‑Risiko sind.

Als erstes kannst du die aktuelle automatisch geladene Größe auf deiner WordPress-Seite prüfen. In deinem phpMyAdmin klicke links auf deine Database und dann auf die Registerkarte SQL. Gib dann den folgenden Befehl ein und drücke „Go“.

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Eventuell musst du die Abfrage oben optimieren, wenn deine WordPress-Seite ein anderes Präfix als wp_ verwendet.

Du kannst auch eine längere Abfrage wie die folgende verwenden. Daraufhin werden die automatisch geladenen Daten, die Anzahl der Einträge in dem Verzeichnis und die ersten 10 Einträge nach Größe angezeigt.

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

Die autoload_size wird in Bytes angegeben. Ein KB besteht aus 1024 Byte, ein MB aus 1024 KB. In unserem Beispiel entsprechen 939.774 Bytes ungefähr 0,91 MB, was für diese Seite ein unkritischer Wert ist. Liegt der Wert unter 1 MB, besteht in der Regel kein Handlungsbedarf. Fällt das Ergebnis jedoch deutlich höher aus, solltest du mit den nächsten Schritten aus diesem Tutorial weitermachen.

Ein typischer Einstieg ist eine Übersicht über die Größe der automatisch geladenen Daten. In phpMyAdmin oder einem anderen MySQL‑Client kannst du z. B. folgende Abfrage nutzen, um Gesamtgröße und Anzahl zu sehen und die größten Brocken zu identifizieren:

SELECT 'autoload_size_kb' AS label,
       ROUND(SUM(LENGTH(option_value))/1024) AS value
FROM wp_options
WHERE autoload = 'yes'
UNION ALL
SELECT 'autoload_count',
       COUNT(*)
FROM wp_options
WHERE autoload = 'yes'
UNION ALL
SELECT option_name,
       LENGTH(option_value) AS value
FROM wp_options
WHERE autoload = 'yes'
ORDER BY value DESC
LIMIT 10;

Als grobe Faustregel gelten 300–1000 KB autoload‑Daten als gesund; mehrere Megabyte deuten meist auf Bereinigungsbedarf hin.

Typische Ursachen für aufgeblähte Autoloads

Große Autoload‑Blöcke entstehen vor allem durch Plugins, die viele Konfigurationsdaten oder Logs in wp_options schreiben und dabei autoload auf „yes“ setzen. Häufig bleiben deren Einträge auch nach Deinstallation in der Datenbank, weil das Plugin beim Entfernen nicht sauber aufräumt oder WP‑Cron‑Jobs fehlschlagen.

Problematisch sind insbesondere serialisierte Arrays mit vielen Einträgen (z. B. Cache‑Daten, Logs, Tracking‑Infos) oder alte Transients, die nie gelöscht wurden. Diese Einträge werden zwar nicht mehr benötigt, aber trotzdem bei jedem Seitenaufruf geladen und verlangsamen so MySQL‑Abfragen und PHP‑Ausführung.

Eine gute Praxis ist, kritische option_name‑Werte, die in der „Top 10“ der größten Autoload‑Einträge auftauchen, gezielt zu analysieren. Du kannst in phpMyAdmin auf „Bearbeiten“ klicken und dir den Inhalt ansehen – oft lässt sich schon am Namensschema erkennen, welches Plugin verantwortlich ist (z. B. Präfixe wie transient, plugin_xyz_, rankmath_, wpseo_ usw.).

Manuelle Analyse und Bereinigung per SQL

Wenn du dich mit SQL wohlfühlst, kannst du gezielt nach großen Autoload‑Optionen suchen und verdächtige Einträge markieren. Eine einfache Liste aller automatisch geladenen Optionen nach Größe sortiert sieht beispielsweise so aus:

SELECT option_id,
       option_name,
       LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 100;

Bevor du etwas änderst oder löschst, solltest du zwingend ein vollständiges Datenbank‑Backup erstellen und idealerweise in einer Staging‑Umgebung testen. Für Einträge, bei denen du sicher bist, dass sie nur Caches, abgelaufene Transients oder alte Plugin‑Daten enthalten, gibt es zwei relativ sichere Schritte:

1. Autoload erst auf „no“ setzen und beobachten, ob etwas bricht:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'DEIN_OPTION_NAME';

2. Wenn nach einigen Tagen alles stabil läuft, den Eintrag löschen:

DELETE FROM wp_options
WHERE option_name = 'DEIN_OPTION_NAME';

Für Transients, die ohnehin ablaufen sollten, kannst du auch ganze Gruppen mit Wildcards entfernen, etwa:

DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

Solche Massenbefehle solltest du nur verwenden, wenn du weißt, dass dein Cache‑/Transient‑System damit umgehen kann, da danach viele Daten neu aufgebaut werden müssen.

WP‑CLI‑Beispiele für wiederkehrende Aufräumarbeiten

Für regelmäßige Bereinigung eignet sich WP‑CLI, weil du damit Listen, Filter und Löschbefehle skripten kannst. Ein Beispiel für eine Übersicht der größten Autoload‑Optionen:

bashwp option list \
  --autoload=on \
  --fields=option_name,autoload,size \
  --format=json \
  --orderby=size \
  --order=desc \
  --field=option_name \
  --page=1 --per-page=20

Um gezielt eine Option zu löschen, kannst du WP‑CLI so nutzen:

bashwp option delete DEIN_OPTION_NAME

Oder du setzt autoload via WP‑CLI auf „no“, ohne direkt zu löschen:

bashwp db query "UPDATE wp_options SET autoload='no' WHERE option_name='DEIN_OPTION_NAME';"

Solche Befehle lassen sich in ein Cron‑Script oder ein kleines Wartungsskript packen, das z. B. einmal im Monat abläuft, nachdem ein Backup erstellt wurde.

Einsatz von Plugins zur automatischen Bereinigung

Wer nicht direkt in der Datenbank arbeiten möchte, kann spezielle Optimierungs‑Plugins nutzen. Tools wie Advanced Database Cleaner, WP‑Optimize oder entsprechende Funktionen in Performance‑Plugins analysieren die wp_options‑Tabelle und bieten Oberflächen zum Entfernen alter Transients, Revisionen und bestimmter Optionen.

Diese Plugins können automatisierte Routinen anlegen, z. B. die regelmäßige Bereinigung abgelaufener Transients oder das Entfernen von verwaisten Plugin‑Einträgen. Allerdings erkennen sie nicht immer alle problematischen Optionen; bei komplexen oder geschäftskritischen Systemen bleibt eine manuelle Prüfung der größten Autoload‑Einträge empfehlenswert.

Visuelle Unterstützung: Diagramme und Screenshots

Um die Situation besser zu kommunizieren, lohnt sich eine einfache Visualisierung. Ein Balkendiagramm, das die Top‑10‑Autoload‑Optionen nach Größe zeigt, macht Stakeholdern klar, warum bestimmte Plugins oder Optionen problematisch sind. Solch ein Diagramm lässt sich aus den SQL‑Ergebnissen (option_name vs. size_bytes) in einem BI‑Tool oder selbstgebauten Dashboard generieren.

Ebenso hilfreich sind Screenshots aus phpMyAdmin oder Adminer, die die wp_options‑Ansicht mit Filter WHERE autoload = 'yes' und sortierten Größen zeigen. Markierte Zeilen (z. B. mit farblichen Kommentaren in Dokumentation oder Präsentation) erleichtern die spätere Zuordnung zu konkreten Plugins und Maßnahmen.

Best Practices und Sicherheitsnetz

Unabhängig von der Methode gelten einige Grundregeln: Vor jeder Bereinigung ein vollständiges Backup erstellen, idealerweise in einer Staging‑Umgebung testen und bei produktiven Systemen ein Wartungsfenster einplanen. Zudem sollte nach größeren Löschaktionen ein Monitoring der Performance, Fehlerlogs und wichtigen Funktionen (Login, Shop, Kontaktformulare) erfolgen, um eventuell fehlende Optionen schnell zu erkennen.

Langfristig lohnt es sich, auf Plugin‑Ebene aufzuräumen: ungenutzte Plugins und Themes wirklich deinstallieren, nicht nur deaktivieren, und bei der Auswahl neuer Erweiterungen darauf achten, wie diese mit wp_options umgehen. Gerade bei Page‑Buildern, SEO‑Tools, Security‑Plugins und komplexen Integrationen lohnt ein Blick in die Dokumentation, ob große Datenmengen im Autoload‑Bereich landen – und ob es Einstellungen gibt, die das reduzieren.

Mit einem solchen Mix aus Analyse, gezielten SQL‑/WP‑CLI‑Aktionen, unterstützenden Plugins und klaren Prozessen lässt sich die wp_options‑Tabelle schlank halten oder wieder in einen gesunden Zustand bringen. Das Ergebnis sind schnellere Datenbankabfragen, weniger Speicherverbrauch und insgesamt spürbar bessere Performance deiner WordPress‑Installation.

Wie identifiziere ich pluginreste in wp_options automatisch geladenen Daten bei WPML und WooCommerce Integration

Automatisch geladene Pluginreste in wp_options lassen sich gut über eine Kombination aus SQL/WP‑CLI, Namensmustern und etwas WPML/WooCommerce‑Know‑how erkennen.

Grundprinzip: autoload‑Optionen analysieren

Der erste Schritt ist immer, die größten automatisch geladenen Optionen zu finden, weil sich dort Pluginreste und Fehlkonfigurationen am stärksten bemerkbar machen. In einem SQL‑Tool (oder via WP‑CLI) kannst du dir z. B. so die Top‑Einträge holen:

SELECT option_id,
       option_name,
       LENGTH(option_value) AS size_bytes
FROM   wp_options
WHERE  autoload = 'yes'
ORDER  BY size_bytes DESC
LIMIT 100;

Viele Reste erkennt man am Präfix des option_name:

• WPML speichert u. a. Optionen mit Mustern wie icl_%, wpml_%, Übersetzungs‑Caches, String‑Indexes.
• WooCommerce und Add‑ons nutzen häufig woocommerce_%, _transient_wc_% oder plugin‑spezifische Präfixe wie wcs_, yith_%.

Tauchen hier große Einträge von Plugins auf, die du längst deinstalliert hast, oder offensichtlich Cache/Log‑Daten, sind das typische Kandidaten für „Pluginreste“.

WPML‑ und WooCommerce‑spezifische Muster

Bei Sites mit WPML und WooCommerce lohnt ein genauer Blick auf Options mit Bezug zu Übersetzungen und Shop‑Funktionen. WPML kann viele automatisch geladene Optionen für Sprachzuordnung und String‑Translation erzeugen; WooCommerce legt z. B. Steuer‑, Versand‑, Session‑ oder Berichtsdaten ab.​

Hilfreich sind Filter nach Namensmustern, etwa:

SELECT option_id, option_name, LENGTH(option_value) AS size_bytes
FROM   wp_options
WHERE  autoload = 'yes'
AND   (option_name LIKE 'icl\_%'
    OR option_name LIKE 'wpml\_%'
    OR option_name LIKE 'woocommerce\_%'
    OR option_name LIKE '\_transient\_wc\_%')
ORDER BY size_bytes DESC;

Findest du dort Einträge, die zu Add‑ons gehören, die nicht mehr im System sind (z. B. alte Payment‑Gateways, alte Übersetzungs‑Tools), kannst du diese als Pluginreste einordnen. Wichtig ist: erst prüfen, ob das zugehörige Plugin wirklich nicht mehr aktiv ist, dann per Backup absichern, und erst danach autoload auf „no“ setzen oder löschen.

Automatisierte Unterstützung durch Analyse‑Tools

Für mehr Komfort gibt es spezielle Optimierungs‑Plugins, die automatisch geladene Optionen scannen und versuchen, sie konkreten Plugins oder Themes zuzuordnen. Beispiele sind:

• Autoload‑Checker oder „Option Optimizer“: zeigen Anzahl, Größe und Namen aller autoload‑Optionen, markieren verwaiste („orphaned“) Optionen und liefern Hinweise auf Herkunft.
• Advanced Database Cleaner: scannt die wp_options‑Tabelle, listet Options nach Größe, Autoload‑Status und vermuteter Plugin‑Zuordnung und erlaubt gefiltertes Löschen.

Diese Zuordnung ist aber nicht unfehlbar: häufig werden Optionen falschen Plugins zugeordnet oder als „verwaist“ markiert, obwohl sie noch genutzt werden. Deshalb gilt: Tools nutzen, um Kandidaten zu finden, Entscheidung aber immer manuell treffen – gerade in einem Setup mit WPML und WooCommerce.

Vorgehensweise in der Praxis

Ein pragmatischer Workflow sieht so aus:

• Gesamtgröße und Top‑Autoload‑Einträge ermitteln, verdächtige option_name nach Pluginpräfixen gruppieren.
• Prüfen, welche Plugins (insbesondere WPML‑Module, WooCommerce‑Add‑ons) tatsächlich noch aktiv sind.
• Offensichtliche Alt‑Plugins markieren und deren Optionsnamen notieren.
• Zuerst autoload dieser Einträge auf „no“ setzen, Seite testen (Frontend, Checkout, Übersetzung).
• Wenn nach einigen Tagen keine Fehler auftreten, die betreffenden Optionen löschen.

So lassen sich Pluginreste aus wp_options gezielt herausziehen, ohne WPML‑ oder WooCommerce‑Funktionalität zu gefährden.

SELECT option_id, option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE autoload = 'yes' ORDER BY size_bytes DESC LIMIT 50