Claude mit WordPress verbinden: WP-CLI ausführen und jede Änderung mit Relvato prüfen

Zwei Hälften: die Website ändern und sie prüfen

WP-CLI ist die Kommandozeile von WordPress. Es listet Plugins auf, aktualisiert sie, exportiert die Datenbank, gleicht Core-Dateien mit WordPress.org ab und mehr. So ändert ein Assistent eine Website. Was es dir nicht zeigen kann, ist die Website, wie Besucher sie sehen: ob der Checkout noch eine Zahlung annimmt, ob das Login-Formular noch abschickt, ob eine Seite noch schnell ist.

Genau diese Lücke steckt hinter den meisten Geschichten à la „ein Update hat meine Website zerstört“: Das Update selbst meldet Erfolg, und der Fehler sitzt woanders, in einem Formular, einem Skript oder einem Template. Relvato prüft genau das, in einem echten Browser, von außen. Über den Connector kann ein Assistent den Zustand einer Website abfragen (site_overview), Prüfungen sofort starten (trigger_scan), einen Lauf im Detail lesen (get_run) und das Briefing zu einem Fehler holen (get_fix_prompt).

Zusammen ergibt das eine Schleife: mit WP-CLI etwas ändern, mit Relvato prüfen und das Ergebnis lesen, bevor es weitergeht – im selben Gespräch.

Welches Claude was kann

Claude Code, im Terminal oder in der Desktop-App von Claude, kann Shell-Befehle ausführen. Es kann WP-CLI gegen eine lokale Website oder, über SSH, gegen eine entfernte ausführen. Das ist der direkteste Weg, Claude mit WordPress zu verbinden.

Claude im Web, auf dem Handy und im Desktop-Chat kann keine Shell ausführen. Um von dort aus eine Website zu ändern, nutze den MCP Adapter von WordPress über HTTPS oder, für dort gehostete Websites, den eigenen Connector von WordPress.com. Der Relvato-Connector funktioniert überall in Claude.

Schritt 1: den Relvato-Connector hinzufügen

Öffne in Claude Settings → Connectors, suche Relvato (oder öffne seine Seite im Verzeichnis), klicke auf Connect und melde dich bei Relvato an. Auf dem Zustimmungsbildschirm erlaubst du dem Assistenten, deine Websites und Ergebnisse zu lesen und Änderungen vorzunehmen: Websites und Prüfungen hinzufügen, Zeitpläne ändern und Scans starten. Gehörst du zu einer Organisation, wählst du, welchen ihrer Workspaces er nutzen darf.

In Claude Code fügst du den Server mit einem Befehl hinzu und meldest dich an, wenn du gefragt wirst. Clients ohne Anmeldung können stattdessen einen Relvato-API-Schlüssel nutzen. Die Entwicklerseite zeigt beide Wege.

# Claude Code: Relvato hinzufügen, dann in Claude Code /mcp ausführen und Authenticate wählen
claude mcp add --transport http relvato https://app.relvato.com/api/mcp

Schritt 2: WP-CLI über SSH freigeben

WP-CLI kann Befehle über SSH auf einem entfernten Server ausführen. Lege Aliase für deine Websites in einer wp-cli.yml in dem Ordner an, in dem du Claude Code startest; jeder Befehl nennt dann die Website, für die er gilt. WP-CLI muss auf dem Server installiert und für den SSH-Benutzer als wp erreichbar sein, und dein SSH-Schlüssel muss ohne Passwortabfrage funktionieren.

Beginne mit einer Staging-Kopie. Prüfe die Verbindung zuerst mit einem harmlosen Befehl: wp @staging core version sollte deine WordPress-Version ausgeben.

# wp-cli.yml
@staging:
  ssh: deploy@staging.example.com/var/www/html
@prod:
  ssh: deploy@example.com/var/www/html

# Verbindung prüfen
wp @staging core version

Schritt 3: festlegen, was ohne Nachfrage laufen darf

Standardmäßig fragt Claude Code vor jedem neuen Befehl nach. In .claude/settings.json kannst du die lesenden Befehle vorab erlauben, Änderungen hinter einer Nachfrage lassen und zerstörerische Befehle ganz verbieten. Verbote (deny) gewinnen immer gegen Erlaubnisse (allow).

Zwei Vorsichtshinweise. Regeln passen auf den Befehl, wie er geschrieben ist, also sind wp @staging plugin list und wp @prod plugin list verschiedene Regeln. Und die Dokumentation von Claude Code selbst nennt Regeln, die die Argumente eines Befehls festnageln wollen, fragil. Sieh sie als Sicherheitsgurt, nicht als Schloss: Die echte Grenze ist, was der SSH-Benutzer auf dem Server darf.

