Vom Claude-Design-Entwurf zu einer lauffähigen WordPress-Testseite: mit Meta-Box-CPTs, 350 importierten Artikeln, Menüs und Builderius-Templates. Dieser Artikel zeigt den Weg, den ich an einem echten Projekt getestet habe, mit allen Befehlen, Prompts und Fallstricken.

Das Prinzip: drei Beteiligte

Der Workflow trennt Bauen und Einrichten. Claude im Browser baut ein Importpaket aus dem Design. Ein zweiter Claude im Terminal spielt es in WordPress ein. Beide arbeiten nach festen Regeln, die als Skills und als Anleitung im Paket stehen.

Wer	Wo	Aufgabe	Werkzeug
Claude im Browser	claude.ai	Design in ein Importpaket (ZIP) verwandeln	Skill `wp-paket-aus-design`
Claude im Terminal	dein Rechner, Claude Code	Paket in WordPress einspielen	Skill `wp-builderius-einrichten`, Playwright-MCP, Sense-AI-MCP
WordPress	Server oder Docker	CPTs, Inhalte, Templates aufnehmen	Builderius, Meta Box AIO

Das brauchst du vorher

Ein Claude-Design-Projekt mit den Seiten, die du brauchst (Start, Archiv, Beitrag).
Eine WordPress-Testinstallation mit den Plugins Meta Box AIO und Builderius (Version Website, Professional oder Studio, nur dort gibt es das HTML-Import-Tool).
Ein Application Password für einen Administrator (Benutzer → Profil → Anwendungspasswörter).
Claude Code im Terminal sowie Node.js (für npx).
Einen Browser auf demselben Rechner, in dem du Builderius öffnen kannst.

Das Ganze ist ein Testlauf auf einer Testseite. Auf einer Live-Seite machst du vorher ein Backup.

Schritt 1: Das Importpaket bauen (in claude.ai)

Der Designentwurf lässt sich nicht direkt in Builderius importieren. Die Datei aus Claude Design (.dc.html) ist kein normales HTML, sondern nutzt eine eigene Laufzeit mit Platzhaltern wie {{ ... }} und Schleifen. Der Builderius-Importer braucht statisches, valides HTML. Das erledigt der erste Skill.

Skill installieren

Öffne claude.ai und lass dir den Skill wp-paket-aus-design vorschlagen und speichere ihn über die Karte.
Bei Bedarf sichere dir auch den zweiten Skill wp-builderius-einrichten (siehe Schritt 2).

Der Prompt in claude.ai

Öffne dein Design-Projekt und schreibe:

Bau mit dem Skill wp-paket-aus-design ein WordPress-Paket für dieses Projekt.
Datenmodell: CPT artikel (Taxonomien thema, artikel_format, artikel_schlagwort),
CPT produkt (Affiliate-Box), CPT sonntagsbrief.
Inhalte: <deine JSON-/CSV-Dateien>. Menüs: Hauptmenü mit den Themen, Footer-Menü mit den Rechtsseiten.
Ziel-Domain: Platzhalter, ich ersetze sie beim Import.

Was im ZIP steckt

Der Skill rendert die Design-Seiten mit einem Headless-Browser zu sauberem HTML, schreibt die Meta-Box-Importdateien in dem Format, das dein Meta Box exportiert, und erzeugt eine WordPress-Importdatei (WXR) mit den Inhalten.

nichtmehr20-wp-paket/
├── AGENT-ANLEITUNG.md        Anleitung und Sicherheitsregeln für den lokalen Claude
├── PROMPT-VORLAGE.md         Der Einstiegsprompt zum Kopieren
├── README.md
├── cpt/
│   ├── taxonomies/           thema, artikel_format, artikel_schlagwort
│   ├── post-types/           artikel, produkt, sonntagsbrief
│   └── field-groups/         Felder je Typ
├── content/
│   └── nichtmehr20.wxr.xml   Artikel, Sonntagsbriefe, Seiten, Menüs
├── css/global.css            Variablen, Basisstile
└── html/                     header, footer, start, archiv, single

Entpacke das ZIP in einen eigenen Ordner. Dort startest du in Schritt 2 den lokalen Claude.

Hinweis zu Meta Box: Es gibt kein dokumentiertes Import-Format für CPTs außerhalb der Backend-Oberfläche. Die Dateien im Paket sind deshalb nach echten Exporten von Meta Box AIO aufgebaut. Hast du eine bestehende Installation, exportiere dort je eine Taxonomie, einen Post Type und eine Feldgruppe und gib sie Claude als Vorlage mit.

Schritt 2: Den lokalen Claude vorbereiten (Terminal)

Der lokale Claude braucht drei Zugänge: zur Builderius-Oberfläche, zur WordPress-REST-API und zu einem Browser für das Backend. Richte sie einmal ein, dann gelten sie für alle Projekte.

