Wie ich diese Website baue

Hier schreibe ich über Design, die Arbeit mit KI, digitale Produkte, Immobilien und das Familienleben in Dubai. Ich brauche eine Website, auf der all das Platz hat: Artikel, Fotos, berufliche Projekte und interaktive Werkzeuge.

Am Anfang stand Framer

Meine erste Website habe ich mit Framer gebaut. Sie ist weiterhin unter nevskii.me erreichbar und dient als mein Portfolio für Produktdesign.

Später habe ich einen separaten Blog auf Ghost Pro eingerichtet. Ich kaufte das Theme Scope von Priority Vision und begann, es anzupassen. Die Arbeit am Theme lief über GitHub und GitHub Actions. Gleichzeitig schrieb ich weiter und sammelte Inhalte. Für Ghost Pro zahlte ich 35 US-Dollar im Monat.

Mit der Zeit bekam die Website ein eigenes Design und eine Änderungshistorie. Beim nächsten Umzug wollte ich das alles erhalten.

Warum ich zu Astro gewechselt bin

Irgendwann entschied ich, dass es einfacher wäre, die Website mit Astro zu bauen. Ich portierte das Design des Themes und arbeitete im Code daran weiter.

Astro setzt Seiten aus Komponenten zusammen und kann fertiges HTML im Voraus erzeugen. Für einen Blog passt das: Artikeltext, Fotos und Navigation können bereits fertig gestaltet im Browser ankommen. Leser müssen nicht warten, bis JavaScript die Seite auf ihrem Gerät aufbaut.

Für den Umzug mussten Artikelvorlagen, Beitragslisten, Galerien, Menüs sowie das helle und das dunkle Theme übertragen werden. Einzelne Seiten können unterschiedliche Layouts haben. Ein Fotoartikel und ein Strom kurzer Notizen müssen nicht gleich aussehen.

Das Erscheinungsbild des Blogs basiert weiterhin auf Scope, seine Vorlagen laufen inzwischen aber in Astro. Framer bleibt ein separates Portfolio und eine der visuellen Referenzen.

Dann kam EmDash

Als die erste Version von EmDash erschien, beschloss ich, sämtliche Inhalte dorthin zu übertragen. An diesem Umzug und an der Weiterentwicklung der Website arbeiten wir bis heute.

EmDash übernimmt die Rolle des CMS, also des Systems zur Verwaltung der Website-Inhalte. Hier arbeite ich an Artikeln, Seiten und ihren Übersetzungen, ändere Bildunterschriften und gemeinsame Oberflächentexte. Die Inhalte haben Entwürfe und veröffentlichte Versionen.

Code und Inhalte sind getrennt. Astro-Komponenten bestimmen, wie ein Artikel oder eine Galerie dargestellt wird. EmDash speichert die Inhalte. Eine Textänderung erfordert daher keine Suche nach dem richtigen Absatz in Vorlagendateien. Eine Änderung der Gestaltung soll auch keine weitere Kopie des Artikels erzeugen.

Wie alles zusammenhängt

Die Website besteht aus einem Editor, einem Build-Prozess und einer öffentlichen Version.

Ich bearbeite die Inhalte im EmDash-Editor. Texte und Veröffentlichungsinformationen werden in der Datenbank Cloudflare D1 gespeichert. Hochgeladene Medien nutzen den Objektspeicher Cloudflare R2: Fotos und andere Dateien liegen getrennt vom Code der Website.

Für eine Veröffentlichung erhält Astro einen Snapshot der veröffentlichten Inhalte und erzeugt daraus die Seiten. Gleichzeitig entstehen Links zu Übersetzungen, die Sitemap und der Suchindex. Entwürfe gelangen nicht in diesen Build.

Die fertige Website läuft auf Cloudflare Workers und wird über die Cloudflare-Infrastruktur ausgeliefert. Eine normale Artikelseite fragt nicht bei jedem Aufruf den Editor oder die Datenbank ab: Ihr HTML ist bereits fertig. Die Suche verwendet den Index derselben veröffentlichten Version.

Ein Inhalt durchläuft diesen Weg:

EmDash → veröffentlichte Version in D1 → Astro-Build → Cloudflare → Leser

