--- title: "Wie eine Website live geht" description: "Entwurf, Überarbeitung, Build, Vorschau, Veröffentlichung und Rollback sowie die Frage, was davon Besucher sehen können." canonical: "https://atelier201.com/docs/de/platform/drafts-builds-and-publishing" updated: "2026-11-06" --- # Wie eine Website live geht Eine Website durchläuft vier Phasen. Nur die letzte verändert, was Besucher sehen. ```mermaid title="Von einer Änderung zur live geschalteten Website" flowchart LR A["Entwurf
jede Änderung"] --> B["Build
Entwurf kompiliert"] B --> C["Vorschau
privater Link"] B --> D["Veröffentlichung
für Besucher sichtbar"] ``` ## Entwurf und Revisionen Der Entwurf ist der aktuelle Stand der Dateien der Website. Jede Änderung erzeugt eine **Revision**: eine 40 Zeichen lange Git-Commit-ID mit einer einzeiligen Zusammenfassung und dem Autor (der Editor, der Assistent, ein Agent über MCP, die CLI oder die API). Nichts wird gelöscht: Der Verlauf führt alle Revisionen auf, und Sie können zwei davon vergleichen oder eine frühere als neuen Eintrag wiederherstellen. Eine Änderung entspricht einer Revision, unabhängig davon, was sie betrifft. Ein Aufruf, der drei Dateien ändert, schreibt einen Eintrag. Eine Änderung, die sich über mehrere Aufrufe erstreckt, verwendet ein [Changeset](/docs/api/changesets/open), das Sie einmal committen. Ein Changeset bleibt 10 Minuten lang geöffnet. ### Zwei gleichzeitige Bearbeiter Wenn Sie eine Datei ändern, senden Sie den Hash mit, den Sie ausgelesen haben (`expected_hash`). Wenn jemand die Datei inzwischen geändert hat, wird die gesamte Änderung mit `409 conflict` abgelehnt, es wird nichts geschrieben, und ein REST- oder CLI-Fehler enthält die aktuelle Revision: ```json { "error": { "type": "conflict_error", "code": "conflict", "message": "...", "details": { "reason": "revision_conflict", "current_revision": "9f2c...", "paths": [ { "path": "src/content/site/business.json", "expected": "a1b2...", "found": "c3d4..." } ] } } } ``` Lesen Sie die unter `paths` genannten Dateien erneut, wenden Sie Ihre Änderung darauf an und versuchen Sie es noch einmal. Über MCP weist der Fehler darauf hin, dass sich die Website seit der Vorbereitung der Bearbeitung geändert hat. `details` ist nicht enthalten, lesen Sie die Dateien also selbst erneut ein. Die Content-Endpunkte lesen den aktuellen Hash selbst aus. Ein Konflikt entsteht daher nur, wenn jemand genau im selben Moment schreibt. ## Builds Ein Build kompiliert den Entwurf oder eine von Ihnen angegebene Revision zu einer statischen Website. Er läuft in einem isolierten Container ohne Netzwerkzugriff und Zugangsdaten und wird nach 5 Minuten beendet. Ein Build durchläuft die Status `queued`, `building` und `collecting`, bevor er `ready` ist, oder endet mit `failed` oder `cancelled`. Wird ein Build für eine Revision gestartet, für die bereits ein fertiger Build vorliegt, wird dieser zurückgegeben, statt die Revision erneut zu bauen. Wenn ein Build fehlschlägt, steht in `error` der Grund. Das Build-Protokoll zeigt die Ausgabe des Compilers. Korrigieren Sie die Dateien und starten Sie den Build erneut. ## Vorschauen Eine Vorschau ist ein privater Link zu einem Build. Standardmäßig ist er 7 Tage gültig, maximal 30 Tage. Jeder mit dem Link kann den Build ohne Konto ansehen. Der Link gewährt keine weiteren Berechtigungen, wird nie indexiert und kann widerrufen werden. Die Vorschau zeigt die Website so, wie sie aussehen würde. Teilen Sie sie daher, bevor Sie veröffentlichen. Eine Vorschau ist keine veröffentlichte Website. Auf jeder Seite erscheint ein kleines „Vorschau“-Banner (beim Bearbeiten in der App ausgeblendet), und die Website läuft in einer Sandbox mit dem Origin `null`. Ihre Skripte können keine Cookies setzen, den Browserspeicher nutzen oder einen Worker starten. Eine Drittanbieter-API, die diesen Origin ablehnt, verhindert ebenfalls ihre Ausführung. Deshalb funktionieren ein Formular, ein Cookie-Banner oder ein clientseitiges Tool, das auf diese Funktionen angewiesen ist, erst nach der Veröffentlichung der Website. Eine Build-Warnung nennt die Funktionen, die Ihre Website nutzt. ## Veröffentlichen Beim Veröffentlichen wird ein Build innerhalb von etwa einer Minute an jeder Adresse der Website für Besucher sichtbar. Nur diese Phase ändert die öffentliche Website. 1. **Prüfen.** `review_publish` zeigt, welcher Build live geschaltet würde, ob es sich um den neuesten Entwurf handelt, was die Veröffentlichung blockiert und welchen Wert `expected_generation` hat. 2. **Veröffentlichen** Sie diesen Build mit dem ausgelesenen Wert für `expected_generation`. Die **Generation** ist ein Zähler, der bei jeder Veröffentlichung, jedem Rollback und jeder Rücknahme der Veröffentlichung erhöht wird. Wenn Sie den Wert mitsenden, veröffentlichen Sie genau den Zustand, den Sie geprüft haben. Falls zwischenzeitlich jemand anderes veröffentlicht hat, wird der Aufruf mit `409 conflict` abgelehnt. Prüfen Sie den Stand dann erneut. Ein Build kann nicht veröffentlicht werden, solange ein Hindernis vorliegt: | Hindernis | Vorgehen | | ------------------ | -------------------------------------------------------------------------------------------------------------------------- | | `guest_site` | Die Person muss zuerst [die Website beanspruchen](/docs/platform/guest-sites). | | `no_build` | Erstellen Sie einen Build des Entwurfs. | | `build_not_ready` | Warten Sie, bis der Build `ready` ist, oder starten Sie einen neuen Build, wenn er fehlgeschlagen ist. | | `origin_changed` | Die Hauptadresse der Website wurde nach diesem Build geändert. Erstellen Sie einen neuen Build. | | `plan_required` | Die Website ist ein Entwurf: Zum Veröffentlichen ist der Site-Tarif erforderlich. Teilen Sie bis dahin einen Vorschaulink. | | `site_unavailable` | Die Website wird gerade erstellt, gesperrt oder gelöscht. | ### Rollback und Veröffentlichung zurücknehmen Bei einem **Rollback** wird wieder der Build einer früheren Veröffentlichung ausgeliefert, ohne ihn erneut zu erstellen. Der Entwurf bleibt unverändert und kann daher neuer sein als die Version, die Besucher sehen. Eine Site speichert die letzten 50 Veröffentlichungen für Rollbacks. Mit **Veröffentlichung zurücknehmen** wird die Website offline geschaltet. Besucher sehen dann an der Adresse, dass keine Website verfügbar ist, bis Sie erneut veröffentlichen. Es wird nichts gelöscht. Für Veröffentlichung, Rollback und Rücknahme der Veröffentlichung ist der Scope `sites:publish` erforderlich. Außerdem kann nur ein Workspace-Admin diese Aktionen ausführen. Ein Agent ohne diesen Scope kann alles vorbereiten und den Inhaber um die Veröffentlichung bitten. ## Export und Import Das gesamte Projekt wird als tar-Archiv exportiert, das sich überall mit `npm ci && npm run build` bauen lässt. Beim Import ersetzt ein Archiv mit seinen Dateien den Entwurf und wird als eine Revision gespeichert. `node_modules`, `dist`, `.git` und Geheimdateien werden ausgelassen. Ein Import löst weder einen Build noch eine Veröffentlichung aus.