KI-generierte WordPress-Themes: Das Problem ist nicht der Code, sondern dass niemand zuständig ist

Einleitung

Promptest du noch oder entwickelst du schon? Die neue Generation an KI-Coding-Assistenten macht es verlockend einfach: Du beschreibst in zwei Sätzen, was du willst, und fünf Minuten später steht ein komplettes WordPress-Theme im Browser. Es sieht schick aus, es fühlt sich magisch an - und technisch ist es oft ein Anti-Pattern mit kaskadierenden Folgefehlern. Das Problem sind nicht die Funktionen von heute. Das Problem sind die Updates von morgen - besonders, wenn WordPress selbst mit KI-Funktionen im Core in eine neue Phase geht.

Was gerade als Vibe Coding durch die Entwickler-Szene geistert - also Software rein über natürliche Sprache zusammenprompten, ohne selbst eine Zeile zu verstehen - erzeugt in Rekordzeit Ergebnisse, die im ersten Moment beeindrucken. Doch wer für Kunden ein reines KI-Theme baut, liefert ein Produkt mit eingebauter technischer Schuld. Eine Wegwerf-Architektur. Und die Rechnung dafür kommt garantiert - nur eben erst dann, wenn der Hoster die alte PHP-Version abschaltet.

Als Geschäftsführer oder Agentur willst du eine Seite, die auch in zwei Jahren noch läuft, ohne dass alles in sich zusammenfällt. In diesem Artikel zeige ich dir mit harten Zahlen, warum reine KI-Themes gefährlich sind - und wie der Ansatz aussieht, mit dem Profis die Geschwindigkeit der KI nutzen, ohne ihre Haftung aufs Spiel zu setzen. Kleiner Spoiler: Diesen Artikel habe ich selbst faktengecheckt - inklusive der Stellen, an denen die Zahlen weniger eindeutig sind, als sie in den meisten Beiträgen zum Thema klingen. Wo ich extrapoliere, schreibe ich dazu, dass ich extrapoliere.

Das Phänomen: Schnell gebaut heißt nicht solide gebaut

Die harten Zahlen: Was die Studien wirklich sagen

Fangen wir bei der Sicherheit an. Der Veracode 2025 GenAI Code Security Report hat 80 kuratierte Coding-Aufgaben durch über 100 Sprachmodelle geschickt. Das Ergebnis ist ernüchternd: In 45% der Aufgaben wählte das Modell die unsichere Variante. Wichtig für die korrekte Einordnung - das heißt nicht "jedes zweite Snippet hat ein Loch", sondern: Wenn das Modell zwischen sicherer und unsicherer Lösung wählen konnte, entschied es sich in fast der Hälfte der Fälle falsch.

Noch unangenehmer wird es bei Cross-Site-Scripting. Bei den XSS-anfälligen Aufgaben (CWE-80) scheiterten die Modelle in 86% der Fälle - nur rund jede siebte Lösung war sauber. Also genau die Lücke, über die ein ungefiltertes Kontaktformular zum Einfallstor wird.

Sicherheit ist kein Zufallsprodukt

Modelle lernen aus Milliarden Zeilen offenem Code - und ein großer Teil davon ist selbst nicht sicher. Ohne explizite Sicherheitsvorgaben im Prompt überlässt du die Entscheidung dem Modell. Und das entscheidet sich in fast der Hälfte der Fälle falsch.

Wartbarkeit im Sinkflug

Die GitClear-Studie hat 211 Millionen geänderte Codezeilen zwischen 2020 und 2024 untersucht. Der Anteil refaktorierter, wiederverwendeter Zeilen fiel von 24,1% (2020) auf 9,5% (2024). 2024 war das erste Jahr überhaupt, in dem mehr kopiert als konsolidiert wurde - und die Zahl duplizierter Code-Blöcke hat sich in diesem Jahr verachtfacht. Und die Kurve ist seitdem nicht abgeflacht: In der Fortschreibung derselben Datenreihe liegt der Anteil refaktorierter Zeilen 2026 bei 3,8%, Copy/Paste bei 15,7%. Aus dem Gleichstand von 2024 ist ein Verhältnis von rund 5:1 zugunsten der Duplikation geworden.