Bilder werden gesondert vorbereitet. Die Originale bleiben erhalten, für die Seiten entstehen Varianten in passenden Größen. Sie werden über cdn.nevsky.ae ausgeliefert, damit beispielsweise eine kleine Karte kein Foto in voller Größe laden muss.

Der Build kann bereits geprüfte Seiten und Ressourcen wiederverwenden, wenn sich deren Abhängigkeiten nicht geändert haben. Änderungen an gemeinsamen Komponenten oder an der Seitenstruktur können einen vollständigen Neubau erfordern.

Wo Svelte zum Einsatz kommt

Für komplexere Interaktionen gibt es im Projekt Svelte. Es wird in einzelnen Darstellungsvarianten für die Suche und das Filtern des Beitragsstroms eingesetzt: Suchanfrage oder Kategorie lassen sich ändern, die Ergebnisse aktualisieren und die gewählten Parameter in der Seitenadresse festhalten.

Astro erlaubt es, solche Komponenten einzeln einzubinden. Ein Artikel bleibt eine normale HTML-Seite. Ein interaktiver Block erhält sein eigenes JavaScript dort, wo es gebraucht wird. Svelte wird nicht auf jeder Seite des Hauptblogs geladen.

Menüs, der Theme-Wechsel und andere kleine Elemente können mit gewöhnlichem JavaScript funktionieren. Dafür ist keine eigene Svelte-Komponente nötig.

Ein Inhalt in sieben Sprachen

Die Website unterstützt Russisch, Englisch, Arabisch, Chinesisch, Französisch, Deutsch und Spanisch. Russisch ist die Ausgangssprache der Inhalte.

Ein Artikel wird in EmDash als ein einziges Dokument gespeichert. Er hat eine gemeinsame Abfolge von Blöcken und Bildern. Texte, Überschriften, Bildunterschriften und SEO-Felder besitzen eigene Sprachversionen.

So bleiben die Übersetzungen miteinander verbunden. Wenn ich die Reihenfolge der Fotos ändere, muss ich dieselbe Änderung nicht in sieben getrennten Artikeln von Hand wiederholen. Jede Sprachversion kann trotzdem eine eigene Adresse und einen eigenen Veröffentlichungsstatus haben.

Die Seiten verlinken auf die zugehörigen Übersetzungen und enthalten hreflang-Angaben für Suchmaschinen. Die arabische Version berücksichtigt die Schreibrichtung von rechts nach links. Ist eine Übersetzung veröffentlicht, führt die Sprachauswahl zu dieser Version des gerade geöffneten Inhalts.

Design und Code

Typografie und Struktur von Scope bilden weiterhin die Grundlage der Gestaltung. Gemeinsame Farben, Buttons und andere wiederkehrende Elemente sind im Designsystem beschrieben.

Die primäre Akzentfarbe ist derzeit #46a758. Die Website nutzt lokal ausgelieferte Schriften Geist und Geist Mono, ein helles und ein dunkles Theme sowie Icons von Remix Icon. Die Stile sind in gewöhnlichem CSS geschrieben.

Die Farbpalette und Komponentenbeispiele stehen auf der öffentlichen Seite des Designsystems. Technische Regeln und Tokens sind in design.md beschrieben, damit neue Seiten dieselben Farben, Größen und Button-Zustände verwenden.

Technischer Stack im Oktober 2026

Das Projekt basiert auf Astro 7.3.8 und EmDash 1.2.0. Komplexe interaktive Ansichten nutzen Svelte 5.57.1, die Anwendungssprache ist TypeScript 6.0.3. Die Cloudflare-Anbindung erfolgt über @astrojs/cloudflare 14.3.4. Der EmDash-Editor verwendet React 19.2.4; sein Modus für ganze Texte basiert auf Ghost Koenig und Lexical. Das sind die Versionen der Projektabhängigkeiten vom 19. Oktober 2026.

Jede Schicht hat eine Aufgabe. Astro übernimmt HTML und Vorlagen, EmDash redaktionelle Inhalte und Revisionen, Svelte interaktive Komponenten. Cloudflare Workers führen Servercode aus, D1 speichert redaktionelle Daten und R2 Medien sowie private Build-Pakete. Das Design entsteht mit gewöhnlichem CSS: Variablen, responsive Raster, Komponentenzustände und unterschiedliche Seitenkompositionen.

