KI-Website veröffentlichen: der 7-Punkte-Release-Check

Eine KI kann in Minuten eine überzeugende Landingpage oder ein Formular bauen. Der schnelle Entwurf ist der große Vorteil von Vibe Coding. Gleichzeitig verführt genau diese Geschwindigkeit dazu, die Vorschau mit einem fertigen Produkt zu verwechseln. Eine Website kann gut aussehen und trotzdem falsche Links, verlorene Formulardaten, unklare Fehlermeldungen oder eine ungeschützte Serveraktion enthalten.

Der folgende Release-Check nutzt eine Workshop-Anmeldung als Beispiel. Besucher wählen einen Termin, tragen E-Mail und Namen ein und erhalten eine Bestätigung. Sieben Gates trennen den KI-Entwurf von einer verantwortbar veröffentlichten Version. Für jedes Gate brauchst du einen sichtbaren Beleg, nicht nur die Aussage „sollte funktionieren“.

1. Ziel und Scope vor dem Test einfrieren

Schreibe zuerst in einem Satz auf, was nach dem Release möglich sein muss: „Eine interessierte Person kann auf Mobil und Desktop einen verfügbaren Workshop wählen, gültige Kontaktdaten absenden und eine eindeutige Bestätigung erhalten.“ Daneben notierst du, was nicht Teil dieses Releases ist, etwa Bezahlung, Nutzerkonto und Kalender-Synchronisierung.

Diese Grenze verhindert, dass die KI während der Prüfung neue Funktionen ergänzt und dabei bereits funktionierende Teile verschiebt. Ein klarer Prompt nennt außerdem die betroffenen Dateien, unveränderte Bereiche und Abnahmekriterien. Sichere die Ausgangsversion in Git oder als benannte Vorschau. Damit kannst du später belegen, welche Änderung geprüft wurde.

2. Den wichtigsten Nutzerweg im echten Browser durchspielen

Öffne die Seite wie ein Besucher, nicht nur als Entwickler. Starte auf der öffentlichen Einstiegsseite, navigiere zur Anmeldung, wähle einen Termin, fülle das Formular aus und prüfe den Zielzustand. Wiederhole den Ablauf nach einem Neuladen und auf schmalem Viewport. Links, Fokus, Ladeanzeige und Bestätigung gehören zum Flow.

Playwright empfiehlt, automatisierte Tests am sichtbaren Nutzerverhalten auszurichten. Suche also einen Button über Rolle und zugänglichen Namen und prüfe die sichtbare Erfolgsmeldung. Eine interne CSS-Klasse beweist nicht, dass ein Mensch die Aktion findet oder versteht.

Der Happy Path reicht nicht. Prüfe mindestens einen leeren, einen ungültigen und einen technischen Fehlerfall:

• Kein Termin verfügbar: Die Seite erklärt den Zustand und bietet einen sinnvollen nächsten Schritt.
• E-Mail ungültig: Das betroffene Feld erhält verständliches Feedback und bleibt fokussierbar.
• Doppelklick oder langsames Netz: Die Anmeldung wird nicht mehrfach gespeichert.
• Server nicht erreichbar: Eingaben verschwinden nicht kommentarlos und Erfolg wird nicht vorgetäuscht.

3. Formulare auf beiden Seiten der Grenze absichern

HTML-Typen, required, sinnvolle Längen und direktes Feedback helfen dem Nutzer. MDN betont aber, dass clientseitige Validierung keine vollständige Sicherheitsmaßnahme ist: Anfragen lassen sich am Browser vorbei senden. Der Server muss deshalb dieselben fachlichen Grenzen unabhängig prüfen.

Für die Workshop-Anmeldung bedeutet das: Der Server akzeptiert nur existierende Termin-IDs, begrenzt Feldlängen, normalisiert die E-Mail bewusst und lehnt unerwartete Zusatzfelder ab. Er prüft außerdem, ob der Termin noch frei ist. Eine versteckte Formular-ID ist keine Berechtigung.

Notiere den Datenweg: Welche Daten verlassen den Browser, wo werden sie gespeichert, wer kann sie lesen und wann werden sie gelöscht? Wenn die KI keine eindeutige Antwort aus Code und Konfiguration liefern kann, ist das ein offenes Release-Risiko.

4. Tastatur, Semantik und verständliche Rückmeldung prüfen