2a: Application Password testen, bevor du irgendetwas konfigurierst

Erzeuge in WordPress unter Benutzer → Profil → Anwendungspasswörter ein neues Passwort und prüfe es sofort:

curl -s -u 'dein-admin:XXXX XXXX XXXX XXXX XXXX XXXX' \
  'https://meine-seite.de/wp-json/wp/v2/users/me?context=edit'

Kommen Benutzerdaten zurück, passt es. Kommt rest_not_logged_in (401), ist das Passwort ungültig, und alles Weitere scheitert mit irreführenden Fehlern (siehe Fallstricke).

2b: MCP-Server für Builderius und WordPress

Claude Code liest die Projekt-Konfiguration .mcp.json im Ordner, in dem du es startest. Die Datei claude_desktop_config.json der Desktop-App gilt dort nicht. Bei mir sah die Datei so aus:

{
  "mcpServers": {
    "builderius": {
      "command": "npx",
      "args": ["-y", "@builderius/sense-ai@latest", "mcp", "--port=7681"],
      "env": {
        "WP_API_URL": "https://meine-seite.de",
        "WP_API_USERNAME": "dein-admin",
        "WP_API_PASSWORD": "<Application Password>"
      }
    },
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://meine-seite.de/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "dein-admin",
        "WP_API_PASSWORD": "<Application Password>"
      }
    }
  }
}

Die Datei enthält ein Geheimnis. Nimm sie nicht ins Git auf.

Damit der Builderius-Server die Seite sehen kann, muss der Builder offen sein: Öffne ein Template im Builderius-Editor in einem Browser auf demselben Rechner und erlaube dort den Zugriff auf das lokale Netzwerk (Symbol links in der Adressleiste). Prüfe die Verbindung so:

curl -s http://127.0.0.1:7681/health      # builderConnected sollte true sein
sense tabs --port=7681                    # listet den verbundenen Builder-Tab

Claude Code liest die MCP-Konfiguration nur beim Start. Nach jeder Änderung: /exit und claude --continue.

2c: Playwright-MCP für alles, was nur im Backend geht

Der Meta-Box-Import und der WordPress-Import sind reine Backend-Seiten. Das Application Password gilt nur für die REST-API, nicht für wp-login.php, und Meta Box hat keine REST-Route, die neue CPTs anlegt. Darum bekommt der Claude einen Browser:

claude mcp add --scope user playwright -- npx @playwright/mcp@latest --browser chromium
npx playwright install chromium

Unter Linux Mint zeigt Playwright den Hinweis, dass das Betriebssystem nicht offiziell unterstützt wird, lädt aber einen passenden Fallback und läuft. Nach dem Neustart öffnet der Claude beim ersten Zugriff ein Chromium-Fenster. Logge dich dort selbst bei wp-admin ein. Dein Passwort bekommt der Claude nie zu sehen, und das Profil bleibt für spätere Sitzungen erhalten. Du kannst deinen Rechner währenddessen normal benutzen: Playwright steuert seinen eigenen Browser und nicht deine Maus oder Tastatur. Klicke nur nicht in dieses Fenster und schließe es nicht.

2d: Skill und Paket bereitstellen

Das ZIP aus Schritt 1 liegt als Unterordner im Projektordner. Die Anleitung steckt im Paket, der Skill wp-builderius-einrichten ist eine zusätzliche Kurzfassung. Wenn du ihn lokal nutzen willst, lege ihn in ~/.claude/skills/wp-builderius-einrichten/SKILL.md ab.

2e: Starten und prüfen

Starte Claude im Projektordner (bei mir über ein eigenes Start-Skript) und tippe /mcp. Die drei Server builderius, wordpress und playwright sollten als verbunden erscheinen.

Schritt 3: Der Prompt und der Ablauf

Jetzt kommt der eigentliche Auftrag. Du fügst diesen Prompt in den lokalen Claude ein und ersetzt die Platzhalter:

Du richtest <ZIEL-URL> (Testinstallation, Projekt <PROJEKTNAME>) ein.
Alle Dateien liegen im Ordner <PAKETORDNER> (README.md, AGENT-ANLEITUNG.md,
cpt/, content/, css/, html/).

Lies zuerst AGENT-ANLEITUNG.md und README.md vollständig und arbeite die
Schritte der Reihenfolge nach ab. Halte die Sicherheitsregeln aus Abschnitt 1
ein, insbesondere: keine Entwurfs-Seite als Startseite, anonymer curl -I-Check
nach jedem riskanten Schritt, Änderungsprotokoll changes.log, nach jedem
Builderius-Schritt speichern, nichts löschen, nichts veröffentlichen außer
der Startseite.

