Plugin-Friedhof: Bestand prüfen und kontrolliert reduzieren

Aktualisiert: 9. September 2026

Plugin-Friedhof ist eine umgangssprachliche Bezeichnung für einen unübersichtlichen WordPress-Plugin-Bestand mit ungenutzten Erweiterungen, überlappenden Funktionen und Datenresten. Entscheidend ist nicht eine bestimmte Plugin-Anzahl, sondern ob Nutzen, Zuständigkeit, Wartung und Abhängigkeiten noch nachvollziehbar sind.

Wie er entsteht

Viele Plugins lösen zunächst ein konkretes Problem: Formular, Cookie-Banner, Galerie oder Weiterleitung. Der Bestand wächst, wenn solche Entscheidungen später nicht erneut geprüft werden.

Das Problem entsteht an einer anderen Stelle, nämlich dort, wo die Entscheidung nie zurückgenommen wird. Die Galerie wird durch eine andere ersetzt, die alte bleibt deaktiviert liegen. Der Kollege, der das Weiterleitungs-Plugin installiert hat, ist nicht mehr da. Niemand weiß, ob das Ding noch etwas tut, also bleibt es.

Ob zehn oder vierzig Erweiterungen installiert sind, sagt allein wenig aus. Problematisch wird es, wenn niemand mehr weiß, welche davon gebraucht werden, wer sie wartet und was beim Entfernen ausfallen könnte.

Kosten: Sicherheit, Ladezeit und Wartung

Sicherheit. Plugin-Code läuft innerhalb der Berechtigungen des WordPress-Prozesses und der verwendeten Datenbankverbindung. Qualität, Pflegezustand und konkrete Schwachstellen zählen mehr als die reine Anzahl. Ausbleibende Updates beweisen keine Lücke, können aber die verlässliche Wartung erschweren.

Ladezeit. Aktive Plugins werden beim regulären WordPress-Bootstrap geladen, führen aber nicht zwangsläufig auf jeder Seite teure Arbeit aus. Bedingt geladene Assets und Caches verändern die Wirkung. Miss PHP-Laufzeit, Datenbankzugriffe und Frontend-Ressourcen für die tatsächlich wichtigen Seiten.

Datenbank. Einstellungen, Protokolle und temporäre Daten können zurückbleiben. Autoloaded Options werden beim Laden der gemeinsam benötigten Optionen berücksichtigt; ein Object Cache kann Datenbankzugriffe vermeiden. Ein vollständiger Seiten-Cache kann WordPress ganz umgehen. Deinstallation entfernt Daten nur, soweit das Plugin dies vorsieht.

Wartbarkeit. Der teuerste Posten und der am schlechtesten messbare. Wenn niemand mehr weiß, was wofür da ist, traut sich niemand mehr, etwas anzufassen. Updates werden aufgeschoben, weil unklar ist, was dabei bricht. Genau daraus wird dann das Sicherheitsproblem.

Warum deaktiviert nicht harmlos ist

Ein deaktiviertes Standard-Plugin wird beim normalen WordPress-Laden nicht eingebunden. Seine Dateien bleiben jedoch vorhanden. Eine unabhängig direkt aufrufbare, verwundbare Datei kann weiterhin ein Risiko darstellen; viele andere Lücken benötigen dagegen ein aktives Plugin. MU-Plugins, Drop-ins und Netzwerkaktivierung müssen getrennt geprüft werden.

Dazu kommt, dass deaktivierte Plugins in der Update-Routine mitlaufen und in der Liste Platz belegen, wodurch die tatsächlich wichtigen Einträge untergehen.

Ungenutzte Erweiterungen nach geklärten Abhängigkeiten und einem Wiederherstellungsplan entfernen. Eine starre Zweiwochenfrist ist dafür kein fachlicher Maßstab. Vor dem Löschen prüfen, ob die Deinstallation Daten unwiederbringlich entfernt oder eine andere Komponente davon abhängt.

