Wie eine Website live geht

Eine Website durchläuft vier Phasen. Nur die letzte verändert, was Besucher sehen.

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, 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:

{
  "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:

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.