WCAG ist der gemeinsame Standard für zugänglichere Webinhalte. Für einen kleinen Release brauchst du nicht jede Anforderung auswendig zu kennen, aber der Kernflow muss ohne Maus bedienbar und verständlich sein. Navigiere nur mit Tab, Shift+Tab, Enter und Leertaste. Der Fokus darf nicht verschwinden oder hinter einem Dialog landen.

Prüfe sichtbare Labels, Überschriftenreihenfolge, Kontrast, Alternativtexte und Statusmeldungen. Vergrößere auf 200 Prozent und teste einen schmalen Viewport. Ein automatischer Audit hilft beim Finden einfacher Probleme; er ersetzt weder Tastaturprüfung noch einen kurzen Screenreader- oder Nutzercheck.

5. Sicherheitsgrenzen statt KI-Zuversicht kontrollieren

OWASP beschreibt wiederkehrende Webrisiken wie fehlerhafte Zugriffskontrolle, Sicherheitsfehlkonfiguration, Lieferkettenprobleme und Injection. Übersetze diese Kategorien in Fragen, die zu deiner Website passen. Kann ein Besucher fremde Anmeldungen lesen? Liegt ein geheimer Schlüssel im Browser-Bundle? Vertraut der Server einer Rollenangabe aus dem Formular? Werden externe Pakete und Umgebungsvariablen kontrolliert?

Lass die KI zuerst Fundstellen und Belege nennen, bevor sie etwas ändert. Bei Authentifizierung, Zahlung, Gesundheits- oder anderen sensiblen Daten ist ein fachkundiges Review kein Luxus. Automatisch erzeugter Code ist nicht grundsätzlich unsicher, aber seine überzeugende Form darf fehlende Schutzannahmen nicht verdecken.

6. Performance auf relevanten Geräten messen

web.dev führt LCP, INP und CLS als stabile Core Web Vitals für Ladeerlebnis, Reaktionsfähigkeit und visuelle Stabilität. Sie sind nützliche Signale, aber kein einzelner „bestanden“-Knopf. Messe zuerst die reale Seite mit ihren Bildern, Schriften und Drittanbietern.

Teste mindestens ein typisches Smartphone, eine langsame Verbindungssimulation und den Desktop-Browser deiner Zielgruppe. Achte besonders auf das größte Bild, blockierende Skripte, verzögert reagierende Buttons und Layoutsprünge beim Laden. Lege ein kleines Budget fest, etwa maximale Bildgrößen und keine neue blockierende Drittanbieter-Abhängigkeit ohne Begründung.

7. Freigabe, Beobachtung und Rückweg vorbereiten

Vor dem Go-live beantwortest du drei Betriebsfragen: Wer gibt frei? Woran erkennt ihr einen Fehler? Wie kehrt ihr zur letzten funktionierenden Version zurück? Eine Plattformvorschau wie im ChatGPT-Sites-Guide ist ideal für die letzte Abnahme, solange Zugriffsgruppe und Formulardaten bewusst gewählt sind.

Veröffentliche eine konkrete geprüfte Version, nicht „den aktuellen Stand“. Kontrolliere danach die öffentliche URL, den Kernflow, Serverfehler und echte Formularereignisse. Ein Rollback ist erst belastbar, wenn Zielversion, Zuständigkeit und Vorgehen bekannt sind.

Kompakte Go-live-Checkliste

• Ziel, Nicht-Ziele und geprüfte Version sind dokumentiert.
• Happy Path, leere Zustände, ungültige Eingaben und Serverfehler wurden im Browser geprüft.
• Client und Server validieren Eingaben; Rechte und Datenweg sind nachvollziehbar.
• Der Kernflow funktioniert per Tastatur, bei Vergrößerung und auf relevantem Mobilgerät.
• Secrets, Umgebungsvariablen, Abhängigkeiten und öffentliche Endpunkte wurden kontrolliert.
• Performance wurde mit realen Assets gemessen und kritische Regressionen sind behoben.
• Freigabe, Monitoring und Rollback haben eine verantwortliche Person.

Der Sinn dieser Gates ist nicht, einen schnellen KI-Workflow langsam zu machen. Sie schützen seinen eigentlichen Vorteil: Aus einer Idee wird zügig ein nutzbares Produkt, dessen Verhalten du erklären und verantworten kannst. Wenn ein Gate keinen Beleg hat, formuliere den fehlenden Nachweis als nächsten kleinen Auftrag. So bleibt die Iteration schnell, ohne die Veröffentlichung zum Glücksspiel zu machen.