Warum dieser Stack

Ein großer Teil der Bloginhalte steht bereits vor einer Leseranfrage fest. Überschriften, Artikel, Fotos und Beitragslisten lassen sich vorab erzeugen. Die Hauptseite liefert deshalb statisches HTML über Cloudflare Workers Assets aus. Ihre öffentliche Laufzeitumgebung hat keine D1-Verbindung: Editor und Build benötigen die Datenbank, das Lesen eines Artikels löst keine CMS-Abfragen aus.

Astro ermöglicht zugleich komplexe Oberflächen. In getrennten Ansichten steuern Svelte-Komponenten interaktive Feeds und Anzeigeparameter. Gewöhnliche Artikel brauchen keine Hydration. Suche, Menüs und Darstellungswechsel verwenden eigene kleine Skripte. So kann ich das Werkzeug nach dem Verhalten eines Blocks auswählen und kontrollieren, wie viel JavaScript beim Leser ankommt.

Das redaktionelle Dokument als Datenmodell

Ein Inhalt in EmDash enthält locales, fields, ein gemeinsames blocks-Array und presentation mit Layout-Zuordnungen. Jeder Block besitzt eine stabile ID, gemeinsame Struktur und Medien; Textwerte liegen in Sprachzellen. Eine Galerie hat eine gemeinsame Bildreihenfolge, Bildunterschriften und Alt-Texte werden lokalisiert. Das Verschieben eines Fotos verändert eine Struktur für alle Übersetzungen.

Russisch ist die Ausgangssprache. Im selben Dokument liegen die englische, arabische, chinesische, französische, deutsche und spanische Ausgabe. Jede erhält einen eigenen Pfad und Veröffentlichungsstatus. Änderungen am Original können über sourceHash eine veraltete Übersetzung markieren. Beim Übersetzungsimport werden IDs, Quellhash und Anzahl der Textfragmente geprüft, damit eine Modellantwort den Inhalt nicht umstrukturiert oder ein Bild verliert.

Auch gemeinsame Beschriftungen, Menüs und Einstellungen werden in EmDash verwaltet. Inhalte können auf Felder ihres jeweiligen Eigentümerdokuments verweisen. Die öffentliche Ansicht löst diese Verweise aus veröffentlichten Dokumenten auf. Eine Beschriftung wird dadurch nicht zu sieben unabhängig bearbeitbaren Kopien, und für eine Navigationsänderung muss ich keinen Text in Vorlagen suchen.

Eigene Editor-Plugins

Für dieses Modell habe ich das native Plugin nevsky-multilingual 1.0.0 entwickelt. Es bindet den Editor und Prüfungen für beforeSave, beforePublish und beforeSchedule ein. Das Plugin prüft Dokumentstruktur, Sprachfassungen, Pfade und Pflichtangaben. Übersetzungen werden innerhalb des Inhalts ergänzt. Nach Veröffentlichung oder Rücknahme sendet es ein Signal an das Release-System.

Der Modus für ganze Texte verwendet den Ghost-Koenig-Editor. Daneben bleibt der Blockmodus bestehen; beide bearbeiten dasselbe Dokument. Ein separates Plugin, nevsky-grid 0.1.0, verbindet Inhalt und Layout: Es prüft die Zugehörigkeit einer Komposition zum Inhalt, Blockverweise und die Layout-Revision. Beim Umstellen des Layouts bleibt die redaktionelle Quelle erhalten.

KI hilft bei Texten und Übersetzungen, die Plugins prüfen das Ergebnis vor Speicherung und Veröffentlichung. Ich kann einen Text in einem ChatGPT-Projekt oder Chat vorbereiten, nach unseren Humanizer-Regeln bearbeiten und in einen mehrsprachigen Inhalt übertragen. Der integrierte serverseitige Übersetzungsanbieter ist derzeit nicht eingerichtet; der Arbeitsablauf nutzt vorbereitete und geprüfte Übersetzungen.

Build und Veröffentlichung

