Zurück zum Blog
15. August 2026

Website mit KI erstellen — Schritt für Schritt

Vom Prompt in Alltagssprache zur veröffentlichten Website mit Tests und Qualitätsprüfungen — hier ist der komplette Ablauf, mit echten Screenshots, an einem Nachmittag.

Eine Website mit KI zu erstellen ist längst kein Partytrick mehr. Die interessante Frage ist nicht mehr „kann die KI eine Seite erzeugen?", sondern „erzeugt sie eine Website, unter die ich meinen Namen setzen würde — mit funktionierendem Backend, Prüfungen, denen ich vertraue, und einer echten Domain?" Dieser Walkthrough zeigt den ganzen Weg in XAIO: vom ersten Satz bis zur Live-Schaltung.

Schritt 1 — Beschreib, was du willst

Starte mit einem Prompt in Alltagssprache: wofür die Website ist, wer sie besucht, was sie können soll. Häng an, was du schon hast — Logo, Screenshots eines Designs, das dir gefällt, ein PDF mit Anforderungen. Kein Setup, keine Konfiguration vorab.

Sei konkret beim Ergebnis statt bei der Technik. „Eine Seite für einen Großhändler, auf der Kunden sich einloggen und ihre Kontohistorie sehen" schlägt „eine moderne, responsive Website". XAIO plant die Architektur aus deiner Absicht.

Der XAIO-Build-Prompt: Beschreibe deine App in natürlicher Sprache
Der Startpunkt: ein Prompt, optional mit Datei-Anhängen.

Schritt 2 — XAIO bauen lassen (und die eigene Arbeit prüfen)

XAIO generiert die Website als ein konsistentes System — Seiten, Styling, Backend-Logik und Datenbank, wo nötig, plus Tests. Build-Fehler werden dabei automatisch abgefangen und repariert; du debuggst also keinen halbfertigen Output.

Jede Änderung läuft danach durch automatische Checks. Im Screenshot unten hat eine kleine Textänderung 43 Prüfungen ausgelöst, bevor sie akzeptiert wurde. Verfeinert wird im Chat: „füge der Headline einen Typewriter-Effekt hinzu", „mach den Ton förmlicher", „ergänze eine Preissektion".

XAIO-Workspace: Chat links, Live-Vorschau und automatische Checks rechts
Der Workspace: Chat, Live-Vorschau und 43 automatische Checks für eine einzige Änderung.

Schritt 3 — Im Design-Modus zu deinem Look machen

Fürs visuelle Feintuning musst du nicht alles in Worte fassen. Im Design-Modus klickst du jedes Element der echten, laufenden Website an und änderst Text, Farben, Abstände oder Layout direkt — oder bittest die KI um eine gezielte Änderung genau an diesem Element. Änderungen an geteilten Komponenten gelten überall, wo sie verwendet werden.

XAIO-Design-Modus: Headline auswählen und visuell bearbeiten
Design-Modus: Element auswählen, direkt umstylen oder an die KI übergeben.

Schritt 4 — Veröffentlichen, durch die Quality-Gates

Ein Klick startet den Publish — aber nichts geht live, bevor die Gates bestehen. Zuerst läuft deine generierte Test-Suite gegen einen eingefrorenen Stand von exakt dem Code, der ausgeliefert wird, mit eigener frischer Testdatenbank — Änderungen, die du währenddessen machst, können das Ergebnis nicht verfälschen. Danach prüft die automatische Sicherheits- und Code-Qualitätsprüfung das Release: Schwachstellen, offengelegte Secrets, riskante Dependencies. Ein fehlgeschlagenes Gate blockiert den Publish — und die meisten Findings kommen mit einem Ein-Klick-Fix, der das Problem repariert und die Checks erneut laufen lässt.

Erst wenn Domain, Website-Build, Backend und QA alle grün sind, geht die Seite live — sofort auf einer kostenlosen .xaio.app-Subdomain oder auf deiner eigenen Domain. Jeder Publish bekommt eine Versionsnummer; Republish und Rollback gehen jederzeit.

Das XAIO-Publish-Panel mit Domain-Einstellungen, Version und QA-Gates
Veröffentlichen: Gates für Domain, Backend und QA — dann ist die Seite live.

Was du am Ende hast

Das ist der Unterschied zwischen „eine Seite generieren" und „eine Website ausliefern". Wer tiefer einsteigen will, liest, wie Code-Generierung und Release-Gate funktionieren — oder probiert den Ablauf einfach selbst aus.

  • Eine live geschaltete Website auf deiner Domain — veröffentlicht mit Tests und einer Sicherheits- und Qualitätsprüfung dahinter.
  • Echten, exportierbaren Code (React, dazu FastAPI und PostgreSQL, wenn deine Seite ein Backend braucht) — pushbar zu GitHub oder self-hostbar.
  • Einen Workspace, in dem jede künftige Änderung durch dieselben Checks läuft wie der erste Build.