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), ihre Monitore 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 Claudes Desktop-App, kann Shell-Befehle ausführen. Es kann WP-CLI auf einer lokalen Website ausführen oder per SSH auf einer entfernten. Das ist der direkteste Weg, Claude mit WordPress zu verbinden.

Der Chat in Claudes Desktop-App kann keine Shell ausführen, aber lokale MCP-Server aus seiner Konfigurationsdatei starten — er kann also den MCP Adapter von WordPress nutzen. Claude im Web und auf dem Handy verbindet sich nur mit entfernten Servern, die sich per OAuth anmelden, und der Adapter meldet sich mit einem WordPress-Anwendungspasswort an. Von dort aus kannst du eine selbst gehostete WordPress-Website also nicht ändern; Websites auf WordPress.com können den eigenen Connector von WordPress.com nutzen. Relvatos Connector funktioniert in jeder Claude-Umgebung.

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 Monitore 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 Monitore 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 seine Monitore 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 Standard, mit dem Plugins beschreiben, was sie können. Der MCP Adapter, ein offizielles WordPress-Plugin außerhalb des Cores und noch vor seiner Version 1.0, macht aus diesen Fähigkeiten einen MCP-Server, den ein Assistent nutzen kann. Automattics früheres Plugin wordpress-mcp ist zu seinen Gunsten archiviert.

Er steht nicht im Plugin-Verzeichnis von WordPress.org: Du lädst ihn von seinen GitHub-Releases herunter, und WordPress aktualisiert ihn nicht für dich. Die folgenden Schritte installieren ihn, zeigen, dass er läuft, geben dem Assistenten ein eigenes Konto und verbinden Claude.

MCP Adapter, Schritt 1: die Voraussetzungen

WordPress 6.9 oder neuer — die Abilities API ist Teil des Cores, ein eigenes Abilities-API-Plugin ist nicht nötig (ältere Versionen des Adapters brauchten eines; das wird nicht mehr unterstützt). PHP 7.4 oder neuer. Sprechende Permalinks: Steht Einstellungen → Permalinks auf „Einfach“, antwortet die REST-Adresse des Adapters nicht.

Für eine entfernte Website brauchst du außerdem HTTPS: WordPress bietet Anwendungspasswörter nur über HTTPS an (oder auf einer Website, die als lokale Umgebung markiert ist), und die entfernte Verbindung meldet sich mit einem an.

MCP Adapter, Schritt 2: herunterladen und installieren

Mit WP-CLI lädt ein Befehl das neueste stabile Release von GitHub herunter und aktiviert es — die Adresse unten zeigt immer auf das Release, das GitHub als Latest markiert. Führe ihn zuerst auf Staging aus, wie die WP-CLI-Schritte oben.

Ohne WP-CLI: Öffne auf GitHub die Releases-Seite des Projekts, wähle das als Latest markierte Release und lade unter Assets die Datei mcp-adapter.zip herunter. Lass das Release namens CI Artifacts oben in der Liste aus — es ist eine Vorabversion voller Test-Builds aus Pull Requests, nichts zum Installieren. Geh dann in WordPress zu Plugins → Neues Plugin hinzufügen → Plugin hochladen, wähle die ZIP-Datei, klicke auf Jetzt installieren und danach auf Plugin aktivieren.

Nutze 0.6.1 oder neuer, nie 0.6.0: Die ZIP-Datei dieses Releases konnte bei normalen Seitenaufrufen einen fatalen Fehler auslösen, sobald ein anderes Plugin nach WP-CLI fragte, und 0.6.1 gibt es nur, um das zu beheben. Zum Aktualisieren führst du denselben Befehl mit --force aus oder lädst die neuere ZIP-Datei genauso hoch. Plugin-Entwickler, die den Adapter mitliefern, können ihn stattdessen per Composer einbinden (composer require wordpress/mcp-adapter, mit dem Jetpack Autoloader); um ihn auf einer Website zu betreiben, ist das Plugin der einfachere Weg.

# install and activate the latest stable release (0.6.1 on 1 Oct 2026)
wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# later: update to a newer release
wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --force

MCP Adapter, Schritt 3: prüfen, dass er läuft

Das Plugin legt seinen Standard-Server an, sobald es aktiv ist. wp mcp-adapter list sollte mcp-adapter-default-server anzeigen, und seine Adresse ist /wp-json/mcp/mcp-adapter-default-server auf deiner Website. In wp-admin erscheint MCP Adapter unter Plugins → Installierte Plugins als aktiv.

Antwortet die Adresse mit 404, prüfe zuerst die Permalink-Einstellung. Antwortet sie, dass du nicht angemeldet bist, läuft der Server — er spricht nur mit angemeldeten Benutzern, und darum geht es im nächsten Schritt.

wp plugin status mcp-adapter
wp mcp-adapter list
# → mcp-adapter-default-server, at /wp-json/mcp/mcp-adapter-default-server

MCP Adapter, Schritt 4: ein eigener Benutzer und ein Anwendungspasswort

