Sites und CMS

Nutzen Sie CMS > Sites, um öffentliche Websites, Landingpages und freigegebene Inhaltsseiten kontrolliert zu bauen, zu prüfen und zu veröffentlichen. Der Site Manager trennt Quellstand, Entwicklungsvorschau, statischen Release-Stand und Live-Auslieferung.

Wofür Sie Sites nutzen

Eine Site bündelt Seiten, Vorlagen, Navigation, Übersetzungen, öffentliche Dateien, Domains und Releases für einen Arbeitsbereich. Sie eignet sich für öffentliche Seiten, die ohne Admin-Navigation laufen und Besucher, Kunden oder externe Integrationen erreichen.

Typische Sites enthalten:

• Marketing- oder Produktseiten.
• öffentliche Formular- und Bestätigungsseiten.
• Storefront-Erweiterungen und Landingpages.
• rechtliche Seiten wie Impressum, Datenschutz oder AGB.
• Kampagnenbereiche mit eigener Navigation und mehreren Sprachen.

Prüfen Sie jede Site aus Besuchersicht. Öffentliche Seiten dürfen keine internen Aktionen, keine Admin-Navigation und keine nicht freigegebenen Arbeitsbereichsdaten anzeigen.

Welche Anleitung passt?

Grundbegriffe

Content Hub und Site Manager trennen

Nutzen Sie den Content Hub, wenn der Inhalt fachlich wiederverwendbar ist oder einen klaren Zweck hat:

• FAQ-Einträge bestehen aus Frage, Antwort, optionaler Kategorie und Sortierung. Sie enthalten keine Layout-Blöcke.
• Blogartikel bestehen aus redaktionellem Text, optionaler Kurzfassung und optionalem Cover-Medienbezug. Sie enthalten keine Layout-Blöcke.
• Landingpage-Inhalte können aus erlaubten Blöcken bestehen, zum Beispiel Hero, Text, Bild, Call-to-Action, Karten, Formular-Teaser oder FAQ-Auszug.

Der Content Hub ersetzt den Site Manager nicht. Er legt keine Websites, Domains, Navigation, PageTypes, Templates, Builds oder Releases an. Diese Aufgaben bleiben bei CMS > Sites und beim Sitegenerator. Eine Content-Hub-Publication zeigt auf eine freigegebene Revision und eine statische Rendition. Prüfen Sie für öffentliche Ausspielung trotzdem den Site-Release, der die passende Shell, Route oder Einbindung bereitstellt.

Öffnen Sie in einer Site den Tab Content Hub, um live geschaltete website_html-Publications des aktuellen Tenants zu sehen. Der Tab zeigt Titel, Slug, Sprache, Rendition-Pfad und Veröffentlichungszeit. Nutzen Sie den Eintrag als bewussten Hand-off in Ihr Site-Projekt. Der Tab baut keinen Release, schreibt keine Site-Dateien und veröffentlicht keine Website.

Prüfen Sie nach der Pflege eines Content-Hub-Inhalts:

1. Die Revision passt zum Content-Typ und lässt sich speichern.
2. Die Revision ist fachlich freigegeben.
3. Die Rendition besitzt einen statischen Pfad oder gespeicherte Ausgabe.
4. Die Publication steht live und ersetzt für denselben Inhalt und Channel den bisherigen Live-Zeiger.
5. Die Site, die den Inhalt nutzt, ist gebaut, geprüft und veröffentlicht.

Projektstruktur

Lesen Sie die Struktur einer Site vor Änderungen aus:

nucli --tenant <tenant> sites structure <site-id>

Die wichtigsten Verzeichnisse sind:

Bearbeiten Sie Quellverzeichnisse. Schreiben Sie nicht direkt in dist/, releases/ oder generierte Build-Artefakte.

Eine Seite bauen

Arbeiten Sie in kleinen, prüfbaren Schritten:

Im Site Manager arbeiten

Die Aktionsleiste am oberen Datensatzrand gilt für die gesamte Site. Dort finden Sie Initialisierung, Dev-Session, Vorschau-Link, Git-Update und die Handlungen für den Live-/Development-Quellstand unabhängig vom geöffneten Tab. Der Quellstatus steht direkt unter dieser Leiste. Aktionen für Releases, Abhängigkeiten, Domains und Content Hub bleiben in ihrem jeweiligen Tab.

1. Öffnen Sie CMS > Sites und legen Sie die Site über Create an.
2. Öffnen Sie den Datensatz.
3. Klicken Sie in der oberen Aktionsleiste bei einer neuen, leeren Site einmal auf Site initialisieren. Workspace legt damit das Default-Kit an. Die Aktion veröffentlicht nichts.
4. Starten Sie dort die Dev session. Erst dieser Zustand erlaubt Änderungen an Site-Dateien.
5. Wechseln Sie in den Tab Editor. Öffnen oder erstellen Sie Pages, PageTypes, Templates, Styles und Konfiguration im Dateibaum. Speichern Sie jede Änderung über Save oder gemeinsam über Save all.
6. Öffnen Sie in der oberen Aktionsleiste Preview link, wählen Sie Ziel, Zielgruppe und Review-Zeitraum und erzeugen Sie den Link. Anonyme Links stehen nur für die aufgeführten öffentlichen Ziele zur Verfügung.
7. Wechseln Sie in Releases und klicken Sie auf Build. Prüfen Sie die Rückmeldung und den neu angelegten Release.
8. Klicken Sie am fachlich freigegebenen Release auf Publish. Erst diese Aktion schaltet den gewählten Stand live.

