Vibecoding und WordPress

Bevor wir klären, ob das ein Problem für WordPress ist, lohnt es sich, den Begriff genau zu fassen, denn er verbreitet sich rasant und wird sehr unterschiedlich verstanden.

Ein Vorbehalt zur Zahl selbst gehört an diese Stelle. Verschiedene Datensätze erzählen verschiedene Geschichten. W3Techs zeigt den Rückgang und das Wachstum der Kategorie ohne erkennbares CMS, aber das ist eine Messung, die auf einer eigenen Erkennungsmethode beruht. Andere Quellen setzen die Akzente anders. An der Richtung ändert das nichts, denn die Richtung bestätigen mehrere unabhängige Beobachtungen, doch wer eine einzelne Zahl als Beweis vorträgt, vereinfacht. Uns interessiert hier nicht der exakte Prozentwert, sondern das Phänomen: Ein Teil des Marktes wendet sich tatsächlich von fertigen CMS ab, hin zu Seiten, die aus einem Prompt entstehen.

#Was Vibecoding ist

Vibecoding bedeutet, eine Anwendung zu bauen, indem man sie einem Sprachmodell beschreibt und akzeptiert, was es erzeugt, ohne den Code Zeile für Zeile zu lesen. Die Werkzeuge heißen Lovable, Bolt.new, v0 von Vercel, Replit Agent und Base44. Sie tippen “bau einen Shop mit Login und Zahlungen”, und Sie erhalten in wenigen Minuten ein funktionierendes Frontend, eine Datenbank (meist Supabase) und ein fertiges Deployment.

Für einen Prototyp, ein internes Werkzeug oder eine Kampagnen-Landingpage, die eine Woche leben soll, ist das wirklich gut. Wir bauen damit unsere eigenen Mockups, um einem Kunden die Richtung zu zeigen, bevor jemand Produktivcode schreibt. Das Problem beginnt erst dort, wo ein solches Ergebnis als Fundament eines Geschäfts in Produktion geht.

#Vibe Coding vs. agentisches Coding und die Tool-Welle 2026

Hinter “lass es die KI schreiben” stecken inzwischen zwei verschiedene Dinge, und die Unterscheidung ist wichtig, bevor Sie entscheiden, was Sie eigentlich vor sich haben. Prompt-to-App-Werkzeuge (Lovable, Bolt.new, v0, Replit Agent, Base44) erzeugen aus einem Satz eine ganze laufende Anwendung und verbergen den Code. Agentisches Coding ist die Welle, die 2026 durchgebrochen ist: Coding-Agenten, die in einem echten Repository arbeiten (Cursor, Claude Code sowie die neuen agentischen IDEs Google Antigravity und AWS Kiro), angetrieben von Spitzenmodellen wie Gemini 3, die Dateien bearbeiten, Tests laufen lassen und Pull Requests öffnen, so wie es ein Entwickler täte.

Die agentischen Werkzeuge liefern spürbar wartbareren Code als die Prompt-to-App-Generation, weil sie an einer echten Codebasis mit Versionskontrolle arbeiten statt an einer versiegelten Vorschau. Das ist eine echte Verbesserung, und deshalb steigt das Suchinteresse an ihnen. Genau hier schleicht sich aber das Missverständnis ein: bessere Codegenerierung ist nicht dasselbe wie Verantwortung. Eine agentische IDE legt trotzdem einen Supabase-Schlüssel ins Bundle, lässt trotzdem eine Admin-Route ohne Autorisierung, rendert trotzdem einen Katalog nur clientseitig, wenn niemand ihr etwas anderes sagt, denn das Modell optimiert auf “die Funktion läuft, wenn ich sie teste”, nicht auf “das übersteht echten Traffic, ein Audit und die EU-Vorgaben zur Barrierefreiheit”. Das Werkzeug ist eine Stufe höher geklettert. Der Abstand zwischen einer laufenden Demo und einem Produktivsystem, für das jemand geradesteht, hat sich nicht bewegt. Welches Werkzeug es auch gebaut hat, die Fragen im weiteren Verlauf dieses Textes bleiben dieselben.

#Wo vibecodete Seiten brechen

Das ist keine reflexhafte Verteidigung von WordPress. Es ist eine Liste dessen, was tatsächlich auftaucht, wenn jemand mit den Worten kommt “es lief, und jetzt läuft es nicht mehr”:

