Sites als kleines Businesswerkzeug entwickeln

Ein kleines Werkzeug braucht einen klaren Zweck

Die Lernwerkstatt möchte Angebote vergleichen und einen Budgetstand sichtbar machen. Sie braucht dafür keinen kompletten Kundenbereich. Beginne mit einer kleinen Seite: drei Angebote, ein veränderbarer Raumpreis, Budgetsumme und offene Angaben. Ein einfacher Prototyp ist leichter zu prüfen und später gezielt zu erweitern.

Verfügbarkeit, geprüft am 5. Oktober 2026: Sites ist in öffentlicher Beta für berechtigte Plus-, Pro-, Business-, Enterprise- und Edu-Pläne; Free und Go sind ausgeschlossen. Die allgemeine Sites-Dokumentation nennt keine regionale Grenze; der spezifische Internal-Apps-Guide nennt für Sites zum Start einen Ausschluss im EWR, UK und der Schweiz. Diese unterschiedlich genauen Angaben belegen weder pauschalen heutigen EU-Zugang noch einen dauerhaften Ausschluss. Prüfe deshalb die tatsächliche Freischaltung in deinem Konto und Workspace. Ohne Freischaltung kannst du Konzept, Übungsdaten und Kontrollfälle vorbereiten.

Schritt 1: Nutzer und Handlung beschreiben

Wer benutzt die Seite? Was soll diese Person danach entscheiden? Für die Übung ist das die interne Leitung. Sie soll Kapazität und Kosten vergleichen, aber keinen Raum buchen. Definiere diese Grenze vor dem Entwurf. Wenn du später Daten speichern oder echte externe Systeme anbinden willst, gehören Zugriffe, Betrieb und Datenschutz in einen eigenen geprüften Schritt.

Entwirf einen kleinen internen Workshopvergleich mit fiktiven Daten.
Zeige die drei Übungsangebote, ihren Terminstatus und ihre Kapazität.
Ergänze einen Budgetrechner mit Raum 240, Moderation 210, Material 70,
Verpflegung 90 Euro und Rahmen 700 Euro, alles netto.
Bei geändertem Raumpreis müssen Summe und Rest korrekt reagieren.
Zeige Datenstand und offene Angaben. Keine Buchungs-/Versandformulare,
keine Kundendaten, keine externe Anmeldung. Zeige Desktop und Mobile.
Erstelle einen prüfbaren Entwurf. Veröffentliche nichts ohne Freigabe.

Schritt 2: Vorschau systematisch prüfen

Öffne die tatsächliche Vorschau. Prüfe Quellen, Zahlen und alle Bedienelemente. Die Ausgangssumme ist 610 Euro; ein Raumpreis von 260 ergibt 630. Anbieter C mit 16 Plätzen passt nicht zur Planung für 18 Personen. Der Termin von A ist offen. Die Seite muss diese Grenzen zeigen, auch wenn die Gesamtempfehlung attraktiv klingt.

Teste leere Suchergebnisse, Zurücksetzen, ungültige Zahleneingaben und einen kleinen Bildschirm. Benutze die Tastatur. Ein Regler ohne sichtbaren Namen oder eine Farbe ohne Text erklärt zu wenig. Bitte um konkrete Korrekturen: „Der Restbetrag reagiert nicht auf die Eingabe; behebe die Berechnung und teste beide Kontrollfälle.“

Schritt 3: Datenstand und Aktualisierung trennen

Eine Seite mit der Überschrift „wöchentlich aktualisiert“ ist noch kein eingerichteter Aktualisierungsprozess. Notiere Datenquelle, Prüfdatum und tatsächlichen Aktualisierungsweg. Wenn später ein Zeitplan eingerichtet wird, teste erst den Einzelablauf. Eine statische Übungsseite darf ihren Datenstand offen nennen und manuell gepflegt werden.

Schritt 4: Zugriff und Publikum prüfen

Gespeichert, Vorschau und veröffentlicht sind verschiedene Zustände. Prüfe vor Freigabe das konkrete Publikum. Sites mit personenbezogenen Plugin-Daten sind in der aktuellen dokumentierten Form workspace-private und featureabhängig. Das Teilen einer Site teilt nicht automatisch deine verbundenen Konten; Besucher brauchen ihre eigenen passenden Verbindungen und Rechte.

