WordPress sigue siendo el CMS más extendido del mundo, pero el lanzamiento de EmDash por parte de Cloudflare ha abierto una conversación seria sobre qué viene después. Cloudflare lo presenta como un “sucesor espiritual” de WordPress: escrito en TypeScript, construido sobre Astro, con plugins aislados, licencia MIT y despliegue pensado para arquitectura serverless, aunque también puede ejecutarse en cualquier servidor Node.js. Al mismo tiempo, la propia compañía deja claro que EmDash está en versión 0.1.0 preview, es decir, en una fase temprana que invita a probar, no a migrar a ciegas un proyecto crítico sin planificación.
Por eso, migrar un WordPress a EmDash no debería plantearse como una simple exportación, sino como una transición técnica con varias capas: contenido, medios, URLs, SEO, frontend, plugins y validación posterior. La buena noticia es que Cloudflare sí ha previsto una ruta de entrada desde WordPress. La mala, si se quiere llamar así, es que esa ruta no elimina el trabajo de reconstrucción donde más suele doler: temas, shortcodes, lógica PHP y funciones que dependían del ecosistema clásico de plugins.
1. Auditoría previa: qué se está migrando realmente
Antes de exportar nada, conviene hacer un inventario completo del sitio. Hay que saber cuántas entradas, páginas y tipos de contenido personalizados existen, qué plugins afectan directamente al contenido y qué parte del sitio depende de comportamiento dinámico en PHP. WordPress ofrece exportación WXR para contenido y WP-CLI dispone de comandos para exportar base de datos y trabajar con contenido, pero eso no equivale a una migración funcional completa del sitio. La propia documentación de WordPress distingue claramente entre mover un sitio completo y exportar contenido para importarlo en otro entorno.
En esta fase también conviene anotar la estructura de URLs actual, revisar taxonomías, detectar imágenes enlazadas desde fuera de la librería y localizar shortcodes o bloques muy personalizados. Cuanto más se parezca el sitio a un blog o medio clásico, más sencilla será la transición. Cuanto más dependa de WooCommerce, builders visuales, campos personalizados complejos o lógica de plugins, más habrá que rediseñar. Esta no es una limitación accidental: EmDash propone otra arquitectura y ahí está, precisamente, parte de su valor.
2. Elegir método de importación: WXR o EmDash Exporter
Cloudflare ha descrito dos caminos oficiales para importar contenido desde WordPress. El primero es el más tradicional: exportar un archivo WXR desde el panel de WordPress y usarlo como base de la importación. El segundo consiste en instalar el EmDash Exporter plugin, que crea un endpoint seguro visible solo para el propietario del sitio y protegido con una WordPress Application Password controlada por el usuario. Cloudflare afirma que ambos métodos permiten traer contenido y medios adjuntos a la librería de EmDash.
La elección depende sobre todo del tamaño del proyecto y del ritmo de la migración. El WXR resulta lógico para pruebas, blogs pequeños y migraciones puntuales. El Exporter encaja mejor cuando interesa repetir sincronizaciones durante varios días antes del corte definitivo o cuando el volumen de contenido hace más cómoda una extracción directa. Lo importante aquí es no asumir que la importación resuelve todo: trae contenido, pero no convierte automáticamente un tema de WordPress en un proyecto listo para producción en EmDash.
3. Exportación con WXR: útil, pero con límites claros
El formato WXR de WordPress existe desde hace años para mover contenido entre instalaciones. La documentación de WordPress y WP-CLI lo describen como un mecanismo de exportación de entradas, páginas, autores, términos, comentarios y adjuntos referenciados. Eso es útil, pero conviene entender bien su alcance: no sustituye una copia completa de la instalación ni empaqueta por sí solo la configuración del tema, plugins o lógica personalizada.
En un proyecto real, lo sensato es usar WXR para llevarse la base editorial y taxonómica, y después tratar el resto como piezas separadas. Si además hay cambio de dominio o de estructura de rutas, WordPress recomienda prestar mucha atención a las referencias antiguas, a los problemas de serialización y a las redirecciones. Eso sigue siendo válido también aquí, aunque el destino sea EmDash y no otra instalación WordPress.
4. Exportación con plugin: más interesante para migraciones vivas
El método del plugin de exportación es probablemente el más atractivo para una migración moderna, porque evita el archivo intermedio y se apoya en las Application Passwords de WordPress, que son credenciales revocables y pensadas para acceso programático. WordPress las define como contraseñas por aplicación para integraciones, scripts o herramientas externas, separadas de la contraseña principal del usuario. Eso permite dar acceso a la extracción sin compartir la credencial general de administración.
Aquí la recomendación práctica es clara: crear una contraseña de aplicación específica para la migración, usarla solo durante ese proceso y revocarla al terminar. Si el proyecto pasa varios días sincronizando contenido antes del corte final, ese detalle importa mucho más de lo que parece. No es solo una cuestión de comodidad, sino también de higiene operativa.
5. Tipos de contenido personalizados: el punto donde empieza el trabajo serio
Cloudflare destaca una de las diferencias clave entre WordPress y EmDash en la gestión del contenido estructurado. Mientras WordPress suele resolver tipos de contenido avanzados mediante custom post types y plugins como ACF sobre la misma tabla de entradas, EmDash permite definir schemas directamente en el panel y crear colecciones separadas en la base de datos. Además, la compañía afirma que en la importación se pueden mapear esos tipos personalizados y convertirlos en colecciones nativas de EmDash.
Ese punto cambia bastante la lógica de la migración. No se trata solo de traer el contenido, sino de decidir cómo se va a modelar en el nuevo sistema. Un portfolio, una ficha de producto editorial, un directorio o una base documental pueden vivir mucho mejor en EmDash si se rediseñan bien los campos desde el principio. La tentación de copiar sin repensar suele salir cara después.
6. Medios, adjuntos e imágenes: qué revisar antes del corte
Cloudflare asegura que la importación desde WordPress trae automáticamente los medios adjuntos a la librería de EmDash. Eso simplifica mucho la transición, pero no cubre todos los casos. Si el sitio arrastra imágenes hotlinked, URLs absolutas reescritas por CDN o dependencias raras en wp-content/uploads, habrá que revisar el contenido y corregirlo. WordPress, además, genera múltiples tamaños derivados por imagen, mientras que el frontend basado en Astro gestiona la optimización de forma diferente. Por eso lo importante no es copiar todas las miniaturas heredadas, sino garantizar que los originales correctos estén disponibles y que las páginas no dependan de rutas obsoletas.
7. Mantener las URLs y el SEO: la parte que no conviene improvisar
Preservar la estructura de enlaces debería ser una prioridad absoluta. Cloudflare explica que EmDash usa el enrutado basado en archivos de Astro, así que la correspondencia entre URLs antiguas y nuevas pasa por cómo se construyan esas rutas en el frontend. Si la estructura puede mantenerse, mejor. Si no, habrá que preparar redirecciones 301 antes del cambio de DNS y revisar sitemap, Search Console y errores 404 después del lanzamiento.
WordPress ya advierte en su documentación que los cambios de dominio o de URLs requieren tratamiento específico para evitar enlaces rotos y referencias antiguas. En una migración a EmDash, esa cautela sigue siendo válida: no basta con mover contenido, hay que proteger la continuidad de indexación y autoridad del sitio.
8. Temas: no se migran, se rehacen
Este es probablemente el punto que más conviene decir sin rodeos: un tema de WordPress no se porta directamente a EmDash. Cloudflare habla de usar Agent Skills para ayudar a reconstruir bloques y componentes, y menciona incluso la posibilidad de portar temas legacy con ayuda del agente. Pero eso no significa reutilizar PHP ni copiar plantillas del tema tal cual. Significa rehacer el frontend como proyecto Astro, con nuevos layouts, componentes y estilos.
La consecuencia práctica es sencilla: si el contenido es la mitad de la migración, el frontend es la otra mitad. En proyectos pequeños puede ser relativamente rápido. En medios con plantillas complejas, módulos publicitarios, widgets, lógicas condicionales o maquetación muy personalizada, será la parte que más tiempo consuma.
9. Plugins: hay que pensar en equivalencias, no en trasplantes
Cloudflare construye buena parte del mensaje de EmDash sobre la seguridad de sus plugins, que funcionan en sandbox con permisos declarativos. Eso resuelve uno de los grandes problemas históricos de WordPress, pero rompe la compatibilidad con el modelo PHP clásico. En la práctica, ningún plugin de WordPress se migra tal cual. Hay que sustituirlo por una función nativa, una integración nueva o un plugin reescrito para EmDash.
Aquí conviene clasificar lo que existía en WordPress en tres grupos: lo que ya no hace falta, lo que tiene sustituto claro y lo que habrá que reconstruir. Formularios, SEO, bloques de contenido y analítica suelen ser más fáciles de cubrir. WooCommerce, shortcodes avanzados, builders visuales y plugins que dependían de tablas propias exigen una estrategia específica.
10. Corte a producción y verificación posterior
El lanzamiento no debería hacerse en seco. Lo recomendable es mantener WordPress operativo mientras se prueba EmDash en paralelo, ejecutar una última sincronización de contenido, revisar páginas clave, validar imágenes, formularios, sitemap, metadatos y analítica, y solo entonces cambiar DNS. Cloudflare no habla de una migración instantánea de producción, sino de una experiencia de importación rápida; ese matiz importa. La importación puede durar minutos, pero una migración bien hecha no.
Después del corte toca verificar con calma: páginas representativas, tipos de contenido, renders de imágenes, Core Web Vitals, errores de rastreo y redirecciones. También conviene dejar WordPress accesible durante un tiempo prudente como respaldo o al menos conservar un backup completo. WordPress, además, recuerda en su documentación de seguridad que el orden típico de copia es base de datos primero y archivos después, algo muy sensato también aquí antes de tocar producción.
11. Errores frecuentes que conviene evitar
El primero es creer que el problema se resuelve exportando contenido. El segundo, subestimar la dependencia del tema y de los plugins. El tercero, olvidar las URLs históricas. Y el cuarto, tratar una preview como si fuera un producto completamente maduro. EmDash puede ser una base muy prometedora para medios, blogs, documentación o proyectos editoriales modernos, pero una migración responsable exige tratarlo como lo que hoy es: una tecnología joven con una ruta de importación interesante, no un sustituto mágico e inmediato de cualquier WordPress complejo.
Preguntas frecuentes
¿Qué método conviene más para migrar WordPress a EmDash?
Para pruebas o sitios pequeños, el WXR es una vía razonable. Para migraciones más vivas o con varias sincronizaciones antes del corte, Cloudflare propone el EmDash Exporter plugin protegido con Application Password.
¿Los temas de WordPress se pueden reutilizar en EmDash?
No directamente. El contenido sí puede importarse, pero el tema hay que reconstruirlo como frontend en Astro, aunque Cloudflare plantea ayudas con Agent Skills para facilitar parte del trabajo.
¿EmDash permite traer custom post types?
Cloudflare afirma que sí. EmDash permite definir schemas propios y usar esas capacidades para convertir tipos de contenido personalizados de WordPress en colecciones nativas.
¿Es recomendable migrar ya un sitio crítico a EmDash?
Solo con planificación y bastante prudencia. Cloudflare lo presenta como v0.1.0 preview, por lo que una migración seria debería hacerse con staging, validación paralela y un plan claro de reversión.
Referencias: lushbinary y emDash
