ChatGPT Sites: Vom Rechner-Briefing zur kontrollierten Veröffentlichung

Ein Workshop-Anbieter möchte Interessierten zeigen, wie sich der Preis aus Teilnehmerzahl, Dauer und Materialpaket zusammensetzt. Statt einer statischen Tabelle soll ein kleiner Rechner Eingaben aufnehmen, den Gesamtpreis erklären und einen unverbindlichen nächsten Schritt anbieten. Dieses begrenzte Produkt begleitet uns vom ersten Sites-Brief bis zur veröffentlichten Version.

OpenAI kündigte ChatGPT Sites am 9. Juli 2026 als öffentliche Beta an. Der Dienst kann fokussierte Websites, Web-Apps und Spiele erstellen, hosten, verfeinern und teilen; Zugriff hängt von Region, Plan, Rollout und Workspace ab.

Den Rechner als Produktauftrag beschreiben

Ein Brief sollte zuerst Zweck und Zielgruppe nennen. In unserem Beispiel nutzen kleine Teams den Rechner, um vor einer Anfrage eine transparente Kostenspanne zu verstehen. Sie wählen zwei bis zwölf Teilnehmende, eine halbe oder ganze Workshop-Dauer und optional ein Materialpaket.

Schreibe auch die Berechnungsregel ausdrücklich auf: Grundpreis plus Preis je Person plus optionales Material, jeweils mit klarer Währung und Rundung. Sites darf keine Rabatte erfinden, keine Buchung auslösen und zunächst keine personenbezogenen Daten speichern. Diese Grenzen folgen denselben Prinzipien wie Dein erster guter Prompt.

Einen vollständigen ersten Brief formulieren

Ein brauchbarer Startauftrag könnte so aussehen:

Erstelle eine deutschsprachige, responsive Site für einen Workshop-
Kostenrechner. Zielgruppe sind kleine Teams, die eine unverbindliche
Preisspanne prüfen möchten.

Eingaben: 2–12 Personen, halber oder ganzer Tag, Materialpaket ja/nein.
Berechnung: Grundpreis 300 Euro; 45 Euro je Person für einen halben Tag,
75 Euro je Person für einen ganzen Tag; Material 20 Euro je Person.
Zeige Rechenweg und Gesamtbetrag inklusive Hinweis „unverbindlich“.

Keine Zahlung, keine Buchung, kein Login und keine Datenspeicherung.
Ergänze verständliche Fehlerzustände und einen Link zur Kontaktseite.

Der Auftrag trennt vorhandene Funktion von späteren Ideen. Das hält die Vorschau klein genug, um Berechnung, Inhalt und Bedienung wirklich zu prüfen.

Die private Vorschau systematisch lesen

Beginne nicht sofort mit Farben und Animationen. Prüfe zuerst, ob Überschrift, Erklärung, Eingaben und Ergebnis in einer nachvollziehbaren Reihenfolge stehen. Eine Person sollte ohne Vorwissen verstehen, welche Werte den Preis beeinflussen und dass noch keine verbindliche Buchung entsteht.

Spiele einen konkreten Fall durch: vier Personen, ganzer Tag, Materialpaket. Erwartet werden 300 Euro Grundpreis, 300 Euro Teilnehmeranteil und 80 Euro Material, also 680 Euro gesamt. Wenn Zahl oder Rechenweg abweichen, beschreibe genau diesen Fall im nächsten Änderungsauftrag.

Halte die Abnahme in einer kleinen Tabelle fest: Prüffall, erwarteter Betrag, tatsächlich sichtbarer Betrag und Status. Ergänze mindestens einen Standardfall, beide Teilnehmergrenzen und jede optionale Auswahl. So wird aus einem flüchtigen Blick eine wiederholbare Prüfung, die auch nach einer späteren Text- oder Designänderung noch funktioniert.

Lass den Kandidaten anschließend von einer Person testen, die den Brief nicht geschrieben hat. Beobachte, welche Eingabe sie zuerst wählt, ob sie Einheiten und Annahmen versteht und ob sie den unverbindlichen Charakter des Ergebnisses erkennt. Rückfragen zeigen, wo Erklärung oder Feldbeschriftung fehlen; sie sind kein Grund, die Formel stillschweigend zu verändern.

Eingaben, Fehlerfälle und Zugänglichkeit prüfen

Teste die Grenzen zwei und zwölf sowie Versuche unterhalb und oberhalb des erlaubten Bereichs. Freitext, Dezimalwerte und ein leeres Feld dürfen keinen unverständlichen Betrag wie NaN erzeugen. Die Site soll die Eingabe blockieren oder verständlich korrigieren und den Fokus an die Fehlerstelle führen.

Prüfe Tastaturbedienung, Beschriftungen, Kontrast und schmale Bildschirmbreiten. Der Gesamtpreis sollte nicht nur durch Farbe ausgezeichnet sein, und eine Änderung der Auswahl muss den Rechenweg konsistent aktualisieren. Ein kurzer realer Nutzerfluss ist ebenso wichtig wie die sichtbare Gestaltung.

Daten und Zugriff vor Erweiterungen klären

Der erste Rechner verarbeitet seine Werte nur für die sichtbare Berechnung. Sobald ein Kontaktformular, gespeicherte Angebote oder Datei-Uploads hinzukommen, ändert sich der Datenfluss. Die Sites-Dokumentation beschreibt je nach Bedarf Speicheroptionen; ob und wie du sie nutzt, muss aus einem konkreten fachlichen Zweck entstehen.

Lege vor jeder Datenerfassung fest, welche Angaben nötig sind, wer sie sehen darf und wie lange sie bestehen. Prüfe außerdem, ob externe Dienste, Analytics oder eingebettete Inhalte Daten übertragen. „Mit KI erstellt“ reduziert keine Betreiberpflichten.

