Por qué un blog en bloques tipados gana al WYSIWYG

Escribes un artículo, haces clic en negrita, pegas una imagen, publicas. Tres meses después, quieres ese mismo contenido en una newsletter y un feed RSS, y ahí llega el drama: `<span style>` de Word pegados a lo bruto, una tabla que revienta en móvil, un h1 duplicado que destroza tu SEO. El problema no es tu editor: es que guardas HTML libre en lugar de guardar datos.

En Zylior tratamos cada artículo como una lista de bloques tipados validados, no como una sopa HTML. Eso lo cambia todo: un solo contenido se renderiza en página web, en email y en texto plano, sin romperse nunca. Aquí va por qué este modelo gana al WYSIWYG, con el detalle técnico.

El WYSIWYG guarda HTML, y el HTML deriva

Un editor WYSIWYG produce una string HTML que metes en base de datos. El problema: esa string es no controlada. Nada impide un `<div>` huérfano, un `style="font-family:Calibri"` pegado desde Word, un `<h1>` en mitad del cuerpo, o una etiqueta que nunca se cierra. No lo ves en el editor —lo "corrige" en silencio al mostrarlo— pero el día que sacas ese HTML de su contexto (email, app móvil, API), se rompe.

• Estilos inline parásitos: un copia-pega desde Word/Notion inyecta `mso-*`, colores fijos, `<o:p>`. Tu tema ya no controla nada.
• Estructura inválida: `<h1>` duplicado, `<h3>` sin `<h2>` padre → jerarquía rota para el SEO y los lectores de pantalla.
• HTML que no sobrevive al email: Gmail elimina la mitad de tus etiquetas, tu `<figure>` se vuelve ilegible.
• Ninguna garantía de re-render: el mismo HTML renderizado por dos motores (web vs cliente de correo) da dos resultados distintos.

Un artículo = datos validados, no markup

La alternativa: nunca guardas HTML, sino un array de bloques tipados, cada uno con una forma conocida validada en la escritura. Un párrafo es `{type:"p", text}`; un título de sección, `{type:"h2", text}`. El inline se restringe a una whitelist (`negrita`, `cursiva`, enlaces https). Todo lo que no encaja en el esquema se rechaza al guardar, no se "tolera al mostrar".

{
  "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é." }
  ]
}

A partir de ahí, validas con un esquema (Zod, JSON Schema, lo que sea): `type` dentro del enum, `text` limitado a N caracteres, `items` un array de strings, `tone` dentro de `{info,warn,tip}`. Un artículo inválido no puede guardarse. Mueves el rigor de la visualización a la escritura, donde un error cuesta un mensaje de error, no una página rota en producción.

Un solo contenido, tres renders garantizados

Esta es la verdadera ventaja operativa para un solo-founder. Como un bloque son datos semánticos ("esto es un título", "esto es una lista") y no markup, escribes un renderer por destino y cada bloque sabe renderizarse en cualquier sitio:

1. Web: `h2` → `<h2 class="...">` con tu sistema de diseño, `code` → coloreado de sintaxis.
2. Email: el mismo `h2` → tabla HTML con estilos inline compatible con Gmail/Outlook; los tipos prohibidos ni siquiera pueden llegar.
3. Texto plano / RSS / LLM: `h2` → `## Título`, `list` → viñetas markdown. Perfecto para resumir un artículo a un agente o alimentar un digest.
4. JSON-LD: derivas automáticamente `articleBody`, `headline`, `wordCount` desde los bloques, sin parsear HTML.

Vista previa = publicado, y SEO realmente controlado

Con HTML libre, tu vista previa suele usar un motor de render distinto al de producción (el editor vs el sitio): lo que ves no es lo que sale. Con bloques tipados, la vista previa llama exactamente al mismo renderer web que la publicación. Cero sorpresas: si la vista previa está bien, lo publicado es idéntico. En el lado SEO, como la estructura está garantizada, controlas lo que el WYSIWYG deja derivar: un solo `h1` (sacado de `meta_title`, nunca en el cuerpo), una jerarquía `h2`/`h3` coherente, una `meta description` limitada a 140-160 caracteres, un `canonical` limpio, y un `JSON-LD` de tipo `Article` derivado mecánicamente de los bloques. Tu markup es válido por construcción, no por esperanza.

Para ser honestos, no es gratis: mantienes tus renderers y el editor está más restringido que un WYSIWYG de "todo vale" (nada de pegado mágico desde Word). Para un blog de portfolio SaaS donde quieres fiabilidad y multicanal, es el buen compromiso. En concreto, para empezar: define un enum de tipos (`p`, `h2`, `h3`, `list`, `code`, `callout`, `quote`), escribe un esquema que rechace todo lo demás, conecta un renderer web y un renderer de texto (el email viene después), y haz que tu vista previa apunte al renderer web de producción. Tendrás un blog donde la vista previa nunca miente, donde el mismo artículo sale en newsletter sin retoques, y donde tu SEO es correcto por defecto, no por vigilancia manual.