Category: KI & Automation

Artikel ueber KI-Automatisierung, MCP und digitale Workflows

  • Stirbt der Webentwickler? Warum KI-generierte Websites deinem Unternehmen schaden

    Lovable, Bolt, v0. Jeder kann jetzt eine Website bauen. In Minuten. Mit einem Prompt.

    Stirbt der Webentwickler?

    Kurze Antwort: Nein. Lange Antwort: Er wird wichtiger als je zuvor.


    Lovable ist das WordPress des KI-Zeitalters

    Wer sich an 2005 erinnert: Jeder konnte plötzlich eine Website haben. WordPress, ein Theme, fertig. Das war revolutionär. Und es war der Beginn einer Flut von Seiten, die alle gleich aussahen. Zwanzig Jahre später gibt es mehr Webentwickler als je zuvor. Weil Unternehmen schnell gemerkt haben: Eine Website haben und eine Website haben die konvertiert, sind zwei verschiedene Dinge. Eine gute Website ist wie ein guter Vertriebsmitarbeiter: Sie arbeitet rund um die Uhr und verwandelt Besucher in Kunden.

    Lovable und Co. sind das WordPress des KI-Zeitalters. Der Enabler zur Mittelmäßigkeit.

    Schnell? Ja. Beeindruckend? Auf den ersten Blick. Individuell? Nicht im Ansatz.

    Die Seiten, die aus diesen Tools kommen, funktionieren technisch. Sie laden. Sie haben Buttons. Sie haben eine Startseite. Aber sie haben keinen Charakter. Keine Markenidentität. Keinen Grund, warum ein Besucher gerade hier bleiben sollte und nicht bei den hundert anderen Seiten, die mit dem gleichen Prompt gebaut wurden.

    Das ist AI-Slop. Technisch funktional, visuell austauschbar, strategisch wertlos.

    Ein Entwickler hat es auf den Punkt gebracht: “Three different platforms, three different prompts, three different goals. And somehow, I got the exact same website. Same skeleton. Different makeup. No soul.” Die Seiten scoren auf einer Generik-Skala zwischen 60 und 85 von 100. Google hat begonnen, solche Seiten im Ranking abzustrafen.

    Und hier wird es branchenrelevant: Mehr generische Websites bedeuten mehr Rauschen im Markt. Noise statt Signal. Wenn jeder in Minuten eine Seite aufsetzen kann, verliert die einzelne Seite an Gewicht. Nicht weil sie schlecht ist. Sondern weil sie nicht anders ist.

    Relevanz schlägt Sichtbarkeit. Immer.

    Phil von Signo

    Phil von Signo
    KI & Webdesign bei Signo Media · April 2026

    Warum “selber machen” für Unternehmer nicht funktioniert

    Der Pitch dieser Tools klingt verlockend: Du brauchst keinen Entwickler mehr. Bau deine Website selbst. Spar dir das Geld.

    Die Realität sieht anders aus.

    Unternehmer sind keine Entwickler. Sie führen ein Unternehmen. Sie haben weder die Zeit noch das Wissen, sich mit Lovable auseinanderzusetzen. Und nein, es ist nicht mit einem Prompt getan. Wer glaubt, “Erstelle mir eine professionelle Website für mein Unternehmen” reiche aus, der hat noch nie ein Website-Projekt verantwortet.

    Eine Website, die konvertiert, braucht Positionierung. Storytelling. Nutzerführung. Suchmaschinenoptimierung. Jede einzelne dieser Disziplinen erfordert Erfahrung. Nicht ein Tool.

    Was passiert stattdessen? Der Unternehmer verbringt ein Wochenende mit Lovable. Die Seite sieht “ganz okay” aus. Er geht live. Und dann: nichts. Kein Traffic. Keine Anfragen. Die Seite existiert, aber sie arbeitet nicht. Weil eine Website ohne Strategie ein digitales Schaufenster ist, das niemand findet.

    Wer mit Lovable seine eigene Website baut, spart kurzfristig Geld und verliert langfristig Relevanz. Das ist kein guter Deal.


    Unser Experiment: KI als Werkzeug, nicht als Ersatz

    Wir sind keine Lovable-Gegner. Wir sind Praktiker. Und als Praktiker haben wir getestet, was KI im Webdesign wirklich kann.

    Im ersten Teil dieser Serie haben wir gezeigt, was passiert, wenn man KI nicht als Ersatz einsetzt, sondern als Verstärker: ein KI-Agent unsere eigene Agentur-Website geklont hat. Drei Phasen, sieben gescheiterte Versuche, am Ende 93 % visueller Match. Das war ein Durchbruch für unser Team. Nicht weil die KI alles alleine gemacht hat. Sondern weil wir zum ersten Mal erlebt haben, wie KI als Werkzeug in den Händen erfahrener Menschen zu einem Ergebnis führt, das manuell Wochen gebraucht hätte.

    Website-Erstellung ist bei uns genau das, was wir einen Gold-Prozess nennen: Er kostet viel Geld und hindert uns daran, noch mehr Geld zu verdienen. Genau dort haben wir KI als Werkzeug eingesetzt. Wir nutzen dafür eine Methodik, die solche gewinnbringenden Prozesse systematisch identifiziert.

    Der entscheidende Unterschied zu Lovable: Wir haben die Richtung vorgegeben. Die KI hat ausgeführt.

    Kein blinder Prompt. Sondern eine klare Strategie, ein definierter Prozess und menschliche Qualitätskontrolle bei jedem Schritt. Das Ergebnis: ein Website-Klon, der nicht nach Template aussieht. Sondern nach Signo.

    Handwerk plus KI ist mehr als KI allein. Jedes Mal.


    Warum KI allein Slop produziert: Drei Ebenen

    Die Frage ist nicht, ob KI Websites bauen kann. Das kann sie. Die Frage ist, warum die Ergebnisse so oft generisch ausfallen. Die Antwort liegt in drei Ebenen, die zusammenspielen müssen.

    Identität: Wer ist dieser KI-Mitarbeiter?

    Jeder KI-Agent braucht eine klare Rolle. Was ist sein Fachgebiet? Wie kommuniziert er? Worauf achtet er? Ohne diese Identität produziert er beliebigen Output. Technisch korrekt, aber ohne Richtung. Wie ein Freelancer ohne Briefing.

    Prozesswissen: Wie geht er vor?

    Ein guter Agent folgt einem erprobten Workflow. Analyse, dann Konzept, dann Umsetzung, dann Qualitätskontrolle. Ohne dieses Prozesswissen würfelt er bei jeder Aufgabe einen neuen Weg zusammen. Manchmal trifft er. Meistens nicht.

    Kapazität: Was kann er tun?

    Welche Systeme kann der Agent bedienen? Auf welche Daten hat er Zugriff? Welche Werkzeuge stehen ihm zur Verfügung? Das ist sein Atelier. Ohne Atelier bleibt er ein kluger Kopf ohne Hände.

    Die DNA bestimmt, wer er ist. Das Briefing bestimmt, wie er vorgeht. Das Atelier bestimmt, was möglich ist.

    Und hier liegt das Problem mit Lovable: Es hat Kapazität. Es kann Websites bauen. Aber es hat keine Identität (es kennt dein Unternehmen nicht) und kein Prozesswissen (es folgt keinem erprobten Workflow). Das Ergebnis ist vorhersehbar: Output ohne Tiefe. Slop.

    Ein Handwerker mit KI hat alle drei Ebenen. Die Identität kommt aus seiner Erfahrung. Das Prozesswissen aus Jahren an Projekten. Die Kapazität aus den Werkzeugen, die er einsetzt. Drei Ebenen, die zusammen Qualität ergeben.



    Drei Ebenen eines KI-Mitarbeiters: Mit vs. Ohne Führung

    Phil von Signo

    Phil von Signo
    KI & Webdesign bei Signo Media · April 2026

    Der Webentwickler stirbt nicht. Er bekommt ein Team.

    Hybride Teams. Mensch plus KI. Das klingt nach Buzzword, ist aber die präziseste Beschreibung dessen, was gerade passiert.

    In der Praxis sieht das so aus: Ein Webdesigner führt ein Team aus KI-Agenten. Ein Agent analysiert die bestehende Website und den Wettbewerb. Ein zweiter übernimmt die Content-Erstellung auf Basis echter Daten. Ein dritter baut. Ein vierter prüft die Qualität, vergleicht Screenshots, testet auf verschiedenen Geräten.

    Der Mensch führt. Die Agenten arbeiten.



    Hybride Teams im Agentic Webdesign

    Das ist kein Zukunftsszenario. Wir arbeiten heute so. Und der Unterschied zu “ich bau mir das mit Lovable” ist fundamental.

    Lovable gibt dir einen Button. Ein hybrides Team gibt dir ein Atelier. Wir nutzen bei WordPress allein 58 verschiedene Fähigkeiten, die ein KI-Agent einsetzen kann. Seiten erstellen, Medien verwalten, Einstellungen ändern, Layouts bauen, responsives Verhalten testen. Nicht ein Prompt, der alles auf einmal soll. Sondern spezialisierte Agenten, die ihren Job kennen.



    Agentic Workflow: Von der Analyse zur fertigen Website

    Der entscheidende Punkt: Die Agenten kommunizieren untereinander. Der Analyse-Agent füttert den Build-Agent mit Daten. Der QA-Agent dokumentiert, was der Build-Agent produziert hat. Kein isoliertes Tool. Ein System.


    AI Manager: Das Berufsbild existiert bereits

    Wer führt solche hybriden Teams? Nicht der klassische Projektmanager. Nicht der reine Entwickler. Jemand Neues.

    437 offene “AI Manager”-Stellen auf StepStone Deutschland. Die IHK Karlsruhe bietet eine Zertifizierung zum “Technischen KI-Manager (IHK)” an. 60 % der Unternehmen haben laut einer AWS-Studie bereits einen Chief AI Officer, weitere 26 % planen einen bis Ende 2026. 92 % rekrutieren aktiv KI-Kompetenz. Douglas, Sopra Steria und die ZEIT Verlagsgruppe suchen aktiv.

    Das ist keine Nische mehr. Das ist ein Arbeitsmarkt.

    Und was hat das mit Webdesign zu tun? Alles. Der Webdesigner, der morgen erfolgreich ist, kann nicht nur gestalten. Er kann hybride Teams führen. Er versteht, welche Aufgaben ein Agent übernehmen kann, wo menschliches Urteil gebraucht wird und wie die Übergaben zwischen Mensch und Maschine funktionieren.

    Der MIT GenAI Divide Report zeigt: 95 % aller Enterprise-KI-Projekte scheitern. Nicht an der Technik. An der Führung. Weder KI noch Tools wie Lovable werden Webentwickler in naher Zukunft wegrationalisieren. Aber sie werden die Anforderungen verschieben. Von reiner Ausführung hin zu Führung, Strategie und Qualitätssicherung.

    Eine Website ist keine teure Visitenkarte. Sie ist dein bester Vertriebsmitarbeiter. Sie arbeitet rund um die Uhr, braucht keinen Urlaub und verwandelt Besucher in Kunden. Aber nur, wenn jemand sie richtig aufgestellt hat.

    Wer das versteht, hat einen Vorsprung. Wer es ignoriert, baut in fünf Jahren Lovable-Seiten für 200 Euro.


    Was das für unsere Kunden bedeutet

    Wir bei Signo liefern keine Lovable-Seiten. Das ist keine Arroganz, das ist Qualitätsanspruch.

    Wir machen hochwertige Designs, die auf den Kunden zugeschnitten sind. Nicht irgendein 0815-AI-Slop. Jede Website, die unser Haus verlässt, hat eine Positionierung, eine visuelle Identität und eine Struktur, die auf Konversion ausgelegt ist.

    Gleichzeitig nutzen wir KI intensiv. Aber als Werkzeug in den Händen erfahrener Menschen. KI-unterstützt, nicht KI-generiert. Der Unterschied klingt subtil, ist in der Praxis aber enorm.

    Eine KI-generierte Website existiert. Eine KI-unterstützte Website konvertiert.

    Aus Business-Sicht schadet AI-Slop sogar. Wenn ein potenzieller Kunde auf eine generische Seite kommt, die aussieht wie tausend andere, ist der erste Eindruck: austauschbar. Und ein austauschbarer erster Eindruck kann die Reputation beschädigen. Bevor überhaupt ein Gespräch stattfindet.

    Was wir stattdessen bieten:

    • Individuelles Design. Keine Templates. Kein “das sieht man gerade überall”. Sondern Gestaltung, die zum Unternehmen passt.
    • Strategische Grundlage. Bevor wir designen, klären wir Positionierung, Zielgruppe und Nutzererwartung. Das kann kein Prompt ersetzen.
    • KI-unterstützter Prozess. Schnellere Umsetzung, datengetriebene Entscheidungen, automatisierte Qualitätsprüfung. Ohne die Kontrolle aus der Hand zu geben.
    • Messbare Ergebnisse. Eine Website ist kein Selbstzweck. Sie soll Anfragen generieren, Vertrauen aufbauen und verkaufen.

    Strategy First, AI Second

    Der Webentwickler stirbt nicht. Er entwickelt sich weiter.

    Die Tools werden besser. Lovable Version 5 wird besser sein als Version 1. Bolt wird neue Features bekommen. Die Einstiegshürde für “irgendeine Website” wird weiter sinken. Und genau deshalb steigt der Wert von Handwerk.

    Wenn jeder eine Website haben kann, wird die Frage nicht mehr “Hast du eine Website?”, sondern “Funktioniert deine Website?”. Und für die Antwort braucht es Menschen, die wissen, was sie tun. Menschen, die KI als Verstärker einsetzen, nicht als Ersatz.

    Bewusstsein kommt vor Transformation. Strategie kommt vor Technologie. Handwerk kommt vor Automatisierung.

    Eine Website ist keine teure Visitenkarte. Sie ist dein bester Vertriebsmitarbeiter. Sie arbeitet rund um die Uhr, braucht keinen Urlaub und verwandelt Besucher in Kunden. Aber nur, wenn jemand sie richtig aufgestellt hat.

    Wer das versteht, hat einen Vorsprung.


    Dieser Artikel ist Teil 2 einer Serie über KI bei Signo Media. Teil 1 dokumentiert das technische Experiment: Wie ein KI-Agent unsere Website geklont hat. Fragen zu KI-gestütztem Webdesign oder hybriden Teams? Kontaktiert uns.

    Verwandte Themen: AI-Slop, Lovable, KI im Webdesign, hybride Teams, Agentic Webdesign, AI Manager, Website-Qualität

  • WordPress MCP: Wie ein KI-Agent unsere Website geklont hat

    Was passiert, wenn man einem KI-Agenten sagt: “Klon mir diese Website”? Nicht als Gedankenexperiment. Sondern wirklich. Mit einer echten Agentur-Website, 12 Sektionen, Custom Fonts und einem Elementor-Layout, das sich über Jahre organisch entwickelt hat.

    Das Ergebnis: drei Phasen, sieben gescheiterte Versuche, ein Durchbruch per SSH und am Ende 93 % visueller Match zwischen Original und Klon. Ganz ohne manuelles WordPress-Backend.


    Was ist MCP und warum ändert es alles?

    MCP steht für Model Context Protocol. Kurz gesagt: ein standardisiertes Interface, über das KI-Agenten mit externen Systemen kommunizieren. Statt dass ein Agent nur Text generiert, kann er über MCP konkrete Aktionen ausführen. Dateien hochladen. Datenbanken abfragen. WordPress-Seiten erstellen.



    Schematische Darstellung des Model Context Protocol

    Für WordPress bedeutet das: Ein KI-Agent wie Claude Code kann über ein MCP-Plugin direkt mit einer WordPress-Instanz sprechen. Seiten anlegen, Einstellungen ändern, Medien hochladen. Alles programmatisch, alles über die REST API.

    Das ist kein theoretisches Konzept. WordPress AI ist bereits in der offiziellen Roadmap verankert. Die Abilities API (eingeführt mit WordPress 6.9) macht Funktionen für KI-Assistenten standardisiert auffindbar. Und das Model Context Protocol ist der Kommunikationskanal dafür.

    Der Unterschied zu klassischen WordPress-Plugins: MCP-Tools agieren nicht als isolierte Features. Sie sind Schnittstellen. Der KI-Agent entscheidet, wann er welches Tool aufruft, in welcher Reihenfolge und mit welchen Parametern. Das macht ihn zu einem digitalen Kollegen, der selbstständig Aufgaben abarbeitet, nicht zu einem Button, den jemand klicken muss.


    Das Setup: WordPress MCP in 10 Minuten

    Die technische Einrichtung ist überraschend simpel. Drei Schritte.



    Setup-Diagramm: WordPress MCP Ultimate konfigurieren

    Schritt 1: Plugin installieren

    Das WP MCP Ultimate Plugin auf der Ziel-WordPress-Instanz installieren und aktivieren. Es stellt eine MCP-kompatible REST API bereit, über die KI-Agenten auf WordPress-Funktionen zugreifen können.

    Schritt 2: API-Key generieren

    Im WordPress-Dashboard unter WP MCP Ultimate einen API-Key erstellen. Dieser Key authentifiziert den KI-Agenten gegenüber der WordPress-Instanz.

    Schritt 3: Claude Code konfigurieren

    Den MCP-Server in der Claude Code Konfiguration hinterlegen:

    claude mcp add wp-mcp-ultimate \
    --transport http \
    https://deine-domain.de/index.php?rest_route=/mcp/wp-mcp-ultimate \
    --header "Authorization: Basic WP_MCP_ULTIMATE_API_KEY"

    Danach kann Claude Code WordPress-Seiten erstellen, Einstellungen ändern, Medien hochladen und Inhalte bearbeiten. Alles per Konversation.


    Die Aufgabe: signo-media.de klonen

    Unser Ziel: die komplette Signo Media Website (signo-media.de) auf eine frische WordPress-Instanz übertragen. Nur mit KI. Ohne manuellen Login ins WordPress-Backend.

    Die Ausgangslage:

    • Original: Elementor-basierte Agentur-Website mit 12+ Sektionen, Custom Fonts (Poppins, Titillium Web), animierten Countern, Flip-Cards, Team-Karussell und einem über Jahre gewachsenen Layout
    • Ziel: Frische WordPress 6.9.4 Installation mit Twenty Twenty-Five Theme, Elementor Free und dem WP MCP Ultimate Plugin. Sonst nichts. Eine leere Leinwand.

    Der KI-Agent startete mit einer systematischen Analyse: Screenshots in zwei Viewports (Desktop 1280px, Mobile 375px), Farbpalette extrahiert (#00437A Dunkelblau, #88B79D Sage, #E6EFF9 Hellblau, #0DB1CD Teal), Fonts identifiziert, 27 Assets heruntergeladen (Logo, Icons, Team-Fotos, Schriftdateien). Alles dokumentiert in einer CI-Datei, bevor auch nur eine Zeile Code geschrieben wurde.

    Bewusstsein kommt vor Transformation. Auch für KI-Agenten.

    Die Farbwelt von signo-media.de

    Dunkelblau
    #00437A
    Headlines, Buttons, Footer

    Sage
    #88B79D
    Akzente, Service-Cards

    Hellblau
    #E6EFF9
    Sektions-Hintergruende

    Teal
    #0DB1CD
    Akzentfarbe, Links, CTAs




    Der Weg von 40% auf 93% in fuenf Phasen

    1
    Phase 1 von 3

    Phase 1: Der naive Ansatz (Ergebnis: ~40 % Match)

    Der erste Versuch klang logisch: HTML und CSS schreiben, per WordPress REST API als Seiteninhalt speichern. Der Agent baute alle 12 Sektionen nach, setzte Farben, Fonts, Abstände.

    Dann kam WordPress dazwischen.

    WordPress kämpft zurück

    Problem 1: Der Theme-Wrapper. Twenty Twenty-Five rendert seinen eigenen Header und Footer um jeden Seiteninhalt. Das Ergebnis: doppelter Header, doppelter Footer. Die Lösung: das elementor_canvas Template verwenden, das nur den reinen Content rendert.

    Problem 2: CSS Custom Properties werden gestripped. WordPress’ Content Sanitizer entfernt var() Funktionen aus gespeichertem HTML. Jedes var(--signo-primary) verschwand stillschweigend.

    / Das hier speichert WordPress nicht: /
    color: var(--signo-primary);
    
    / Stattdessen müssen Hex-Werte rein: /
    color: #00437A;

    Problem 3: Inline Styles werden entfernt. Auch style="background-color: #00437A" auf HTML-Elementen löscht der Sanitizer. Alles muss über CSS-Klassen laufen.

    Problem 4: Footer-Styling ignoriert. CSS auf dem <footer>-Tag wurde vom Theme überschrieben. Erst ein <div> mit eigener Klasse funktionierte.

    Sieben Versionen (v1 bis v7), jede mit einem neuen Fix für ein neues Problem. Am Ende standen alle 12 Sektionen. Die Farben stimmten. Aber die Proportionen, die Abstände, das Grid-System, die responsive Breakpoints: alles daneben. Der visuelle Gesamteindruck lag bei bestenfalls 40 %.



    Screenshot: Version 7, manueller HTML-Ansatz

    Die Erkenntnis war unbequem, aber klar: eine Elementor-Seite per Hand-HTML nachzubauen ist ein Kampf gegen Windmühlen. Elementor generiert hochkomplexes, verschachteltes HTML mit hunderten CSS-Klassen, die praezise zusammenspielen müssen. Manuelles Nachbauen kann das nicht leisten.


    2
    Phase 2 von 3

    Phase 2: Der Quellcode-Trick (Ergebnis: ~80 % Match)

    Wenn Nachbauen nicht funktioniert, dann kopieren wir eben den Quellcode. Nicht das Design. Den tatsaechlichen, gerenderten Output.

    Die Extraction

    Ein Browser-Agent navigierte zu signo-media.de und extrahierte den kompletten DOM:

    Komponente Größe
    Body HTML 375 KB
    Inline CSS (44 Style-Tags) 160 KB
    Externe CSS-Bundles 1,35 MB
    Bereinigter Content 225 KB

    225 KB bereinigter HTML-Content. Alle Elementor-Klassen intakt. Alle CSS-Referenzen funktionsfähig. Ein Standalone-Test im lokalen Browser bestätigte: die extrahierte Seite sah nahezu identisch zum Original aus.

    Das Größenproblem

    Jetzt musste dieser 225 KB Block in die WordPress-Datenbank. Aber die WP MCP API hat harte Limits bei der Content-Größe pro Request. Drei Versuche scheiterten: Base64-kodiertes Plugin (zu gross), Chunking über die Options API (einzelne Chunks zu gross), Plugin mit URL-Fetch (Server konnte localhost nicht erreichen).

    Der Durchbruch: SSH

    ssh root@jan.philflow.me

    Zwei Woerter, die das gesamte Projekt wendeten.

    Per SSH konnten wir den Content direkt auf den Server kopieren und ein PHP-Script ausführen, das ihn ohne Umweg in die Datenbank schreibt:

    <?php
    require_once('/var/www/html/wp-load.php');
    global $wpdb;
    
    $content = file_get_contents('/tmp/wp-page-content.html');
    $wpdb->update(
        $wpdb->posts,
        array('post_content' => $content),
        array('ID' => 24)
    );

    Warum das funktioniert: Die direkte DB-Injection umgeht den WordPress Content Sanitizer komplett. Alle HTML-Attribute, inline Styles, CSS-Klassen, verschachtelten Strukturen bleiben erhalten. Exakt wie Elementor sie generiert hat.

    Das Ergebnis



    Screenshot: Version 8, nach Quellcode-Injection

    Von ~40 % auf ~80 %. In einem Schritt. Das Elementor-Grid-System funktionierte. Die CSS-Klassen griffen. Responsive Breakpoints waren da. Die Seite sah auf Desktop und Mobile fast identisch zum Original aus.

    Der Unterschied zwischen “sieht so ähnlich aus” und “ist kaum zu unterscheiden”.


    3
    Phase 3 von 3

    Phase 3: Die letzten Prozente (Ergebnis: ~93 % Match)

    90 % klingt gut. Aber auf einer Agentur-Website fallen fehlende Bilder sofort auf.

    42 von 62 Bildern fehlten

    Der HTML-Code referenzierte noch Bild-URLs vom Original-Server. signo-media.de blockiert Hotlinking: der Server prueft den Referer-Header und liefert für fremde Domains ein 403.

    Die Lösung: alle Bild-URLs im Content umschreiben und die Dateien auf den neuen Server spiegeln.

    signo-media.de/wp-content/uploads/2022/05/bild.webp
    → jan.philflow.me/wp-content/uploads/signo/bild.webp

    125 Dateien kopiert. 64 URL-Ersetzungen im HTML. Drei Runden für Unterverzeichnisse und Pfad-Konsolidierung.

    Danach zeigten HTTP-Checks: 82 von 85 Dateien auf der Festplatte, alle mit Status 200. Alles sollte funktionieren.

    Das Lazy-Loading-Desaster

    Die Bilder luden trotzdem nicht. Im Browser unsichtbar. naturalHeight = 0.

    Der Grund: WordPress fuegt zur Render-Zeit loading="lazy" zu Bild-Tags hinzu. Das passiert nicht im gespeicherten HTML, sondern während des PHP-Renderings. Das Original nutzt WP Rocket, das den JavaScript-Handler für Lazy Loading mitliefert. Auf unserer frischen Instanz gab es kein WP Rocket. Die Bilder bekamen loading="lazy", aber kein Script triggerte jemals das eigentliche Laden.

    Besonders tückisch: der HTML-Source sah korrekt aus. Die HTTP-Requests gaben 200 zurück. Erst die Prüfung von naturalHeight im Browser entlarvte das Problem.

    Der Fix: ein Must-Use Plugin

    <?php
    // /wp-content/mu-plugins/disable-lazy-load.php
    add_filter("wp_lazy_loading_enabled", "__return_false");
    
    add_action("template_redirect", function() {
        ob_start(function($html) {
            $html = preg_replace('/ loading=["\']lazy["\']/i', '', $html);
            return $html;
        });
    });

    Ein mu-Plugin (Must-Use Plugin) wird von WordPress immer geladen und kann nicht deaktiviert werden. Nach der Installation: 60 von 62 Bildern sichtbar. Die verbleibenden zwei waren CSS-Animationen, die auch im Original nur unter bestimmten Bedingungen erscheinen.


    Ergebnisse: Vorher vs. Nachher

    Phase Ansatz Visueller Match
    Original signo-media.de (Referenz) 100 %
    Phase 1, v7 Manueller HTML-Ansatz ~40 %
    Phase 2, v8 Quellcode-Injection ~80 %
    Phase 3, final Bilder + Lazy-Load Fix ~93 %

    v7 — 40%

    Phase 1: Manueller HTML-Ansatz


    Final — 93%

    Phase 3: Nach Bilder + Lazy-Load Fix

    Die fehlenden 7 % bestehen aus: zwei CSS-Animationen (Hover-States, die im Klon nicht getriggert werden), minimale Font-Rendering-Unterschiede durch fehlende Schrift-Lizenzen, und ein WP Rocket spezifisches Preloading das wir bewusst nicht repliziert haben.


    Was wir gelernt haben

    1. Die WordPress REST API ist nicht für komplexen HTML gemacht

    WordPress’ Content Sanitizer schuetzt vor XSS-Angriffen. Das ist richtig und wichtig. Aber für das Klonen von Elementor-Output ist die REST API unbrauchbar. CSS var() Funktionen, inline Styles, bestimmte HTML-Attribute: alles wird gestripped.

    Direkte DB-Injection war der einzige Weg.

    2. Quellcode kopieren schlägt manuelles Nachbauen

    Der Qualitätssprung von 40 % auf 80 % spricht für sich. Elementor-Layouts bestehen aus tausenden ineinander greifenden CSS-Klassen. Manuell nachbauen kann dieses Zusammenspiel nicht reproduzieren. Den gerenderten Output direkt zu extrahieren und einzufuegen: schon.

    3. loading="lazy" ohne WP Rocket = unsichtbare Bilder

    WordPress fuegt loading="lazy" zur Render-Zeit hinzu. Wenn das zugehörige JavaScript fehlt, werden Bilder nie geladen. Der HTML-Source sieht korrekt aus. HTTP gibt 200 zurück. Nur naturalHeight = 0 im Browser verrät das Problem.

    Achtung bei WordPress-Migrationen

    Wer WordPress-Seiten klont oder migriert: immer prüfen, ob Lazy Loading ohne das urspruengliche Performance-Plugin noch funktioniert.

    4. SSH-Zugang war der Game Changer

    Ohne SSH wäre das Projekt gescheitert. Die WP MCP API hat harte Limits bei der Content-Größe. SSH ermöglichte direkte Datei-Transfers, direkte DB-Manipulation, mu-Plugin-Installation und Bulk-Download von Assets.

    Für jeden, der mit WordPress MCP arbeitet: ein API-Key allein reicht für einfache Aufgaben. Für komplexe Projekte braucht der KI-Agent auch Zugang zur Server-Infrastruktur.


    Fazit: MCP als Paradigmenwechsel für WordPress

    Dieses Experiment war kein Produktiv-Workflow. Es war ein Stresstest. Wie weit kann ein KI-Agent gehen, wenn man ihm eine komplexe Aufgabe gibt und die richtigen Schnittstellen zur Verfuegung stellt?

    Die Antwort: weiter als erwartet. Aber nicht so weit, wie mancher Hype suggeriert.

    Was funktioniert: Analyse, Asset-Download, Konfiguration, Content-Injection, Debugging, iteratives Problemloesen. Der KI-Agent hat Probleme identifiziert, Hypothesen aufgestellt, Lösungen implementiert und verifiziert. Sieben Versionen, jede besser als die vorherige.

    Was nicht funktioniert: Blindes Vertrauen. Der Agent brauchte klare Ziele, die richtigen Schnittstellen und menschliche Entscheidungen an kritischen Punkten. Der Wechsel von API zu SSH war eine strategische Entscheidung, keine die der Agent selbst getroffen hat.

    WordPress MCP steht am Anfang. Die offizielle Abilities API, das Automattic MCP-Plugin, die wachsende Community um Claude Code und WordPress: das sind frühe Signale eines grundlegenden Wandels. KI-Agenten werden WordPress nicht ersetzen. Aber sie verändern, wie wir damit arbeiten.

    Für Agenturen bedeutet das: repetitive Aufgaben (Seiten aufsetzen, Content migrieren, Einstellungen konfigurieren) werden delegierbar. An digitale Kollegen, die rund um die Uhr verfügbar sind, keine Tickets brauchen und in Minuten erledigen, was vorher Stunden dauerte.

    Für Entwickler bedeutet das: eine neue Abstraktionsebene. Statt jedes Plugin einzeln zu konfigurieren, beschreibst du das gewünschte Ergebnis. Der Agent findet den Weg.

    Die Technik ist da. Die Schnittstellen existieren. Was noch fehlt: Erfahrungswerte. Genau deshalb haben wir dieses Experiment dokumentiert.


    Plot Twist: Und dieser Artikel?

    Wenn ein KI-Agent eine Website klonen kann, dann stellt sich die nächste Frage fast von selbst.

    Wer hat diesen Artikel geschrieben?

    Ehrliche Antwort: Wir haben ihn zusammen geschrieben. KI-gestuetzte Recherche hat die SERP-Landschaft analysiert, Suchvolumen und Keyword-Difficulty geprüft, die Konkurrenz-Inhalte ausgewertet. Modulare Agenten-Architektur hat SEO-Daten gesammelt, den Content strukturiert, Entwuerfe produziert.

    Aber die Idee, dieses Experiment zu machen? Menschlich. Die Entscheidung, ehrlich über Fehler zu schreiben statt nur die Erfolge zu zeigen? Menschlich. Der Ton, die Story, die Qualitaetskontrolle? Menschlich. Die strategische Einordnung, was das für Agenturen und Entwickler bedeutet? Menschlich.

    KI ersetzt uns nicht. Sie verändert, wie wir arbeiten. Sie ermöglicht Dinge, die vorher so nicht möglich waren. Ein einzelner Mensch mit den richtigen KI-Kollegen kann heute Ergebnisse produzieren, für die früher ganze Teams noetig waren.

    Aber ohne Strategie, ohne Bewusstsein für das Ziel, ohne menschliches Urteilsvermoegen produziert auch die beste KI nur gut klingendes Nichts.

    Bewusstsein kommt vor Transformation. Strategy First, AI Second.

    Das gilt für Website-Cloning. Und für alles andere auch.


    Dieser Artikel basiert auf einem realen Experiment von Signo Media im April 2026. Die technische Dokumentation, Screenshots und Code-Snippets stammen aus unserem internen Entwicklertagebuch. Fragen oder eigene Erfahrungen mit WordPress MCP? Kontaktiert uns.


    Verwandte Themen: WordPress AI, Claude Code WordPress, KI Website erstellen, WordPress Seite klonen