Publicar un artículo debería consistir en escribir, revisar y darle a publicar. Cuando también exige reajustar columnas, corregir estilos en móvil o pedir un despliegue, el sistema editorial está dejando trabajo pendiente a quien escribe.
Combinamos Astro con EmDash para resolver ese problema en webs con diseño a medida: que el equipo pueda gestionar el contenido y que cada publicación respete la web que hemos diseñado. Este blog usa esa combinación. La decisión tiene ventajas concretas y también costes que conviene conocer antes de abandonar WordPress.
El CMS debe permitir editar contenido y conservar las reglas de diseño
Un CMS es un gestor de contenidos: el lugar donde guardas artículos, imágenes y otros datos que después aparecen en una web. El editor y la página pública pueden compartir una aplicación, aunque tengan responsabilidades distintas.
Pensemos en una ficha de proyecto. Quien la publica necesita cambiar el título, la descripción, las fotografías y sus créditos. La tipografía, el ancho de lectura y la composición de la galería deberían seguir las reglas del sitio.
Si cada ficha se monta arrastrando bloques desde cero, la consistencia depende de que todos recuerden esas reglas. Si todo vive en archivos del repositorio, cada corrección puede acabar en la cola de desarrollo. Ambos enfoques tienen usos, pero para una web editorial buscamos otro reparto del trabajo.
Definir qué se puede editar forma parte del diseño. Un título largo, una fotografía vertical y un artículo con una tabla son casos que la plantilla debe resolver. Restringir opciones sin probar esos casos tampoco produce una buena experiencia.
Ese reparto se puede construir con WordPress, un CMS separado o EmDash. Lo que evaluamos es cuánto trabajo requiere mantenerlo en cada proyecto.
Qué aporta Astro: HTML y JavaScript donde hace falta
Astro es el framework con el que construimos las páginas, los componentes y los estilos. Los componentes Astro producen HTML sin añadir un runtime propio al navegador. Cuando una parte necesita interactividad, podemos activar una isla de JavaScript para esa parte, como una galería o un buscador. Es la base de su arquitectura de islas.
Para una web de servicios o un blog, eso nos da una forma de decidir qué código necesita recibir el visitante. Una página de lectura tiene necesidades diferentes de las del editor donde se escribe.
Astro también permite renderizar páginas bajo demanda. Una página puede generar su HTML durante la compilación o hacerlo en el servidor al recibir una petición. La elección depende de cuándo cambian sus datos y de cómo queremos publicarlos.
Por eso, «hecho con Astro» no significa necesariamente «todo estático». Tampoco garantiza una puntuación de rendimiento: imágenes, fuentes, scripts de terceros, consultas y caché siguen contando. Nos interesa controlar esas decisiones, y después medir el resultado de cada web.
Qué es EmDash y por qué se presenta como sucesor de WordPress
EmDash es un CMS de código abierto construido en TypeScript sobre Astro. Cloudflare lo presentó como el «sucesor espiritual de WordPress» y publicó su versión estable 1.0 el 28 de septiembre de 2026. La expresión describe la ambición del proyecto; no demuestra que pueda sustituir cualquier instalación de WordPress. Así lo sitúa el anuncio de EmDash 1.0.
Para entender su propuesta, conviene empezar por los datos. EmDash organiza el contenido en colecciones y campos. Un artículo puede tener título, extracto, cuerpo e imagen de portada; una ficha de proyecto necesitará otros campos. El panel genera los formularios de edición a partir de ese modelo de contenido.
El texto enriquecido se almacena como Portable Text, una estructura de bloques, en lugar de depender de la maquetación de una página concreta. El proyecto documenta ese formato y sus funciones editoriales en su repositorio.
Aquí sigue habiendo trabajo de desarrollo: hay que decidir qué bloques se admiten y cómo se muestran. Nos parece una responsabilidad razonable para una web a medida. El equipo editorial puede concentrarse en lo que publica, mientras las plantillas se ocupan de presentarlo.
Cómo combinamos Astro y EmDash en el blog de Neca
En este blog, la colección de artículos tiene cuatro campos de contenido: título, portada, extracto y cuerpo. Las páginas Astro deciden cómo se presentan, junto con los datos editoriales y el SEO del artículo.
El panel de EmDash y la web pública forman parte de una aplicación desplegada en Cloudflare Workers. El contenido se guarda en D1 y los archivos en R2. Las páginas consultan el contenido a través de EmDash y producen el HTML que recibe el navegador.
Flujo simplificado del blog: edición en EmDash, datos en D1, archivos en R2 y páginas renderizadas por Astro.
Las rutas del blog se renderizan en el servidor. Publicar un cambio de contenido no requiere reconstruir el sitio completo. Un cambio en las plantillas o en el código sí requiere un despliegue. Este reparto coincide con la arquitectura documentada de EmDash, que integra el CMS dentro de la aplicación Astro.
También hay una separación editorial importante: guardar cambios crea un borrador y conserva la revisión que ven los visitantes. Publicar promueve ese borrador a versión pública. El panel, la API y las herramientas para agentes siguen el mismo ciclo de publicación.
Así podemos revisar una reescritura completa sin sustituir el artículo publicado mientras trabajamos en ella.
WordPress, CMS separado o EmDash: qué trabajo asume cada opción
WordPress sigue siendo una opción sólida cuando el equipo domina su editor o cuando el negocio depende de extensiones que ya resuelven sus procesos. Cambiar un sistema conocido tiene un coste, incluso si la nueva tecnología nos gusta más.
Tampoco sería correcto describir WordPress como lento por definición. Su documentación explica cómo usar caché de páginas y objetos para reducir el trabajo del servidor. Una instalación bien resuelta puede servir contenido con buen rendimiento. La comparación útil exige revisar la web real, como recoge su guía de optimización.
Un CMS separado, a menudo llamado headless, permite que distintas webs o aplicaciones consuman el mismo contenido. Puede encajar cuando una organización necesita varios canales o un servicio editorial gestionado por un proveedor. A cambio, hay que resolver la integración, la vista previa, los permisos y el coste del servicio según el producto elegido.
EmDash nos interesa cuando queremos desarrollar con Astro y mantener el CMS dentro de la misma aplicación. Eso concentra el despliegue, pero también concentra nuestra responsabilidad sobre sus actualizaciones, datos y funcionamiento.
Situación del proyecto | Opción que merece evaluarse primero |
|---|---|
El equipo trabaja bien con WordPress y depende de plugins concretos | Mantener y mejorar WordPress |
Varias aplicaciones necesitan compartir contenido y un servicio editorial independiente | Un CMS headless |
Una web a medida con Astro necesita edición frecuente y un panel integrado | Astro con EmDash |
El contenido apenas cambia y lo mantiene un equipo técnico | Astro con archivos de contenido puede bastar |
La contrapartida de nuestras plantillas es deliberada: permiten editar lo que hemos previsto. Una nueva composición o función requiere ampliar el sistema. Si necesitas libertad total de maquetación en cada página, debemos resolver esa necesidad antes de elegir el CMS.
Los plugins de EmDash cambian los permisos, no eliminan el mantenimiento
Uno de los cambios técnicos de EmDash es su modelo de plugins aislados. Con el entorno de ejecución correspondiente, estos plugins trabajan en un sandbox y acceden a las capacidades que se les conceden. Los plugins nativos, en cambio, se ejecutan dentro del proceso de la aplicación y no reciben ese aislamiento.
La distinción importa al desplegar. En Cloudflare, el sandbox usa Dynamic Workers y requiere Workers Paid y un binding Worker Loader. En Node.js existe un runner basado en workerd, con diferencias en los límites de recursos que puede imponer. La documentación del sandbox detalla esas condiciones.
Nos interesa poder revisar qué acceso necesita una extensión antes de instalarla. Eso no evita revisar su calidad, mantener el software actualizado ni preparar copias de seguridad. Tampoco convierte una extensión nueva en equivalente a un plugin de WordPress que lleva años resolviendo un proceso del negocio.
EmDash puede ejecutarse fuera de Cloudflare. Aun así, un proyecto construido alrededor de D1, R2 y servicios específicos necesita trabajo para cambiar de proveedor. Conviene presupuestar esa salida si es un requisito.
Gestionar contenido con IA mediante MCP
EmDash incluye un servidor MCP, un protocolo que permite a asistentes compatibles usar herramientas del CMS. Puede dar acceso a contenido, medios y revisiones, sujeto a autenticación, scopes y permisos del usuario. Lo explica su referencia de MCP.
Para nosotros, el uso práctico es trabajar sobre la entrada real: leer un artículo, preparar cambios y guardarlos para revisión. Podemos hacerlo sin copiar manualmente el texto entre un chat y el editor.
La revisión sigue siendo necesaria. Un asistente puede confundir un dato, añadir una promesa que la empresa no hace o generar un texto correcto que no aporta nada. La herramienta facilita la gestión; el criterio editorial decide qué merece publicarse.
Preguntas frecuentes sobre Astro, EmDash y WordPress
¿EmDash sustituye los plugins de WordPress?
Hay que comprobar cada función. Una importación de artículos no traslada automáticamente reservas, pagos, membresías o integraciones de un plugin. Esa dependencia puede justificar mantener WordPress.
¿Necesito programar para publicar en EmDash?
Puedes editar desde el panel los contenidos y campos preparados para tu web. Crear nuevas plantillas, integraciones o comportamientos requiere desarrollo.
¿Astro con EmDash mejora el SEO automáticamente?
La implementación debe resolver metadatos, URLs, indexación y contenido. En nuestro blog, las plantillas incorporan esas piezas. El posicionamiento requiere además contenido útil y seguimiento; no se deduce del nombre del framework.
¿Puedo migrar mi blog de WordPress a EmDash?
EmDash dispone de herramientas de importación. Antes de cambiar el sitio público hay que verificar contenidos, imágenes, enlaces, redirecciones y funciones. Importar los datos no reproduce el tema ni todas las extensiones. La guía de migración desde WordPress explica el proceso.
Prueba el flujo editorial antes de decidir una migración
Elige un artículo representativo de tu web, con imágenes, enlaces y algún bloque que uses de verdad. Reproduce su edición y publicación en el sistema candidato. Comprueba qué puede hacer el equipo por su cuenta y qué necesita desarrollo.
Después, revisa las funciones imprescindibles del sitio actual y calcula el trabajo de trasladarlas. Esa prueba dice más sobre el encaje que una lista de tecnologías.
Si vas a construir con Astro, empieza por la guía de EmDash. Si quieres evaluar tu web con nosotros, contacta con Neca indicando qué publicáis y qué funciones necesitáis conservar. Con esos datos podemos valorar si esta combinación os ahorra trabajo.