Plugin-Überladung: wenn ein KI-Build Sie mit 40 aktiven Plugins zurücklässt

#Wenn die Plugin-Liste länger ist als die Sitemap

Wenn der Build zusätzlich Custom-PHP von einem KI-Assistenten mitlieferte, kombinieren Sie dieses Audit mit dem Auditieren von KI-generiertem WordPress-Plugin-Code. Wenn Überladung, Custom-Code und Traffic-Verlust sich summieren, liegt die Arbeit im Rahmen der Rettung KI-erstellter Websites.

#Der anonymisierte Fall: 38 Plugins, 1,47 s TTFB

Eine B2B-Dienstleistungsseite (Schulungen und Beratung für regulierte Branchen im DACH-Raum) kam zu uns, nachdem ein interner Stakeholder Lighthouse lief und fragte, warum „WordPress so träge wirkt“. Die Site war in etwa drei Wochen mit Cursor und ChatGPT zusammengesetzt worden: Seitenstruktur, Textentwürfe, Formular-Flows und typische „installier einfach etwas dafür“-Plugin-Picks aus dem Verzeichnis. Niemand war Eigentümer der Plugin-Liste.

Das Hosting blieb unverändert: ein 2-vCPU-VPS bei einem deutschen Anbieter, PHP 8.2, beim Intake ohne Object Cache. Redis kam nach dem Plugin-Pass dazu und sparte weitere ~120 ms TTFB, aber der Großteil des Gewinns kam aus Entfernen und Zusammenführen von Plugins, nicht aus Infrastruktur-Upgrades.

Auf dem Staging lief Query Monitor neben einem einfachen curl-Loop über fünf Minuten; die 187 Startseiten-Abfragen kamen nicht von WooCommerce, sondern von drei Analytics-Plugins, die Metadaten pro View nachluden, plus einem Related-Posts-Plugin, das WP_Query auf jeder Unterseite feuerte. Das Muster kennen wir aus anderen DACH-Rescues, oft nach einem WordCamp-Vortrag oder einem YouTube-„Best-of“-Video, das der Assistent als Installationsliste interpretiert hat.

Die erste Reaktion des Auftraggebers war vorhersehbar: „Wir haben doch nur installiert, was wir brauchten.“ Genau so präsentiert sich Überladung. Jede einzelne Installation hatte einen plausiblen Grund. Die Kosten waren kumulativ.

#Wie KI-Builds schneller 40 Plugins erreichen als manuelle

Manuelle Überladung wächst meist über Monate: Ein Freelancer fügt einen Slider hinzu, Marketing ein Popup-Tool, jemand installiert ein zweites SEO-Plugin „nur zum Testen“. KI-gestützte Überladung presst dasselbe Verhalten in Tage, weil das Modell plausible Vollständigkeit optimiert, nicht Stack-Kohärenz.

Wiederkehrende Muster bei Rescue-Intakes:

1. Ein Prompt, ein Plugin. Der Assistent sagt nicht „erweitere dein bestehendes Formular-Plugin“. Er liefert einen Slug.
2. Kein Inventargedächtnis. Session zwei weiß nicht, dass Session eins Rank Math installiert hat; Session vier empfiehlt Yoast für „besseres Schema“.
3. Tutorial-Stapeln. Blogposts und YouTube-Transkripte aus dem Training empfehlen Listen „beste Plugins für X“. Der Build erbt die ganze Liste.
4. Custom-Code plus kommerzieller Wildwuchs. Derselbe Assistent, der zwölf Plugins vorschlug, generierte auch drei kleine Custom-Plugins als „schnelle Fixes“ und legte ungepflegtes PHP auf ungepflegte Abhängigkeiten.
5. Optimizer-Plugins als Pflaster. Steigt der TTFB, lautet der nächste Prompt „installiere ein Cache-Plugin“, manchmal ohne das erste Cache-Plugin zu deaktivieren.

