Ich gab Claude Code ein WordPress App-Passwort und einen Satz. Es verwaltete die ganze Website.
Ein Kunde schickt mir eine E-Mail. Nichts Dramatisches: die spanische Flagge im Sprachumschalter seiner WP-Seite gegen eine mexikanische austauschen. So ein Zeug, das man nicht täglich macht und das locker den ganzen Vormittag fressen kann.
Ich habe diese Seite ewig nicht mehr angefasst. Ein Freelancer hat sie vor Jahren gebaut. Ich weiß nicht mal mehr, wie er die i18n aufgesetzt hat. Und ehrlich? Null Bock.
Dann hatte ich eine Idee. Was wäre, wenn Claude Code das einfach... übernimmt.
Also hab ich's gemacht: WordPress App-Passwort generiert, zusammen mit der Site-URL und der Kundenanfrage in Claude Code reingekippt, und bin was anderes machen gegangen.
TL;DR: Claude Code hat Polylang eigenständig gefunden, die Flagge getauscht, den Elementor Cache geleert, das Frontend überprüft. Ich hab nie erwähnt, welches Plugin die Sprachen verwaltet. Dann hat es den Rest der Seite auditiert. Dann hab ich meine anderen 54 Kundenseiten geöffnet. Was ein Krampf war, wurde zum Workflow.
Das Kundenticket, das ich fast ignoriert hätte
Die Anfrage war simpel genug. Kunde hat eine zweisprachige Seite (Spanisch/Englisch), und der Sprachumschalter zeigt eine Spanien-Flagge für die spanische Version. Sie wollen stattdessen die mexikanische Flagge. Macht total Sinn für ihre Zielgruppe.
Normalerweise loggst du dich ein, findest die Übersetzungs-Plugin-Einstellungen, lokalisierst die Flaggen-Konfiguration, änderst sie, leerst den Cache der gerade läuft, checkst das Frontend, antwortest dem Kunden. Zwanzig Minuten wenn du die Seite kennst. Fünfundvierzig wenn nicht.
Ich kannte diese Seite nicht. Ich hab sie vor zwei, drei Jahren an einen Freelancer ausgelagert. Ich weiß nicht, was er für Übersetzungen verwendet hat, welcher Page Builder da drin ist, welches Cache-Plugin läuft. Die ganze mise en place von jemand anderem WordPress-Installation, und ich soll einfach blind reinspringen.
Also anstatt mich wie ein verantwortlicher Erwachsener in wp-admin einzuloggen, bin ich zu Einstellungen > Benutzer > Anwendungspasswörter. Dreißig Sekunden. Ich hab die URL, das App-Passwort und die Kunden-E-Mail in Claude Code eingefügt. Ein Satz Kontext von mir: "mach das."
Und bin gegangen.
Ich hab ihm die Schlüssel gegeben. Ich hab ihm nicht gesagt, was für ein Auto es ist.
Es hat Polylang gefunden. Ich hab nie Polylang gesagt.
Flagge geändert. Cache geleert. Frontend verifiziert. Fünf Minuten insgesamt. Das ist das Ergebnis.
Das Transcript erzählt eine andere Geschichte als ich erwartet hatte (ich hab es nachträglich gelesen, weil ich zu dem Zeitpunkt ganz woanders war).
Claude Code hat den HTML-Quellcode der Seite geholt. Es hat eine CSS-Klasse entdeckt: cpel-switcher__flag--es. Allein von dieser Klasse hat es herausgefunden, dass Polylang die Übersetzungen verwaltet. Es hat /pll/v1/languages über die REST API abgefragt, den Spracheintrag für Spanisch gefunden, flag_code von es zu mx per PUT geändert, dann den Cache angegangen.
Der Cache-Teil war chaotisch (wie immer mit Elementor). Claude Code hat mehrere Endpoints probiert, bevor es den gefunden hat, der tatsächlich eine Leerung ausgelöst hat. Dann hat es das Frontend-HTML nochmal geholt und einen grep auf die Klassen gemacht, um zu bestätigen, dass die neue Flagge live ist.
Ehrliche Anmerkung: Claude Code hat es nicht beim ersten Versuch hinbekommen. Es hat zunächst versucht, Chrome zu öffnen und sich über das wp-admin-Formular einzuloggen. Es hatte das App-Passwort, aber interpretierte es als normale Anmeldedaten. Ich hab eine Korrektur geschickt: "verwende die REST API, nicht den Browser." Ein Satz. Danach vollständig autonom.
Es hat den gesamten Stack aus rohem HTML abgeleitet. Ich hätte zehn Minuten damit verbracht, durch Einstellungs-Panels zu klicken.
Dann hab ich gefragt, ob was nicht stimmt. Das war ein Fehler.
Die Flagge war erledigt. Aber ich hatte Claude Code noch mit der Seite verbunden, und ich bin die Art Mensch, die ein Tool nicht laufen lassen kann, ohne daran rumzufummeln. Also tippte ich: "während du schon mal da bist, sieht irgendwas komisch aus? Read-only. Ändere nichts."
Ich erwartete vielleicht ein fehlendes Alt-Tag. Ein veraltetes Plugin. Irgendwas Harmloses.
Drei Minuten später: acht Probleme. Und nicht die kosmetische Sorte.
XML-Sitemap unvollständig: die mexikanischen Seiten fehlten komplett. Bei einer zweisprachigen kommerziellen Seite ist das deine SEO für die Hälfte deines Contents einfach... nicht indexiert. Gar kein SEO-Plugin installiert. Seite mit dem Titel "About US", wo die Großbuchstaben es wie "United States" aussehen ließen (wahrscheinlich ein Überbleibsel von drei Redesigns, das niemand bemerkt hat). Polylang-Übersetzungen nicht richtig verknüpft, was bedeutet, dass der Sprachumschalter Nutzer zur Startseite der anderen Sprache schickte statt zur übersetzten Seite, auf der sie tatsächlich waren. Security-Header komplett fehlend: kein HSTS, kein X-Frame-Options, kein CSP. Admin-Benutzername war buchstäblich admin. Eine zufällige ZIP-Datei in der Medienbibliothek, die niemand erklären konnte. Und eine mexikanische Seite ohne englisches Pendant, was die zweisprachige Struktur kaputt machte.
Was das unangenehm machte: Ich bin derjenige, der diese Seite betreuen soll. Diese Probleme lagen die ganze Zeit da. Ein Kunde zahlt für Wartung, und der Freelancer (und dann ich, im weiteren Sinne) hatte alles übersehen. Claude Code hat es in drei Minuten gefunden, indem es methodisch jeden REST-Endpoint abgefragt und verglichen hat, was existieren sollte gegen das, was tatsächlich da ist.
Ein WordPress-Berater rechnet mindestens 2 Stunden für diese Art von Audit ab. Manche Agenturen packen es als eigenständige Leistung.
Das kostete einen Satz, den ich aus einer Laune heraus getippt hab.
Warum das bei jeder WordPress-Seite funktioniert, die du nie angefasst hast
Die WordPress REST API ist kein Feature. Es ist die gesamte Seite, als Endpoints freigelegt, nativ, seit Version 5.6. Und das ändert, was "einer KI Zugang geben" tatsächlich bedeutet.
Kein Plugin zu installieren. Kein MCP-Server aufzusetzen. Keine Config-Datei, kein Docker-Container, gar nichts. Die API läuft bereits auf jeder WordPress-Seite, die sie nicht explizit deaktiviert hat (fast keine tun das). Posts, Seiten, Medien, Benutzer, Plugins, Site-Config. Und das Ökosystem ist gefolgt: Polylang liefert /pll/v1/. WooCommerce liefert /wc/v3/. Yoast, RankMath, gleiches Muster. Alles dokumentiert, alles abfragbar.
Ein Anwendungspasswort gibt dem Inhaber exakt dieselben Berechtigungen wie der WordPress-Benutzer, der es generiert hat. Das ist das gesamte Setup. Dreißig Sekunden in wp-admin. Kein OAuth-Tanz. Kein API-Key-Dashboard. Keine Webhook-Registrierung.
Jetzt kombiniere das mit dem, was Claude Code bereits gut kann: Dokumentation lesen, API-Oberflächen erkunden, Kontext aus Antworten ableiten. Es liest das HTML der Seite, erkennt Polylang an einer CSS-Klasse, fragt den richtigen Endpoint ab, validiert das Ergebnis. Das ist dasselbe Muster wie der n8n MCP-Server, der Claude Code strukturierten Zugang zu n8ns vollständiger API gibt, mit kompletter Autonomie und null UI. Außer bei WordPress installierst du nichts. Es ist seit Jahren da, in aller Öffentlichkeit.
Die Brücke zwischen Claude Code und WordPress existiert seit 2021. Wir haben es nur gerade bemerkt.
Ich hatte 54 andere Seiten. Hier ist, was passiert ist.
Ich verwalte 54+ Kundenseiten. Die Flaggen-Session dauerte weniger als zehn Minuten. Also hab ich weitergemacht, und über die nächsten Tage hab ich drei echte Tests auf verschiedenen Seiten durchgeführt.
Content-Updates und Artikel-Erstellung. Claude Code liest bestehende Seiten über die API, nimmt den Ton und die Struktur von dem auf, was bereits veröffentlicht ist, generiert passenden Content und pusht ihn per POST/PUT auf /wp/v2/posts und /wp/v2/pages. Kein wp-admin, kein Copy-Paste in Gutenberg, keine Neuformatierung. Ein Ein-Zeilen-Brief geht rein, eine veröffentlichte Seite kommt raus.
Batch Alt-Tag-Updates. Claude Code hat alle Medien über /wp/v2/media geholt, jedes Bild mit fehlendem oder leerem Alt-Text identifiziert und sie stapelweise aktualisiert. Eine Seite hatte 200+ Bilder. Das ist ein Nachmittag durch die Medienbibliothek klicken, Alt-Text eins nach dem anderen schreiben, speichern, scrollen, weiter. Eine Session hat es erledigt.
Security-Härtung. Den vorhersagbaren Admin-Benutzernamen umbenennen, Response-Header prüfen, Benutzerberechtigungen und -rollen auditieren. Das Zeug, das auf deiner "Mach ich nächsten Monat"-Liste für jede Kundenseite steht, die du verwaltest.
Hier ist das, was dir nur auffällt, wenn du das große Bild betrachtest: keine dieser Aufgaben ist einzeln schwer. Jeder Dev kann Alt-Tags aktualisieren. Jeder Dev kann einen Admin-Benutzer umbenennen. Das Problem war nie die Schwierigkeit. Es war, dass es auf einer Seite zu machen okay ist, es auf 54 Seiten zu machen ist ein Grund für Prokrastination. Die API macht jede Aufgabe zu einer wiederholbaren Session. Claude Code macht die Session zu einem Batch. Die Multiplikation ist wichtig, nicht die Einheit.
Ehrliche Offenlegung: Ich hab Content- und Alt-Tag-Workflows auf 3-4 Seiten getestet, nicht auf allen 54. Aber das Muster hielt jedes Mal identisch, und die Skalierung auf das volle Portfolio ist an diesem Punkt Arithmetik, nicht Spekulation.
54 Seiten. Vorher: eine Aufgabe pro Seite. Jetzt: eine Session pro Batch.
Der Teil, den dir niemand über Admin-Zugang für eine KI erzählt
Okay. Lass uns über das reden, woran du bereits denkst.
Ein App-Passwort mit Admin-Privilegien gibt vollen Schreibzugang über die REST API. Voll. Das bedeutet Erstellen, Modifizieren und Löschen von Content. Bei einer mehrdeutigen Anfrage wie "räume ungenutzte Medien auf" könnte Claude Code "aufräumen" großzügiger interpretieren als du beabsichtigt hast.
Bei einem Test hab ich Claude Code gebeten, "die Medienbibliothek zu überprüfen und zu organisieren." Es hat Dateien zur möglichen Löschung markiert und vor dem Fortfahren gefragt. Es war vorsichtig. Aber vorsichtig ist ein Verhalten, kein Vertrag. Das Modell entscheidet, wie es deine Anfrage interpretiert, und du kontrollierst diese Interpretation nicht immer im Voraus.
Nicht verhandelbare Regel: vollständiges Backup vor jeder Session. Oder auf Staging arbeiten. Such dir eins aus.
Zweite Sache: Scope Drift. Die Flaggen-Session hat es klar gezeigt. Claude Code hat den Browser-Login probiert, bevor ich es korrigiert hab. Ohne explizite Grenzen im Prompt wird es erkunden, worauf es zugreifen kann, und diese Oberfläche könnte breiter sein als du erwartet hast.
Genau hier macht das Definieren des Ausführungsbereichs vor dem Start von Claude Code auf einer Kundenseite den Unterschied zwischen einer glatten Session und einem Zwischenfall. "Modifiziere nur die Polylang-Config. Rühre den Seiteninhalt nicht an." Diese Art expliziter Grenze.
Noch eine Sache, die die REST API nicht abdeckt: PHP-Dateien, Theme-Code, WordPress Core. Dafür brauchst du SSH-Zugang. Claude Code weiß das und sagt es, wenn es an diese Wand stößt.
Das App-Passwort gibt dir die Schlüssel zum LKW. Du solltest besser gesagt haben, wohin du fährst, bevor du den Motor startest.
Nächstes Jahr wird jemand ein WordPress-Plugin für 29€/Monat rausbringen, das genau das macht. Saubere UI. Sieben-Schritte-Onboarding. Leute werden zahlen.
Währenddessen ist die REST API seit 2021 da. Das App-Passwort dauert dreißig Sekunden. Claude Code findet den Rest heraus. Kein Plugin. Kein Setup. Kein Abo.
(Und für die App-Passwort-Rotation über alle deine Seiten? Du fragst einfach Chrome in Claude, sie stapelweise zu generieren. Psst.) 🤫
Quellen
WordPress REST API Handbook: developer.wordpress.org/rest-api
Falls dein Workflow heutzutage mehr Claude Code als Stack Overflow beinhaltet, schreibe ich über die Muster, die tatsächlich shippen. Folge mit, wenn das deine Art von Lektüre ist.
(*) Das Cover ist KI-generiert. Die Flaggen sind aber akkurat, was mich mehr überrascht hat als der Artikel selbst.
Wie ein KI-Agent eine WordPress-Seite in Minuten übernimmt – direkt aus der Praxis der Produktions-Automatisierung.