Por qué HTTrack falla con sitios de Framer, Webflow y Wix

HTTrack es un programa realmente bueno. Lleva replicando sitios web desde 1998, es gratuito, y con un sitio construido como se construían en 1998 funciona a la perfección.

Las plataformas no-code modernas no se construyen así. Si has apuntado HTTrack a una URL de Framer, Webflow, Wix o Squarespace y has recibido una carpeta que se ve como una página en blanco, como un muro de texto sin estilos, o con todos los breakpoints apilados a la vez, aquí está el motivo. Y no se arregla cambiando un parámetro.

La versión de una frase

HTTrack guarda el HTML que envió el servidor. Tu navegador muestra el HTML que construyó JavaScript después. En un sitio no-code son dos documentos distintos, y el interesante solo existe en memoria.

Qué hace HTTrack en realidad

HTTrack es un cliente HTTP con un analizador de enlaces. Para cada URL:

1. Pide la URL y guarda el cuerpo de la respuesta
2. Busca atributos href y src en ese cuerpo
3. Encola lo que encuentra y repite

Ese es todo el modelo. Nunca ejecuta una línea de JavaScript, porque no lleva un navegador dentro. No tiene DOM, ni motor de maquetación, ni idea de cómo se ve la página.

Para un sitio estático eso basta: la respuesta del servidor es la página. Para un sitio renderizado con React no se le acerca.

Qué te cuesta, en concreto

Falta el CSS de maquetación

Este es el que produce el "se ven todos los breakpoints a la vez".

Framer envía las variantes responsive como subárboles del DOM separados, ocultos y mostrados por reglas @media que viven dentro de un bloque <script id="__framer__breakpoints"> o de un atributo data-framer-hydrate-v2, en formato JSON, no como CSS. Un navegador ejecuta ese script y las reglas correctas se inyectan. HTTrack copia la etiqueta como texto y ahí se queda.

El resultado es una página donde la versión móvil, la de tablet y la de escritorio se muestran simultáneamente, apiladas. El archivo no está roto: las reglas que ocultarían cuatro de las cinco variantes nunca llegaron a generarse.

Los estilos calculados nunca se resuelven

Framer aplica mucho estilo visual en tiempo de ejecución: colores de fondo, radios de borde, sombras, filtros de fondo, tipografía. Esos valores los calcula el framework mientras hidrata, no vienen escritos en el HTML que manda el servidor.

HTTrack captura el marcado previo a la hidratación, así que esos elementos llegan sin estilo alguno. Obtienes el contenido correcto en más o menos el orden correcto, sin parecerse al sitio.

Falta todo lo que está por debajo del pliegue

Casi todas las plataformas no-code cargan las imágenes de forma diferida, y muchas cargan secciones enteras al hacer scroll. HTTrack no hace scroll, porque no tiene viewport. Las imágenes que esperaban a un IntersectionObserver nunca se piden, así que nunca se descubren y nunca se descargan.

Lo mismo vale para lo que haya detrás de un botón Cargar más, una pestaña o un acordeón. Si hace falta un clic para revelarlo, HTTrack no lo encontrará.

Te llevas la basura de la plataforma

HTTrack copia con fidelidad, incluyendo el distintivo "Made in Webflow", el runtime Thunderbolt de Wix, las balizas de analítica y los scripts de seguimiento que inyectó la plataforma. Te quedas con cada kilobyte de sobrecarga del que querías escapar.

Hay un problema de segundo orden. El runtime de Wix arranca un Worker desde el origen del sitio original. En cuanto alojas la copia en otro sitio, esa petición pasa a ser de origen cruzado y falla con un SecurityError antes de que la página hidrate. El archivo copiado no solo pesa de más: el runtime que quedó dentro lo rompe activamente.

Los enlaces siguen apuntando al dominio antiguo

HTTrack reescribe las URLs que ha descubierto. Todo lo que se construya en JavaScript (enlaces del router, rutas de imagen generadas, cualquier cosa montada con una plantilla de texto) sigue apuntando al dominio del que copiaste. La réplica parece autónoma hasta que haces clic y acabas de vuelta en el sitio original.