Korrelation, kein Beweis

Fairerweise: GitClear vergleicht keine KI- gegen Nicht-KI-Commits, sondern misst eine Zeitreihe. Die Kurve fällt parallel zur Verbreitung der Assistenten - ein starkes Indiz, aber kein Kausalnachweis, und GitClear formuliert es selbst vorsichtig. Dazu kommt: Die Daten stammen aus Enterprise- und großen Open-Source-Repos, nicht aus dem WordPress-Themebau. Nimm die Zahl als Richtungssignal, nicht als Messwert für deinen Stack.

Der Mechanismus ist trotzdem plausibel

Ein Assistent macht das Einfügen eines neuen Blocks billiger als das Konsolidieren eines bestehenden. Wo Kopieren einen Tastendruck kostet und Refactoring zehn Minuten Nachdenken, verschiebt sich das Verhältnis von allein. Und jeder duplizierte Block ist eine Stelle mehr, die du bei einem zukünftigen Fix von Hand nachziehen musst.

Kurz gesagt: Der Output ist schnell, aber die Schulden wachsen mit. Und bei einer Kundenseite erbst am Ende du - oder dein Kunde - die Aufräumarbeit.

Und die WordPress-eigene Datenlage

Beide Studien oben haben denselben Schwachpunkt: Sie sind nicht WordPress. Die dritte schon. Patchstack nennt das Phänomen im State of WordPress Security in 2026 beim Namen: Vibe Coding - also LLM-generierter Plugin-Code, den der Ausliefernde selbst nicht auditieren kann - wird dort als direkter Treiber der Schwachstellen-Zunahme geführt. Die Zahlen dazu: 11.334 neue Schwachstellen im Ökosystem 2025, ein Plus von 42% gegenüber dem Vorjahr, wobei die hoch ausnutzbaren Lücken um 113% zulegten. Der gewichtete Median von der Veröffentlichung bis zur ersten Massenausnutzung: fünf Stunden. Und 46% der 2025 offengelegten Lücken hatten zum Zeitpunkt der Veröffentlichung überhaupt keinen Patch.

Wie die Laborquote von 45% in einem realen Projekt aussehen kann, zeigt ein Bericht aus der Agenturpraxis: In einem einzigen vibe-codeten Plugin fanden sich 100 verschiedene Sicherheitsprobleme. Eine Anekdote, kein Sample - aber eine, die man einmal gelesen haben sollte, bevor man ungeprüften Code an einen Kunden übergibt.

Das Update-Vakuum: Der Snapshot, der niemanden hat

Ein reines KI-Theme ist ein Foto von einem einzigen Moment. Es bekommt keine Updates, weil niemand welche baut. Sobald dein Hoster eine alte PHP-Version abschaltet und veraltete Funktionen wegfallen, fliegen dem Kunden entweder Deprecated-Warnungen oder gleich Fatal Errors um die Ohren. Und dann ist da niemand mit einem "Update"-Button, der das behebt.

"Kein Update" ist dabei noch der harmlose Fall. WordPress fragt für jedes installierte Theme den wordpress.org-Endpoint ab - und zwar anhand des Ordner-Slugs. Nennt deine KI das Theme portfolio, business oder blog, und existiert im offiziellen Verzeichnis ein Theme mit demselben Slug in höherer Versionsnummer, dann ist dein Custom-Theme genau einen Auto-Update-Lauf davon entfernt, durch ein völlig fremdes Theme überschrieben zu werden.

Das ist keine theoretische Sorge: WordPress hat in Version 6.1 den Theme-Header Update URI eingeführt - mit der ausdrücklichen Begründung, dass Drittanbieter-Themes nicht mehr versehentlich vom gleichnamigen Theme aus dem offiziellen Verzeichnis überschrieben werden sollen. Der Mechanismus existiert also, weil das Problem existiert.