Das erfordert weder Bosheit noch Inkompetenz. Es erfordert eine Prozesslücke: Niemand mit Verantwortung für die WordPress-Architektur hat den Stack vor dem Launch geprüft.

#Acht Kategorien, die bei KI-Builds überproportional vorkommen

Auf der anonymisierten Site machten diese acht Eimer 31 der 38 Plugins aus. Ihre Liste wird abweichen, aber die Kategorien wiederholen sich bei Rescues.

#1. Doppelte SEO- und Schema-Tools

Zwei SEO-Plugins waren aktiv. Beide gaben Schema aus. Beide hingen an wp_head. Eines blieb von einer Migration vom alten Hosting, eines aus der KI-Build-Woche. Behalten Sie eines. Einstellungen manuell zusammenführen; automatische Importer blind vertrauen funktioniert selten.

#2. Mehrere Formular-Builder

Contact Form 7, ein Drag-and-Drop-Builder aus einem Prompt und ein leichtes Modal-Formular-Plugin sammelten Leads in verschiedene Postfächer. Die Konsolidierung brachte drei Formulare in einen Builder; der Rest wurde gelöscht.

#3. Konkurrierende Cache- und Optimierungs-Plugins

Ein Host-Level-Cache-Plugin und ein zweiter „Speed Booster“ minifizierten Skripte gleichzeitig. Auf der Preisseite entstand intermittierend kaputtes JavaScript. Niemals zwei vollständige HTML-Cache-Schichten. Wählen Sie ein System und konfigurieren Sie es.

#4. Analytics- und Pixel-Wildwuchs

GA-Connector, Facebook-Pixel-Plugin, LinkedIn-Insight-Tag-Plugin, Heatmap-Trial und GTM doppelt eingefügt (einmal per Plugin, einmal per Header-Snippet). Die Messung wurde nicht besser. Das Request-Gewicht schon.

#5. Page Builder und Addon-Pakete

Elementor plus kommerzielles Addon-Paket plus Legacy-Slider „für alle Fälle“. Die Startseite nutzte den Builder; Innenseiten nicht. Wir exportierten statische Abschnitte wo möglich und entfernten den Slider vollständig.

#6. Sicherheits- und Housekeeping-Duplikate

Zwei Login-Limiter, ein Dateimanager-Plugin (sofort entfernt) und ein „Datenbank-Reiniger“, der bei jedem Admin-Load lief. Sicherheit gehört in einen bewussten Stack, nicht in drei überlappende Plugins.

#7. KI-Content- und Bild-Tools

Ein KI-Schreib-Plugin und ein Auto-Alt-Text-Tool fügten Admin-Cron-Jobs und ausgehende API-Calls hinzu. Content-Workflows gingen in den Redaktionsprozess; die Plugins verschwanden.

#8. Custom-KI-mu-Plugins

Drei Dateien in mu-plugins/ aus eingefügtem PHP: eigener Redirect-Handler, ein „Fix“ für REST-Berechtigungen und ein Admin-Spalten-Tweak. Ein Redirect-Plugin duplizierte .htaccess-Regeln. Ein REST-Tweak deaktivierte eine Integration, die Marketing täglich nutzte. Nach dem Sicherheitsreview behielten wir den Admin-Spalten-Tweak als geprüften Code in einer einzigen gepflegten Datei und löschten die anderen beiden.

#Selbstdiagnose: Anzeichen, dass Sie plugin-tief sind

Führen Sie das aus, bevor Sie einen weiteren Optimizer installieren.

Query Monitor auf Staging (nicht Produktion, wenn die Policy es verbietet), Startseite ausgeloggt laden, Screenshot des Query-Stacks. Diese eine Ansicht schämt den Stack oft genug, dass jemand Verantwortung übernimmt.

#Triage: behalten, zusammenführen, ersetzen, entfernen

Wir nutzen bei jedem Überladungs-Rescue ein vier-Spalten-Register. Jedes aktive Plugin bekommt genau ein Label.