Ein schwer erratbarer Link ist keine Vertraulichkeitsgarantie. Prüfe mit einem berechtigten und einem nicht berechtigten Kontext, welche Inhalte sichtbar sind. Für die fiktive Übung kannst du öffentliches Teilen erwägen, aber auch dort braucht es die konkrete Freigabe der geprüften Version.

Schritt 5: Veröffentlichung als eigenen Arbeitsschritt behandeln

Halte Version, Ziel, Publikum und Testergebnis fest. Nach einem tatsächlichen Deployment öffnest du die veröffentlichte URL selbst. Vergleiche Inhalt und Funktionen mit der geprüften Vorschau. Ein Erfolgsdialog allein beweist nicht, dass die richtige Version für das richtige Publikum erreichbar ist.

Drei Varianten für den Businessalltag

Informationsseite: Sie braucht keine Verbindung zu Kundendaten. Prüfe Quellen, Navigation und Mobilansicht, speichere eine Version und veröffentliche nur die abgenommene Fassung. Das ist der leichteste Anfang.

Internes Werkzeug: Eine Liste fiktiver Anfragen kann Status und Verantwortliche speichern. Teste neue Eingaben, ungültige Werte, Aktualisierung und erneutes Öffnen. Besucher und Editoren haben unterschiedliche Rollen; Editoren müssen im passenden Workspace aktiv sein und können Live-Daten sehen. Die Erstveröffentlichung liegt beim Eigentümer. Gib nicht mehr Bearbeitungsrechte als erforderlich.

Verbundenes Dashboard: Die DevDay-Neuerung kann auf passenden workspace-privaten Sites die eigenen verbundenen Konten jedes Besuchers verwenden. Prüfe mit zwei erlaubten Testnutzern, einem Nutzer ohne Verbindung und einem externen Besucher. Erstellerverbindung, Besuchereinwilligung und Quellrechte bleiben getrennt. Berücksichtige die oben beschriebene regionale Quellenlage und den tatsächlichen Konto-/Rolloutstand.

Betrieb, Domain und sensible Daten

Eine eigene bereits besessene Domain kann über den angebotenen Sites-Weg verbunden werden; Sites registriert keine neue Domain. Zum Start sind Custom Domains nicht für Enterprise zugesagt. Eine Domainänderung ist ein eigener technischer Schritt und wird nicht aus dieser Übung abgeleitet.

Runtime-Secrets gehören in die vorgesehenen Site-Einstellungen, nie in sichtbaren Text oder Quellcode. Änderungen brauchen ein erneutes Deployment. Strukturierte Daten und Dateispeicher haben unterschiedliche Grenzen; prüfe aktuelle Beta-Limits statt einen Prototyp für unbegrenzt zu halten. Daten-/Inferenzresidenz ist zum Start nicht zugesagt. Laut Dokumentation eignen sich Sites nicht für geschützte Gesundheitsinformationen, Kartenzahlungsdaten oder die Abwicklung von Finanztransaktionen. Das Löschen einer Site ist endgültig; prüfe zuvor Sicherung und weniger einschneidende Zugriffsbeschränkungen.

Weiterführende offizielle Quellen: Internal Apps und Region, Sites im Workspace verwalten. Stand: 5. Oktober 2026.

Variante A: eine reine Informationsseite vollständig durchgehen

Diese Übung ist ein nach den offiziellen Bedienwegen formulierter Lernablauf, kein Nachweis eines hier bereits ausgeführten Sites-Deployments. Sie setzt tatsächlichen Kontozugang voraus. Free und Go sind nicht berechtigt; die regionale Quellenlage steht am Anfang dieses Guides. Auf Desktop öffnest du Sites; im Web More → Sites beziehungsweise chatgpt.com/sites. Beginne einen Work-Auftrag ausdrücklich mit @Sites und lade Projektbrief, Angebote und Budget.