Um es noch fairer zu sagen: Ein KI-Theme explodiert nicht automatisch beim Sprung auf PHP 8.4. Ob es bricht, hängt davon ab, wie sauber der Code ist. Und das Update-Vakuum ist streng genommen gar kein KI-spezifisches Problem - ein handgeschriebenes Agentur-Theme hat exakt dasselbe. Was fehlt, ist in beiden Fällen dasselbe: ein Wartungspfad. Niemand ist zuständig. Und "niemand ist zuständig" ist bei einer geschäftskritischen Website die gefährlichste aller Ausgangslagen. Spätestens bei sicherheitskritischen Updates wird das relevant, wie die 24-Stunden-Sperre für Plugins und Themes zeigt.

Das ist nicht nur meine Sicht. Patchstack schreibt im selben Report, die Angriffsfläche einer WordPress-Website werde künftig deutlich größer sein als Core, Plugins und Themes zusammen - und man brauche Sichtbarkeit auch in custom-codeten Code und in die verwendeten JavaScript- und PHP-Pakete. Genau dort liegt der blinde Fleck: Individuell erzeugter Code landet in keiner CVE-Datenbank. Bei einem verwundbaren Marktplatz-Plugin erfährst du es irgendwann. Bei einem vibe-codeten Custom-Theme nie.

Aus meinem Arbeitsalltag: Das Theme ohne Zuständigen ist der Normalfall

Wenn ich hier von einem Wartungsvakuum schreibe, ist das kein Gedankenspiel für die Zukunft. Es ist der Zustand, in dem ich Projekte regelmäßig übernehme - und in den seltensten Fällen hat eine KI dieses Theme gebaut. Meistens war es eine Agentur, vor Jahren, sauber gemeint und handgeschrieben.

Das Muster wiederholt sich so verlässlich, dass ich es mittlerweile schon am ersten Telefonat erkenne. Die Seite kommt nie zu mir, weil jemand vorausschauend über Wartbarkeit nachdenkt. Sie kommt, weil etwas bereits kaputt ist: Der Hoster hat die PHP-Abschaltung angekündigt, oder es ist nach einem Update schlicht nichts mehr da außer einer weißen Seite. Erst dann stellt sich die Frage, wer eigentlich zuständig ist - und die Antwort lautet regelmäßig: niemand. Die Agentur gibt es nicht mehr, oder es gibt sie noch, aber den Entwickler nicht, der das Theme gebaut hat. Der Vertrag lief aus, ohne dass jemand die Wartung nachgeschärft hätte.

Was ich dann vorfinde, ist meist dasselbe Bild. Kein Repository, kein Changelog, keine Dokumentation - die einzige existierende Fassung des Themes liegt auf dem Produktivserver. Eine functions.php, die über Jahre gewachsen ist, mit Snippets aus verschiedenen Quellen, ohne Kommentare, ohne erkennbare Herkunft. Und ein Dashboard, das behauptet, alles sei auf dem neuesten Stand.

Der unangenehmste Teil ist selten technisch. Es ist das Gespräch, in dem ich erklären muss, dass "maßgeschneidert" in diesem Fall eben auch "ungewartet" bedeutet hat - und dass das dem Kunden nie jemand gesagt hat, weil es beim Kauf niemand ausgesprochen hat. Niemand hat böswillig gehandelt. Es hat nur nie jemand die Zuständigkeit aufgeschrieben.

Bevor ich überhaupt reparieren kann, muss ich erst verstehen, was das Theme eigentlich alles tut. Welche Funktion hängt an welchem Hook, was passiert, wenn ich sie entferne, welcher Teil ist Deko und welcher trägt tragende Funktionalität. Das ist keine Reparatur, das ist Archäologie - und sie kostet ein Vielfaches dessen, was ein sauber gekapseltes Setup an laufender Wartung gekostet hätte.

Genau deshalb halte ich die KI-Diskussion an dieser Stelle für zu eng geführt. Das Vakuum ist älter als jeder Coding-Assistent. Was sich mit KI ändert, ist die Geschwindigkeit und die Menge: Es entstehen mehr solcher Themes, sie entstehen schneller, und sie entstehen zunehmend bei Leuten, die den Code nicht lesen können, den sie ausliefern. Das Problem ist nicht neu. Es skaliert nur gerade.

Das Kundenrisiko: Von der Black Box zur Haftungsfalle

Kunden sind es gewohnt, im Dashboard auf "Aktualisieren" zu klicken. Fällt das weg, entsteht ein Produkt, das sich für sie wie eine Black Box anfühlt - und für dich als Dienstleister wie ein offenes Haftungsrisiko.