Behalten - einzelner Eigentümer einer Funktion, gepflegt, keine Überlappung. Beispiel: das eine SEO-Plugin nach Einstellungs-Merge.

Zusammenführen - zwei Plugins mit benachbarten Aufgaben, die ein gepflegtes Tool abdecken kann. Beispiel: drei Formular-Plugins zu einem.

Ersetzen - Plugin-Aufgabe ist valide, die Implementierung schwer; ersetzen durch wenige Zeilen im Child-Theme oder ein Block-Pattern. Beispiel: Related-Posts-Plugin mit WP_Query auf jedem View durch einen kuratierten Block ersetzt.

Entfernen - verwaist, doppelt, gefährlich oder ungenutzt. Dateimanager-Plugins, Hello-World-SEO-Tests und „temporäre“ Debug-Tools landen hier.

Arbeiten Sie in Chargen von maximal fünf bis acht Plugins. Deaktivieren, Checkout und Formulare testen, TTFB messen, dann löschen. Massenlöschungen sind der Weg, wie Produktion freitags bricht.

Auf der anonymisierten Site sah die Aufteilung so aus:

• Behalten: 21 Plugins nach Konsolidierung (ein SEO, ein Formular-Stack, ein Cache, ein Security-Suite)
• Zusammenführen: 9 Plugins in behaltene Tools eingeflossen
• Ersetzen: 4 Plugin-Aufgaben in Theme-Code oder Blöcke verschoben
• Entfernen: 8 Plugins gelöscht (darunter 2 verwaiste, 1 Dateimanager, 1 doppelter Cache)

#Custom-KI-Plugins sind trotzdem Plugins

Teams zählen oft nur Verzeichnis-Plugins und vergessen mu-plugins oder „Code Snippets“-Plugins, die PHP injizieren. KI-Assistenten generieren diese gern, weil es schneller wirkt als saubere Plugin-Struktur zu lernen.

Behandeln Sie jede Custom-Datei wie Third-Party-Code:

• Prüfen auf ABSPATH-Guards, Nonces und $wpdb->prepare()
• Prüfen, ob die Funktion ein bestehendes Plugin dupliziert
• Überlebenden Code in Versionskontrolle verschieben, nicht in die Einfügebox im wp-admin

Fehlen Nonces und SQL wird konkateniert, hören Sie auf, kommerzielle Plugins zu deinstallieren, bis Custom-Code eingegrenzt ist. Schlechtes Custom-PHP plus schrumpfender kommerzieller Stack kann Endpoints freilegen, an die sich niemand erinnert.

#Konsolidierungs-Workflow auf Staging

1. Neue Installationen einfrieren. Keine Plugin-Antworten, bis das Register existiert.
2. Aktive Liste exportieren in eine Tabelle: Slug, Version, letztes Update-Datum, deklarierte Aufgabe, tatsächliche Aufgabe.
3. Überlappungen markieren bei SEO, Cache, Formularen, Analytics und Sicherheit zuerst.
4. Duplikate auf Staging deaktivieren, alle Caches leeren, primäre Conversion-Pfade testen.
5. TTFB und Abfragezahl messen auf Startseite, schwerster Landingpage und Checkout-/Kontakt-Danke-Seite.
6. In kleinen Chargen löschen, nach jeder Charge erneut messen.
7. Finalen Stack dokumentieren im Projekt-README oder Client-Handover, damit die nächste KI-Session ein Inventar zum Lesen hat.

Die Preisgestaltung für Rescue-Arbeit ist immer individuell, weil die Plugin-Anzahl nur eine Variable ist. Datenbank-Bloat, Custom-KI-Code und Traffic-Niveau zählen genauso wie die Zahl im wp-admin.

#Was Sie nicht tun sollten

