¿Es EmDash un verdadero reemplazo de WordPress?

EmDash ya puede reemplazar a WordPress en sitios centrados en el contenido que necesitan pocos plugins y cuyo equipo se siente cómodo desarrollando con Astro. Sin embargo, todavía no es un reemplazo directo para sitios que dependen de temas PHP, plugins específicos de WordPress o extensiones de pago.

Todos los clientes que han sufrido un ataque a su sitio de WordPress a través de un plugin han preguntado si existe una opción más segura. Cuando EmDash llegó a la versión 1.0 con el lema “sucesor espiritual de WordPress”, muchas agencias volvieron a plantearse esa pregunta.

Este artículo compara EmDash con WordPress en cuatro aspectos: el modelo de seguridad de los plugins, los requisitos de hosting, la migración y lo que se sacrifica.

¿Qué es el CMS EmDash?

EmDash es un CMS de código abierto escrito en TypeScript y construido sobre Astro. Tiene licencia MIT y se ejecuta en Cloudflare o en un servidor Node.js. El anuncio de EmDash 1.0 de Cloudflare lo describe como un CMS estable, gratuito y de código abierto, “listo para impulsar un sitio web en producción”.

Cada rol tiene su propia vía de acceso. Los desarrolladores construyen el sitio en Astro. Los editores trabajan en el panel de administración de EmDash. Los agentes de IA pueden leer y modificar contenido a través de la API, la CLI o el servidor integrado de Model Context Protocol (MCP). Para crear la estructura de un sitio nuevo se usa:

npm create emdash@latest

Cloudflare afirma que migró su propio blog a EmDash en agosto, antes del lanzamiento de la versión 1.0.

¿En qué se diferencia el modelo de plugins de EmDash del de WordPress?

El modelo de plugins es la mayor diferencia entre ambos sistemas. En WordPress, cada plugin se ejecuta en el mismo proceso PHP que el sitio y puede acceder a la base de datos, al sistema de archivos y a la red. Un plugin de EmDash en sandbox empieza aislado y tiene que solicitar cada capacidad que necesite.

Según la publicación de Cloudflare sobre EmDash 1.0, un plugin en sandbox recibe su propio almacenamiento privado y nada más. El contenido del sitio, los medios, los usuarios, los secretos, las variables de entorno, el sistema de archivos y la red le están vedados por defecto. Un plugin solo obtiene acceso a algo más después de declarar esa necesidad y de que el administrador del sitio la apruebe, de forma muy parecida a los permisos de una aplicación móvil. El ejemplo que da Cloudflare es un optimizador de imágenes: solicita permiso para leer y gestionar medios, pero no puede leer el contenido de los usuarios.

El registro de plugins de EmDash es descentralizado. Está construido sobre AT Protocol, y los editores firman y almacenan sus propios registros de paquetes y versiones en su propia cuenta de Atmosphere. Si el catálogo de EmDash oculta una ficha por moderación, el editor sigue siendo propietario del plugin y de su historial de versiones.

Hay una excepción al sandbox. La referencia de configuración indica que el array plugins está destinado a los plugins que comparten el proceso del sitio Astro, y ahí es donde van los plugins nativos. Esos plugins se ejecutan sin aislamiento. Los plugins instalados desde el registro siempre pasan por el sandbox.

¿Conviene alojar EmDash en Cloudflare o en Node.js?

Puedes alojar EmDash en Cloudflare o en Node.js, pero el sandbox funciona de forma distinta en cada caso. Cloudflare tiene un coste y aplica más límites. El runner de Node.js no supone un coste adicional, pero aplica menos.

La documentación del sandbox de plugins detalla estos requisitos. Sin un runner, EmDash omite todos los plugins incluidos en sandboxed: []. Puedes seguir explorando un registro que hayas configurado tú mismo, pero la instalación o actualización de un plugin en sandbox se detiene con un error SANDBOX_NOT_AVAILABLE. El resto del sitio sigue funcionando.

En Node.js, instala el adaptador de Node y el runner del sandbox y, a continuación, apunta la configuración al runner:

npm install @astrojs/node @emdash-cms/sandbox-workerd workerd

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";
import emdash from "emdash/astro";
import { sqlite } from "emdash/db";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
  integrations: [
    emdash({
      database: sqlite({ url: "file:./data/emdash.db" }),
      sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox",
    }),
  ],
});

La documentación de capacidades confirma que el runner de Node.js solo aplica el límite de 30 segundos de tiempo real. Si un sitio establece límites de CPU, memoria o subsolicitudes, el runner registra una advertencia, ya que workerd en modo standalone no puede aplicarlos. En Node.js, un plugin que consume demasiada CPU solo se interrumpe cuando alcanza el límite de tiempo real.

¿Cómo se migra de WordPress a EmDash?

EmDash migra contenido, no código. La documentación de importación de contenido recoge dos formas de importar contenido: un archivo WordPress eXtended RSS (WXR) o una conexión a un sitio que ejecute el plugin EmDash Exporter. WordPress.com no cuenta con una fuente de importación propia, por lo que esos sitios también utilizan una exportación WXR o el EmDash Exporter.

