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

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:

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 workspace <site-id>
   nucli --tenant <tenant> sites readiness <site-id>

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.
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

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. 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 publish <site-id> --release <release-id>

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

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.

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 put <site-id> pages/index.de.yaml --input index.de.yaml --if-match <etag>
nucli --tenant <tenant> sites files apply <site-id> --input patchset.json

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.

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 oder über SFTP an die Site. 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

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

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.

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

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>

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

Die Site ist für den öffentlichen Betrieb bereit, wenn web wait operations readiness: ready meldet. 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.

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 Kaufzuordnung nutzt nur ein Attribution-Cookie, wenn ein Consent-Cookie Tracking erlaubt. 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.
• 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 oder Dev-Mode automatisch live gehen. Live wird erst der Release, den Sie beim ersten Init mit sites init --release oder später mit publish --release <release-id> ausdrücklich veröffentlichen.