Migrar un blog desde Wix hacia un generador de sitios estáticos como Astro o Hugo promete simplicidad y control absoluto sobre el contenido. Sin embargo, cuando se trata de portar tutoriales técnicos —con bloques de código, imágenes, vídeos incrustados y fragmentos de Gist— la realidad es muy distinta. El HTML que sirve Wix no contiene todo lo que el usuario ve en pantalla. Una parte crítica del contenido se hidrata mediante JavaScript en el navegador, y cualquier script que lea únicamente el HTML servidor falla en silencio. Este artículo desvela esa trampa, explica por qué una expresión regular mal construida puede saturar la CPU sin fin, y cómo una empresa como Q2BSTUDIO aplica metodologías robustas para migraciones sin pérdida de datos.
Durante años, muchos desarrolladores y equipos de contenido han confiado en herramientas genéricas de conversión HTML a Markdown. Funcionan bien con páginas sencillas, pero al enfrentarse a la estructura específica de Wix —listas anidadas, etiquetas de énfasis partidas, imágenes que realmente son bloques de figura— el resultado es un Markdown incompleto o directamente erróneo. El verdadero problema no es la conversión, sino la recuperación de lo que no está en el HTML inicial. Wix entrega un esqueleto y, mediante JavaScript, carga el resto: reproductores de YouTube, galerías de imágenes, botones estilizados, comentarios y, sobre todo, los fragmentos de Gist para código. Ninguna herramienta que opere solo sobre el HTML servidor puede recuperarlos. Engañarse pensando que sí es la forma más rápida de publicar tutoriales con agujeros silenciosos.
La solución no pasa por usar inteligencia artificial para 'adivinar' el contenido faltante. Un LLM puede parafrasear tu prosa y, peor aún, eliminar los bloques de código sin previo aviso, destruyendo el valor del tutorial. El enfoque correcto es determinista: extraer el HTML servidor real, aislar el cuerpo del artículo entre los marcadores que Wix utiliza ( y ) y procesarlo con un tokenizador de una sola pasada. Esto permite conservar el orden de los elementos y convertir cada tipo de etiqueta a su equivalente en Markdown sin perder información. El secreto está en capturar primero los bloques de código y las listas (que contienen caracteres arbitrarios) mediante placeholders, y luego aplicar una expresión regular combinada que recorre todo en orden.
Pero aquí aparece la segunda trampa: una expresión regular mal diseñada puede provocar un bucle infinito que satura la CPU. Si la regex incluye una alternativa vacía (por ejemplo, un | seguido de nada), esa alternativa coincide con la cadena vacía en cada posición entre caracteres. Si además se usa un bucle manual que avanza el índice basándose en la longitud del match, un match de longitud cero nunca avanza el puntero, y el bucle se queda atascado en la misma posición, consumiendo el 100% de un núcleo de la CPU sin generar error. Este fallo es especialmente peligroso en artículos con muchas imágenes, donde hay muchos huecos entre etiquetas <figure> que la alternativa vacía puede aprovechar. En Q2BSTUDIO, cuando desarrollamos herramientas de migración o automatización, siempre auditamos las expresiones regulares en busca de alternativas vacías y usamos matchAll en lugar de bucles manuales, porque sabemos que los detalles de implementación marcan la diferencia entre una migración exitosa y una pérdida silenciosa de contenido.
Más allá de la ingeniería de la extracción, hay que lidiar con los 'paper cuts' específicos de Wix: listas anidadas que pierden la indentación, negritas que envuelven espacios en blanco y producen marcadores vacíos, imágenes redimensionadas cuya URL original se puede recuperar eliminando la parte de transformación, y la duplicación de la imagen hero que aparece tanto en el encabezado como en el cuerpo. Cada uno de estos detalles requiere un tratamiento específico. Por ejemplo, para las negritas partidas, es necesario mantener los espacios fuera de los marcadores para que no se genere **** intermedios. Para las imágenes de alta resolución, basta con extraer el identificador de la URL de transformación y solicitar la versión sin escalar desde static.wixstatic.com/media/<id>. Estos ajustes no son complejos, pero ignorarlos produce un Markdown quebrado.
Una vez obtenido el Markdown, el trabajo no termina. Hay una parte del contenido —la que Wix hidrata del lado del cliente— que es irrecuperable por medios automáticos. Por eso es fundamental incluir un linter de control de calidad que revise el Markdown generado en busca de indicios de contenido faltante: imágenes con alt vacío, líneas huérfanas que mencionen 'preferir vídeo' sin el vídeo incrustado, fragmentos de código que parecen introducciones sin bloque posterior, o tablas aplanadas en párrafos cortos. Este linter no rellena los huecos; solo señala dónde debe intervenir un humano, verificando contra la página original en vivo. En el flujo de trabajo de Q2BSTUDIO con inteligencia artificial, aplicamos este mismo principio: la IA ayuda a detectar patrones, pero jamás fabrica contenido que no exista. La transparencia es clave para mantener la credibilidad técnica.
Si el destino final es Astro con MDX, aparecen dos trampas adicionales del compilador: un < sin escapar en el texto se interpreta como el inicio de una etiqueta JSX y rompe la compilación. Esto es muy común en escritura técnica (Array<String>, n <= 1). La solución es envolverlo en un span de código o usar la entidad <. Asimismo, las llaves { y } en el texto alternativo de una imagen se interpretan como expresiones JSX. Un linter con la bandera --mdx puede detectar ambos casos antes de lanzar la construcción. En Q2BSTUDIO integramos estas comprobaciones en nuestros pipelines de CI/CD para garantizar que cada migración pase sin errores de build.
La lección final es clara: una migración exitosa de Wix a Markdown no depende de una herramienta mágica, sino de un proceso disciplinado que combine extracción determinista, manejo cuidadoso de expresiones regulares, linter de calidad y revisión humana. Ignorar el contenido hidratado o confiar en que una IA lo reconstruirá lleva a publicar tutoriales con agujeros invisibles. En el mundo del desarrollo de software a medida, la precisión es un valor irrenunciable. Por eso en Q2BSTUDIO desarrollamos aplicaciones a medida con estándares de calidad que evitan estos problemas desde el diseño. Ya sea migrando contenido, desplegando infraestructura en la nube (AWS/Azure), implementando agentes de IA para automatización, o fortaleciendo la ciberseguridad de los datos, el principio es el mismo: nunca inventar lo que no existe, solo recuperar lo que realmente está ahí.
