Warum ich WordPress-Erweiterungen künftig lieber von KI-Agenten maßschneidern lasse

WordPress ist großartig. WooCommerce ist großartig. Das Plugin-Ökosystem ist großartig.

Bis man es benutzt.

Dann installiert man ein Plugin, weil man genau eine Funktion benötigt. Eine einzige. Vielleicht einen sauberen Meta-Title. Vielleicht ein Open-Graph-Bild. Vielleicht ein zusätzliches Feld im Produkt. Vielleicht eine kleine Automatisierung im Checkout.

Und was bekommt man?

Ein halbes Raumschiff.

• Mit Dashboard.
• Mit Wizard.
• Mit Onboarding.
• Mit Upsell.
• Mit Tracking.
• Mit fünf Untermenüs.
• Mit zehn Premium-Hinweisen.
• Mit Datenbanktabellen, die man nie bestellt hat.
• Mit CSS und JavaScript auf Seiten, auf denen sie nichts zu suchen haben.
• Mit Funktionen, die man nicht braucht, nicht versteht und niemals benutzen wird.

Willkommen im modernen WordPress-Alltag.

Das Plugin-Problem: Man kauft selten eine Funktion, sondern fast immer ein Paket

Das Grundproblem ist simpel: Die meisten WordPress-Plugins sind keine präzisen Werkzeuge mehr. Sie sind Produktplattformen.

Ein SEO-Plugin macht nicht nur Meta-Titles und Descriptions. Es macht XML-Sitemaps, Redirects, Schema.org, Social Media, Content-Analyse, Lesbarkeitsbewertung, Keyword-Vorschläge, WooCommerce-Erweiterungen, Breadcrumbs, REST-Ausgaben, Admin-Hinweise, Premium-Teaser und gelegentlich noch Dinge, von denen man erst erfährt, wenn sie irgendwo dazwischenfunken.

Ein Formular-Plugin ist nicht einfach ein Formular-Plugin. Es ist ein CRM-Ansatz, ein Newsletter-System, ein Zahlungsmodul, ein Anti-Spam-System, ein Marketing-Werkzeug und ein Analytics-Sammler.

Ein Performance-Plugin ist nicht einfach ein Cache. Es ist ein Kontrollzentrum mit Dutzenden Einstellungen, die man vorsichtig anfassen muss, weil sonst plötzlich der Warenkorb, das Login oder die Produktbilder nicht mehr funktionieren.

Man installiert also ein Plugin wegen zehn Prozent seines Nutzens und bekommt hundert Prozent seiner Komplexität.

Der Preis ist nicht nur Geld

Natürlich kosten viele Plugins Geld. Manchmal einmalig, oft jährlich, immer häufiger im Abo. Aber Geld ist nicht einmal der größte Preis.

Der größere Preis ist Betriebsaufwand.

• Jedes Plugin muss installiert werden.
• Jedes Plugin muss konfiguriert werden.
• Jedes Plugin muss verstanden werden.
• Jedes Plugin muss aktualisiert werden.
• Jedes Plugin kann mit anderen Plugins kollidieren.
• Jedes Plugin kann Sicherheitslücken enthalten.
• Jedes Plugin kann den Shop langsamer machen.
• Jedes Plugin kann nach einem Update plötzlich anders funktionieren.

Und irgendwann besteht eine WordPress-Installation nicht mehr aus WordPress, WooCommerce und einer klaren Geschäftslogik, sondern aus einem historisch gewachsenen Plugin-Gestrüpp.

Niemand weiß mehr genau, welches Plugin wofür zuständig ist.
Niemand traut sich, etwas abzuschalten.
Niemand weiß, warum auf einer Produktseite acht verschiedene JavaScript-Dateien geladen werden.
Niemand weiß, warum die Datenbank plötzlich Tabellen enthält, die nach längst gelöschten Erweiterungen aussehen.

Das ist kein System. Das ist digitale Archäologie.

Sicherheitslücken: Der öffentliche Code als Angriffskarte

