Eine WordPress-Seite mit 27 aktiven Plugins ist kein Ausreißer, sondern ein ziemlich alltägliches Bild: ein SEO-Plugin, zwei Caching-Plugins (weil das alte bei einem Update Probleme gemacht hat und niemand das neue danach wieder entfernt hat), ein Kontaktformular-Plugin, ein zweites nur für die Newsletter-Anmeldung, ein Cookie-Banner, ein Backup-Tool, ein Sicherheits-Plugin, ein Page Builder mit eigenem Icon-Paket und ein halbes Dutzend kleiner Helfer, die irgendwann für genau ein Feature installiert wurden. Mobil lädt die Seite über vier Sekunden, im PageSpeed-Test liegt der Wert im gelben bis roten Bereich. Was Plugin Nummer 14 eigentlich tut, weiß im Team niemand mehr genau – aber löschen will es auch keiner, aus Angst, dass danach etwas kaputtgeht.
Das ist der Kern des Problems, um das es hier geht: Plugin-Bloat entsteht selten durch eine einzelne falsche Entscheidung, sondern durch viele Jahre „kurz ein Plugin installieren, das für das eine Ding erledigt“. Am Ende steht eine Website, die schwerer zu warten ist, langsamer lädt und bei jedem Update ein kleines Risiko trägt – und ein Team, das sich nicht mehr traut, etwas davon zu entfernen.
Eine feste Zahl dafür gibt es nicht, und jede Agentur, die dir „maximal 20 Plugins“ nennt, rät eher, als dass sie misst. Entscheidend ist nicht die Anzahl allein, sondern was jedes einzelne Plugin lädt und wie oft es sich mit anderen überschneidet. Zehn schlanke, sauber programmierte Plugins verursachen oft weniger Last als ein einziges überladenes All-in-one-Tool, das auf jeder Seite Skripte nachlädt, die dort gar nicht gebraucht werden. Kritisch wird es vor allem, wenn mehrere Plugins dieselbe Aufgabe übernehmen – zwei SEO-Plugins, zwei Firewalls, zwei Caching-Systeme parallel – oder wenn ein Plugin auf jeder Unterseite Assets einbindet, die nur auf einer einzigen Seite gebraucht würden.
Ein brauchbarer Praxis-Maßstab: Jedes aktive Plugin sollte einen klaren, aktuell gültigen Zweck haben, den jemand im Team benennen kann. Sobald du bei einem Plugin ins Stocken gerätst, wenn du erklären sollst, warum es aktiv ist, ist das ein stärkeres Warnsignal als jede absolute Zahl.
Bevor du irgendetwas deaktivierst, brauchst du Daten statt Bauchgefühl. Drei Ebenen sind dafür sinnvoll:
Google PageSpeed Insights zeigt dir die Core Web Vitals der Seite – Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) – getrennt für Mobil und Desktop. GTmetrix oder Pingdom ergänzen das um ein Wasserfall-Diagramm, in dem du siehst, welche CSS- und JS-Dateien überhaupt geladen werden und wie viele davon von Plugins stammen, die mit der eigentlichen Seite nichts zu tun haben. Wenn du im Wasserfall zwanzig Skripte von Plugins siehst, die auf dieser Unterseite keine Funktion erfüllen, hast du bereits einen konkreten Ansatzpunkt.
Falls du wissen willst, welche anderen Ursachen abseits von Plugins eine WordPress-Seite ausbremsen – Hosting, Bilder, Theme, Datenbank –, findest du eine ausführlichere Einordnung in unserem Artikel Warum ist meine WordPress-Website so langsam?.
Für die Detailanalyse ist das kostenlose Plugin Query Monitor das Standardwerkzeug. Nach der Installation erscheint ein neuer Punkt in der Admin-Toolbar, der pro Seitenaufruf unter anderem die Anzahl der Datenbankabfragen, die Ladezeit und den Speicherverbrauch anzeigt. Besonders hilfreich ist der Tab „Queries by Component“: Er ordnet jede einzelne Datenbankabfrage einem konkreten Plugin, dem Theme oder dem WordPress-Kern zu. So siehst du auf einen Blick, welches Plugin überdurchschnittlich viele oder langsame Abfragen erzeugt. Zusätzlich zeigt Query Monitor unter „Scripts“ und „Styles“, welches Plugin welche CSS- und JS-Dateien einbindet – auch auf Seiten, auf denen diese Dateien offensichtlich nicht gebraucht werden.
Aktiviere Query Monitor testweise auf einer Staging-Umgebung oder zumindest außerhalb der Stoßzeiten, öffne typische Seitentypen (Startseite, Blogartikel, Produktseite, Formularseite) und vergleiche die Werte. Auffällig sind Plugins, die auf jeder Seite laufen, obwohl ihre Funktion nur auf einzelnen Seiten gebraucht wird.
Unter Werkzeuge → Website-Zustand zeigt WordPress selbst grundlegende Performance- und Sicherheitshinweise, etwa veraltete PHP-Versionen oder fehlende Object-Caches. Ergänzend lohnt sich ein Blick ins Debug-Log: Aktivierst du in der wp-config.php vorübergehend WP_DEBUG und WP_DEBUG_LOG, protokolliert WordPress PHP-Notices und -Warnungen in eine Datei im wp-content-Verzeichnis. Viele davon stammen aus veralteten oder schlecht gepflegten Plugins und sind ein guter Hinweis darauf, welche Erweiterungen technisch nicht mehr auf der Höhe sind.
In der Praxis wiederholen sich immer dieselben Bereiche, in denen sich Plugins stapeln, ohne dass es jemandem auffällt:
Häufig sind gleich zwei große SEO-Suiten gleichzeitig aktiv – etwa weil beim Wechsel des Tools das alte nur deaktiviert, aber nie entfernt wurde. Beide schreiben parallel Metadaten, XML-Sitemaps und strukturierte Daten, was zu widersprüchlichen Angaben führen kann. Hier gehört nur ein Tool aktiv, der Rest raus.
Mehrere Caching-Lösungen gleichzeitig – etwa WP Rocket, Autoptimize, LiteSpeed Cache oder W3 Total Cache in beliebiger Kombination – erzeugen eher Konflikte als zusätzlichen Nutzen. Sie minifizieren teils dieselben Dateien doppelt oder widersprechen sich beim Cache-Purging. Ein sauber konfiguriertes Caching-Plugin ersetzt meist mehrere halbherzig eingerichtete.
Kontaktformular, Newsletter-Anmeldung, Bewerbungsformular, Event-Anmeldung – wächst das über Jahre, sammeln sich schnell drei oder vier verschiedene Formular-Plugins an, obwohl die meisten von ihnen sämtliche dieser Fälle allein abdecken könnten.
Zwei Firewalls oder zwei Malware-Scanner gleichzeitig (etwa Wordfence neben Sucuri oder einer Security-Suite des Hosters) bremsen nicht nur, sie können sich auch gegenseitig aussperren oder legitime Anfragen blockieren. Ein aktives, gut gepflegtes Sicherheits-Plugin reicht in der Regel.
Nach einem Wechsel des Page Builders bleiben oft alte Addon-Pakete aktiv, weil einzelne Altseiten noch mit den alten Elementen gebaut sind. Dazu kommen üppige Addon-Bundles für Page Builder, die hunderte Widgets mitbringen, obwohl im Projekt vielleicht fünf davon verwendet werden – und trotzdem laden sie ihre Assets oft global mit.
Popup-Plugins für eine einmalige Aktion, Social-Share-Buttons aus einer Kampagne, ein Analytics-Zusatz für ein Projekt, das längst abgeschlossen ist – diese Kategorie ist am leichtesten zu bereinigen, weil der ursprüngliche Zweck meist eindeutig erledigt ist.
Aufräumen sollte nicht bedeuten, auf gut Glück Plugins zu deaktivieren und zu hoffen, dass nichts passiert. Ein methodisches Vorgehen nimmt dem Prozess die Angst:
Der eigentliche Grund, warum Plugin-Friedhöfe entstehen, ist selten Faulheit, sondern fehlende Zuständigkeit. Niemand ist offiziell dafür verantwortlich, regelmäßig zu prüfen, was noch gebraucht wird. Ein fester Termin – etwa halbjährlich – reicht meist schon aus, um zu verhindern, dass sich wieder zwanzig ungenutzte Plugins ansammeln. Bei jedem neuen Plugin lohnt sich vorher die kurze Frage, ob die Funktion nicht bereits ein vorhandenes Tool oder das Theme selbst abdecken kann.
Wenn eine Website nach der Bereinigung immer noch träge wirkt oder technisch grundsätzlich an ihre Grenzen stößt, liegt das oft nicht mehr an einzelnen Plugins, sondern an der Gesamtarchitektur – dann ist eher ein technisches Fundament-Update oder ein Relaunch das Thema, für das sich auch ein Blick in unseren Artikel Wie lange dauert eine neue Website? lohnt. Für die laufende technische Pflege und Betreuung von WordPress-Websites unterstützt dich M2K ebenfalls, falls dafür intern die Zeit oder die Kapazität fehlt.