Auf dieser Seite
Veröffentlichen
Ein Clay-Build ist ein Ordner statischer Dateien: Es gibt keinen Server zu betreiben, und jeder Hoster, der Dateien ausliefert, kann eine Clay-Seite ausliefern.
#Von deiner Dokumentation ins Web
- Schau beim Schreiben zu mit
npx clay dev. - Bau und prüfe mit
npx clay build --strict. Kaputte Links und Tippfehler in den Einstellungen stoppen den Build. - Sieh dir das Ergebnis an mit
npx clay preview, so wie ein Webhoster es ausliefert. - Veröffentliche
publish/public, am besten mit einem Workflow bei jedem Push, siehe GitHub Pages oder andere Hoster.
#Wo hosten
| Hoster | Kosten | Eingerichtet mit |
|---|---|---|
| GitHub Pages | Kostenlos für öffentliche Repositories | Einer Workflow-Datei, siehe Anleitung |
| Netlify, Cloudflare Pages | Kostenlose Tarife | Den Build-Einstellungen des Hosters |
| GitLab Pages | Kostenlos | .gitlab-ci.yml |
| Dein eigener Server | Dein Server | nginx, Caddy oder Docker |
#Bevor du online gehst
Liegt die Seite unter einem Pfad?
Eine Seite unter https://meine-org.github.io/mein-projekt/ braucht baseURL: "/mein-projekt/" in der clay.yaml, sonst brechen Styles und Links. Prüf es mit npx clay preview, das die Seite unter ihrer baseURL ausliefert.
Willst du Links und Daten für Suchmaschinen?
Setz siteURL auf den Ursprung der Seite, etwa https://meine-org.github.io: Seiten bekommen dann kanonische Links, und der Build schreibt eine Sitemap. Siehe SEO.
Holt die CI die ganze Historie?
Clay nimmt das Änderungsdatum jeder Seite aus Git. Die meisten CI-Systeme klonen nur den letzten Commit; checke die ganze Historie aus, um die Daten zu bekommen, siehe Seitendetails.
Tipp
Führ npx clay build --strict vor dem Pushen lokal aus. Es dauert ein paar Sekunden und findet dieselben Probleme wie die CI.