Zugang: Application Password und MCP sind eingerichtet. Backend-Importe
(Meta Box, Werkzeuge → Daten importieren, Builderius) machst du mit dem
Playwright-Browser. Wenn du nicht eingeloggt bist, sag mir das und warte.
Ich logge mich im Browserfenster selbst ein.

Vorab: Prüfe Verbindung, aktive Plugins und die Domain in der WXR-Datei
(Kopie mit Ziel-URL anlegen, Original unverändert). Melde mir dann kurz den
Stand und starte Schritt 1.

Nach jedem Schritt kurz berichten (Anzahl Einträge, Statuscodes, Fehler).
Bei Fehlern, 404/5xx oder Konflikten stoppen und melden.
Am Ende: Kurzbericht mit (1) was angelegt wurde, (2) was nicht geklappt hat,
(3) was ich manuell tun muss.

Beim ersten Browser-Zugriff meldet der Claude, dass er nicht eingeloggt ist. Logge dich im geöffneten Fenster bei wp-admin ein und schreibe „eingeloggt“.

Was der Claude dann der Reihe nach tut

Schritt	Aufgabe	Wie	Prüfung
1	Domain in der WXR-Kopie ersetzen	Datei im Paketordner	Original bleibt unverändert
2	Taxonomien, Post Types, Feldgruppen importieren (in dieser Reihenfolge), Permalinks speichern	Meta Box → Import-Button, per Playwright	Typen im Backend und per REST sichtbar
3	350 Artikel, 5 Sonntagsbriefe, 7 Seiten, Menüs importieren	Werkzeuge → Daten importieren, WordPress Importer	Anzahl Einträge stimmt
4	CSS-Variablen einspielen, Schriften lokal hosten	Builderius Merge-Modus, Font Manager	Variablenzahl steigt, Schriften greifen
5	Header, Footer, Start, Archive, Single als Templates importieren, zuweisen	Builderius-HTML-Import (Sense-AI)	Template-Zuweisung, anonymer `curl`-Check
6	Query-Schleifen, Felder, Menüs statt fester Links	Builderius-GraphQL (Sense-AI)	Archiv und Single zeigen echte Daten

Die Reihenfolge in Schritt 2 ist wichtig. Der WordPress Importer überspringt Post-Typen, die es noch nicht gibt, also müssen die CPTs vor den Inhalten existieren. Alle Artikel und Seiten bleiben Entwürfe, veröffentlicht wird nur die Startseite.

Das Änderungsprotokoll

Der Claude führt eine Datei changes.log, in der jede Einstellung mit Alt- und Neuwert steht, zum Beispiel:

Plugin        | WordPress Importer | nicht installiert -> installiert + aktiviert
Einstellungen | Lesen: show_on_front | posts -> page
Builderius    | Globales CSS gemerged | Variablen 268 -> 287
Builderius    | Commit-Gruppe gespeichert (Archive dynamisch)

Das Protokoll hat im Testlauf geholfen, den Ausfall der Seite zurückzuverfolgen. Dazu mehr im nächsten Abschnitt.

Fallstricke aus dem Praxistest

Diese Probleme sind bei mir wirklich aufgetreten. Die Tabelle spart dir die Suche.

Symptom	Ursache	Lösung
Tools melden „No builder page is connected“, obwohl der Builder offen ist und `/health` `builderConnected: true` zeigt	Das Application Password ist ungültig (401). Die Meldung führt auf eine falsche Spur	Passwort mit `curl` gegen `/wp-json/wp/v2/users/me` testen, neues erzeugen, in beiden Einträgen der `.mcp.json` ersetzen, Claude neu starten
Claude kann die Meta-Box-Typen nicht per Skript anlegen („field group might have been deleted“)	Die Route `/mbb/save` speichert nur bestehende Einträge. Es gibt keine REST-Route zum Anlegen	Import über das Backend mit dem Playwright-Browser
Playwright findet keinen Browser	Standard ist Google Chrome unter `/opt/google/chrome/chrome`	MCP mit `--browser chromium` einrichten und `npx playwright install chromium` ausführen
Seite komplett weg, „No Available Server“, auch `/wp-admin`	Eine Entwurfs-Seite war als Startseite gesetzt. Für Besucher ohne Login ergibt das 404, der Healthcheck schlägt fehl und der Proxy schaltet den Container ab	Seite veröffentlichen (siehe unten), Healthcheck robuster machen
Falsches Template auf der Startseite	Das vorinstallierte „Blog Index“-Template hat Vorrang vor der Front Page	Statische, veröffentlichte Startseite setzen
Karten im Archiv stehen versetzt	Leerraum zwischen den Elementen wird im Import zu leeren Zellen	HTML ohne Leerraum zwischen den Tags (der Skill erledigt das)
Builderius-Komponenten sind leer oder ungültig	Der Claude hat Komponenten ohne gültige Konfiguration angelegt	Komponente erst über die Oberfläche anlegen, dann das HTML hinein importieren
Änderungen verschwinden	Builderius hat sie nicht gespeichert	Nach jedem Schritt eine Commit-Gruppe speichern
MCP-Einträge greifen nicht	Sie stehen in `claude_desktop_config.json` statt in `.mcp.json`	Konfiguration im Projektordner anlegen, Claude neu starten

