Decides mover tu blog de WordPress a Hugo, 11ty u Obsidian, haces clic en Herramientas y luego en Exportar — y lo que obtienes es un archivo XML, no Markdown. Aquí es donde se atascan la mayoría de las migraciones. No existe una única ruta: el camino más corto depende de cuántas entradas tengas y de qué herramientas puedas ejecutar. Esta guía compara tres rutas, explica cada una paso a paso y cubre la limpieza final que todas dejan pendiente.
Qué ruta elegir
La decisión va primero.
- Decenas o cientos de entradas, y puedes ejecutar Node.js en tu equipo — Ruta A (wordpress-export-to-markdown)
- Quieres que todo ocurra en el servidor y tienes permisos de administrador para instalar plugins — Ruta B (plugins exportadores)
- Solo unas pocas entradas, sin Node.js, sin permisos para plugins, o contenido que no puedes pegar en un servicio que lo suba a sus servidores — Ruta C (conversión en el navegador, gratis, sin registro, sin subir nada)
La Ruta C es menos una "migración" y más una herramienta de extracción precisa, pero para rescatar unas pocas entradas de un WordPress interno o adelantar un borrador, es el camino más corto.
Por qué el XML exportado todavía no es Markdown
Al ejecutar Herramientas y luego Exportar en el panel de WordPress, descargas un archivo WordPress eXtended RSS (WXR)Se abre en una pestaña nueva: un formato XML que agrupa entradas, páginas, categorías, etiquetas y comentarios. El cuerpo de cada entrada está dentro de ese XML como HTML incrustado. Es decir, la exportación es "HTML dentro de una cáscara XML", y llegar a Markdown requiere dos conversiones.
Además, las entradas escritas con el editor de bloques (Gutenberg) llevan los delimitadores de bloque serializados como comentarios HTML. Como muestra la documentación oficial de arquitectura del editor de bloquesSe abre en una pestaña nueva, un párrafo se guarda así:
<!-- wp:paragraph -->
<p>Bienvenido al mundo de los bloques.</p>
<!-- /wp:paragraph -->
Los shortcodes como [gallery] también permanecen incrustados en el cuerpo. Cómo tratas estas tres capas — la cáscara XML, los comentarios de bloque y los shortcodes — es lo que realmente diferencia las rutas.
Antes de migrar — qué se conserva y qué se pierde
Todas las rutas convierten el cuerpo de la entrada (encabezados, párrafos, listas, enlaces, tablas, bloques de código) a Markdown. Las diferencias están en los metadatos.
- Las fechas de publicación, slugs, categorías y etiquetas viven en el archivo WXR. La Ruta A las escribe en el frontmatter; la Ruta C solo ve el HTML del cuerpo que copiaste, así que el frontmatter lo añades tú
- Los comentarios de los lectores no se convierten en Markdown en ninguna ruta. Si los quieres conservar, planifica por separado el cambio a un servicio de comentarios para sitios estáticos
- Los campos personalizados dependen de la herramienta. Si dependes de campos concretos, haz inventario antes de empezar
Ruta A — conversión masiva con wordpress-export-to-markdown
El estándar de facto es wordpress-export-to-markdownSe abre en una pestaña nueva. Toma el archivo WXR como entrada, escribe cada entrada como un archivo Markdown con frontmatter, y descarga las imágenes referenciadas reescribiendo las referencias (la lista de funciones está en el README del repositorio).
- En el panel, abre Herramientas, luego Exportar, elige "Todo el contenido" y descarga el XML.
- En un equipo con Node.js, ejecuta:
npx wordpress-export-to-markdown
Un asistente interactivo pregunta dónde está el archivo exportado, dónde dejar la salida, cómo organizar carpetas (--post-folders / --date-folders), si prefijar los nombres con fechas (--prefix-date), cómo guardar imágenes (--save-images) y qué campos incluir en el frontmatter (--frontmatter-fields). Cuantas más entradas tengas, más rinde este procesamiento por lotes.
Ruta B — exportar con un plugin
Si prefieres que todo quede en el servidor, existen plugins exportadores como Static Site Exporter (antes Jekyll Exporter)Se abre en una pestaña nueva, que empaquetan tus entradas y páginas como archivos Markdown con frontmatter YAML en un ZIP, listos para Jekyll o Hugo.
Dos advertencias. Instalar un plugin requiere permisos de administrador y, como indica la propia página del plugin, los sitios grandes tienden a agotar el tiempo de espera al exportar desde la interfaz web, por lo que allí se recomienda la ejecución por línea de comandos. En hosting compartido también puedes chocar con los límites de memoria de PHP.
Ruta C — convertir en el navegador, sin instalar nada
Para unas pocas entradas, la conversión en el navegador sin configuración es la ruta más corta. Hay dos formas de obtener la entrada:
- Abre la entrada en el editor de bloques, cambia a la vista "Editor de código" desde el menú de opciones y copia el HTML del cuerpo. Este HTML contiene los comentarios de bloque como
<!-- wp:paragraph --> - Abre la página publicada en un navegador y copia el HTML del artículo con las herramientas de desarrollo. Es HTML renderizado, así que no hay comentarios de bloque — pero vienen elementos envoltorio del tema
Pega lo copiado en HTML a Markdown y ejecuta la conversión.
Por ejemplo, al pegar este HTML copiado de la vista de editor de código:
<!-- wp:heading -->
<h2 class="wp-block-heading">Migrating the archive</h2>
<!-- /wp:heading -->
<!-- wp:image -->
<figure class="wp-block-image size-large"><img src="https://example.com/wp-content/uploads/2024/03/diagram.png" alt="Architecture diagram" class="wp-image-42"/><figcaption class="wp-element-caption">Figure 1: the old stack</figcaption></figure>
<!-- /wp:image -->
la salida es esta:
## Migrating the archive
Figure 1: the old stack
Los comentarios de bloque, las clases wp-block-* y los estilos inline desaparecen; los encabezados y las imágenes pasan a sintaxis Markdown. El texto del figcaption sobrevive como una línea de texto plano bajo la imagen. El código en <pre class="wp-block-code"> se convierte en un bloque de código con vallas, y las tablas en tablas de tuberías. Los shortcodes no son HTML, así que pasan sin convertir — quedan como texto plano escapado, por ejemplo \[gallery ids="12,13,14"\] (ver la sección de limpieza).
La conversión se ejecuta por completo en el JavaScript de tu navegador; nada de lo que pegas se transmite a ningún sitio. Esa diferencia importa cuando las entradas vienen de un WordPress interno o son borradores sin publicar — lo contrario de los SaaS de conversión que suben archivos. Cómo evaluar ese riesgo lo tratamos en ¿son seguros los convertidores en línea?. Para el flujo general de conversión, consulta la guía de HTML a Markdown, y para limpiar HTML pegado desde Word o la web, pegar HTML como Markdown — este artículo se centra en lo específico de WordPress.
Lista de limpieza posterior a la migración
Tomes la ruta que tomes, estos cuatro puntos quedan para el final.
- Limpieza de shortcodes.
[gallery],[caption]y los shortcodes de plugins no se convierten a Markdown. Sus formas varían (con atributos, envolventes), así que buscar[en tus archivos y decidir caso por caso es más seguro que un reemplazo global - Reubicación de imágenes. En la Ruta C, las URLs de imagen siguen apuntando a
wp-content/uploads. Descarga las imágenes a tu nuevo entorno y reescribe las URLs. Los atributossrcsetyloading="lazy"se pierden en la conversión; añade equivalentes en la plataforma destino si los necesitas - Enlaces internos. Reescribe los enlaces que apunten al dominio antiguo o a estructuras de permalink antiguas (como la forma
?p=123) según el esquema de URLs del nuevo sitio - Frontmatter. Añade título, fecha y etiquetas como YAML al inicio de cada archivo. Para las diferencias entre formatos de SSG, consulta frontmatter de Markdown en YAML y JSON
Comparación — cómo elegir entre las tres rutas
| Ruta | Ideal para | Requisitos | Metadatos | Imágenes |
|---|---|---|---|---|
| A: wordpress-export-to-markdownSe abre en una pestaña nueva | Migración masiva de decenas o cientos de entradas | Node.js + exportación WXR | Escritos al frontmatter automáticamente | Descargadas, referencias reescritas |
| B: plugins exportadores | Mantener el trabajo en el servidor | Permisos de administrador (instalar plugins) | Escritos al frontmatter automáticamente | Depende del plugin |
| C: HTML a Markdown | Migración puntual de pocas entradas | Un navegador (gratis, sin registro) | Añadidos a mano | URLs conservadas, reubicación manual |
Preguntas frecuentes
¿Puedo convertir entradas de WordPress a Markdown sin Node.js?
Sí. Si puedes instalar plugins, usa la Ruta B; si no, la Ruta C. Cambia la entrada a la vista de editor de código, copia el HTML y pégalo en HTML a Markdown — sin configurar nada.
¿Los comentarios de bloque de Gutenberg sobreviven a la conversión?
En la conversión de FormatArc, los comentarios HTML como <!-- wp:paragraph --> no aparecen en la salida. Ten en cuenta que estos comentarios solo existen en el HTML copiado desde la vista de editor de código; el HTML copiado de una página publicada nunca los tuvo.
¿Se pueden migrar las imágenes junto con las entradas?
La Ruta A descarga las imágenes referenciadas y reescribe las referencias (según el READMESe abre en una pestaña nueva). La Ruta C solo convierte el marcado — las URLs de imagen siguen apuntando al sitio original. Para pocas entradas, guardar las imágenes a mano y reescribir las URLs es práctico.
¿Es seguro pegar borradores sin publicar o contenido de un WordPress interno en una herramienta externa?
Con las herramientas que envían datos a un servidor, el contenido sale de tus manos en el momento en que lo pegas. FormatArc procesa todo dentro del navegador, así que no hay transmisión alguna. Los criterios para evaluarlo están en ¿son seguros los convertidores en línea?.
¿Las entradas escritas con el editor clásico funcionan con los mismos pasos?
Sí. El cuerpo del editor clásico es HTML plano sin comentarios de bloque, lo que de hecho simplifica la conversión. Las Rutas A, B y C manejan entradas del editor clásico.
Resumen
La migración de WordPress a Markdown se decide por escala y entorno. Para cientos de entradas, wordpress-export-to-markdown; para quedarte en el servidor, un plugin exportador; para unas pocas entradas sin configurar nada — o contenido que no debe subirse a ningún sitio — la conversión en el navegador con HTML a Markdown es el camino más corto. Elijas lo que elijas, trata la limpieza de shortcodes, la reubicación de imágenes, la reescritura de enlaces internos y el frontmatter como parte de la migración, no como un añadido. Si haces el mismo ejercicio con contenido de Notion, exportar Notion a Markdown aplica la misma lógica.