• Schlüssel im Bundle. Das Modell legt einen service_role-Schlüssel von Supabase in Code, der im Browser landet. Jeder mit geöffneten Entwicklertools liest ihn aus. Im Laufe von 2025 wurden über offengelegte Schlüssel aus Lovable-Apps und Supabase-Datenbanken ohne aktiviertes Row Level Security ganze Nutzertabellen offengelegt.
• Endpunkte ohne Autorisierung. Der Prompt “bau ein Admin-Panel” erzeugt ein Panel, aber die Route /api/admin prüft nie, wer anklopft. Es sieht funktionsfähig aus, weil der Autor sie eingeloggt auf seinem eigenen Konto testet.
• Keine Validierung, keine Limits. Ein Kontaktformular ohne Rate Limiting und ohne Sanitisierung wird zur offenen Tür für Spam-Versand und Injection-Versuche.
• Unsichtbar in der Suche. Inhalte, die erst clientseitig gerendert werden, ohne serverseitiges Rendering, sind für den Googlebot eine leere Seite. Ein Produktkatalog, der im HTML nicht existiert, gelangt nicht in den Index.
• Kein Wartungspfad. Keine Datenbankmigrationen, keine Backups, keine Versionierung, keine Pipeline. Die erste ernsthafte Änderung bedeutet Neuschreiben von Grund auf, weil niemand, auch nicht der Autor des Prompts, weiß, warum es so und nicht anders gebaut wurde.
• E-Mail-Zustellung dem Anbieter überlassen. Das generierte Formular verschickt Mails über einen kostenlosen Provider, ohne SPF, DKIM und DMARC. Bestellbestätigungen landen im Spam, und der Betreiber erfährt es von seinen Kunden, nicht aus dem Panel.
• Barrierefreiheit ignoriert. Kontrast, Fokus, Tastaturbedienung, Feldbeschriftungen. Das Modell erzeugt einen hübschen Bildschirm, keine zugängliche Oberfläche. In der EU ist das mit dem European Accessibility Act und dem deutschen Barrierefreiheitsstärkungsgesetz keine Kosmetik mehr, sondern ein rechtliches Risiko.
• Bindung an eine einzige Plattform. Der Code ist mit einem bestimmten Preview-Hosting und einer bestimmten Datenbank verschweißt. Der Ausstieg aus diesem Ökosystem, sobald die Rechnungen mit dem Traffic steigen, bedeutet eine Migration, auf die sich niemand vorbereitet hat.

Zwei konkrete Fälle aus den letzten Monaten. Ein Berliner Startup baute sein Kundenportal in Bolt.new und ging binnen einer Woche live. Zwei Wochen später zeigte sich, dass Nutzer die Daten fremder Konten sehen und bearbeiten konnten, weil der anon key von Supabase im Code lag und Row Level Security schlicht nie aktiviert war. Der zweite Fall: ein Onlineshop aus dem DACH-Raum stellte seinen “Shop” in v0 auf. Schnell, sauber, ansehnlich, und nach drei Monaten null Traffic aus Google, weil der gesamte Katalog erst im Browser gerendert wurde. Beide Seiten wirkten am Tag des Launches tadellos. Genau das ist die Falle des Vibecodings: Das Demo ist makellos, die Rechnung kommt später.

#Unsichtbar für Google und auch für KI

Darin liegt eine Ironie. Vibecoding ist ein Produkt der KI-Ära, und die Seiten, die es hervorbringt, sind ausgerechnet für KI oft unsichtbar. Erscheint der Inhalt erst, nachdem im Browser ein Skript gelaufen ist, dann sehen ihn weder der Googlebot noch die Antwortmaschinen, die AI Overviews und ähnliche Funktionen speisen. Ein Modell, das das Web zusammenfasst, liest HTML, es rendert keine Anwendung. Steht der Katalog nicht im HTML, steht er auch nicht in der Antwort.

Das ist ein doppelter Verlust. Die Seite verliert Traffic aus den klassischen Ergebnissen und fällt zugleich aus dem neuen Kanal, an dem immer öfter die Kaufreise beginnt. Sichtbarkeit in generativen Funktionen lässt sich messen, dazu schreiben wir an anderer Stelle, aber zuerst muss der Inhalt überhaupt in einem Code existieren, den die Maschine lesen kann. Eine rein clientseitig gebaute Seite überschreitet diese Schwelle nicht.

#Warum generierter Code schwer zu warten ist

