Insights / Technische Beiträge
Eine Astro + Cloudflare Website Schritt für Schritt erweitern
Wie wir Astro und Cloudflare Pages mit AI-Kontaktchat, Sveltia CMS, mehrsprachigem Blog, Service-CTA, sicherem Markdown-Rendering und Kommentaren ohne externen Dienst kombiniert haben.
Inhaltsverzeichnis
Wer mit Astro und Cloudflare Pages startet, braucht oft zuerst nur schnelle und sichere statische Seiten.
Mit der Zeit kommen neue Anforderungen hinzu: Bearbeitung im Browser, lokalisierte Seiten, Führung per AI-Chat, Formular-Kontext aus Service-Seiten und Kommentare.
Dieser Artikel ist ein Implementierungsindex: Er hilft zu entscheiden, in welche Schicht eine Funktion gehört, in welcher Reihenfolge sie ergänzt wird und welcher Detailartikel als Nächstes passt. Das Beispiel stammt von der Acecore-Website, das Muster lässt sich aber auf andere Astro + Cloudflare-Websites übertragen.
Kurzfassung
Die Architektur trennt Zuständigkeiten:
| Schicht | Zuständigkeit |
|---|---|
| Astro | Seiten, Blog, OGP, RSS, Sitemap und UI |
| Cloudflare | Pages, Pages Functions, D1 und Turnstile |
| GitHub | PRs, CMS-Diffs, Übersetzungen, Historie |
| Sveltia CMS | Japanische Quelle, Autoren, Tags, Bilder |
| OpenAI API | Antworten des Kontaktchats |
| Pagefind | Suchindex für geprüftes statisches HTML |
Was statisch sein kann, bleibt statisch. Dynamik wird als kleine API ergänzt.
Kleine APIs auf Cloudflare
AI-Chat und Kommentare folgen demselben Muster.
Astro rendert die UI. Pages Functions bilden die API-Grenze. Secrets, D1 bindings, Turnstile, Origin checks und rate limits bleiben serverseitig.
CMS als Bearbeitungsoberfläche
Sveltia CMS ist keine Runtime-Datenbank. Es erzeugt Git-Änderungen.
Japanische Inhalte, Autoren, Tags, Bilder und JSON-Texte laufen durch PR, Build und Review.
Übersetzung als statischer Inhalt
Lokalisierung ist keine reine Browser-Übersetzung.
Jede Sprache hat eigene URLs, title, description, OGP, JSON-LD, RSS, sitemap und hreflang.
Kontaktwege haben verschiedene Rollen
Der AI-Chat hilft bei der Auswahl. Service-CTAs behalten Kontext. Das Formular erfasst die formelle Anfrage.
AI-Ausgabe ist kein vertrauenswürdiges HTML
Markdown-Links aus der AI werden erst validiert.
Nur Links auf der Allowlist werden als DOM-Elemente gerendert.
Kommentare bleiben in Cloudflare
Die Kommentare nutzen kein externes Widget.
Pages Functions verarbeiten GET/POST, D1 speichert Kommentare und Turnstile schützt Einreichungen.
Nach Ziel lesen
Man muss nicht zuerst alles lesen. Starten Sie mit der Funktion, die Sie ergänzen möchten.
| Ziel | Zuerst lesen |
|---|---|
| Artikel und Bilder im Browser bearbeiten | Sveltia CMS Setup Guide |
| Mehrsprachige Seiten indexierbar veröffentlichen | Mehrsprachigen Blog mit Sveltia CMS betreiben |
| Besucher per AI-Chat führen | Technisches Design für den AI-Kontaktchat |
| Sichere Links in AI-Antworten rendern | Sichere Markdown-Links in AI-Antworten rendern |
| Service-Kontext an das Formular übergeben | Service-CTA-Kontext an das Formular übergeben |
| Kommentare ohne externen Dienst ergänzen | Astro-Blogkommentare nur mit Cloudflare umsetzen |
Implementierungsreihenfolge
Für eine ähnliche Website ist diese Reihenfolge praktikabel:
- Statische Seiten, Blog, RSS, Sitemap und OGP mit Astro stabilisieren.
- Sveltia CMS für die japanische Quelle ergänzen.
- Lokalisierte Seiten als statisches HTML generieren.
- AI-Chat-Führung und Service-CTAs ergänzen.
- Markdown-Links, Formular-Prefill, Origin checks und rate limits absichern.
- Kommentare erst dann innerhalb von Cloudflare ergänzen, wenn sie wirklich gebraucht werden.
Fazit
Astro + Cloudflare kann eine Unternehmenswebsite erweitern, ohne die Vorteile statischer Auslieferung aufzugeben.
Nutzen Sie diese Seite als Einstieg und ergänzen Sie nur die Teile, die Ihre Website wirklich braucht, ohne die statische Grundlage zu schwächen.
Site Architecture
Schichten für wachsende Website-Funktionen
Standardmäßig statisch bleiben und Dynamik nur dort ergänzen, wo sie nötig ist.
Ausliefern
HTML mit Astro generieren und über Cloudflare Pages ausliefern.
Bearbeiten
Japanische Quellen in Sveltia CMS bearbeiten und über PRs prüfen.
Übersetzen
Übersetzungen in PRs auslagern, statt alle Sprachen im CMS zu pflegen.
Leiten
AI-Chat und Service-CTAs führen Besucher zum passenden Formular.
Unterschied zwischen einzeln hinzugefügten Funktionen und einer ganzheitlichen Architektur
Funktionen einzeln hinzufügen
- KI, CMS, Kommentare und Formulare folgen jeweils unterschiedlichen Designprinzipien
- Skripte und Verwaltungsoberflächen externer Dienste nehmen zu und verteilen die Erklärungsverantwortung
- Mehrsprachige URLs, Suchindex und Vorschauumgebung weichen leicht voneinander ab
- Die Beziehung zwischen den Funktionen bleibt unsichtbar und die Einführungsreihenfolge ist schwer festzulegen
Nach Schichten hinzufügen
- Die Rollen von Astro, Cloudflare, GitHub und OpenAI API lassen sich getrennt erklären
- Dynamische APIs werden in Pages Functions gebündelt und Speicher mit D1 näher an Cloudflare gebracht
- CMS-Aktualisierungen, Übersetzungen, Suche, RSS und Sitemap verwenden dieselbe Inhaltsstruktur
- Die Seite lässt sich als Index nach Zweck und Einführungsreihenfolge lesen
Designprüfung für die Übertragung auf andere Websites
- Statisch generierbare Inhalte von API-pflichtigen Funktionen trennen
- CMS als Bearbeitungseinstieg, Übersetzung als PR und Veröffentlichungsentscheidung als Build trennen
- Keine personenbezogenen Daten an die Anfrage-KI senden und nur mit veröffentlichten Informationen führen lassen
- Formularkontext über URL-Parameter übergeben und empfangene Werte als stabile Kategorien führen
- Für Einsendedaten wie Kommentare den physischen D1-Namen und das Binding in der Konfiguration festlegen
- KI-Ausgaben und Nutzereingaben nicht als vertrauenswürdiges HTML behandeln, sondern Allowlisten verwenden
Zugehörige Seiten
- Technisches Design für den AI-KontaktchatAPI-Grenzen und Antwortkontrolle mit Informationen aus der Website.
- Sveltia CMS Setup GuideCMS, GitHub backend, OAuth und PR-basierter Betrieb für statische Websites.
- Mehrsprachigen Blog mit Sveltia CMS betreibenLokalisierte statische Seiten statt reiner UI-Übersetzung veröffentlichen.
- Service-CTA-Kontext an das Formular übergebenDen gelesenen Service in Kategorie und Betreff des Formulars übernehmen.
- Sichere Markdown-Links im AI-Chat rendernNur erlaubte Links rendern und AI-Ausgabe nicht als vertrauenswürdiges HTML behandeln.
- Blog-Kommentare nur mit CloudflareKommentare ohne externen Dienst, mit Pages Functions, D1 und Turnstile.
Häufig gestellte Fragen
Wo sollte man mit der Einführung beginnen?
Festigen Sie zuerst die statischen Astro-Seiten, den Blog, RSS, Sitemap und OGP. Fügen Sie danach CMS und Mehrsprachigkeit hinzu; erst wenn ein Anfrageweg nötig wird, folgen KI-Chat, Service-CTAs und Kommentare.
Sollte alles ausschließlich mit Cloudflare gebaut werden?
Nein. Teile wie die Anfrage-KI verwenden auch die OpenAI API. Entscheidend ist, Auslieferung, API-Grenze, Datenbank und Bot-Schutz bei Cloudflare zu bündeln und bewusst zu trennen, wo externe Dienste eingesetzt werden.
Braucht eine kleine Website all das?
Nicht alles ist von Anfang an nötig. Wenn jedoch CMS, Anfragewege, Mehrsprachigkeit oder Kommentare geplant sind, erleichtert eine frühe Entscheidung über URLs, Speicherort, Vorschauumgebung und Suchindex die spätere Arbeit.