1. Verwende den Vergleichsauftrag oben und ergänze: „Reine Informationsseite, keine gespeicherten Besucherprofile, keine Formulare und keine externen Handlungen.“
2. Lass eine Version speichern, ohne sie zu deployen. Jede tatsächliche Sites-Deployment-URL ist eine Produktionsbereitstellung, auch wenn du sie nur zum Prüfen nutzt. Bitte um die lokale beziehungsweise angebotene Vorschau und benenne Version und Dateien.
3. Prüfe Desktop, Mobilansicht und die zwei Budgetwerte 610/630. Der Vergleich aller Anbieter ergibt A 610, B 730, C 570 Euro netto. B liegt damit 30 Euro über Rahmen; A reicht für 18, nicht für 22; C ist mit 16 Plätzen zu klein und ohne Beamer.
4. Bitte gezielt um eine Korrektur und eine neue gespeicherte Version: „Zeige bei B 30 Euro über Budget; behalte den offenen Termin von A.“ Prüfe die korrigierte Aussage in der Vorschau erneut.
5. Erst nach konkreter Abnahme wählst du das erlaubte Publikum und lässt genau die gespeicherte Version deployen. Öffne die gemeldete URL selbst und prüfe die Zahlen, Links und Mobilansicht. Versionsname, Zeitpunkt und Testergebnis gehören in den Freigabevermerk.

Anbieter B nennt kostenlose Stornierung bis sieben Kalendertage vor Beginn. Für den 8. Oktober ist das der 1. Oktober; am Datenstand 5. Oktober liegt diese Grenze bereits zurück. Eine neue Buchung würde eine ausdrückliche Kostenklärung benötigen. Ob „voller Raumpreis“ auch die Technikpauschale umfasst, ist in den gelieferten Daten nicht entschieden. Die Seite soll diese offene Vertragsfrage zeigen, keine Antwort erfinden.

Variante B: ein internes Werkzeug mit gespeicherten Aufgaben

Beginne eine getrennte Übungs-Site mit drei fiktiven Aufgaben: Agendaentwurf, Raumklärung und Teilnehmerstand. Nutze keine echten Teilnehmernamen. Sage ausdrücklich, was zwischen Besuchen erhalten bleiben soll:

@Sites Erstelle einen workspace-privaten Workshop-Aufgabentracker.
Drei Testaufgaben: Agendaentwurf (Mara, Frist offen), Raumklärung
(Owner offen), finale Teilnehmerzahl (Owner offen).
Speichere Status und Verantwortliche dauerhaft in D1. Eine Aufgabe darf
nicht als freigegeben gelten, solange ihr Owner fehlt. Ergänze Filter,
verständlichen Leerzustand und einen Zurücksetzen-Button.
Kein Versand, keine Buchung, keine echten Personendaten. Speichere einen
prüfbaren Stand; deploye und teile noch nichts.

Prüfe zuerst die drei Startaufgaben. Ändere in der erlaubten Testansicht den Agenda-Status auf „Entwurf liegt vor“. Öffne die Seite erneut beziehungsweise in einem zweiten zugelassenen Testkontext: Der Status muss erhalten bleiben. Ein Wert, der nur bis zum Browser-Neuladen hält, erfüllt keine dauerhafte Speicherung. Versuche außerdem, die Raumklärung ohne Owner freizugeben; erwartet wird eine verständliche Sperre. Teste einen Filter ohne Treffer und danach Zurücksetzen.

D1 ist die SQLite-kompatible Datenbank für strukturierte Werte, beispielsweise Status und Dateimetadaten. R2 speichert die eigentlichen Dateibytes. Ein Tracker ohne Dateianhänge braucht deshalb nicht automatisch R2. Am 5. Oktober nennt die allgemeine Sites-Dokumentation 10 GB D1-Speicher je Site und keinen festen R2-Speichergrenzwert; planabhängige Beta-Nutzungslimits gelten weiterhin. Das ist kein Versprechen unbegrenzter kostenloser Nutzung.

