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

---

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.

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.

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.

---

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 %.

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.

---

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

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”.

---

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 %

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

---

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.

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