Der wunde Punkt ist die Betriebssicherheit. Bricht die Seite nach einem PHP-Sicherheitsupdate zusammen, ist der Ärger vorprogrammiert - und wer dann zuständig ist, entscheidet nicht dein Gefühl, sondern dein Vertrag. Genau deshalb ist die Wartungsvereinbarung kein Zusatzverkauf, sondern der Teil, der die Verantwortung überhaupt erst zuordnet.

Und wenn durch eine unentdeckte Lücke ein echter Schaden entsteht - etwa Datenabfluss über ein ungefiltertes Formular - dann ist das kein Schönheitsfehler mehr, sondern ein Fall fürs Kleingedruckte. KI prüft weder DSGVO-Konformität noch validiert sie Eingaben zuverlässig; die technische Umsetzung bleibt an dir hängen.

Die saubere Lösung: KI als Co-Pilot, nicht als Architekt

Dieser Ansatz löst das Update-Dilemma komplett, weil er zwei Dinge strikt trennt: das Fundament, das jemand anderes pflegt, und deine Erweiterungen, für die nur du zuständig bist. Vier Regeln haben sich dabei in der Praxis durchgesetzt:

Der Unterschied im Code: Was die KI liefert vs. was du übergibst

Das gängigste Negativbeispiel für KI-Code ist eine ungefilterte Ausgabe aus $_GET. Nur: Das ist Lehrbuch-XSS von 2010 und kein Muster, das ein aktuelles Modell noch produziert. Der realistische Failure-Mode sieht harmloser aus und ist gefährlicher - er tut nämlich genau das, was du bestellt hast.

Beide folgenden Snippets liefern die Beiträge eines Autors über einen REST-Endpoint. Im Browser ist das Ergebnis identisch. Beispiel 1 ist ein offenes Scheunentor, Beispiel 2 nicht.

add_action( 'rest_api_init', function () {
    register_rest_route( 'meintheme/v1', '/autor-posts', [
        'methods'             => 'GET',
        'callback'            => 'autor_posts',
        'permission_callback' => '__return_true', // "sonst kommt 401"
    ] );
} );

function autor_posts( $request ) {
    global $wpdb;
    $id = $request->get_param( 'id' );
    return $wpdb->get_results(       // Parameter direkt in die Query
        "SELECT ID, post_title, post_status FROM {$wpdb->posts}
         WHERE post_author = {$id}"
    );
}

Drei Fehler in zwölf Zeilen, und keiner davon sieht im Browser nach einem Fehler aus:

permission_callback => '__return_true'

Nicht als Entscheidung gesetzt, sondern als Reflex gegen die 401-Meldung. Damit ist der Endpoint für jeden im Internet erreichbar - und alles, was dahinter passiert, ist die einzige verbliebene Schutzschicht. Wie wenig darauf Verlass ist, hat wp2shell im Juli 2026 gezeigt: Dort war die Berechtigungsprüfung im Core zwar vorhanden, wurde aber über eine Route-Confusion im Batch-Endpoint umgangen. Wer sie gleich ganz weglässt, braucht dafür keine Lücke. Mehr dazu in der Bedrohungslage 2026.

Parameter direkt in die SQL-Query interpoliert

SQL-Injection über einen öffentlich erreichbaren Endpoint. Kein Login nötig, kein gültiger Benutzername nötig.

Kein post_status-Filter

Der Endpoint gibt Entwürfe, private und passwortgeschützte Beiträge mit aus. Kein "Hack", einfach nur stiller Datenabfluss - und im Test fällt es nicht auf, weil der Endpoint ja tut, was er soll: Er liefert Beiträge.

/**
 * @generiert_mit KI-Assistent - 2026-07-17, manuell geprüft
 * @zweck        REST-Endpoint: veröffentlichte Beiträge eines Autors
 * @ablageort    Funktions-Plugin
 */
