Warum ein Blog aus typisierten Blocken WYSIWYG schlagt

Du schreibst einen Artikel, klickst auf fett, fügst ein Bild ein, veröffentlichst. Drei Monate später willst du genau diesen Inhalt in einem Newsletter und einem RSS-Feed, und da geht das Drama los: `<span style>` aus Word reingerotzt, eine Tabelle, die auf dem Handy zerbricht, ein doppeltes h1, das dein SEO ruiniert. Das Problem ist nicht dein Editor — es ist, dass du freies HTML speicherst statt Daten zu speichern.

Bei Zylior behandeln wir jeden Artikel als eine Liste validierter typisierter Blöcke, nicht als HTML-Suppe. Das ändert alles: ein einziger Inhalt rendert als Webseite, als E-Mail und als reinen Text, ohne je zu zerbrechen. Hier ist, warum dieses Modell WYSIWYG schlägt, mit den technischen Details.

WYSIWYG speichert HTML, und HTML driftet

Ein WYSIWYG-Editor erzeugt einen HTML-String, den du in die Datenbank legst. Der Haken: dieser String ist unbeschränkt. Nichts hält ein verwaistes `<div>` auf, ein aus Word eingefügtes `style="font-family:Calibri"`, ein `<h1>` mitten im Body oder ein nie geschlossenes Tag. Du siehst es im Editor nicht — er "korrigiert" es stillschweigend bei der Anzeige — aber an dem Tag, an dem du dieses HTML aus seinem Kontext ziehst (E-Mail, Mobile-App, API), zerbricht es.

• Parasitäre Inline-Styles: ein Copy-Paste aus Word/Notion injiziert `mso-*`, hartcodierte Farben, `<o:p>`. Dein Theme kontrolliert nichts mehr.
• Ungültige Struktur: dupliziertes `<h1>`, `<h3>` ohne `<h2>`-Eltern → Hierarchie kaputt für SEO und Screenreader.
• HTML, das die E-Mail nicht überlebt: Gmail strippt die Hälfte deiner Tags, dein `<figure>` wird unlesbar.
• Keine Garantie fürs Re-Rendering: dasselbe HTML, von zwei Engines gerendert (Web vs. Mail-Client), ergibt zwei verschiedene Ergebnisse.

Ein Artikel = validierte Daten, kein Markup

Die Alternative: du speicherst nie HTML, sondern ein Array typisierter Blöcke, jeder mit einer bekannten, beim Schreiben validierten Form. Ein Absatz ist `{type:"p", text}`; eine Abschnittsüberschrift `{type:"h2", text}`. Inline ist auf eine Whitelist beschränkt (`fett`, `kursiv`, https-Links). Alles, was nicht ins Schema passt, wird beim Speichern abgelehnt, nicht "bei der Anzeige toleriert".

{
  "meta_title": "Blocs typés > WYSIWYG",
  "blocks": [
    { "type": "p", "text": "Accroche en **gras** et [un lien](https://zylior.com)." },
    { "type": "h2", "text": "Une section" },
    { "type": "list", "ordered": false, "items": ["Item 1", "Item 2"] },
    { "type": "callout", "tone": "tip", "text": "Un encadré." }
  ]
}

Ab da validierst du mit einem Schema (Zod, JSON Schema, egal): `type` im Enum, `text` auf N Zeichen begrenzt, `items` ein Array von Strings, `tone` in `{info,warn,tip}`. Ein ungültiger Artikel kann nicht gespeichert werden. Du verschiebst die Strenge von der Anzeige zum Schreiben — dorthin, wo ein Fehler eine Fehlermeldung kostet, nicht eine kaputte Seite in Produktion.

Ein Inhalt, drei garantierte Renderings

Das ist der echte operative Gewinn für einen Solo-Founder. Weil ein Block semantische Daten ist ("das ist eine Überschrift", "das ist eine Liste") und kein Markup, schreibst du einen Renderer pro Ziel und jeder Block weiß, sich überall zu rendern:

1. Web: `h2` → `<h2 class="...">` mit deinem Design-System, `code` → Syntax-Highlighting.
2. E-Mail: dasselbe `h2` → inline-gestylte HTML-Tabelle, kompatibel mit Gmail/Outlook; die verbotenen Typen können gar nicht erst ankommen.
3. Reiner Text / RSS / LLM: `h2` → `## Titel`, `list` → Markdown-Aufzählung. Perfekt, um einen Artikel für einen Agenten zusammenzufassen oder einen Digest zu speisen.
4. JSON-LD: du leitest automatisch `articleBody`, `headline`, `wordCount` aus den Blöcken ab, ohne HTML zu parsen.

Vorschau = veroffentlicht, und SEO wirklich im Griff

Mit freiem HTML nutzt deine Vorschau oft eine andere Render-Engine als die Produktion (der Editor vs. die Seite): was du siehst, ist nicht das, was rausgeht. Mit typisierten Blöcken ruft die Vorschau exakt denselben Web-Renderer auf wie die Veröffentlichung. Null Überraschung: wenn die Vorschau gut ist, ist das Veröffentlichte identisch. Auf der SEO-Seite kontrollierst du, weil die Struktur garantiert ist, was WYSIWYG driften lässt: ein einziges `h1` (aus `meta_title`, nie im Body), eine konsistente `h2`/`h3`-Hierarchie, eine `meta description` auf 140-160 Zeichen begrenzt, ein sauberes `canonical` und ein `JSON-LD` vom Typ `Article`, mechanisch aus den Blöcken abgeleitet. Dein Markup ist gültig per Konstruktion, nicht per Hoffnung.

Ehrlich gesagt ist das nicht umsonst: du pflegst deine Renderer und der Editor ist stärker eingeschränkt als ein "alles erlaubt"-WYSIWYG (kein magisches Word-Einfügen). Für einen SaaS-Portfolio-Blog, bei dem du Zuverlässigkeit und Multi-Channel willst, ist das der richtige Kompromiss. Konkret zum Loslegen: definiere ein Enum von Typen (`p`, `h2`, `h3`, `list`, `code`, `callout`, `quote`), schreibe ein Schema, das alles andere ablehnt, häng einen Web-Renderer und einen Text-Renderer dran (die E-Mail kommt später), und lass deine Vorschau auf den Prod-Web-Renderer zeigen. Du hast dann einen Blog, bei dem die Vorschau nie lügt, bei dem derselbe Artikel ohne Nacharbeit in den Newsletter geht und bei dem dein SEO standardmäßig korrekt ist — nicht durch manuelle Wachsamkeit.