{
  "permissions": {
    "allow": [
      "Bash(wp @staging core version)",
      "Bash(wp @staging plugin list *)",
      "Bash(wp @staging plugin update * --dry-run)"
    ],
    "ask": [
      "Bash(wp @staging plugin update *)",
      "Bash(wp @staging db export *)"
    ],
    "deny": [
      "Bash(wp * db drop *)",
      "Bash(wp * db reset *)",
      "Bash(wp * eval *)",
      "Bash(wp * search-replace *)"
    ]
  }
}

Ein echter Ablauf: Plugins aktualisieren, ohne den Checkout zu zerstören

So sieht die Schleife in der Praxis aus, zuerst auf Staging. Frag Claude, welche Plugins veraltet sind. Es führt wp @staging plugin list --update=available aus. Frag dann Relvato nach dem Zustand der Website, bevor du etwas anfasst (site_overview), damit es einen Ausgangswert zum Vergleich gibt.

Mach ein Backup (wp @staging db export) und sieh dir das Update vorab an (--dry-run). Aktualisiere ein Plugin und lass Relvato dann die Prüfungen der Website sofort ausführen (trigger_scan) und lies die Ergebnisse (get_run). Schlägt der Checkout, das Login oder ein Formular fehl, liefert get_fix_prompt dasselbe Briefing, mit dem Relvatos eigene KI arbeitet: den Stack der Website, was sich kurz davor geändert hat, und den genauen Fehler. Claude kann über die Ursache nachdenken und das Plugin bei Bedarf mit WP-CLI auf die vorherige Version zurücksetzen.

Erst wenn Staging sauber ist, wiederholst du es auf Produktion. Ist das Relvato-Plugin verbunden, führt Relvato nach Plugin-Updates auch von selbst Prüfungen aus. Fragst du im Gespräch danach, bekommst du die Antwort, solange du noch dabei bist.

Schließe mit Integritätsprüfungen ab, die WP-CLI selbst kann: wp core verify-checksums gleicht Core-Dateien mit WordPress.org ab, und wp plugin verify-checksums --all tut dasselbe für Plugins von WordPress.org. Premium-Plugins lassen sich so nicht prüfen.

wp @staging plugin list --update=available
wp @staging db export
wp @staging plugin update woocommerce --dry-run
wp @staging plugin update woocommerce
#  → Relvato: trigger_scan, dann get_run
#  → wenn etwas fehlschlug: get_fix_prompt und zurücksetzen:
wp @staging plugin install woocommerce --version=<vorherige Version> --force
wp @staging core verify-checksums
wp @staging plugin verify-checksums --all

Ohne Terminal: der WordPress MCP Adapter

WordPress 6.9 hat die Abilities API eingeführt, einen Standardweg, auf dem Plugins beschreiben, was sie können. Der MCP Adapter, ein offizielles Plugin getrennt vom Core und noch vor Version 1.0, stellt diese Fähigkeiten KI-Assistenten als MCP-Server bereit. Automattics früheres Plugin wordpress-mcp ist zu seinen Gunsten archiviert.

Der Adapter spricht mit lokalen Clients über WP-CLI (wp mcp-adapter serve) und mit entfernten über HTTPS unter /wp-json/mcp/mcp-adapter-default-server, angemeldet mit einem WordPress-Anwendungspasswort. Es werden nur Fähigkeiten freigegeben, die ein Plugin als öffentlich markiert, also hängt das, was der Assistent tun kann, davon ab, was deine Plugins veröffentlichen. WooCommerce hat darauf eine Entwicklervorschau für Produkte und Bestellungen aufgebaut.

Gib ihm einen eigenen WordPress-Benutzer mit so wenig Rechten wie nötig, nicht dein Admin-Konto, und widerrufe das Anwendungspasswort, wenn du fertig bist. Websites auf WordPress.com können stattdessen den eigenen MCP-Connector von WordPress.com nutzen, in den kostenpflichtigen Tarifen.

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# Claude Code, verbunden mit einer lokalen Website über WP-CLI
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

Leitplanken, die mehr zählen als der Prompt

Ein Assistent ist genau so sicher wie das Konto, mit dem er handelt. Nutze zuerst eine Staging-Kopie, ein Backup vor jeder Änderung und einen SSH- und WordPress-Benutzer mit nur den Rechten, die die Aufgabe braucht. Lass Änderungen hinter einer Nachfrage, und betreibe Claude Code auf einer Live-Website nicht mit abgeschalteten Nachfragen: Seine Dokumentation behält das isolierten Containern und virtuellen Maschinen vor.

Prüfe nach jeder Änderung, nicht nur davor. WP-CLI kann dir sagen, dass ein Update fertig ist. Nur eine Prüfung von außen sagt dir, dass die Website für die Menschen, die sie nutzen, noch funktioniert. Deshalb ist der Relvato-Connector für diese Schleife gebaut, und deshalb kann er bewusst keine Daten löschen, keine visuellen Änderungen übernehmen, keine Korrekturen anwenden und keine API-Schlüssel anfassen: Das bleibt im Relvato-Dashboard, wo du selbst hinschaust.