Bei populären Plugins kommt ein weiterer Punkt hinzu: Der Code ist öffentlich bekannt oder zumindest weit verbreitet. Das ist für Open Source nicht grundsätzlich schlecht. Im Gegenteil: Transparenz kann Sicherheit erhöhen.

Aber in der Praxis bedeutet es auch: Wenn ein weit verbreitetes Plugin eine Lücke hat, ist diese Lücke für Angreifer interessant. Nicht, weil mein kleiner Shop besonders spannend wäre, sondern weil dieselbe Lücke auf Tausenden oder Millionen Installationen existieren könnte.

Ein Angreifer muss nicht wissen, wer ich bin. Er muss nur automatisiert testen, ob mein System eine bekannte Schwachstelle hat.

Das ist der unangenehme Teil der Plugin-Ökonomie: Standardsoftware erzeugt Standardangriffsflächen.

Je mehr verbreitete Plugins man installiert, desto mehr hängt die Sicherheit des eigenen Systems von fremdem Code, fremden Release-Zyklen und fremder Sorgfalt ab.

Meine neue Strategie: Nicht mehr Plugin suchen, sondern Funktion definieren

Ich habe deshalb meine Vorgehensweise geändert.

Ich frage nicht mehr zuerst:

Welches Plugin kann das?

Sondern:

Welche Funktion brauche ich wirklich?

Das ist ein fundamentaler Unterschied.

Ich suche mir die Leistungsmerkmale verschiedener Plugins zusammen. Nicht, um diese Plugins zu installieren. Sondern um zu verstehen, welche Funktionen überhaupt relevant sind.

Dann bilde ich eine Vereinigungsmenge:

• Welche Features sind wirklich wichtig?
• Welche überschneiden sich?
• Welche sind nur Marketing?
• Welche brauche ich jetzt?
• Welche brauche ich vielleicht später?
• Welche kann man bewusst weglassen?

Aus dieser Feature-Liste entsteht kein Plugin-Kauf.
Daraus entsteht ein Bauplan.

Und diesen Bauplan gebe ich an einen KI-Agenten.

Der KI-Agent als persönlicher Plugin-Entwickler

Der Ablauf ist erstaunlich pragmatisch:

• Ich beschreibe dem Agenten, was das Plugin leisten soll.
• Ich definiere die gewünschten Admin-Seiten.
• Ich bestimme, welche Daten gespeichert werden.
• Ich sage ausdrücklich, was nicht eingebaut werden soll.
• Ich verlange sauberen, wartbaren Code.
• Ich lasse die Erweiterung exakt für meinen Anwendungsfall bauen.

Am Ende entsteht kein generisches Massenprodukt, sondern ein internes Werkzeug.

• Mit eigenem Namen.
• Mit eigener Admin-Seite.
• Mit genau den Funktionen, die ich brauche.
• Ohne Ballast.
• Ohne Premium-Teaser.
• Ohne fremde Produktstrategie.
• Ohne Feature-Friedhof.

Und wenn später neue Anforderungen entstehen, wird das Plugin erweitert. Nicht ersetzt. Nicht durch ein weiteres Plugin ergänzt. Sondern gezielt ausgebaut.

Beispiel SEO: Der Klassiker des Plugin-Bloats

SEO ist das beste Beispiel.

Fast jeder WordPress-Betreiber kennt SEO-Plugins. Fast jeder hat irgendwann eines installiert. Und fast jeder nutzt davon nur einen Bruchteil.

Was brauche ich wirklich?

• Meta-Title.
• Meta-Description.
• Canonical-URL.
• Robots-Angaben.
• Open Graph für Facebook, LinkedIn und andere Plattformen.
• Twitter Cards.
• JSON-LD strukturierte Daten.
• WooCommerce-Produktdaten.
• Sitemap-Logik, falls WordPress nicht reicht.
• Optionale Overrides pro Beitrag oder Produkt.

Das ist technisch kein Hexenwerk.

