5 Sicherheitsmaßnahmen, bevor du einen KI-Coding-Agenten an WordPress lässt

Hinweis: Ich entwickle die Mac-App ShipPress. Am Ende des Artikels stelle ich sie kurz vor. Die Tipps davor funktionieren auch ganz ohne mein Tool.

Mit Claude Code oder Codex kann man inzwischen erstaunlich viel an einem WordPress-Theme oder an Seiten erledigen lassen. Gleichzeitig gehen Agenten manchmal etwas über den Auftrag hinaus: Sie ändern Dateien, die sie nicht anfassen sollten, oder schreiben direkt in die Datenbank. Hier sind fünf Dinge, die ich nach einigen Monaten mit KI und WordPress gerne von Anfang an gemacht hätte.

1. Lokal oder auf Staging arbeiten, nicht auf Produktion

Klingt banal, bringt aber am meisten. Lass den Agenten nicht per SSH auf der Live-Seite arbeiten. Besser: lokal oder auf einer Staging-Umgebung ändern, prüfen und erst dann übernehmen.

Ob wp-env, Local oder Docker ist egal. Wichtig ist nur, dass es ein Ort ist, an dem kaputte Dinge niemandem wehtun.

2. Das Arbeitsverzeichnis eingrenzen

Wenn du dem Agenten das ganze Repo oder das WordPress-Root gibst, liest er auch wp-config.php und Core-Dateien. Soll er nur am Theme arbeiten, starte ihn im Theme-Ordner:

cd wp-content/themes/my-theme
claude   # oder codex usw.

Bei Claude Code hilft zusätzlich eine CLAUDE.md im Projekt, die festhält, was erlaubt ist:

## Regeln
- Nur Dateien unter wp-content/themes/my-theme ändern
- wp-config.php und Core-Dateien weder lesen noch ändern
- Neue Plugins nur vorschlagen, nicht selbst installieren

3. Nicht nur Dateien, auch die Datenbank sichern

Dateien lassen sich mit git zurückdrehen. Aber Beiträge, Seiten, Menüs und Änderungen an Block-Theme-Templates liegen in der Datenbank. Mit git allein bekommst du eine von der KI erstellte Seite nicht zurück.

Vor jeder Session also ein Export mit WP-CLI:

# vorher
wp db export backups/before-ai-$(date +%Y%m%d-%H%M).sql

# zurück, wenn nötig
wp db import backups/before-ai-20261028-1300.sql

Und auf der Dateiseite nach jedem Schritt committen:

git add -A && git commit -m "vorher: Header-Farbe ändern lassen"

4. Aufträge klein halten

„Bau mir die ganze Website" ist schwerer zu prüfen und zurückzunehmen als „Bau nur den Hero-Bereich der Startseite". Wenn du in kleinen Runden arbeitest (Auftrag, prüfen, Snapshot), siehst du sofort, welche Anweisung etwas kaputt gemacht hat.

5. Vor dem Deploy den Diff anschauen

Bevor etwas live geht, prüfe ich mindestens das hier:

git diff --stat                  # welche Dateien sich geändert haben
wp plugin list --status=active   # sind unbekannte Plugins dazugekommen?
wp option get siteurl            # wurde die URL umgeschrieben?

Landen siteurl oder home mit der lokalen URL auf Produktion, ist die Seite nicht mehr erreichbar. Darauf lohnt sich ein zweiter Blick.

Zusammenfassung

• Lokal oder auf Staging arbeiten
• Den Arbeitsbereich des Agenten eingrenzen
• Dateien mit git, Datenbank mit wp db export sichern
• Kleine Aufträge, nach jedem Schritt prüfen
• Vor dem Deploy Diff und Einstellungen kontrollieren

Nebenbei: eine App, die das automatisch macht

Weil mir die Schritte 1 bis 3 jedes Mal zu viel Handarbeit waren, habe ich die kostenlose Mac-App ShipPress gebaut. Sie richtet eine lokale WordPress-Umgebung ein, lässt deine vorhandene KI-CLI (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) die Seite bauen und legt bei jeder Änderung der KI einen Wiederherstellungspunkt an. Veröffentlichen kannst du über Host-Integrationen wie InstaWP, per SSH oder als statischen Export.

Download: https://shippress.codotx.com/?ref=devto-de

Wenn ihr eigene Tricks habt, um KI-Agenten bei WordPress sicher arbeiten zu lassen, freue ich mich über einen Kommentar.

Oberon Lai