Bestand reduzieren: Schritt für Schritt

Inventarisieren. Liste aller Plugins mit Version, letztem Update im Verzeichnis, aktiv oder nicht, und einer Spalte: Wofür ist das da? Was dort leer bleibt, ist der eigentliche Fund.
Nutzung belegen. Auch Hintergrundaufgaben, REST-Endpunkte, Tracking, E-Mail-Zustellung und Abhängigkeiten anderer Plugins prüfen. Eine fehlende sichtbare Funktion ist kein Beweis für Nichtnutzung.
Nach Risiko sortieren. Zuerst raus, was nachweislich ungenutzt und seit Jahren nicht aktualisiert ist. Zuletzt, was tief in Darstellung oder Bestellprozess eingreift.
Einzeln deaktivieren und testen. Auf Staging Formulare, Suche, Darstellung, Hintergrundaufgaben und gegebenenfalls Checkout prüfen. Erst danach die Deinstallation und ihre möglichen Datenlöschungen durchführen.
Reste aufräumen. Verbliebene Optionen, eigene Tabellen, Ordner in wp-content/, geplante Aufgaben.
Messen. Vorher und nachher: Zahl der Plugins, Größe der Autoloaded Options, TTFB, Zahl der Datenbankabfragen auf einer typischen Seite.

Alles davon auf einer Staging-Kopie, nicht live. Und mit einem Backup, das man auch schon einmal zurückgespielt hat.

Datenreste: Zuordnung vor dem Löschen

Mögliche Rückstände sind Optionen, eigene Tabellen, Cron-Ereignisse und Dateien in wp-content/. Ein Namenspräfix hilft bei der Zuordnung, reicht aber nicht als Löschbegründung. Manche Daten bleiben absichtlich für eine spätere Reaktivierung erhalten.

Die folgenden Abfragen lesen nur. wp_ durch das tatsächliche Präfix ersetzen und bei Multisite die richtige Website-Tabelle wählen. Seit WordPress 6.6 umfasst die Standardliste für Autoload yes, on, auto-on und auto. Ein Filter kann diese Liste einschränken; die SQL-Abfrage bildet die Standardwerte ab.

SELECT option_name, LENGTH(option_value) AS groesse
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY groesse DESC
LIMIT 25;

Die Gesamtsumme liefert einen Rohwert in Bytes, keine direkte Messung von Arbeitsspeicher oder Ladezeit. Die Autoload-Warnschwelle im Website-Zustand ist ein Diagnosehinweis und kann gefiltert werden. Ein Wert darunter beweist weder gute Performance noch unnötige Daten darüber.

SELECT COALESCE(SUM(LENGTH(option_value)), 0) AS autoload_gesamt
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Beim Löschen von Einträgen gilt dieselbe Vorsicht wie beim Rest: erst sichern, dann einzeln, dann prüfen. Ein Präfix, das nach einem entfernten Plugin aussieht, kann auch zu einem noch aktiven gehören.

Wirkung prüfen: Ein Messprotokoll statt pauschaler Versprechen

Die Wirkung lässt sich mit einem reproduzierbaren Messprotokoll prüfen: gleiche URLs, gleiche Hosting-Umgebung, gleicher Cache-Zustand und mehrere Durchläufe. TTFB, Abfragen, Autoload-Größe und kritische Funktionen vor und nach jeder Änderung vergleichen.

Vorbeugen mit einer Regel

Für jedes neue Plugin Zweck, Verantwortlichen, Abhängigkeiten und einen Prüftermin dokumentieren. Das lässt sich in der bestehenden Projektdokumentation führen.

Beim nächsten Review ist damit nachvollziehbar, weshalb die Erweiterung existiert und wie sie geprüft werden muss. Ziel ist ein verständlicher, gepflegter Bestand, nicht eine möglichst kleine Zahl um jeden Preis.