Die Seite, die Sie gerade lesen, ist unser erstes Referenzprojekt. Nicht, weil sie besonders groß wäre, sondern weil sie den ganzen Weg zeigt: von der leeren Domain bis zur laufenden Website, die jemand ohne Serverzugang aktualisieren kann.
Ausgangslage
Eine neue Firma braucht eine Website. Die üblichen Wege sind ein Baukasten, der die Daten irgendwo anders hält, oder eine Agentur, die Wochen braucht. Wir wollten beides nicht. Die Anforderungen waren klar: WordPress, damit Inhalte später ohne Entwickler gepflegt werden können. Ein eigenes Theme statt einer gekauften Vorlage. Keine externen Dienste, keine Tracking-Skripte, keine Schriften von fremden Servern. Und ein Deployment, das ein KI-Agent selbst auslösen kann – ohne SSH-Zugang auf den Server.
Lösung
Der Agent hat das Projekt als Docker-Compose-Stack mit drei Diensten angelegt: WordPress, MariaDB und ein kurzlebiger Einrichtungscontainer, der nach dem Start wartet, bis die Datenbank antwortet, WordPress installiert, das Theme aktiviert und dann ein PHP-Skript per wp-cli ausführt. Dieses Skript legt Seiten, Beiträge, Kategorien, Menüs und Optionen an. Es ist idempotent: Es merkt sich eine Versionsnummer und überschreibt bei späteren Deployments keine Inhalte, die jemand im Redaktionsbereich geändert hat.
Das Theme ist ein klassisches WordPress-Theme mit 55 Dateien: Templates, ein Hero-Slider, Kartenlayouts, ein dunkler Footer und Icons als SVG. Die beiden Schriften liegen als variable WOFF2-Dateien im Theme selbst. Der Datei-Editor im Backend ist abgeschaltet; Änderungen laufen ausschließlich über das Projektverzeichnis.
Veröffentlicht wird über die Hosting-API unseres Partners: Der Agent packt das Projektverzeichnis als tar.gz und schickt es mit einem Token, das nur für diese eine Applikation gilt, an POST /api/site/deploy. Der Host prüft die Compose-Datei gegen feste Regeln, stoppt den alten Stand, baut den neuen und wartet bis zu 60 Sekunden auf eine HTTP-Antwort. Bleibt die aus, kommt der alte Stand automatisch zurück, und der Agent bekommt die Logs. Über dieselbe API hat er ein Versandpostfach für das Kontaktformular eingerichtet – inklusive SPF, DKIM und DMARC – und die Seite für Suchmaschinen erst einmal gesperrt, bis die Abnahme erfolgt ist.
Ergebnis
- Website mit Leistungsseiten, Blog, Referenzen, Kontaktformular, Impressum und Datenschutzerklärung – alles aus einem Skript reproduzierbar
- Keine Cookies für Besucher, keine Drittdienste, alle Schriften und Skripte vom eigenen Server
- Deployment in unter zwei Minuten, Rollback in Sekunden, Logs auf Abruf
- Der Agent hatte zu keinem Zeitpunkt Zugriff auf den Server, nur auf seine eine Applikation
Was wir daraus gelernt haben
Drei Dinge. Erstens: Die Provisionierung als Code ist der eigentliche Gewinn. Wer die Inhalte im Skript hat, kann die Site jederzeit neu aufbauen, auf Staging kopieren oder den Stand von gestern vergleichen. Zweitens: Das Wartemuster am Anfang entscheidet über die Stabilität. Eine Datenbankabfrage, die erst dann durchgeht, wenn MariaDB wirklich bereit ist, ist zuverlässiger als jeder feste Sleep. Drittens: Der Agent hat die Rechtstexte von sich aus angelegt, weil die Regeln des Hosts es verlangen. Pflichtangaben, die in einer Regeldatei stehen, werden nicht vergessen.