Wenn die Seite weg ist: Reparatur in Coolify

In meinem Fall lief WordPress in Coolify mit Docker. So bin ich vorgegangen:

Im Terminal des WordPress-Containers curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/ ausführen. Bei 404 ist die Startseite der Grund.
Im Compose-File (Edit Compose File) steht beim Dienst wordpress der Healthcheck curl -f http://127.0.0.1. Er bewertet 404 als Fehler.
Im Terminal des MariaDB-Containers die Seite veröffentlichen. Datenbank-Benutzer und Passwort stehen in den Environment Variables des Dienstes:

mariadb -u"<DB-USER>" -p"<DB-PASSWORT>" wordpress -e "UPDATE wp_posts SET post_status='publish' WHERE ID=<SEITEN-ID>;"

Nach wenigen Sekunden steht der Container wieder auf „healthy“.

Damit es nicht wieder passiert, ändere im Compose-File den Healthcheck auf http://127.0.0.1/wp-login.php. Diese Adresse antwortet auch bei kaputter Startseite mit 200 oder 302.

Die Sicherheitsregeln für den Claude

Aus dem Ausfall sind feste Regeln geworden, die in AGENT-ANLEITUNG.md und im Skill stehen:

Nie eine Entwurfs-Seite als Startseite oder Beitragsseite setzen.
Nach jeder riskanten Änderung Startseite und /wp-login.php ohne Login mit curl -I prüfen. Erlaubt sind 200, 301 und 302. Bei 404 oder 5xx stoppen und die Änderung zurücknehmen. Eine Vorschau im Browser als Admin reicht nicht.
Ein Änderungsprotokoll mit Alt- und Neuwert führen.
Nichts löschen, was vorher existierte.
Artikel und Seiten bleiben Entwürfe, veröffentlicht wird nur die Startseite.
Nach jedem Builderius-Schritt speichern.
Zugangsdaten nie in Dateien oder Ausgaben schreiben.

Ein Gedanke zur Fehlersuche: Wenn der Server läuft, der Builder verbunden ist und die Tools trotzdem nichts sehen, prüfe zuerst die Zugangsdaten. Das ist ein einziger curl-Aufruf und hätte mir mehrere Neustarts erspart.

Checkliste für das nächste Projekt

Design-Projekt fertig, Inhalte und Datenmodell (CPTs, Felder, Menüs) liegen bereit
Skill wp-paket-aus-design in claude.ai gespeichert, Paket gebaut und entpackt
Testinstallation mit Meta Box AIO und Builderius (Website, Professional oder Studio)
Application Password erzeugt und mit curl gegen /wp-json/wp/v2/users/me getestet
.mcp.json mit builderius und wordpress im Projektordner angelegt
Playwright-MCP mit Chromium eingerichtet (claude mcp add ..., npx playwright install chromium)
Builderius-Editor im Browser offen, Zugriff auf das lokale Netzwerk erlaubt, /health meldet builderConnected: true
Claude im Projektordner gestartet, mit /mcp drei verbundene Server geprüft
Prompt aus Schritt 3 eingefügt, im Playwright-Fenster bei wp-admin eingeloggt
Nach jedem Schritt Statuscodes und Anzahlen geprüft, Commit-Gruppen gespeichert
Am Ende den Kurzbericht gelesen und die offenen Punkte abgearbeitet

Was nach dem Import noch offen ist

Das Paket richtet Struktur und Darstellung ein, nicht den fertigen Inhalt. Danach sind noch zu erledigen:

Fließtexte der Artikel (importiert sind nur Titel und Auszug) und Beitragsbilder.
Ein Mail-Tool für das Newsletter-Formular, das als reines HTML importiert wird.
Impressum und Datenschutz, die nur als Platzhalter-Seiten vorliegen und vor einer Veröffentlichung rechtlich geprüft werden müssen.
Passwörter erneuern: Application Password und Datenbank-Passwort, wenn sie in einem Chat oder einer Datei gelandet sind.
Auf Live-Seiten: Backup vorher, Domain in der Importdatei anpassen, Healthcheck prüfen.

Fazit

Der Workflow ist an einem Projekt erprobt und hat die Struktur in einem Durchlauf angelegt. Die größten Zeitfresser waren falsche Zugangsdaten und die Startseiten-Einstellung, beides ist inzwischen als feste Regel im Paket. Behandle die ersten Durchläufe als Test. Erwarte beim Builderius-Import eigene Stolpersteine und halte sie in deiner changes.log fest, damit sie in den nächsten Skill einfließen.