Der Build liest ausschließlich native veröffentlichte Revisionen über live_revision_id sowie veröffentlichte Beziehungen zu Kategorien, Tags und Autoren. Entwürfe gelangen nicht in den Export. Vor einem Release werden Quellversion und Fingerprint der veröffentlichten Daten festgehalten. Veröffentlicht jemand während des Builds neue Inhalte oder ändert den Code, stoppt eine erneute Prüfung das überholte Release.

Für wiederholte Builds habe ich eine Abhängigkeitsverfolgung pro Seite entwickelt. Beim Rendern zeichnet der Adapter SQL-Abfragen, Parameter und Ergebnishashes auf. Beim nächsten Release führt er sie auf einem neuen Snapshot aus: Ein verändertes Ergebnis erfordert das Rendern der Seite. Unverändertes HTML lässt sich wiederverwenden. Berücksichtigt werden Feed-Zusammensetzung und Reihenfolge, leere Ergebnisse, Autoren, gemeinsame Felder und verwandte Karten. Änderungen an Code, Abhängigkeiten, Umgebung oder Routenbestand führen zu einem vollständigen Neuaufbau.

Das Ergebnis wird zu einem vollständigen Paket aus HTML, Suchindex, Stilen, Medien und maschinenlesbaren Dateien zusammengesetzt. Nach lokalen Prüfungen wird eine neue Worker-Version hochgeladen. Anschließend werden öffentliche URLs und Release-Metadaten geprüft. Scheitert eine Prüfung, ist die Rückkehr zur vorherigen Version vorgesehen. Quelle und veröffentlichte Daten werden unmittelbar vor dem Upload erneut geprüft.

Cloudflare, Cloud-Builds und Arbeiten im Chat

Editor, D1, R2 und öffentliche Auslieferung laufen bereits auf Cloudflare, der Code liegt in GitHub. Für Cloud-Releases ist ein privater Publisher auf Workers und Durable Objects vorbereitet. Er empfängt EmDash-Ereignisse, bündelt zeitnahe Veröffentlichungen und kann einen geprüften Build über GitHub Actions starten. Den automatischen Start habe ich derzeit ausgeschaltet; Production veröffentliche ich manuell im Terminal mit denselben Prüfungen.

Abgenommene Build-Pakete können in einem privaten R2-Cache mit AES-256-GCM-Verschlüsselung liegen. Ein Paket enthält generierte Ausgabe, Abhängigkeiten und Prüfsummen. Entwürfe, CMS-Datenbank und Geheimnisse sind ausgeschlossen. Vor der Wiederverwendung werden Quelle, Umgebung und Dateiintegrität abgeglichen. Mit einem solchen Paket lässt sich ein Build in einer anderen Umgebung fortsetzen; ein neues Betriebssystem oder eine andere Werkzeugversion braucht zunächst eine eigene vollständige Basis.

Ich verlagere weitere Arbeitsschritte in die Cloud, damit Website-Aufgaben aus einem Projekt oder Chat gestartet werden können, ohne einen dauerhaft eingeschalteten Arbeitsrechner zu benötigen. Textvorbereitung, Codebearbeitung und Veröffentlichung bleiben getrennte Aktionen. Auch eine Dialogoberfläche braucht Entwürfe, Änderungsprüfungen und Veröffentlichungskontrolle.

Technisches SEO im Build

Jede veröffentlichte Sprachfassung hat eine eigene URL, canonical, lang und hreflang-Verweise auf die entsprechenden Übersetzungen. Die Standardsprache erhält x-default. Arabische Seiten bekommen dir="rtl". Titel, Descriptions, Open-Graph- und Twitter-Metadaten stammen aus demselben EmDash-Dokument wie der sichtbare Text.

JSON-LD beschreibt WebSite und den jeweiligen Seitentyp: BlogPosting für Artikel, ProfilePage für Autoren, CollectionPage für Sammlungen und WebPage für gewöhnliche Seiten. Autorenschaft und Datumsangaben stammen aus redaktionellen Daten. Sitemaps sind nach Inhaltstyp aufgeteilt, RSS entsteht aus veröffentlichten Inhalten. Die Build-Prüfungen durchlaufen den gesamten Graphen interner Links, canonical, hreflang und Sitemap-URLs und prüfen mehr als die Existenz einiger Meta-Tags.