Zielgruppe und Freigabemodell wählen

Nicht jede Site sollte öffentlich sein. Ein interner Rechner mit vertraulichen Preisregeln braucht ein anderes Zugriffsmodell als eine öffentliche Orientierungshilfe. Prüfe die in deinem Plan und Workspace verfügbaren Freigabeoptionen und teste den Zugriff mit einem Konto, das nicht am Bau beteiligt war.

Formulare und nutzergenerierte Inhalte erhöhen das Risiko. Bevor du sie freigibst, brauchst du klare Berechtigungen, Missbrauchsschutz und eine verantwortliche Stelle für eingehende Daten. Der Beitrag über KI-Agenten zeigt, warum minimale Rechte auch bei automatisierten Abläufen gelten.

Für den kreativen Prototyp vor der Veröffentlichung hilft außerdem der kontrollierte Ablauf aus Vibe Coding: kleine Änderung, sofortige Vorschau und erst danach der nächste Schritt.

Version speichern und bewusst veröffentlichen

OpenAI unterscheidet zwischen Bearbeitungsansicht und Deployment. Laut Sites-Dokumentation ist jede Deployment-URL eine Produktions-URL; speichere deshalb unmittelbar vor dem Release eine Version, die alle Prüfungen bestanden hat. Notiere, welche Berechnungsregel und welche Inhalte diese Version enthält.

Öffne nach der Veröffentlichung genau die geteilte URL in einem privaten Browserfenster. Wiederhole Standardfall, Grenzwerte, Rücknavigation und mobile Ansicht. So stellst du fest, ob der öffentliche Stand wirklich dem geprüften Kandidaten entspricht.

Rechtliche und inhaltliche Verantwortung übernehmen

Der Betreiber verantwortet Aussagen, Berechnungen, Zugriffe und Datenverarbeitung. Für den Beispielrechner müssen Preisstand, Währung, Steuerhinweis und Unverbindlichkeit fachlich korrekt und aktuell sein. Öffentliche Sites brauchen außerdem passende Kontakt-, Impressums- und Datenschutzinformationen nach den für Betreiber und Zielgruppe geltenden Regeln.

Die ChatGPT-Sites-Nutzungsbedingungen ergänzen die allgemeinen Produktregeln. Lies sie vor der Veröffentlichung und lass rechtlich oder finanziell relevante Inhalte fachlich prüfen. Ein automatisch erzeugter Disclaimer korrigiert keine falsche Berechnung.

Betrieb und Rückweg planen

Eine Site ist nach dem Teilen nicht fertig. Benenne eine verantwortliche Person, einen Prüfzyklus für Preise und Links sowie einen Weg, Fehler zu melden. Speichere vor Änderungen eine funktionierende Version, damit du bei einer Regression kontrolliert zurückkehren kannst.

Beobachte besonders den Kernfluss, ohne unnötig persönliche Daten zu sammeln. Wenn der Rechner falsche Preise ausgibt, sollte er vorübergehend deaktiviert oder auf eine sichere Informationsseite zurückgesetzt werden können. Änderungen durchlaufen danach wieder Vorschau, Prüfung und Release.

Führe ein kurzes Release-Protokoll mit Versionszeitpunkt, geprüften Beispielen, öffentlicher URL und verantwortlicher Person. Bei einer Preisänderung lässt sich dadurch nachvollziehen, welcher Stand wann sichtbar war und welche Regel ersetzt wurde. Das Protokoll sollte keine Formulareingaben oder andere unnötige Nutzerdaten enthalten.

Plane auch die Kommunikation bei einem Fehler. Ein sichtbarer Hinweis mit alternativem Kontaktweg ist hilfreicher als ein Rechner, der still einen falschen Betrag zeigt. Nach der Korrektur wiederholst du dieselben Referenzfälle und dokumentierst die erneute Freigabe.

Wann Sites nicht die passende Architektur ist

Ein fokussierter Rechner passt gut zum promptbasierten Sites-Ablauf. Ein System mit komplexer Zahlungsabwicklung, spezialisierten Hintergrunddiensten, strengen Audit-Anforderungen oder tiefen Integrationen kann eine klassische Softwarearchitektur und eigene Betriebsprozesse benötigen. Entscheide nach Anforderungen, nicht nach der Kürze des ersten Entwurfs.

Auch Verfügbarkeit ist eine Grenze. Plane keine verbindliche Einführung, bevor Sites im benötigten Plan, Workspace und in der Zielregion tatsächlich freigeschaltet und getestet ist. Die aktuellen Release-Notes und Hilfeartikel sind dafür die maßgeblichen OpenAI-Quellen.

Checkliste vor jeder Sites-Veröffentlichung

• Zielgruppe, Kernaufgabe und ausdrücklich ausgeschlossene Funktionen sind dokumentiert.
• Berechnungsregeln und fachliche Inhalte wurden mit konkreten Beispielen geprüft.
• Leere, ungültige und minimale beziehungsweise maximale Eingaben sind abgefangen.
• Tastatur, Beschriftungen, Kontrast und mobile Ansicht funktionieren.
• Datenflüsse, Speicher, externe Dienste und Zugriffsmodell sind nachvollziehbar.
• Rechtliche Seiten und verantwortliche Betreiberangaben passen zum tatsächlichen Einsatz.
• Eine geprüfte Version wurde unmittelbar vor dem Deployment gespeichert.
• Die veröffentlichte Produktions-URL wurde unabhängig erneut getestet.
• Verantwortliche Person, Monitoring, Änderungsprozess und Rückweg sind festgelegt.