add_action( 'rest_api_init', function () {
    register_rest_route( 'da/v1', '/autor-posts', [
        'methods'  => WP_REST_Server::READABLE,
        'callback' => 'da_autor_posts',
        // Bewusst öffentlich: liefert ausschließlich publizierte Daten.
        'permission_callback' => '__return_true',
        'args' => [
            'id' => [
                'required'          => true,
                'sanitize_callback' => 'absint',
                'validate_callback' => static function ( $v ) {
                    return (bool) get_user_by( 'id', absint( $v ) );
                },
            ],
        ],
    ] );
} );

function da_autor_posts( WP_REST_Request $request ) {
    $posts = get_posts( [
        'author'         => $request->get_param( 'id' ),
        'post_status'    => 'publish',
        'posts_per_page' => 20,
    ] );

    return array_map( static function ( $p ) {
        return [
            'id'    => $p->ID,
            'title' => get_the_title( $p ),
            'link'  => get_permalink( $p ),
        ];
    }, $posts );
}

Der Punkt ist nicht "nie __return_true"

Öffentliche Endpoints sind völlig legitim. Der Punkt ist, dass es eine dokumentierte Entscheidung sein muss - und dass die Daten dahinter dann auch wirklich öffentlich sind. Der Kommentar darüber ist kein Deko-Element, er ist der Beleg, dass jemand nachgedacht hat.

Keine eigene Query, keine Injection

get_posts() mit post_status => 'publish' löst dasselbe Problem, ohne dass du Escaping selbst richtig machen musst. Die sichere Variante ist hier auch die kürzere.

Validierung am Schema, nicht im Handler

sanitize_callback und validate_callback fangen den Parameter ab, bevor deine Logik ihn je zu sehen bekommt. Das ist die WordPress-eigene Lösung - die KI kennt sie, schlägt sie aber ungefragt selten vor.

Wartbar durch Tagging

Der standardisierte Header macht das Snippet bei einem späteren PHP-Audit in Sekunden auffindbar. Suchen, prüfen, weiter.

Und das Gegenstück: sauber gekapselt statt ins Haupt-Theme gekippt

Der zweite Teil des Arguments ist keine Sicherheits-, sondern eine Wartbarkeitsfrage. Dieselbe Autoren-Box, aber am richtigen Ort und mit klaren Bedingungen:

/**
 * @generiert_mit KI-Assistent - 2026-07-17, manuell geprüft
 * @zweck        Autoren-Box unter Single-Posts
 * @ablageort    Child-Theme / functions.php
 */
function da_autoren_box( $content ) {
    // Nur im Beitrag, nur im Main-Loop - kein Content-Spam
    if ( ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) {
        return $content;
    }
    $autor = get_the_author_meta( 'display_name' );
    $bio   = get_the_author_meta( 'description' );

    $box  = '<aside class="autor-box">';
    $box .= '<strong>' . esc_html( $autor ) . '</strong>';
    $box .= '<p>' . wp_kses_post( $bio ) . '</p>';
    $box .= '</aside>';

    return $content . $box;
}
add_filter( 'the_content', 'da_autoren_box' );

Update-sicher

Weil diese Funktion im Child-Theme oder Plugin liegt, kann das Fundament jeden Monat aktualisiert werden. Die Autoren-Box bleibt unberührt.

Kontextgerecht escaped

esc_html() für den Namen, wp_kses_post() für die Biografie. Escaping ist in WordPress kontextabhängig - für Attribute gilt esc_attr(), für URLs esc_url(). Ein pauschales "escape halt irgendwas" reicht nicht.

Kein Content-Spam

Dank is_singular() und in_the_loop() weiß der Code exakt, wann er feuern darf - und taucht nicht versehentlich auf Archivseiten oder in Suchergebnissen auf.

Reines KI-Theme vs. Hybrid: Die Gegenüberstellung

Kein Einzelfall: Was die Community gerade diskutiert

Das Thema kocht nicht nur in Nischen-Foren hoch. Im offiziellen Core-Umfeld wird seit dem Beitrag "AI as a WordPress Fundamental" heftig darüber gestritten, wie tief KI ins System darf. Der Kommentarverlauf darunter ist lesenswert - allerdings dreht er sich um etwas anderes, als man aus der Ferne vermuten würde.