• Kein „Plugin-Manager“-Plugin installieren, um Plugin-Überladung zu beheben. Sie haben ein weiteres Plugin hinzugefügt.
• Keine zwei Full-Page-Caches aktivieren „zur Sicherheit“.
• Kein KI-Assistent soll ein Aufräum-Skript generieren, das Zeilen in wp_options massenhaft löscht, ohne Backup und Diff-Review.
• Nicht annehmen, deaktivierte Plugins seien harmlos. Manche laden Code auf init, wenn sie in seltsamen Zuständen bleiben; nach Verifikation löschen.
• Formular- und Checkout-Tests nicht überspringen, weil „es nur ein Blog ist“. Auf der anonymisierten Site saß das kaputte JavaScript auf der Preisseite, nicht im Blog-Index.

#Wann auf Rescue eskalieren

Inkrementelles Aufräumen funktioniert, wenn Überlappungen offensichtlich sind, Custom-Code minimal ist und jemand Technisches Staging besitzt. Eskalieren Sie zu einem formalen Rettung KI-erstellter Websites-Engagement, wenn:

• Aktive Plugins nach dem ersten Durchgang über Mitte dreißig bleiben
• Mehrere Custom-KI-Plugins Authentifizierung, Uploads oder SQL berühren
• TTFB uncached über ~1 s bleibt, nachdem doppelte Cache- und SEO-Tools entfernt wurden
• Das Unternehmen sich keinen kaputten Formular- oder Zahlungsflow bei ungeleiteten Löschungen leisten kann
• Sicherheitsscans bekannte CVEs über verwaiste Plugins zeigen, die niemand aktualisieren wird

Rescue ist kein Euphemismus für Rebuild. Im Fall oben verließen 17 Plugins den Stack, Theme und Hosting-Tier blieben. Das Deliverable ist ein gemessenes Register, kein Verkaufspitch für eine neue Plattform.

#Erfolg messen jenseits der Plugin-Anzahl

Die Plugin-Anzahl ist ein Proxy. Verfolgen Sie Metriken, die die Nutzererfahrung widerspiegeln:

Nach der Konsolidierung ein Plugin-Budget setzen: Für diese Site-Klasse kein neues Plugin ohne ein bestehendes zu pensionieren oder zusammenzuführen. Diese Regel in die Projekt-Anweisungsdatei für KI-Assistenten schreiben, damit der nächste Prompt das Rescue nicht an einem Nachmittag rückgängig macht.

#Glossar

• Plugin sprawl / Plugin-Überladung - Ansammlung aktiver Plugins mit überlappenden Aufgaben, bis Performance, Sicherheit und Wartbarkeit leiden.
• TTFB (Time to First Byte) - Server-Antwortzeit, bevor der Browser Content rendert; sensibel für PHP-Hook-Anzahl und Datenbankabfragen.
• mu-plugin - Must-Use-Plugin, bei jedem Request aus wp-content/mu-plugins/ geladen; oft für KI-generierte „schnelle Fixes“.
• Autoloaded Options - WordPress-Optionen, die bei jedem Request geladen werden; aufgebläht durch Plugins mit großen Arrays und autoload=yes.
• Query sprawl - übermäßige Datenbankabfragen pro Seitenaufruf, typisch wenn viele Plugins Metadaten unabhängig abfragen.

#Fazit

Vierzig Plugins tief ist kein moralisches Versagen. Es passiert, wenn schnelle KI-gestützte Montage die Architektur-Review überholt. Die anonymisierte Site in diesem Leitfaden ging von 38 auf 21 aktive Plugins, medianer uncached TTFB von 1,47 s auf 0,68 s und Startseiten-Abfragen von 187 auf 94, ohne Host-Wechsel oder Theme-Rebuild. Die Arbeit war mühsam, messbar und größtenteils Deinstallationen.

Beginnen Sie mit dem Register, beenden Sie doppelte SEO- und Cache-Schichten, prüfen Sie Custom-KI-Dateien, bevor Sie das Löschen kommerzieller Plugins feiern, und messen Sie nach jeder Charge. Wenn der Stack weiter kämpft, dafür ist Rettung KI-erstellter Websites da: eine Behalten-Umschreiben-Entfernen-Aufteilung mit Zahlen, keine weitere Plugin-Empfehlung.