La guía de migración desde WordPress advierte que un exportador anterior a la versión 1.2.0 descarta los comentarios, los menús, el logotipo y el favicon sin avisar. La importación se completa igualmente y no indica que falte nada. Comprueba la versión del exportador antes de empezar. En cuanto a temas y plugins, el README de EmDash indica que las skills para agentes ayudan a portar plugins y temas. Aun con esa ayuda, cuenta con tener que reconstruirlos.

¿En qué sigue ganando WordPress?

WordPress conserva cuatro ventajas prácticas. Tiene un ecosistema de temas y plugins mucho más amplio, casi todos los proveedores de hosting lo admiten, los editores ya lo conocen y cuenta con un mercado maduro de plugins de pago. En el lanzamiento de la versión 1.0, Cloudflare indicó que el registro de EmDash solo admitía plugins gratuitos y que los de pago llegarían más adelante.

El hosting es la segunda carencia. WordPress funciona en prácticamente cualquier hosting PHP. El sandbox completo de plugins de EmDash requiere un plan de pago de Cloudflare o un servidor Node.js gestionado por ti.

Los editores suponen el tercer coste. El panel de administración de EmDash les resulta nuevo, así que migrar a un cliente implica volver a formar al personal, no solo trasladar contenido. Si estás valorando varias alternativas a WordPress, la comparativa entre 11ty y WordPress muestra cómo se manifiestan estas concesiones en una opción orientada a sitios estáticos.

Quién debería probar EmDash ya y quién debería esperar

Pruébalo ya si:

• Desarrollas sitios de contenido, como blogs, documentación o páginas de marketing, y tu equipo ya trabaja con Astro.
• El riesgo en la cadena de suministro de plugins es una preocupación real para ti o tus clientes.
• Quieres que los agentes trabajen con el contenido a través de la API, la CLI o el servidor MCP.

Espera si:

• El sitio depende de un plugin concreto de WordPress, de un tema comercial o de funcionalidades al estilo de WooCommerce.
• Necesitas plugins de pago del registro.
• Tu hosting tiene que ser un hosting PHP compartido y económico.

Si vas a desplegar en Cloudflare, echa un vistazo a cf, la nueva CLI de Cloudflare que entró en beta abierta el 28 de septiembre de 2026. Gestiona la configuración y los bindings de Workers mediante un archivo cloudflare.config.ts, mientras que Wrangler sigue encargándose de los proyectos configurados con wrangler.jsonc.

EmDash es un verdadero reemplazo de WordPress para un tipo concreto de sitio: centrado en el contenido, con pocos plugins y desarrollado por un equipo con experiencia en Astro que valora más los plugins en sandbox que el tamaño del ecosistema. Para todo lo demás, merece la pena hacer una prueba piloto, pero aún no está listo para dar el salto. Un buen siguiente paso es pasar por el importador una exportación WXR de un sitio real de un cliente y anotar todo lo que falte.

Preguntas frecuentes

¿Puede EmDash importar un sitio de WordPress solo a partir de su URL?

No. Sin el plugin EmDash Exporter, la URL de un sitio solo permite a EmDash consultar la API REST pública de WordPress. Esa comprobación puede confirmar que el sitio funciona con WordPress y contar sus entradas, páginas y medios públicos, pero no puede importar nada. Para importar, sube un archivo de exportación WXR o instala el EmDash Exporter en el sitio de WordPress y conéctate con una contraseña de aplicación de WordPress, que además permite acceder a contenido que la API REST pública no expone.

¿Qué ocurre con los bloques de Gutenberg y los bloques de plugins al importar a EmDash?

EmDash convierte el marcado de Gutenberg a Portable Text y procesa el HTML del editor clásico con el mismo conversor. Los bloques que WordPress genera en el servidor, como Últimas entradas o muchos bloques de plugins, no almacenan marcado en la entrada. El importador conserva cada uno de ellos como un bloque HTML que solo contiene el comentario original del bloque y que no muestra nada en el sitio, por lo que tendrás que reconstruirlos o eliminarlos. Los bloques reutilizables se convierten en secciones de EmDash.

¿Las entradas en borrador, programadas y privadas de WordPress conservan su estado en EmDash?

Solo las entradas publicadas siguen publicadas. El importador de EmDash asigna el estado publish de WordPress a publicado, mientras que los estados draft, pending, private, future, trash y los desconocidos se convierten en borradores. Por tanto, las entradas programadas y privadas requieren una revisión manual tras la importación. La guía de migración de EmDash también recomienda contar las entradas por estado y confirmar que los borradores permanecen ocultos para los visitantes sin sesión iniciada antes de cambiar el DNS o retirar el sitio de WordPress.

¿Qué bases de datos y backends de almacenamiento admite EmDash?

EmDash utiliza Kysely para SQL y la API de S3 para el almacenamiento, por lo que funciona con SQLite, Cloudflare D1, Turso o libSQL y PostgreSQL para los datos, y con Cloudflare R2, AWS S3, cualquier servicio compatible con S3 o el sistema de archivos local para los medios. En Cloudflare, los plugins en sandbox siguen leyendo y escribiendo a través de un binding de D1 llamado DB, independientemente del adaptador de base de datos que utilice el propio sitio.