Wenn Site initialisieren nicht erscheint, enthält die Site bereits eine Projektstruktur. Eine Initialisierung repariert oder überschreibt keine bestehenden Dateien.

Nutzen Sie das Vollbildsymbol rechts in der Editorleiste, wenn Sie Dateibaum und Editor ohne die übrige Verwaltungsoberfläche bearbeiten möchten. Die lokalen Editoraktionen bleiben dabei erreichbar; Site-weite Aktionen bleiben bewusst außerhalb der Vollbildfläche. Esc beendet den Vollbildmodus.

Tippen Sie in einer Datei unter templates/, pages/ oder pagetypes/ {{, um die an dieser Stelle unterstützten Template-Werte und -Funktionen anzuzeigen. Wählen Sie einen Eintrag aus; der Editor fügt den vollständigen Ausdruck einschließlich der Template-Klammern ein. Für statische Dateien wie Scripts, Styles, Übersetzungsbündel und Dateien unter public/ bietet der Editor bewusst keine Template-Vorschläge an.

Beginnen Sie in pages/*.yaml oder pagetypes/*.yaml einen YAML-Schlüssel oder drücken Sie Strg+Leertaste. Der Editor zeigt nur die Schlüssel an, die zur aktuellen Einrückung und Teilstruktur passen, beispielsweise Felder für variant, access, Navigationseinträge oder Container-Komponenten. Namen von Navigationsgruppen und Container-Slots vergeben Sie weiterhin selbst. Auch in freien Bereichen wie params, translations und structuredData sowie innerhalb eines Inhaltsblocks wie content: | erscheinen bewusst keine festen YAML-Schlüsselvorschläge.

Mit nucli arbeiten

1. Listen Sie Sites und wählen Sie die richtige Site.

   nucli --tenant <tenant> sites list

1. Lesen Sie Workspace, Readiness und aktuellen Status.

   nucli --tenant <tenant> sites inspect <site-id> --strict
   nucli --tenant <tenant> sites workspace <site-id>
   nucli --tenant <tenant> sites readiness <site-id>

inspect --strict bricht in Skripten ab, wenn Readiness, Build oder Maintenance-State den nächsten Arbeitsschritt blockieren.

1. Lesen Sie die Projektstruktur.

   nucli --tenant <tenant> sites structure <site-id>

1. Starten Sie eine Dev-Session, wenn Sie Dateien schreiben oder eine Entwicklungsvorschau brauchen.

   nucli --tenant <tenant> sites dev start <site-id> --review-window 7d

1. Stimmen Sie technische Änderungen an PageTypes, Templates, Pages, Übersetzungen und Assets mit den Entwicklern ab. Die technische Umsetzung steht in Webseiten umsetzen. Bilddateien legen Sie unter images/ ab. Im Siteeditor können Sie Bilder hochladen, anzeigen, ersetzen und löschen; per nucli verwenden Sie dafür die sites files image-*-Befehle.
2. Prüfen Sie die Site.

   nucli --tenant <tenant> sites validate <site-id>

1. Erzeugen Sie einen Release-Build.

   nucli --tenant <tenant> sites build <site-id> --wait
   nucli --tenant <tenant> sites build-status <site-id>
   nucli --tenant <tenant> sites releases list <site-id>

1. Veröffentlichen Sie nur nach ausdrücklicher Freigabe.

   nucli --tenant <tenant> sites publish <site-id> --release <release-id>

Der Build erzeugt einen statischen Release-Stand. publish macht genau diesen Release live. Ein Build allein veröffentlicht nicht automatisch. Git-Deploy erzeugt ebenfalls nur einen Release-Stand. Nur sites init --release verbindet beim erstmaligen Init einer leeren Site Struktur, Build und Veröffentlichung ausdrücklich in einem Schritt.

Technische Umsetzung

Die technische Site-Struktur gehört in die Entwicklerarbeit. Dazu zählen Page-Dateien, PageTypes, Templates, Container-Slots, Container-Komponenten, Navigationstemplates, Produkt-Snippets und Plugin-Komponenten.

Nutzen Sie dafür Webseiten umsetzen. Die Administrationsseite beschreibt den Bedien- und Betriebsfluss für Dev-Mode, Vorschau, Build, Veröffentlichung, Domains und Readiness.

Dev-Mode und Vorschau

Der Dev-Mode ist ein zeitlich begrenzter Bearbeitungszustand. Er aktiviert Entwicklungsvorschau, Dateiwrites und laufende Aktualisierung für die Site. Er veröffentlicht nichts automatisch.

Ein Vorschau-Link führt Reviewer auf einen bestimmten Vorschau-Stand, Pfad und Zugriffsmodus. Wenn Ihr Team Freigabelink sagt, verwenden Sie in der Doku trotzdem Vorschau-Link: Der Begriff passt zum CLI-Befehl sites preview link und vermeidet Verwechslungen mit Share-Links aus anderen Bereichen.

Dev-Mode starten

Starten Sie den Dev-Mode für die Site:

nucli --tenant <tenant> sites dev start <site-id> --review-window 7d

Nutzen Sie <tenant> für den Arbeitsmandanten der Site und <site-id> aus sites list. --review-window 7d hält die Bearbeitungs- und Review-Zeitspanne bewusst begrenzt.

Vorschau-Link für angemeldete Reviewer erzeugen

Erzeugen Sie einen Vorschau-Link für Reviewer, die sich im Zielbrowser anmelden sollen:

nucli --tenant <tenant> sites preview link <site-id> --mode dev --path / --consumer authenticated --open

Verwenden Sie --consumer authenticated, wenn die Seite Login, geschützte Bereiche oder personalisierte Inhalte braucht. Der Reviewer öffnet den Link, meldet sich normal an und sieht danach den gewählten Vorschau-Stand.

Vorschau-Link für öffentliche Reviewer erzeugen

Nutzen Sie --host <host>, wenn die Vorschau über einen bestimmten Host laufen soll. Für Reviewer ohne Login erzeugen Sie einen anonymen Link. Anonyme Links dürfen nur öffentliche Ziele öffnen, die der Workspace unter previewHandoff.publicTargets meldet:

nucli --tenant <tenant> sites preview link <site-id> --mode dev --path /kampagne --consumer anonymous

Nutzen Sie --consumer anonymous nur für öffentliche Pfade wie Landingpages, Bestätigungsseiten oder Kampagnenseiten. Wenn ein Reviewer geschützte Seiten prüfen soll, verwenden Sie --consumer authenticated und lassen den Reviewer sich im Zielbrowser normal anmelden.

mode=dev richtig einordnen

--mode dev im Befehl legt fest, dass der Vorschau-Link den Dev-Mode-Stand der Site öffnet. Schreiben Sie ?mode=dev nicht manuell an öffentliche Site-URLs, um eine Freigabe zu simulieren. Erzeugen Sie den Link mit nucli sites preview link, damit Workspace Pfad, Host, Zugriffsmodus und Preview-Handoff korrekt setzt.

In der Admin-Oberfläche kann ein Link wie /cms/sites?mode=dev die Site-Verwaltung im passenden Modus öffnen. Das ist kein Site-Vorschau-Link. Es ersetzt keine Veröffentlichung und macht unfertige Inhalte nicht automatisch öffentlich.

Preview zeigt nur den gewählten Quellstand. Ein Vorschau-Link erweitert keine Seitenrechte, ersetzt keine fachliche Freigabe und schaltet nichts live.

Freeze, Build und Release

Die Live-Site läuft aus einem gefrorenen Release-Stand. Dadurch bleiben Besucher auf einem stabilen statischen Build, während Sie im Dev-Mode weiterarbeiten.

Der Releaseprozess läuft bewusst getrennt vom Dev-Mode:

1. validate prüft Struktur, Referenzen und offensichtliche Fehler.
2. build --wait erzeugt einen Release-Stand unter einer Release-ID.
3. Review prüft genau diesen Release-Stand fachlich und technisch.
4. Die fachliche Freigabe bezieht sich auf genau diese Release-ID.
5. publish --release <release-id> schaltet genau diesen Release live.

nucli --tenant <tenant> sites validate <site-id>
nucli --tenant <tenant> sites build <site-id> --wait
nucli --tenant <tenant> sites build-status <site-id>
nucli --tenant <tenant> sites releases list <site-id>
nucli --tenant <tenant> sites publish plan <site-id> --release <release-id>
nucli --tenant <tenant> sites publish <site-id> --release <release-id>

Wenn eine neue Veröffentlichung fehlschlägt oder fachlich nicht freigegeben ist, bleibt der bisherige Live-Release bestehen.

Sitegenerator-Vertrag explizit aktualisieren

Bestehende Sites ohne sitegeneratorContractVersion verwenden weiterhin den kompatiblen Vertrag V1. Aktualisieren Sie eine Site nur dann auf V2, wenn Sie den strengeren Buildvertrag bewusst aktivieren möchten. V2 bricht einen Build bei relevanten Render-, Routing- oder Manifestfehlern ab, statt eine unvollständige neue Release-Version bereitzustellen.

Prüfen Sie das Upgrade zuerst ohne Schreibzugriff auf dem Server:

numin site upgrade-contract --site <site-uuid> --target 2

Wenden Sie den geprüften Plan anschließend explizit an:

numin site upgrade-contract --site <site-uuid> --target 2 --apply

--apply erzeugt zuerst einen Source-Snapshot und setzt danach die Vertragsversion in config/defaults.yaml. Das Kommando verändert keine bestehenden Releases und veröffentlicht nichts. Erzeugen Sie anschließend einen neuen Build, prüfen Sie genau dessen Release-ID und veröffentlichen Sie ihn erst nach der Freigabe.

Das Upgrade ist erfolgreich vorbereitet, wenn der Dry-Run als aktuelle Version 1, als Ziel 2 und genau die geplante Versionsänderung meldet. Nach --apply nennt die Ausgabe zusätzlich die Source-Snapshot-ID. Der bisherige Live-Release bleibt während des gesamten Ablaufs erreichbar.

Upgrade-Snapshots liegen getrennt von Release-Snapshots unter .nucleus/site-maintenance/upgrade-snapshots/. Stoppen Sie während des Upgrades alle parallelen CMS-, SFTP- und externen Dateischreibvorgänge. Das Kommando vergleicht den Sitequellstand und defaults.yaml vor dem atomaren Write erneut und bricht bei erkannter Drift ohne Konfigurationsänderung ab. Legacy-Werte wie 0 oder quoted "1" normalisieren Sie explizit mit --target 1; ein Downgrade einer V2-Site ist nicht möglich. Nutzen Sie publish plan vor der Freigabe für eine read-only Prüfung von Release, Operations-Readiness und Diff-Zusammenfassung. Der Befehl baut und veröffentlicht nicht. Legen Sie Build und Publish nicht als Komfortabkürzung zusammen. Ein Ein-Schritt-Ablauf darf nur ausdrücklich als Veröffentlichung erkennbar sein, zum Beispiel sites init --release bei einer leeren Site oder maintenance/publish im Live-Wartungsfluss.

Dynamische Produktdetailseiten folgen demselben Release-Vertrag. Wenn Sie eine Page mit dynamicRoute.kind: productDetail, ihr URL-Präfix oder ihre Container ändern, wirkt diese Änderung in Live erst nach build und publish. Ein Datei-Apply im CMS-Quellstand aktualisiert Dev-Mode und Vorschau, aber nicht das Live-Routing des bisher veröffentlichten Site Release.

Definieren Sie pro Site, Locale und Jurisdiction höchstens eine solche Page. Eine leere Jurisdiction zählt wie global. Workspace lehnt einen CMS-Quellstand mit zwei Product-Detail-Routen im gleichen Scope ab. Der Build prüft die Eindeutigkeit erneut und erzeugt in diesem Fall keinen Release. Korrigieren Sie den doppelten Scope und starten Sie den Build anschließend erneut.

Dynamische Produktdetailseiten im Live-Release prüfen

Eine dynamische Produktdetailseite wird nicht als einzelne HTML-Datei pro Produkt veröffentlicht. Der Release enthält eine Shell der Produktdetail-Page und das Artefakt dynamic-routes.json. Bei einem Besucher-Request löst Workspace daraus die passende Produkt-Route, die Site-Navigation und die Produkt-Snippets auf. Dadurch kommen Header, Footer, rechtliche Navigation und Produktbereiche aus demselben veröffentlichten Release.

Prüfen Sie nach einem Build oder vor einer Veröffentlichung:

• sites route inspect <site-id> /de/produkte/<slug> --host <host> --release live oder eine konkrete Release-ID zeigt dynamicRoute und die erwartete Shell-Datei.
• Produktdetail-URLs dürfen nicht als staticPage erscheinen. Wenn eine statische Page denselben Pfad wie eine Produktdetail-URL besitzt, entfernen oder verschieben Sie diese CMS-Page und veröffentlichen Sie danach einen neuen Release.
• Die betroffenen ProductSnippets sind ready. Required-Snippets dürfen nicht fehlen.
• Die gerenderte Detailseite enthält sichtbare Header-, Footer- und Legal-Navigation. Im Browser-DOM dürfen keine data-nucleus-runtime-navigation-Templates stehen bleiben.
• /_page-feed.json liefert bei einem Referer auf die Produktdetailseite Navigation und sichtbare Seiten. Der Feed ersetzt keine Produktdatenprüfung.

Wenn eine Produktdetailseite 503 Service Unavailable mit Retry-After liefert, ist die Produkt-Route nicht automatisch falsch. Prüfen Sie zuerst, ob die Route über den Public Catalog auflösbar ist und ob die Required-Snippets für Tenant, Variante, Locale und Sales Channel als Artefakte vorliegen. Fehlt ein Required-Snippet, bleibt der Status 503 korrekt: Die Detailseite ist temporär nicht auslieferbereit und meldet den Zustand über Telemetry.

Gestalten Sie für diesen Fall eine eigene Fehlerseite im Design der Site. Legen Sie dafür eine statische Error-Page mit dem Slug 503 in der Default-Locale der Site an. Nach Build und Publish muss das veröffentlichte Release die Datei global/<default-locale>/503.html enthalten. Die Runtime liefert diese HTML-Datei mit HTTP-Status 503 und Retry-After aus. Fehlt die Datei, zeigt Workspace die Standardfehlerseite. Setzen Sie die Page auf robots: noindex, follow und nehmen Sie sie nicht in die Sitemap auf.

Halten Sie die 503-Seite unabhängig von ProductSnippets und Runtime-Platzhaltern. Verwenden Sie keine Runtime-Navigation, keine productSnippet-Komponenten und keine dynamischen Routenmarker. Verlinken Sie stattdessen statisch auf robuste Seiten wie Startseite, Kontakt oder Kategorieseiten. Der Besucher sieht dann eine Seite im Shop-Design, während Crawler und Monitoring weiterhin den richtigen 503-Status erhalten.

Wenn die Seite 200 liefert, aber Navigation oder Page-Feed leer bleiben, behandeln Sie das als Auslieferungsfehler im Release-Pfad. Bauen Sie keinen tenant-spezifischen JavaScript-Fallback ein; erstellen Sie eine Produkt- oder Sitegenerator-Diagnose mit Route, Release-ID, Host, Snippet-Status und DOM- Befund.

Build-Ressourcen begrenzen

Begrenzen Sie Site-Builds, wenn parallele Bildverarbeitung oder Kompression andere Serveraufgaben verdrängt. Die Werte gelten global für die laufende Workspace-Instanz:

Starten Sie mit kleinen positiven Werten, wenn Builds Lastspitzen verursachen, und erhöhen Sie die Grenzen erst nach einer Messung. Negative Werte sind ungültig und verhindern den Build.

Workspace verwendet unveränderte Bild- und Kompressionsresultate in späteren Builds erneut. Jeder Release enthält trotzdem eigene Dateien und bleibt ohne den internen Build-Cache auslieferbar. Änderungen an Quelldateien, Buildoptionen oder der Verarbeitungsversion erzeugen automatisch neue Artefakte. Sie müssen bestehende Sites dafür nicht migrieren.

Dateien per nucli senden

Nutzen Sie nucli, wenn Sie einzelne Dateien oder geprüfte Patchsets kontrolliert senden wollen.

nucli --tenant <tenant> sites files tree <site-id>
nucli --tenant <tenant> sites files get <site-id> pages/index.de.yaml > index.de.yaml
nucli --tenant <tenant> sites files get <site-id> pages/index.de.yaml --json
nucli --tenant <tenant> sites files create <site-id> pages/neue-seite.yaml --input neue-seite.json
nucli --tenant <tenant> sites files put <site-id> pages/index.de.yaml --input index.de.yaml --if-match <etag>
nucli --tenant <tenant> sites files delete <site-id> pages/alte-seite.yaml --if-match <etag>
nucli --tenant <tenant> sites files apply <site-id> --input patchset.json
nucli --tenant <tenant> sites files diff <site-id> --release <release-id>

Ohne --json schreibt sites files get den Dateiinhalt direkt auf stdout. Mit --json enthält die Antwort den Dateiinhalt als data.content und den aktuellen ETag als data.etag.

get liefert den aktuellen Stand und einen ETag. Verwenden Sie --if-match <etag> beim Schreiben, damit Sie keine parallele Änderung überschreiben. Für mehrere zusammengehörige Dateien ist ein Patchset besser als viele einzelne Schreibbefehle. files create erstellt neue Textdateien über den Serververtrag und ist für neue Pages, Snippets oder Styles geeignet. Bestehende Dateien ändern Sie weiter mit ETag oder Patchset. files delete entfernt eine Quell-Datei im Dev-Workspace physisch und verlangt ebenfalls den zuletzt gelesenen ETag. Das ist Quellenbereinigung, kein automatischer Publish und kein Ersatz für Redirects, robots oder Sitemap- Entscheidungen. Der Befehl darf nur den Dev-Workspace verändern und niemals gefrorene Releases, Freeze- oder Live-Artefakte. Prüfen Sie bei Fallback-Sites, ob das Löschen einer tenant-spezifischen Datei eine Fallback-Seite wieder sichtbar macht. files diff vergleicht erlaubte Projektdateien gegen ein angegebenes Release nach Server-Dateipolicy. Release-Verzeichnisse können Build-Artefakte enthalten; nutzen Sie Git weiter als Review- und Historienprozess.

Prüfen Sie Redirects und Routen vor Launches ohne lokale YAML- oder Manifest- Parser:

nucli --tenant <tenant> sites redirects list <site-id>
nucli --tenant <tenant> sites redirects test <site-id> --host www.example.com --input urls.txt
nucli --tenant <tenant> sites routes list <site-id>
nucli --tenant <tenant> sites route inspect <site-id> /pfad --host www.example.com

redirects test simuliert Redirect-Ketten gegen den Serverzustand und erkennt Ketten sowie Loops. Der Server startet dabei keine freien HTTP-Probes gegen --host.

routes list und route inspect zeigen auch, welche öffentliche HTML-Seite oder dynamische Produktdetailroute für einen Pfad greift. Nutzen Sie diese Befehle nach Änderungen an Slugs, defaultPage oder der Canonical-Path-Policy, bevor Sie einen Release veröffentlichen. Die technische Konfiguration der Slash-Policy steht in Webseiten umsetzen. Für Produktdetail-URLs ist dynamicRoute der erwartete Treffer. Eine staticPage unter demselben Produktpräfix ist kein gültiger Produktseitenweg, weil sie ProductRoute, freigegebene Produktinhalte, SEO-Purpose und Snippet-Readiness umgehen würde.

Wenn Ihr Team Site-Dateien in Git pflegt, bleibt Git der Review- und Historienprozess. Senden Sie freigegebene Änderungen anschließend über nucli sites files apply, Git-Deploy oder SFTP an die Site. Diese Wege ändern den Quellstand und können einen Release-Build erzeugen, schalten aber nicht live. Nach einem optionalen Initial-Release bleibt Veröffentlichung der Site-Manager-Ablauf aus Validierung, Build und explizitem Publish.

Site-Dateien lokal im Dev-Mode bearbeiten

Nutzen Sie einen lokalen Mount, wenn Sie viele Projektdateien mit Ihrer IDE oder Ihrem Editor bearbeiten möchten. Der Mount ist kein Offline-Modus: Er verbindet Ihren Rechner per SSHFS mit den Site-Projektquellen im Dev-Mode. Die Live-Site läuft weiter aus dem veröffentlichten Freeze.

Wenn Sie die Site-ID nicht kennen, listen Sie zuerst die Sites:

nucli --tenant <tenant> sites list --json

Die Ausgabe enthält id. Nutzen Sie diesen Wert als <site-id>. Wenn Sie sites dev mount in einem interaktiven Terminal ohne Site-ID starten, zeigt nucli eine nummerierte Site-Liste. Wählen Sie dann die Site per Zahl, Site-ID oder Slug.

Prüfen Sie zuerst den geplanten Mount. Für Skripte geben Sie die Site-ID direkt an:

nucli --tenant <tenant> sites dev mount <site-id> --dry-run --json

Im Terminal können Sie die Site auch interaktiv auswählen:

nucli --tenant <tenant> sites dev mount --dry-run

Führen Sie den Mount anschließend interaktiv aus:

nucli --tenant <tenant> sites dev mount <site-id>

Oder wählen Sie die Site im Terminal aus:

nucli --tenant <tenant> sites dev mount

nucli startet oder verlängert dabei die Dev-Session, prüft lokal sshfs, zeigt den Mount-Befehl und fragt nach Bestätigung. Linux, macOS und Windows über WSL werden unterstützt. Installieren Sie sshfs vorher auf Ihrem System; nucli installiert keine lokalen Pakete. Mit --json gibt --dry-run den Mount-Plan maschinenlesbar aus. Geben Sie dabei die Site-ID explizit an.

Nach erfolgreichem Mount zeigt nucli den lokalen Site-Pfad. Standardmäßig liegt die Site unter dem Site-Slug:

~/mnt/nucleus-sites/<site-slug>

Öffnen Sie diesen Ordner in Ihrem Editor. Wenn Sie eine Datei speichern, sendet das SFTP-Gateway die Änderung an die Dev-Session. Die Entwicklungsvorschau kann dadurch aktualisieren. Prüfen Sie den Stand über einen Vorschau-Link:

nucli --tenant <tenant> sites preview link <site-id> --mode dev --path / --consumer authenticated --open
nucli --tenant <tenant> sites preview link <site-id> --mode dev --path / --consumer authenticated --json

SFTP ist ein projektbezogener Dateizugriff. Es stellt keine Shell und keinen allgemeinen Serverzugriff bereit. Schreibzugriff braucht passende Berechtigungen, eine aktive Dev-Session und je nach Umgebung einen registrierten SSH-Schlüssel.

Bearbeiten Sie über SFTP nur die Quellverzeichnisse der Site. Schreiben Sie keine Build-Ausgaben, Release-Verzeichnisse oder Abhängigkeiten direkt. Die Live-Site ändert sich erst, wenn Sie validieren, bauen und genau den freigegebenen Release veröffentlichen.

Wenn Sie nur die Verbindungsdaten sehen möchten, lesen Sie die Mount- Informationen:

nucli --tenant <tenant> sites mount-info <site-id> --json

Backups und Restore

Erstellen Sie vor größeren Änderungen ein Backup:

nucli --tenant <tenant> sites backup <site-id> --output site-backup.zip

Bewahren Sie das ZIP geschützt auf. Site-Backups können öffentliche Inhalte, Entwürfe, Dateinamen, Organisationsbezüge und technische Struktur enthalten.

Prüfen Sie ein Restore zuerst als Plan:

nucli --tenant <tenant> sites restore <site-id> --input site-backup.zip

Wenden Sie den Restore nur bewusst an:

nucli --tenant <tenant> sites restore <site-id> --input site-backup.zip --apply

Ein Restore mit --apply braucht eine aktive Dev-Session. Validieren und bauen Sie die Site nach einem Restore neu, bevor Sie wieder veröffentlichen.

Domains und Zusammenspiel mehrerer Sites

Eine Organisation kann mehrere Sites betreiben. Trennen Sie Sites nach fachlichem Zweck, Domain, Veröffentlichungsrhythmus oder Verantwortlichkeit.

Prüfen Sie für jede Site:

• Welche Domains auf die Site zeigen.
• Welche Site als Standard-Site dient.
• Welche Standard-Sprache gilt.
• Welcher Release live ist.
• Ob die Site Storefront-, Formular- oder andere öffentliche Integrationen nutzt.

Domains und Ingress bleiben Betriebsaufgaben. Die Site steuert Inhalt, Projektstruktur und Release; die Erreichbarkeit über Hostnamen muss zur Betriebs- und Ingress-Konfiguration passen. Weitere Betriebsgrundlagen finden Sie unter Container und Ingress.

Storefront- und Site-Domains einrichten

Verwenden Sie für öffentliche Websites und Storefronts eine Tenant Domain mit der Surface cms_public. Diese Domain ist nicht dasselbe wie System Domains (CSV) für die Administrationsoberfläche. Die Abgrenzung steht in System Domains verstehen.

Prüfen Sie vor der Domainbindung:

• DNS und Ingress zeigen den öffentlichen Host auf die Workspace-Auslieferung.
• TLS deckt den öffentlichen Host ab.
• Reverse Proxy oder Ingress geben Host, X-Forwarded-Host und X-Forwarded-Proto korrekt weiter.
• Die Site ist aktiv, hat bei Storefront-Nutzung einen Sales Channel und ein veröffentlichter Release ist vorhanden.

Richten Sie die Domain mit nucli ein:

nucli --tenant <tenant> sites list
nucli --tenant <tenant> web domains create shop.example.test
nucli --tenant <tenant> web domains start-verification <tenant-domain-id>

Die Verifikationsantwort enthält verificationName, verificationValue und token. Veröffentlichen Sie verificationValue als TXT-Record unter verificationName. Prüfen Sie die Domain erst, wenn DNS den TXT-Record ausliefert:

nucli --tenant <tenant> web domains verify-dns <tenant-domain-id> --token <token>
nucli --tenant <tenant> web bind-domain <site-id> <tenant-domain-id>

Wenn eine cms_public-Tenant-Domain bereits registriert und verifiziert ist, können Sie die CMS-Bindung auch direkt über den CMS-Domain-Befehl prüfen und setzen:

nucli --tenant <tenant> cms domains list-registered
nucli --tenant <tenant> cms domains bind <site-id> <tenant-domain-id>

Beim Bind-Befehl steht zuerst die Site-ID und danach die Tenant-Domain-ID. web bind-domain und cms domains bind schreiben denselben Site-Domain-Bindungsvertrag. Verwenden Sie web readiness und web wait anschließend weiterhin für die Betriebsbereitschaft.

In Workspace Cloud erzeugt Workspace daraus eine Edge-Veröffentlichung. Diese Edge-Veröffentlichung beschreibt den gewünschten technischen Zustand für Routing und TLS. Sie ersetzt keine DNS-TXT-Verifikation und erlaubt Mandanten nicht, interne Upstreams, Dial-Adressen oder Proxy-Ziele zu setzen. Bei Self-Hosting bleibt edge.domain_publication.mode auf self_hosted. Workspace zeigt dann keinen Edge-Status für Tenant Domains an und blockiert Readiness nicht an einer Edge-Veröffentlichung. Der Betreiber richtet DNS, TLS und HTTPS selbst ein, direkt im Server oder über eigenen Reverse Proxy, Load Balancer oder Ingress.

Prüfen Sie danach die Betriebsbereitschaft der Site:

nucli --tenant <tenant> web readiness <site-id>
nucli --tenant <tenant> web wait <site-id> --timeout 5m --json

Die Site ist für den öffentlichen Betrieb bereit, wenn web wait operations readiness: ready meldet oder mit --json den Status ready ausgibt. web readiness prüft insbesondere Domainbindung, DNS-Verifikation, HTTPS-Erreichbarkeit, Build-Status, Release und bei Storefront-Nutzung die Sales-Channel-Zuordnung. In Workspace Cloud kommt zusätzlich die Edge-Veröffentlichung als eigener technischer Check dazu. Beheben Sie blockierte Checks in der genannten Verantwortlichkeit; bauen Sie im Storefront-Client keinen lokalen Domain-, Edge- oder Sales-Channel-Fallback.

In Workspace Cloud startet Workspace die HTTPS-Prüfung erst, wenn der Edge die Domain als technisch bereit gemeldet hat. So sehen Administratoren klar, ob sie zuerst Domain-Verifikation, Site-Bindung, Edge-Synchronisation oder HTTPS prüfen müssen. In Self-Hosting-Umgebungen läuft die HTTPS-Prüfung direkt gegen den konfigurierten öffentlichen Host.

Lokale Domain-Tests

Eine Hosts-Datei kann nur Hostnamen auf IP-Adressen abbilden. Sie kann keinen TXT-Record für die Tenant-Domain-Verifikation bereitstellen. Verwenden Sie Hosts-Dateien daher nur, um Browser oder lokale CLI-Aufrufe auf eine lokale Workspace-Instanz zu routen, wenn kein besserer lokaler DNS-Weg verfügbar ist. Für die Workspace-Docker-Demo brauchen Sie im Normalfall keine Hosts-Datei: Subdomains unter localhost.alvine.dev, zum Beispiel shop.localhost.alvine.dev, lösen im Browser bereits auf 127.0.0.1 auf.

Wenn Sie den vollständigen Domainfluss lokal testen möchten, muss der Workspace-Server den TXT-Record über seinen DNS-Resolver lesen können. Nutzen Sie dafür einen eigenen Storefront-Subhost wie shop.localhost.alvine.dev, nicht den nackten Host localhost und nicht localhost.alvine.dev selbst. Viele Systeme behandeln localhost als Loopback-Sonderfall, und localhost.alvine.dev bleibt der lokale Systemhost. Verwenden Sie entweder eine echte Entwicklungs-DNS-Zone oder einen lokalen DNS-Resolver wie dnsmasq oder CoreDNS, der für die Runtime sichtbar ist und A-/AAAA- sowie TXT-Records ausliefert. Für Docker-Compose-Demos beschreibt Lokale Storefront-Domain mit DNS-TXT testen ein CoreDNS-Override.

Für den abschließenden web wait reicht DNS allein nicht. Der Shop-Host muss aus der Workspace-Runtime zusätzlich per HTTPS auf Port 443 erreichbar sein, und das Zertifikat muss dem konkreten Host oder einem passenden Wildcard-SAN entsprechen. Importieren Sie die lokale CA außerdem in die Trust Stores von Browser, Betriebssystem und Workspace-Runtime. Die lokale Zertifikats- und HTTPS-Prüfung steht unter Lokales HTTPS für web wait.

Öffentliche Storefront-Submissions absichern

Prüfen Sie bei Sites mit Kontakt-, Firmenzugangs- oder Angebotsformularen, ob die öffentliche Storefront die gemeinsamen Schutzsignale sendet. Der Client soll honeypot, filledSeconds und, wo fachlich möglich, pageUrl mitsenden. Die Seite darf daraus keine eigene Spam-Entscheidung ableiten; Workspace bewertet Rate-Limit, Body-Größe, Mindestfüllzeit und serverseitige Risikosignale.

Konfigurieren Sie die Grenzen für formularartige Storefront-Eingänge passend zum erwarteten Traffic:

• public.storefront.submission.max_bytes
• public.storefront.submission.rate_limit.client.limit
• public.storefront.submission.rate_limit.sales_channel.limit
• public.storefront.submission.rate_limit.email.limit
• public.storefront.submission.rate_limit.window_seconds
• public.storefront.submission.minimum_fill_seconds

Behandeln Sie 429 Too Many Requests und 413 Payload Too Large als Schutzsignale, nicht als CRM- oder Commerce-Fehler. Verdächtige Firmenzugangs-Anfragen können unter CRM > Pipeline > Firmenzugangsanfragen mit Risk-Feldern sichtbar sein. Geben Sie riskReason, riskScore, interne IDs, Bucket-Namen oder Diagnosewerte nicht an Besucher weiter.

Für angemeldete Kundenkonto-Aktionen verwendet Workspace eigene Grenzen. Diese Grenzen schützen API-Aufrufe wie Abonnementliste, Kündigung, Reaktivierung und Zahlungsmittelbindung, ohne Formular-Honeypots zu verlangen:

• public.storefront.account.rate_limit.read.client.limit
• public.storefront.account.rate_limit.read.identity.limit
• public.storefront.account.rate_limit.read.window_seconds
• public.storefront.account.rate_limit.write.client.limit
• public.storefront.account.rate_limit.write.identity.limit
• public.storefront.account.rate_limit.write.subscription.limit
• public.storefront.account.rate_limit.write.window_seconds
• public.storefront.account.max_bytes

Behandeln Sie auch hier 429 Too Many Requests und 413 Payload Too Large als Schutzsignale. Zeigen Sie Besuchern keine Bucket-Namen, gehashten Keys, Provider-Token, Identity-IDs oder technischen Diagnosewerte an.

Site-Analytics auswerten

Öffnen Sie im Site Manager den Tab Analytics, um die Live-Nutzung einer Site zu prüfen. Workspace zeigt aggregierte Kennzahlen für Besuche, Hits, Ressourcenarten, Länder und Quellen. Nutzen Sie die Werte, um veröffentlichte Seiten, Dokumente, Bilder, Newsletter-Links und Kampagnen-Traffic zu bewerten.

Die Auswertung zählt nur Live-Auslieferung. Dev-Mode und Vorschau fließen nicht in die Produktivmetriken ein. CSS, JavaScript, Source Maps und Fonts werden ignoriert, damit technische Asset-Last die fachlichen Kennzahlen nicht verzerrt.

Workspace speichert für Site-Analytics keine IP-Adressen, keine vollständigen User-Agent-Strings und keine Browser-Fingerprints. Länder stammen aus vorgelagerten Edge-Headern. User-Agent-Daten werden nur in grobe Geräte- und Bot-Klassen normalisiert.

Verwenden Sie für Newsletter- und Anzeigenlinks die vorgesehenen Tracking-Redirects, wenn Sie Klicks und spätere Werte einer Kampagne zuordnen wollen. Der Analytics-Tab zeigt Kampagnenkennzahlen für Klicks, Käufe und Umsatz. Manuelle Tracking-Kampagnen und Tracking-Links pflegen Sie unter Marketing. Newsletter-Links werden beim finalen Versand automatisch empfängerbezogen umgeschrieben.

Personenbezug entsteht nur über vorhandene Systembeziehungen wie Newsletter-Empfänger oder CRM-Personen und bleibt berechtigungsgebunden. Anonyme Tracking-Link-Kaufzuordnung nutzt nur ein Attribution-Cookie, wenn ein Consent-Cookie Tracking erlaubt. Consentless CTA-Attribution bindet CTA- und Kampagnenkontext nur an Warenkorb und Bestellung. Prüfen Sie vor Kampagnenstart, ob Datenschutzhinweise, Einwilligungen und berechtigtes Interesse fachlich freigegeben sind. Den vollständigen Bedienfluss beschreibt Website-Analytics und Marketing-Attribution.

Veröffentlichungscheckliste

Prüfen Sie vor publish:

• Die richtige Site und der richtige Tenant sind aktiv.
• Readiness zeigt keine blockierenden Punkte.
• web readiness zeigt keine blockierenden Domain-, DNS-, HTTPS-, Build-, Release- oder Sales-Channel-Punkte.
• Dev-Session und Vorschau zeigen den erwarteten Stand.
• Navigation, Sprache, Slugs und Root-Seite stimmen.
• Dynamische Produktdetailseiten zeigen Header-, Footer- und Legal-Navigation ohne Runtime-Template-Platzhalter.
• Required-Snippets für Produktdetailseiten sind gebaut.
• Eine statische 503-Fehlerseite im Site-Design ist veröffentlicht, wenn ProductSnippet-Required-Fälle für Besucher sauber dargestellt werden sollen.
• validate ist erfolgreich.
• Der Release-Build ist erfolgreich abgeschlossen.
• Rechtliche Texte, Datenschutz, Kontaktangaben und Tracking-Hinweise sind fachlich freigegeben.
• Öffentliche Dateien enthalten keine Secrets, internen URLs oder Entwürfe.
• Backup oder Git-Stand erlauben eine Wiederherstellung.
• Die Freigabe für genau diese Release-ID liegt vor.

Grenzen

Der Site Manager ersetzt keinen rechtlichen Freigabeprozess und kein DNS-, TLS- oder Infrastrukturkonzept. Er veröffentlicht nur den freigegebenen statischen Site-Stand, den Sie bauen und explizit veröffentlichen.

Verlassen Sie sich nicht darauf, dass Git, SFTP, Git-Deploy, Build oder Dev-Mode automatisch live gehen. Live wird erst der Release, den Sie beim ersten Init mit sites init --release, im Wartungsfluss mit maintenance/publish oder später mit publish --release <release-id> ausdrücklich veröffentlichen.