Aber viele SEO-Plugins machen daraus eine eigene Welt: Ampelsysteme, Content-Scores, Keyword-Assistenten, Premium-Integrationen, Redirect-Manager, Link-Zähler, Lesbarkeitsanalysen und Dashboard-Flächen, die mehr nach Marketing-Suite aussehen als nach sauberer technischer SEO.

Ich will aber keine Marketing-Suite.

• Ich will kontrollierte technische Ausgaben im HTML-Head.
• Ich will saubere strukturierte Daten.
• Ich will keine doppelten Tags.
• Ich will keine Magie.
• Ich will keinen Overhead.

Also lasse ich mir ein schlankes SEO-Modul bauen, das genau diese Dinge erledigt. Nicht mehr und nicht weniger.

Maßgeschneidert schlägt Massenware

Der entscheidende Vorteil liegt nicht darin, dass KI „billiger programmiert“. Das wäre zu kurz gedacht.

Der entscheidende Vorteil liegt darin, dass ich die Architektur wieder selbst bestimme.

Ein Standardplugin muss für möglichst viele Nutzer funktionieren. Es muss Anfänger abholen, Agenturen bedienen, Sonderfälle berücksichtigen, Premium-Funktionen vorbereiten und möglichst viele Szenarien abdecken.

Mein eigenes Plugin muss nur für meinen Fall funktionieren.

Das ist ein massiver Unterschied.

Wenn mein Shop bestimmte Produkttypen hat, kann das Plugin genau diese Produkttypen berücksichtigen.
Wenn ich bestimmte Meta-Daten brauche, werden genau diese gespeichert.
Wenn ich bestimmte Admin-Workflows habe, wird genau dafür eine Oberfläche gebaut.
Wenn ich bestimmte Funktionen niemals nutzen werde, werden sie gar nicht erst eingebaut.

Das Ergebnis ist kleiner, verständlicher und kontrollierbarer.

Weniger Abhängigkeit, mehr Kontrolle

Ein eigenes Plugin bedeutet auch: weniger Abhängigkeit.

• Kein Anbieter kann plötzlich die Preise erhöhen.
• Kein Anbieter kann Funktionen hinter eine Paywall verschieben.
• Kein Anbieter kann das Interface umbauen.
• Kein Anbieter kann Tracking einbauen.
• Kein Anbieter kann beschließen, dass meine Lieblingsfunktion künftig nur noch im Business-Tarif steckt.

Natürlich bedeutet eigener Code auch Verantwortung. Man muss testen. Man muss sauber entwickeln. Man muss Sicherheitsaspekte ernst nehmen. Man muss Updates von WordPress und WooCommerce beachten.

Aber diese Verantwortung existiert ohnehin.

Der Unterschied ist: Ich weiß wenigstens, was im Code steht.

Das ist kein Aufruf zu blindem Vibe-Coding

Wichtig: Das ist kein Plädoyer dafür, irgendeinem KI-Agenten blind Produktionscode in den Shop werfen zu lassen.

Das wäre fahrlässig.

Ein KI-Agent ist kein Ersatz für technisches Verständnis. Er ist ein Beschleuniger. Er kann Code erzeugen, Strukturen vorbereiten, Admin-Seiten bauen, WordPress-Hooks einrichten und wiederkehrende Arbeit drastisch reduzieren.

Aber jemand muss wissen, was geprüft werden muss.

• Sicherheit.
• Escaping.
• Nonce-Prüfungen.
• Capabilities.
• Datenbankzugriffe.
• Performance.
• Kompatibilität mit WooCommerce.
• Keine doppelten Ausgaben.
• Keine unnötigen Assets im Frontend.
• Saubere Deaktivierung.
• Saubere Fehlerbehandlung.

Der Agent schreibt.
Ich entscheide.
Ich prüfe.
Ich teste.
Ich deploye.

So herum funktioniert es.

Der eigentliche Fortschritt: Software wird wieder kleiner

In den letzten Jahren ist Software oft größer geworden, weil es geschäftlich sinnvoll war. Mehr Features verkaufen sich besser als weniger Features. Mehr Menüpunkte sehen mächtiger aus. Mehr Integrationen rechtfertigen höhere Preise.