Für Zusammenarbeit öffnet der Eigentümer Share, fügt ein aktives Mitglied desselben Workspace zuerst als Besucher hinzu und wählt daneben Can view → Can edit. Der Editor kann live gespeicherte Daten lesen, ändern und Versionen speichern. Erst nach der ersten Veröffentlichung durch den Eigentümer darf er Updates veröffentlichen. Er kann weder Publikum/Rechte verwalten noch Einstellungen, Analytics, frühere Versionen wiederherstellen oder Eigentum übertragen. Ein Besucher mit Leserecht erhält diese Editorrechte nicht. Prüfe genau diese zwei Rollen mit freigegebenen Testkonten.

Variante C: ein Dashboard mit eigenen Verbindungen je Besucher

Dieses Beispiel ist ein Entwurfs- und Prüfablauf für einen tatsächlich freigeschalteten Workspace, keine Behauptung, dass dein Konto die Funktion schon hat. Verwende etwa den offiziell beschriebenen Issue-Tracker und eine genehmigte Testprojektquelle. Benenne im Auftrag das tatsächlich installierte Plugin, beispielsweise Linear, und lass zuerst verfügbare Leseaktionen prüfen. Eine erfundene Verbindung oder ein fiktiver Pluginname reicht nicht.

Formuliere: „Workspace-private Site; zeige nur mir zugewiesene Testtickets mit Quelle und manuellem Refresh. Keine Schreibaktion. Beim Verbindungsfehler verständliche Erklärung, keine Ersatzdaten aus dem Erstellerkonto.“ Die Vorschau beim Erstellen benutzt deine eigenen Verbindungen; das beweist noch nicht die Besuchersicht. Für eine freigegebene Bereitstellung werden folgende vier Fälle getrennt geprüft:

Jeder Besucher meldet sich mit ChatGPT an, prüft die angefragten Apprechte und wählt sein verbundenes Konto. Die Verbindung des Erstellers wird durch das Teilen nicht automatisch geteilt. Ein Besucher kann ohne Appfreigabe fortfahren, aber datenabhängige Funktionen funktionieren dann nicht. Teste Refresh, Quelllinks, leere Ergebnisse und gegebenenfalls Load more bei mehreren Datenseiten. Ein Serverfehler darf keine Daten einer anderen Person zeigen. Schreibaktionen würden zusätzliche Freigabe und eine ausdrückliche Nutzerhandlung benötigen; sie gehören nicht in diesen Lesetest.

Adresse, gespeicherte Version und Domain unterscheiden

Eine gespeicherte Version ist ein prüfbarer Kandidat. Ein Deployment macht diese Version für das konfigurierte Publikum erreichbar. Change URL in den Site-Einstellungen ändert die ChatGPT-Adresse, ohne ein neues Deployment zu erstellen; die alte Adresse leitet einschließlich Pfad und Query weiter. Eine eigene Domain ist ein weiterer separater Schritt.

Wenn eine bereits besessene Testdomain ausdrücklich dafür freigegeben ist, öffne Settings → Add domain, trage Domain oder Subdomain ein und übernehme ausschließlich die tatsächlich angezeigten DNS-Werte beim zuständigen Domainanbieter. Kehre zurück und aktualisiere den Domainstatus. Kopiere keine DNS-Werte aus einer fremden Anleitung. Zum Start sind Custom Domains nicht für Enterprise verfügbar. Diese Übung fordert weder eine Registrierung noch eine Änderung deiner vorhandenen Unternehmenswebsite.

Quellen: Sites: Versionen, Rollen, Storage und Domain, Internal Apps, Enterprise-Sites. Stand: 5. Oktober 2026.

Wenn es hakt

Falsche Daten: Quelle und Datenstand prüfen. Filter ohne Ergebnis: verständlichen Leerzustand hinzufügen. Zugriff unerwartet: Freigabe und Quellrechte separat prüfen. Aktualisierung fehlt: den tatsächlichen Ablauf einrichten oder die Aussage korrigieren. Beta-Limit erreicht: die aktuelle Kontoinformation lesen und Umfang anpassen; keinen unbestätigten Preis oder dauerhaften Zugriff versprechen.

Dein Transfer

Wähle eine kleine wiederkehrende Entscheidung, die sich mit wenigen geprüften Angaben erleichtern lässt. Beschreibe eine einzige zentrale Handlung und drei Kontrollfälle. Erst wenn diese funktionieren, lohnt sich die nächste Funktion.