Die mit Abstand häufigste Forderung ist eine simple: ein vollständiger Aus-Schalter. Mehrere Entwickler und Agenturbetreiber verlangen, KI müsse per Default deaktiviert und auf Codeebene abschaltbar sein - teils aus ethischen Gründen, teils weil ihre Kunden aus Compliance-Gründen gar keine KI-Verarbeitung zulassen dürfen. Der Begriff AI Slop fällt dabei mehrfach. Gemeint ist damit allerdings minderwertiger generierter Inhalt, nicht generierter Code.

Projektseitig wird darauf durchaus eingegangen. Der Autor des Beitrags verweist auf eine offene Diskussion im Repository zu Kontroll- und Abschaltmechanismen und stellt klar, dass WordPress selbst keine Provider-Integration mitliefert - eine frische Installation nutzt also von sich aus keine KI. Zum Slop-Thema zieht er einen Vergleich, der hier gut passt: KI-Wildwuchs sei wie Datenbank-Ballast, der eine Seite in die Knie zwingt. Jedes System muss bewusst und maßvoll eingesetzt werden.

Was in diesem Thread ausdrücklich nicht diskutiert wird, ist die Frage, die diesen Artikel antreibt: Wer repariert in zwei Jahren die Seiten, die Laien per Prompt zusammengeklickt haben? Die Sorgen dort drehen sich um Kontrolle, Datenschutz, Kosten und Ressourcenverbrauch - nicht um die Wartbarkeit generierter Themes. Das ist keine Schwäche des Arguments, aber es wäre unredlich, es einer fremden Diskussion unterzuschieben. Es ist meine These, nicht die des Core-Teams.

Und weil ich sie als These kennzeichne, hier die Gegenrede gleich mit: Man kann mit gutem Grund argumentieren, dass sich das Problem selbst erledigt. Themes sind laut Patchstack nur für 9 % der Schwachstellen im Ökosystem verantwortlich, die Modelle werden besser, und ein Großteil der schnell geprompteten Seiten wird in zwei Jahren ohnehin nicht mehr existieren. Wer das anders sieht, hat gute Argumente.

Ich halte trotzdem an zwei Stellen dagegen. Erstens ist der Prozentsatz die freundlichste mögliche Darstellung: 9 % von 11.334 sind rund 1.020 Theme-Schwachstellen in einem einzigen Jahr, fast drei pro Tag. Der Anteil ist klein, weil das Plugin-Ökosystem riesig ist - nicht, weil Themes harmlos wären. Zweitens hat Veracode die Annahme "die Modelle werden besser" im Frühjahr 2026 selbst nachgemessen: Die Syntax-Trefferquote stieg seit 2023 von rund 50 % auf 95 %, die Sicherheits-Trefferquote blieb flach zwischen 45 % und 55 % - über alle Modellgenerationen hinweg und unabhängig von der Modellgröße. Die Modelle schreiben besser lauffähigen Code. Sicherer schreiben sie ihn nicht.

Was sich ohnehin nicht wegargumentieren lässt, sind die belegten Zahlen weiter oben - Fehlerdichte und Duplikation - und die Tatsache, dass ein Custom-Theme ohne Update-Pfad niemanden hat, der im Ernstfall zuständig ist.

Häufig gestellte Fragen

Fazit: KI nimmt dir die Schreibarbeit ab, nicht das Denken

KI-Coding-Tools sind ein brutal schneller Assistent - aber ein miserabler Architekt. Wer die komplette Struktur einer WordPress-Seite an einen Prompt abgibt, baut auf Sand: Der erste PHP-Sprung, das erste Core-Update, der erste Endpoint ohne echten permission_callback, und die Wegwerf-Architektur hat ihre Halbwertszeit überschritten. Und dann steht - je nach Vertrag - der Kunde oder du selbst in der Verantwortung.

Nutz die Geschwindigkeit der KI für maßgeschneiderte Snippets - aber setz sie auf ein unkaputtbares Fundament. Dann bleibt die Seite für den Kunden wartbar und für dich als Entwickler sicher. Wie du dein WordPress darüber hinaus konsequent verschlankst, zeigt der WordPress-Diät-Guide. Und warum das Fundament auch beim Ressourcenverbrauch entscheidet, liest du in der 512-MB-Falle.