Aber für den einzelnen Betreiber ist mehr nicht automatisch besser.

Mehr Code bedeutet mehr Angriffsfläche.
Mehr Optionen bedeuten mehr Fehlkonfiguration.
Mehr Abhängigkeiten bedeuten mehr Wartung.
Mehr Plugin-Logik bedeutet mehr Performance-Risiko.

KI-Agenten ermöglichen nun etwas Interessantes: Man kann wieder kleinere Software bauen.

Nicht, weil Entwickler plötzlich überflüssig wären. Sondern weil die wirtschaftliche Schwelle sinkt, kleine Spezialwerkzeuge zu erstellen.

Früher hätte man für ein eigenes internes SEO-Plugin vielleicht tagelang geplant, programmiert und getestet. Heute kann ein Agent einen großen Teil der Grundstruktur erzeugen. Der Mensch konzentriert sich auf Architektur, Kontrolle und fachliche Korrektheit.

Das ist für mich der eigentliche Paradigmenwechsel.

Mein Fazit

Ich will keine WordPress-Installation mehr, die aus zwanzig Plugins besteht, von denen ich jeweils nur fünf Prozent nutze.

• Ich will keine aufgeblähten Admin-Oberflächen.
• Ich will keine unnötigen Datenbanktabellen.
• Ich will keine jährlichen Plugin-Abos für Standardfunktionen.
• Ich will keine Performance-Probleme durch fremden Ballast.
• Ich will keine Sicherheitsrisiken durch Code, den Millionen andere Installationen ebenfalls einsetzen.

Ich will kleine, klare, eigene Werkzeuge.

• Maßgeschneidert.
• Wartbar.
• Erweiterbar.
• Reduziert auf das, was wirklich gebraucht wird.

WordPress bleibt. WooCommerce bleibt. Aber die Zeit, in der ich für jede kleine Funktion sofort ein Plugin installiere, ist für mich vorbei.

Plugins kaufen, ade.

Ab jetzt wird gebaut.

Anhang

Das ist meine Feature-Liste für SEO-Funktionalität

• SEO-Title für Posts, Pages, Products, Product Categories, Tags, Archives
• Meta Description mit manuellen Overrides und sinnvollen Fallbacks
• Canonical URLs für alle relevanten Seitentypen
• Robots-Meta: index/noindex, follow/nofollow, noarchive, nosnippet
• Open Graph: og:title, og:description, og:image, og:type, og:url
• Twitter Cards: summary_large_image, Title, Description, Image
• JSON-LD: WebSite, Organization, WebPage, Article, BreadcrumbList
• WooCommerce JSON-LD: Product, Offer, AggregateRating, Review
• E-Book JSON-LD-Erweiterung: Book, Autor, Verlag, ISBN, Sprache, Format, Reihe, Bandnummer
• Automatische Nutzung des Produktcovers als Social Image
• XML-Sitemap: Posts, Pages, Products, Product Categories, Images
• Ausschluss von noindex-Inhalten aus der Sitemap
• WooCommerce-Noindex-Regeln: Cart, Checkout, My Account, Order Received, interne Suche
• Filter-, Sortier- und Tracking-Parameter bereinigen oder kanonisieren
• Admin-Metabox für SEO-Daten bei Posts, Pages und Products
• Admin-Felder für Product Categories und Tags
• Globale Templates für Title und Description
• Template-Variablen: %title%, %sitename%, %product%, %author%, %price%, %isbn%, %format%
• Globale Publisher-/Organization-Daten: Name, Logo, URL, Social Profiles
• Breadcrumb-Unterstützung
• Keine Kompatibilitätslogik für fremde SEO-Plugins nötig
• Sauberes Escaping aller Outputs
• Keine doppelte Ausgabe von Meta-Tags oder JSON-LD
• WooCommerce nur laden, wenn aktiv
• Performance-schonende Implementierung ohne unnötige Queries
• Debug-Modus zur Prüfung der generierten SEO-Ausgaben