Inhalte für LLMs

Aus veröffentlichten Inhalten entstehen automatisch Markdown-Seiten sowie llms.txt und llms-full.txt in sieben Sprachen. Die kurze Datei enthält Profil, Sprachen und Inhaltslinks, die vollständige eine erweiterte Textausgabe. Die maschinenlesbare Version hat dieselbe redaktionelle Quelle wie die Website. Ich pflege keine eigene Biografie für Roboter.

KI-Werkzeuge erhalten Text mit Überschriften, Links und Quell-URLs, den sie ohne Analyse der Seitenoberfläche lesen können. Beim Build eines Releases wird das gesamte zusammengehörige Paket aktualisiert. Hier kommen für mich Redaktion, SEO und KI zusammen: Ein Inhalt braucht eine sorgfältige Darstellung für Menschen, Suchroboter und Modelle.

Medienauslieferung und Änderungsprüfung

Medien werden getrennt vom HTML ausgeliefert. Der Build wählt responsive Bildvarianten, bewahrt Links zu Originalen und prüft abgeleitete Dateien. Bei verlustfreier Optimierung werden, wo sie eingesetzt wird, dekodierte Pixel verglichen. Für die lokalen Schriften Geist und Geist Mono wird die Zeichenabdeckung vorbereitet; fehlende Zeichen nutzen einen System-Fallback. Remix Icon wird über lokale CSS-Masken eingebunden.

Änderungen durchlaufen Typprüfungen, Datenmodell- und Veröffentlichungstests, Builds der Ansichten, Abhängigkeitsaudits und Browserszenarien. Die veröffentlichte Version wird separat geprüft: Ein erfolgreicher lokaler Build beweist noch nicht, dass das richtige HTML, die Schrift und die Übersetzung unter der öffentlichen URL angekommen sind. Jedes Release hält Quellversion, Inhaltsfingerprint und Prüfergebnisse fest.

Wie ich weiter an der Website arbeite

Ich bearbeite Inhalte in EmDash und verwalte den Code auf GitHub. Bei der Arbeit am Code nutze ich KI-Werkzeuge. Änderungen werden durch Builds, Tests und im Browser geprüft. GitHub Actions gehörte schon zur Arbeit am Ghost-Theme. Das heutige Projekt bietet außerdem einen eigenen Veröffentlichungsweg über das Terminal, mit Prüfungen vor dem Upload und nach der Bereitstellung.

Beim Speichern eines Textes entsteht ein Entwurf. Die Veröffentlichung in EmDash und die Bereitstellung einer neuen Version der öffentlichen Website sind getrennte Schritte. Derzeit werden Website-Veröffentlichungen nach den Prüfungen manuell gestartet.

Der Umzug dauert noch an. Veröffentlichungen in sieben Sprachen, eine gemeinsame Inhaltsbibliothek und mehrere Darstellungsvarianten dieser Inhalte funktionieren bereits. Auf dieser Grundlage entwickle ich den Editor, die Gestaltung und die interaktiven Seiten weiter.

Was ich auf dieser Grundlage bauen kann

Ich kann eine solche Website für Autoren, Studios oder Unternehmen gestalten und entwickeln: Inhalte aus einem bisherigen CMS migrieren, URLs erhalten, mehrere Sprachen einrichten und den Editor auf die tatsächliche Inhaltsarbeit abstimmen. Für einen Katalog oder eine komplexe Darstellung lassen sich interaktive Komponenten und eigene Seitenkompositionen ergänzen.

Dabei verbinde ich meine Erfahrung im Produktdesign mit KI-gestützter Entwicklung. Ich kann den gesamten Weg übernehmen: Inhaltsstruktur bestimmen, Oberfläche bauen, redaktionelle Plugins schreiben, Cloud-Auslieferung einrichten und das veröffentlichte Ergebnis prüfen. Wenn Sie eine solche Website brauchen, schreiben Sie mir auf Telegram und zeigen Sie, was Sie veröffentlichen möchten und wie Sie damit arbeiten wollen.