Por qué "usa un parámetro mayor" no ayuda

El consejo habitual es --mirror, más profundidad de recursión o un timeout más largo. Nada de eso cambia el resultado, porque la limitación es arquitectónica, no de configuración. Ninguna profundidad hace que un cliente HTTP ejecute React. wget --mirror, curl, Guardar como y las extensiones que vuelcan document.documentElement.outerHTML chocan todas con alguna versión del mismo muro.

Guardar como es lo que más se acerca, porque sí tiene un navegador real detrás, pero captura una sola página, conserva el runtime de la plataforma y no reescribe los enlaces internos para uso local.

Qué hace en su lugar un exportador que renderiza

La alternativa es controlar un navegador de verdad y guardar lo que dibujó. Es el enfoque de NoCodeExport:

1. Cargar la página en un navegador real y esperar a la señal de hidratación de la propia plataforma, en vez de a un temporizador fijo
2. Recorrer toda la altura del viewport, lo que dispara la carga diferida y los IntersectionObserver, y pulsar los controles de Cargar más
3. Esperar a que fuentes, imágenes y vídeo terminen de decodificarse
4. Leer los estilos calculados e incrustarlos en los elementos que los necesitan, para que sobrevivan a la eliminación del runtime
5. Reconstruir el CSS de breakpoints como reglas @media reales, para que solo se muestre una variante a la vez
6. Y entonces serializar el DOM: el que construyó el navegador, no el que mandó el servidor

A partir de ahí es un problema normal de sitio estático: reescribir los enlaces a rutas relativas, quitar rastreadores y distintivos, descargar los recursos y empaquetar el resultado.

Las partes interactivas se tratan aparte. Los sliders, pestañas, acordeones y animaciones de scroll dependen del runtime de la plataforma que se acaba de eliminar, así que se reimplementan en unos pocos kilobytes de JavaScript puro. Por eso una exportación puede prescindir del runtime de Webflow y conservar las pestañas funcionando.

Cuándo HTTrack sigue siendo la herramienta correcta

No ha dejado de ser útil:

• Sitios renderizados en servidor: WordPress sin un maquetador pesado, HTML plano, la mayoría de sitios de documentación. La respuesta del servidor es la página, así que HTTrack se lo lleva todo.
• Rastreos de archivo en los que quieres las respuestas crudas y no una copia funcional.
• Todo lo que necesites ejecutar sin conexión, con scripts y a escala, en sitios que sabes que son estáticos.

Si el sitio se hizo en Framer, Webflow, Wix o Squarespace, es la herramienta equivocada. No por antigua, sino porque resuelve otro problema.

Cómo copiarlo bien, paso a paso

1. Confirma que la página se construye en el navegador. Abre el sitio, haz clic derecho, elige Ver código fuente de la página y busca un titular que veas en pantalla. Si no está en el código fuente, lo puso JavaScript, y HTTrack tampoco lo encontrará.
2. Exporta desde la URL publicada. Pega la URL en vivo en un exportador que renderiza. Carga la página en un navegador real, espera a la hidratación, hace scroll para disparar la carga diferida y serializa el DOM que construyó el navegador.
3. Decide cómo se tratan los recursos. Los recursos descargados van dentro del ZIP, así la copia es autónoma. Los recursos enlazados siguen en el CDN original y necesitan que el sitio de origen siga en línea.
4. Sirve la carpeta y compruébala. No abras index.html con doble clic: los navegadores bloquean los módulos por file://. Ejecuta npx serve en la carpeta y revisa la consola, la pestaña Network en busca de 404 y redimensiona la ventana para confirmar que solo se renderiza un breakpoint. Instrucciones completas aquí.

Pruébalo con tu propio sitio

La forma más rápida de ver la diferencia es lanzar ambos contra la misma URL y abrir cada resultado. Pega tu sitio en el exportador de código web y compáralo con tu réplica de HTTrack.

Si vienes de una plataforma concreta, estos profundizan en qué sobrevive a una exportación y qué no:

• Exportar Webflow a HTML
• Exportar Framer a HTML
• Exportar un sitio Wix a HTML