Notion como CMS editorial: edito en Notion y diegomaury.mx se publica solo

Proyecto propio · diegomaury.mx · 2026 · Bilingüe ES/EN

Contexto

Mi sitio personal es una herramienta de decisión: debe permitir que un reclutador, hiring manager o cliente entienda en menos de 2 minutos qué problemas resuelvo, con qué evidencia y por qué soy una apuesta de bajo riesgo. Hasta julio de 2026 era HTML estático editado a mano.

Problema

Cada cambio de texto, imagen o cifra exigía tocar código y hacer un deploy manual. La fricción entre "quiero cambiar esto" y "ya está publicado" tenía un costo real: un sitio desactualizado que subrepresentaba el trabajo. El problema era sistémico: el contenido vivía lejos de donde escribo y decido.

Mi responsabilidad

Era responsable de:

• Arquitectura del sistema y del contrato de datos Notion ↔ Astro.
• Schema editorial de la base SSOT: capas Insignia, Soporte y Archivo, y taxonomía de capacidades.
• Gobernanza de métricas: grados de evidencia, verificador bloqueante y lista negra de cifras retiradas.
• Pipeline de publicación: webhook nativo de Notion, Cloudflare Worker con validación HMAC y build en Cloudflare Pages.
• Redacción, clasificación y evidencia de las 30 fichas publicadas.

No era responsable de:

• Nada delegable: es un proyecto unipersonal. La delimitación real está en las plataformas: Notion (API y webhooks), Astro (build) y Cloudflare (Pages y Worker) son servicios de terceros; todo lo demás, del schema al copy, es construcción propia.

Sistema construido

Diseñé un CMS donde Notion es la única fuente de verdad editorial. El principio rector: el código define cómo se muestra el sitio; Notion define qué contenido se publica.

• Cuatro fuentes en Notion: casos de portafolio, copy del Home y /portfolio, imágenes fijas y métricas oficiales.
• El build de Astro valida cada ficha con Zod. Si una ficha Insignia no tiene métrica ancla y evidencia, el build falla a propósito y el sitio anterior sigue vivo.
• Auto-publish: el webhook nativo de Notion llega a un Cloudflare Worker que valida la firma HMAC-SHA256 y dispara el rebuild. De 90 a 115 segundos después, el cambio está LIVE sin tocar código ni hacer push.
• Métricas gobernadas: cada cifra pública tiene slug inmutable, grado de evidencia y fuente; un verificador bloqueante impide publicar cifras retiradas.
• Imágenes descargadas en build, cacheadas localmente y comprimidas a WebP.

Arquitectura

```

Notion → API de Notion → Astro (validación Zod) → Cloudflare Worker (webhook) → Cloudflare Pages → diegomaury.mx

```

Trade-offs

• Descarté Make.com para el auto-publish a propósito: un Worker propio no consume el budget de operaciones compartido con SOFI y deja la validación de firma en mis manos.
• Preferí un build que se rompe antes que un sitio que miente: la integridad editorial vive en el pipeline, no en la disciplina.

Resultados

30 fichas publicadas con gate completo de calidad (4 Insignia + 24 Soporte), corte agosto 2026.

Evidencia

Lo que falló y qué haría distinto

Un bloque AI de Notion sin convertir a texto rompió unos 40 deploys en un solo día. La automatización amplifica los aciertos y también los descuidos: hoy validaría el contenido en local antes del primer auto-publish, no después. Lo transferible: cualquier organización que ya viva en Notion puede convertir su workspace en el CMS editorial de su sitio con este patrón, sin CMS headless de terceros.