Verbinde nicht dein eigenes Admin-Konto. Lege für den Assistenten einen Benutzer mit der niedrigsten Rolle an, die für die Aufgabe reicht — Redakteur für Inhalte, Administrator nur, wenn er wirklich Plugins verwalten muss —, denn alles, was der Assistent tut, läuft mit den Rechten dieses Benutzers.

Gib diesem Benutzer dann ein Anwendungspasswort: Öffne in wp-admin Benutzer, bearbeite den Benutzer, such den Bereich Anwendungspasswörter, gib einen Namen wie „Claude“ ein und klicke auf Neues Anwendungspasswort hinzufügen. WordPress zeigt es einmal an; kopiere es dann. Du kannst es dort jederzeit widerrufen — damit ist der Assistent getrennt, ohne dass sich sonst etwas ändert.

# a user just for the assistant, with only the role it needs
wp user create ai-editor ai-editor@example.com --role=editor
# its Application Password (printed once)
wp user application-password create ai-editor "Claude" --porcelain

MCP Adapter, Schritt 5: Claude Code verbinden

Claude Code mit der Website auf demselben Rechner: Claude startet den Adapter selbst über WP-CLI, angemeldet als der Benutzer, den du mit --user angibst (STDIO, kein Passwort nötig).

Claude Code mit einer entfernten Website oder die Claude-Desktop-App: Beide laufen über @automattic/mcp-wordpress-remote, einen kleinen Proxy von Automattic, der auf deinem Rechner läuft (er braucht Node.js) und mit der Website per HTTPS und dem Anwendungspasswort des Benutzers spricht.

# Claude Code, site on this machine (STDIO through WP-CLI)
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

# Claude Code, remote site (HTTPS through Automattic's proxy; needs Node.js)
claude mcp add \
  -e WP_API_URL=https://example.com/wp-json/mcp/mcp-adapter-default-server \
  -e WP_API_USERNAME=ai-editor \
  -e WP_API_PASSWORD="xxxx xxxx xxxx xxxx xxxx xxxx" \
  wordpress -- npx -y @automattic/mcp-wordpress-remote@latest

MCP Adapter, Schritt 6: die Claude-Desktop-App verbinden

Öffne in der Desktop-App Einstellungen → Entwickler → Konfiguration bearbeiten (Settings → Developer → Edit Config), füge den Block unten in claude_desktop_config.json ein und starte Claude neu. Das Passwort steht in dieser Datei im Klartext, also lass sie auf deinem eigenen Rechner.

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "ai-editor",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

MCP Adapter, Schritt 7: was Claude danach tun kann

Claude sieht drei Tools des Standard-Servers: mcp-adapter/discover-abilities listet auf, was die Website anbietet, mcp-adapter/get-ability-info beschreibt eine Fähigkeit, und mcp-adapter/execute-ability führt sie aus. Fähigkeiten sind standardmäßig privat — nur die, die ein Plugin als öffentlich markiert (meta.public), tauchen auf, und jede prüft beim Ausführen trotzdem die Rechte des Benutzers.

Was der Assistent tun kann, hängt also von deinen Plugins ab: Eine frische Website bietet wenig, und die Entwicklervorschau von WooCommerce bringt Produkte und Bestellungen dazu. Bitte Claude zuerst, die Fähigkeiten aufzulisten, damit ihr beide wisst, was er anfassen kann — und lass nach jeder Änderung deine Relvato-Monitore in derselben Unterhaltung laufen, genau wie im WP-CLI-Ablauf oben.

Ist das Relvato-Plugin (ab 1.42.0) auf der Website, listet discover-abilities auch Relvatos eigene: relvato/get-site-status, relvato/list-monitors, relvato/get-fix-brief und relvato/run-monitors. Sie brauchen ein Administratorkonto, mit dem Redakteur-Benutzer aus Schritt 4 bleiben sie also verborgen; nutze für diese Schleife dann den Relvato-Connector aus Schritt 1. Was jede tut, steht in der Doku zur WordPress Abilities API.

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 ein Test 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 Datei- oder Skriptänderungen freigeben und keine API-Schlüssel anfassen: Das bleibt im Relvato-Dashboard, wo du selbst hinschaust. Was er ändern darf, etwa eine visuelle Änderung übernehmen, tut er erst nach deiner Bestätigung, und jede solche Entscheidung lässt sich rückgängig machen.

ChatGPT statt Claude nutzen

Relvato gibt es auch als Plugin in ChatGPT. Füge es auf dieser Seite hinzu und melde dich bei Relvato an. Zustimmungsbildschirm und Tools sind dieselben wie in Claude: ChatGPT kann den Zustand einer Website abfragen (site_overview), ihre Monitore sofort starten (trigger_scan), einen Lauf im Detail lesen (get_run) und das Briefing zu einem Fehler holen (get_fix_prompt).

Damit übernimmt ChatGPT die Hälfte dieses Guides, in der du die Website prüfst. ChatGPT hat keine Shell auf deinem Server, deshalb bleiben die WP-CLI-Schritte oben bei Claude Code oder deinem eigenen Terminal: Nimm die Änderung dort vor und bitte dann ChatGPT, die Relvato-Monitore der Website zu starten und zu erklären, was sie gefunden haben.