Das Problem endet nicht bei einzelnen Lücken. Es geht um die Struktur. Das Modell optimiert darauf, dass der Bildschirm jetzt funktioniert, nicht darauf, dass jemand den Code in einem halben Jahr weiterentwickelt. In der Praxis bedeutet das ein paar wiederkehrende Muster: dieselbe Logik in fünf Stellen kopiert statt einmal ausgelagert, keine Aufteilung in Schichten, keine Tests, die warnen würden, dass eine Änderung etwas kaputtgemacht hat, und Abhängigkeiten, die nach Mode statt nach Stabilität gewählt sind.

Jede dieser Sachen für sich ist verkraftbar. Zusammen ergeben sie Code, in dem eine kleine Änderung etwas Entferntes zerstören kann, und niemand merkt es, bis der Kunde anruft. Wartung ist nicht das Anflanschen von Funktionen. Sie ist die Gewissheit, dass eine neue Funktion nichts umwirft. Diese Gewissheit gibt generierter Code nicht, weil niemand ihn mit Blick auf Veränderung entworfen hat.

#Wie Sie eine vibecodete Seite erkennen

Dafür braucht es keinen Zugang zum Code. Ein paar Signale reichen:

• Der Quelltext (Strg+U) zeigt einen fast leeren <body> und eine große JavaScript-Datei. Der Inhalt erscheint erst, nachdem das Skript geladen ist.
• JavaScript deaktivieren hinterlässt eine weiße Seite statt Text.
• In den Google-Ergebnissen hat die Seite außer der Startseite keine Unterseiten, obwohl der Browser viele zeigt.
• Keine Login-Seite unter der eigenen Domain, oder ein Panel, das ausschließlich auf einem externen Dienst ohne konfigurierte Rechte beruht.
• Die Antwort-Header deuten auf Preview-Hosting (Vercel, Netlify) ohne eigene Anwendungsschicht hin.

Keiner dieser Punkte ist für sich genommen ein Urteil. Zusammen ergeben sie das Bild einer Seite, die aus einem Prompt entstand und nie ein Fundament bekam.

#Vibecoding und WordPress in Produktion

Die Tabelle sagt nicht, dass Vibecoding schlecht ist. Sie sagt, wozu jedes Werkzeug passt. Um eine Idee an einem Wochenende zu prüfen, gewinnt Vibecoding ohne Diskussion. Für eine Seite, die in einem Jahr Umsatz bringen soll, gewinnt das Fundament.

#Was ein Audit einer KI-erstellten Seite wirklich prüft

Wenn eine solche Seite bei uns landet, fangen wir nicht mit dem Neuschreiben an. Wir fangen mit der Diagnose an, denn “es lief, und jetzt läuft es nicht mehr” hat meist mehrere Schichten. Die Reihenfolge ist immer ähnlich:

1. Sicherheit zuerst. Liegen im Code, der in den Browser geladen wird, Schlüssel, die dort nichts zu suchen haben. Hat die Datenbank aktive Zugriffsregeln. Prüfen die Endpunkte Berechtigungen. Das entscheidet, ob die Seite während der Reparatur überhaupt gefahrlos online bleiben kann.
2. Rendering und Index. Steht der Inhalt im HTML oder erst im JavaScript. Wie viele Unterseiten sieht Google tatsächlich. Gibt es Weiterleitungen, Canonicals und eine Sitemap. Das beantwortet, warum kein organischer Traffic kommt.
3. Daten und Kontinuität. Wo liegen die Daten, gibt es Kopien, lassen sie sich exportieren. Ohne das ist jede weitere Entscheidung riskant.
4. Entscheidung: retten oder neu schreiben. Erst jetzt. Manchmal genügt es, eine fehlende Schicht zu ergänzen. Manchmal ist es günstiger und sicherer, den Inhalt auf ein wartbares Fundament zu heben. Das Audit sagt, welcher Weg über das Jahr gerechnet günstiger ist, nicht nur in dieser Woche.

Das Wichtigste: Das ist keine Aufgabe für den nächsten Prompt. Ein Prompt liest fremden Code nicht mit dem Bewusstsein für die Folgen. Ein Entwickler schon.

#Warum das nicht das Ende von WordPress ist

Der Anteil sinkt, weil das untere Ende des Marktes, also die einfachen Seiten, die man früher aus Gewohnheit auf WordPress stellte, tatsächlich zur KI abwandert. Und das ist in Ordnung. Es war der am wenigsten profitable, am ehesten wegwerfbare Teil des Marktes. WordPress verliert die Arbeit, an der ohnehin niemand verdient hat.

Es bleibt der Rest: WooCommerce-Shops mit echtem Umsatz, mehrsprachige Seiten mit korrektem hreflang, DSGVO-gebundene Projekte und andere Compliance-Anforderungen, Arbeiten, die fünf Jahre laufen und ein Dutzend Updates überstehen sollen. Dorthin reicht Vibecoding nicht, denn dort geht es nicht darum, einen Bildschirm zu generieren. Es geht um ein Fundament: Sicherheit, in Core Web Vitals messbare Performance, Wartung und die Verantwortung dafür, was um zwei Uhr nachts im Black-Friday-Peak passiert.

WordPress gewinnt nicht, weil es in Mode ist. Es gewinnt, weil es zwei Jahrzehnte Ökosystem, einen berechenbaren Wartungspfad und einen Menschen hat, der weiß, warum etwas so und nicht anders gebaut wurde.

#Wann WordPress auch nicht die Antwort ist

Der Fairness halber: Nicht jedes Projekt ist WordPress. Wer eine Echtzeitanwendung baut, ein Produkt, das vollständig auf einer einzigen Programmierschnittstelle beruht, ein Panel mit schwerer Logik auf der Clientseite oder etwas, das seinem Wesen nach eine Anwendung und kein Inhaltsdienst ist, fährt mit anderen Werkzeugen besser. WordPress führt Inhalte, einen Shop, Integrationen und Sichtbarkeit in der Suche hervorragend. Es ist kein Universalhammer, und es als solchen zu behandeln endet ebenso schlecht wie ein Shop auf einem vibecodeten Prototyp.

Der Unterschied liegt darin, dass die Wahl zwischen WordPress, einer maßgeschneiderten Anwendung und noch etwas anderem eine Architekturentscheidung ist, die jemand bewusst trifft, im Wissen um die Folgen. Vibecoding trifft diese Entscheidung nicht. Es generiert das, was statistisch zum Prompt passt, und lässt die Folgen auf später liegen.

#Wer haftet, wenn etwas schiefgeht

Diese Frage fällt meist zu spät, weil sie erst fällt, wenn schon etwas schiefgegangen ist. Ein Prompt hat keinen Bereitschaftsdienst. Das Modell ruft nicht zurück, wenn der Shop am Samstagabend keine Zahlungen mehr annimmt. Die generierte Seite hat keinen technischen Verantwortlichen, der ihre Geschichte kennt und weiß, wo zu suchen ist.

Ein Fundament ist nicht nur Code. Es ist jemand, der die Verantwortung für die Folgen trägt. In einer Zeit, in der sich immer mehr generieren lässt, wird gerade Verantwortung zum knappen Gut. Es geht nicht darum, keine KI zu nutzen. Wir nutzen sie selbst täglich. Es geht darum, dass zwischen dem generierten Bildschirm und einem laufenden Geschäft ein Mensch steht, der den Unterschied versteht und für das haftet, was in Produktion geht.

#Wann Vibecoding Sinn ergibt und wann Sie einen Senior rufen sollten

Klar und einfach: für einen Prototyp, ein MVP, ein internes Werkzeug oder eine Kampagnen-Landingpage vibecoden Sie unbesorgt. Schnell, günstig, gut genug. Ein Shop, eine Unternehmensseite oder alles, was von etwas leben und in einem Jahr noch existieren soll, braucht ein Fundament, keinen generierten Bildschirm.

Bleibt die Frage nach den Kosten, die am häufigsten fällt: Wenn die KI das an einem Tag gebaut hat, müsste die Reparatur doch günstig sein. Nicht immer. Der Aufwand hängt davon ab, wie tief die Probleme reichen. Fehlt nur eine Sicherheitsschicht und ein sauberes Rendering, während Inhalt und Daten sich übernehmen lassen, ist die Arbeit begrenzt und berechenbar. Fehlt das Fundament vollständig, und die Seite hat bereits Kunden, Daten und Positionen in Google gesammelt, dann ist die Migration unter Erhalt all dessen ein größeres Projekt als ein Neubau auf sauberem Grund. Deshalb beginnt das Audit mit der Diagnose, und das Angebot ist immer individuell: Erst wenn geklärt ist, was zu retten ist, lässt sich seriös sagen, welcher Weg über das Jahr gerechnet günstiger ist.

Wenn Sie bereits eine KI-gebaute Seite haben und etwas anfängt zu bröckeln, von Datenlecks über fehlenden Traffic bis “das lässt sich nicht mehr erweitern”, ist das meist reparierbar, aber nicht mit dem nächsten Prompt. Wir retten KI-erstellte Websites: Sicherheitsaudit, SEO von Grund auf und die Entscheidung, was neu geschrieben und was gerettet wird. Das macht ein Entwickler, der den Code liest, den vorher niemand gelesen hat.